[Frontend] Add --tool-strict-level for server-side control for structural tag activation

[wtdcode]

Purpose

As discussed with @sfeng33 in #54686, this PR adds a server-side control for tool call strictness, achieving the same functionality as sglang SGLANG_TOOL_STRICT_LEVEL.

Test Plan

Unit tests, CI.

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

BEFORE SUBMITTING, PLEASE READ https://docs.vllm.ai/en/latest/contributing (anything written below this line will be removed by GitHub Actions)

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Reviewers with write access and configured trusted contributors can comment /ci run for upstream CI or /amd-ci run for AMD CI only whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use the corresponding /ci run, /ci retry, and /ci cancel commands, or their /amd-ci variants. New commits do not start upstream CI automatically.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀

[mergify]

Documentation preview: https://vllm--56268.org.readthedocs.build/en/56268/

[BugenZhao]

I believe this is something that's really good to have, as we're definitely confusing different level of "strictness" or constraint right now, i.e. tool choices and parameter schema.

Some suggestions:

• I think we can just make it a CLI option instead of an env var?
• Shall we change the fallback value for absent strict from true to false? Otherwise,

Consider level=function and tool_choice=auto, with two tools:

[
  {"name": "weather", "strict": true},
  {"name": "search"}
]

The PR sees weather.strict=true, enables the grammar, and passes both tools through unchanged. The grammar builder then interprets:

Tool	Received strict	Argument constraint
weather	true	Weather’s parameter schema
search	Omitted	Search’s parameter schema, because omitted defaults to schema enforcement

Both tools get schema enforcement.

Now remove "strict": true from weather. With zero explicitly strict tools, the PR’s function branch sets both tools to strict=false, so both get broad argument syntax.

That is the surprising interaction: adding strict=true to one tool also causes another tool with omitted strict to receive schema enforcement.

After the change, the decision tree seems pretty straightforward and reasonable:

flowchart TD
    A["Request"] --> B{"Tools present and<br/>tool_choice ≠ none?"}
    B -- No --> OFF["Tool grammar disabled"]
    B -- Yes --> C{"tool_choice"}

    C -- "required / named" --> ON["Enable tool grammar"]
    C -- auto --> D{"Server strictness level?"}
    D -- "function / parameter" --> ON
    D -- off --> E{"Any tool explicitly<br/>strict = true?"}
    E -- Yes --> ON
    E -- No --> OFF

    ON --> F["Call obligation follows tool_choice:<br/>auto → optional<br/>required → at least one<br/>named → selected function"]

    F --> G{"For EACH tool:<br/>server level = parameter<br/>OR this tool's strict = true?"}
    G -- Yes --> SCHEMA["Enforce declared argument schema"]
    G -- No --> BROAD["Enforce call syntax;<br/>permit broad arguments"]

Loading

• Would you also add support for Rust frontend? It should be straightforward as well since we're also adopting (a ported version of) xgrammar for strict tool calling.

[wtdcode]

@BugenZhao Thanks for the review! I have adopted your suggestsions and rebased to the latest main branch.

[BugenZhao]

LGTM! Thanks @wtdcode

I'm renaming off to auto because off might suggest that the server suppresses the strict value specified by the request, while actually we're deriving the value from the request.

[BugenZhao]

/ci run

[github-actions]

✅ Triggered Buildkite CI #89771 for commit 1150d48577e6.

[github-actions]

✅ @wtdcode, CI is now available for this PR.

• /ci run starts upstream CI; /amd-ci run starts AMD CI only.
• Your branch must contain every commit currently on its upstream target branch. Merge or rebase onto the latest target branch, then rerun the command. Append --allow-stale to a run command to test an outdated branch at your own risk.
• /ci retry retries failed jobs in the CI build for the current PR head. If the current head has no CI build, it starts a new CI build for the current head containing only jobs that failed in the latest earlier CI build for this PR.
• /amd-ci retry retries failed jobs in AMD CI for the current PR head. Use /amd-ci run when the current head has no AMD CI build.
• /ci cancel cancels scheduled or running CI builds for this PR branch; /amd-ci cancel does the same for AMD CI only.