Loading ToolBench
Ward MCP presents 6 tools with mixed quality. Naming is clear and action-oriented (get_*, scan_*). Descriptions are present but variable in quality, some (scan_remote, scan) include helpful context about parameters; others (get_rule_schema, get_supported_languages) are minimal. Input schemas are fully visible for all tools with proper JSON Schema structure and type declarations. However, several critical gaps reduce the score: (1) parameter descriptions are uneven, some fields lack depth or actionable guidance (e.g., 'category' parameter in scan/scan_remote could explain the impact of each option more clearly); (2) output schemas are not documented in the tool descriptions, agents cannot predict what fields to expect; (3) error handling is present in code but not surfaced in tool definitions; (4) the 'config' parameter accepts freeform strings without an enumerated list of valid options, inviting hallucinated values; (5) tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent despite all tools being READ_ONLY operations. Composition is reasonable, tools do single things well, but chaining is not obvious from descriptions.
Parse code and return its Abstract Syntax Tree (AST) in JSON format for deep analysis.
Get the JSON schema for writing custom analysis rules.
List all programming languages supported by the analyzer.
Scan files from the local filesystem for code quality issues.
Scan code content for issues. Use AFTER generating code. Pass code as string, not file path.
Scan code with a custom YAML rule for project-specific patterns or requirements.
Output schemas not documented. Tool descriptions do not explain what fields to expect in responses. Agents cannot plan downstream calls or extract data reliably.
'config' parameter accepts freeform strings without enumeration. Tool description hints at valid values ('p/python', 'p/security-audit') but does not formalize them as an enum. LLMs will hallucinate invalid config strings.
Tool annotations missing. All tools are marked READ_ONLY in the metadata, but neither descriptions nor schema include readOnlyHint. Agents cannot automatically determine safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Minimal descriptions on 'get_rule_schema' and 'get_supported_languages'. At 35 chars each, descriptions lack context for LLM selection (baseline 194 chars average). No explanation of when to use these tools or what they enable downstream.
'category' parameter description in scan/scan_remote is generic. Does not explain trade-offs of each option (e.g., 'security' may miss quality issues, 'all' may timeout on large codebases). LLMs cannot reason about which to choose.
scan vs scan_remote naming could be clearer. 'scan' operates on local files, 'scan_remote' accepts code content directly. Tool names alone do not convey the distinction, description clarifies it, but agents may conflate them.