sansan0/TrendRadar · error · InvalidParameterError
无效的模式: {mode}
Error message
无效的模式: {mode} What it means
Raised by validate_mode when the mode string is not a member of the caller-supplied valid_modes set. This is a membership failure, not a type failure — the value is a str but not one of the allowed mode names. The error message embeds the invalid value and the suggestion lists the supported modes.
Source
Thrown at mcp_server/utils/validators.py:554
Args:
mode: 模式字符串
valid_modes: 有效模式列表
default: 默认模式
Returns:
验证后的模式
Raises:
InvalidParameterError: 模式无效
"""
if mode is None:
return default
if not isinstance(mode, str):
raise InvalidParameterError("mode 必须是字符串类型")
if mode not in valid_modes:
raise InvalidParameterError(
f"无效的模式: {mode}",
suggestion=f"支持的模式: {', '.join(valid_modes)}"
)
return mode
def validate_config_section(section: Optional[str]) -> str:
"""
验证配置节参数
Args:
section: 配置节名称
Returns:
验证后的配置节
Raises:View on GitHub (pinned to 8ee26026ba)
Solutions
- Read the suggestion field in the error: it lists every supported mode; pick one of those.
- Update the MCP server/client to matching versions so the mode list is consistent.
- Check for typos and case sensitivity in the mode string.
- Omit mode to fall back to the default rather than guessing names.
Example fix
# before mode = "aggressive" # not supported # after mode = "deep" # from suggestion: 支持的模式: fast, normal, deep
Defensive patterns
Strategy: validation
Validate before calling
VALID_MODES = {"fast", "normal", "deep"} # sync with tool schema
if mode not in VALID_MODES:
mode = "normal" # or raise locally with a clear message
tool_call(mode=mode) Type guard
def is_known_mode(v, valid_modes: set) -> bool:
return v is None or (isinstance(v, str) and v in valid_modes) Try / catch
try:
tool_call(mode=mode)
except InvalidParameterError as e:
# suggestion lists supported modes; parse or hardcode fallback
mode = "normal"
tool_call(mode=mode) Prevention
- Pin the mode list from the tool's schema and validate before calling.
- After upgrading the MCP server, re-fetch tool schemas — mode sets change between versions.
When it happens
Trigger: Calling a tool with mode="aggressive" when valid_modes={"fast","normal","deep"}; using a mode name from an older/newer version of the API; typos or casing mismatches such as mode="Fast".
Common situations: Version drift: the set of supported modes changed between releases and stale client code sends a removed name. Copy-pasting a mode from docs of a different tool. Locale/case confusion ('Fast' vs 'fast').
Related errors
AI-assisted analysis of sansan0/TrendRadar@8ee26026ba (2026-08-15).
Data as JSON: /api/errors/cd8957125888250e.
Report an issue: GitHub.