vllm-project/vllm · error · ToolParserError

`{name}` only provides a unified parser; the same reasoning

Error message

`{name}` only provides a unified parser; the same reasoning parser and tool parser should be specified together

What it means

ToolParserError::DummyUnifiedParser mirrors the reasoning-side variant: it is returned when trying to build a standalone (split) tool parser from a family that only provides a unified parser. Unified families must be constructed as one combined reasoning+tool parser, never as separate halves.

Source

Thrown at rust/src/parser/src/tool/error.rs:16

// SPDX-License-Identifier: Apache-2.0
// SPDX-FileCopyrightText: Copyright contributors to the vLLM project

use thiserror::Error;
use thiserror_ext::Macro;

/// Result alias for tool parser operations.
pub type Result<T> = std::result::Result<T, ToolParserError>;

/// Errors produced while creating or running tool parsers.
#[derive(Debug, Error, Macro)]
#[thiserror_ext(macro(path = "crate::tool::error"))]
pub enum ToolParserError {
    #[error("tool parser parsing failed: {message}")]
    ParsingFailed { message: String },
    #[error(
        "`{name}` only provides a unified parser; the same reasoning parser and tool parser should be specified together"
    )]
    DummyUnifiedParser { name: String },
}

View on GitHub (pinned to c794754062)

Solutions

Enable both parsers of the same family so the unified parser path is taken
Pick a family with a genuine split tool parser if you need tool parsing alone
Guard programmatic enumeration against unified-only families

Example fix

# before
--tool-parser granite

# after
--reasoning-parser granite --tool-parser granite

Defensive patterns

Strategy: validation

Validate before calling

let unified_only = matches!(name.as_str(), "granite");
if unified_only && reasoning_parser_name != name {
    return Err(anyhow::anyhow!("{name} requires --reasoning-parser {name} too"));
}

Type guard

fn is_dummy_unified_tool(e: &ToolParserError) -> bool {
    matches!(e, ToolParserError::DummyUnifiedParser { .. })
}

Try / catch

match build_tool_parser(name, tokenizer) {
    Err(ToolParserError::DummyUnifiedParser { name }) => {
        eprintln!("{name} is unified-only; set both --reasoning-parser and --tool-parser to {name}");
        std::process::exit(2);
    }
    r => r,
}

Prevention

Configure both parser roles together for unified families
Validate parser pairing at config load, before any request traffic
Keep a registry flag marking unified-only families and check it in tooling

When it happens

Trigger: Calling the tool-parser factory with a unified-only family name — i.e. enabling tool parsing without also enabling the matching reasoning parser from the same family.

Common situations: Configuring --tool-parser granite without --reasoning-parser granite; code iterating over available tool parsers and instantiating each; config migrations from split-parser setups.

Related errors

AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/7598155dc03f1a6a. Report an issue: GitHub.