Loading ToolBench
Native Model Context Protocol (MCP) support for RustAPI - expose your endpoints as tools for LLMs and AI agents
The RustAPI MCP server has critical definition quality gaps. Only 3 tools are present, and while tool names follow verb-noun conventions, schemas and descriptions are severely incomplete. The 'initialize' tool is a protocol handshake (not a real MCP tool), 'tools/list' is a discovery tool (not a domain tool), and only 'tools/call' is a genuine proxy tool. The input schema for 'tools/call' is visible and basic, but lacks validation constraints. Error handling is minimal, no recovery guidance for LLM agents. The server exposes a dynamic OpenAPI-derived tool set, but the MCP layer itself lacks polish. Most critically: (1) no documented output schemas for any tool, (2) no parameter descriptions beyond name/type, (3) no error recovery patterns. This server acts as a thin HTTP proxy wrapper around RustAPI, useful for bridge scenarios but not optimized for agentic patterns.
Perform the initialize handshake. MCP clients call this first. Returns server info + supported capabilities.
Execute a tool call by proxying it as a real HTTP request to the main RustAPI server (using the configured http_base). This is the heart of Native MCP: the call goes through your normal layers, interceptors, extractors, validation, error handling, etc.
Discover and return the list of tools that should be exposed to MCP clients. Tools are derived from the attached OpenAPI spec (from RustApi), filtered according to McpConfig::allowed_tags and allowed_path_prefixes.
initialize and tools/list are protocol/meta tools, not domain tools. They should not be counted as real MCP tools in the tool list. This inflates the server's apparent capability set.
No output schemas documented for any tool. LLMs cannot predict what fields will be returned or plan downstream calls. 'tools/call' is particularly problematic, agents have no idea what the proxy response contains.
Parameter 'arguments' in tools/call is typed as 'object' with no shape. This is underspecified, LLMs cannot validate argument structure without knowing what fields the underlying tool expects. Dynamically proxying OpenAPI tools is architecturally valid, but the MCP interface must document the expected schema or provide validation.
No error handling guidance. If tools/call fails (invalid tool name, upstream error, malformed arguments), there is no recovery hint for the agent. The description does not indicate whether errors are retryable or user-fixable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 24 | - | v1 |
No parameter descriptions. The 'name' parameter in tools/call has a description ('The exact name of the tool to invoke'), but 'arguments' is described only as 'Tool-specific arguments', too vague. What structure? What constraints?
tools/call is marked WRITE but has no confirmation, dry-run, or idempotency guarantee. If an agent calls this 10 times with the same arguments (due to a retry loop), what happens? Without idempotency documentation, the agent cannot safely retry on ambiguous failures.
The dynamically generated tool set (from OpenAPI spec) is not directly visible in the MCP server code. This is a pattern violation: tool definitions should be statically declared or explicitly registered with full metadata (name, description, input schema, output schema) at server startup. Inferring tools from a config file and an external OpenAPI spec is architecturally fragile and makes validation impossible.