Loading ToolBench
Minimal feasibility prototype MCP server for German Foreign Office travel advisories.
Travel Advisory MCP is a functional CRUD wrapper around the German Foreign Office API with three well-named, READ_ONLY tools. All three tools are explicitly defined with names, descriptions, and input schemas visible in src/main.rs. Naming follows verb_noun convention (ping, list_warnings, get_warning). Descriptions are present but minimal (10-72 chars, well below the 194-char baseline for A+ tools). Schemas are properly typed using schemars JsonSchema derive, but parameter descriptions are sparse: 'country' lacks guidance on exact matching behavior; 'onlyWarnings' and 'limit' are documented but terse; 'format' enum is well-constrained. Output schemas are not explicitly documented in the visible code, the tool returns McpJson wrappers but the response structure (ListWarningsResponse, GetWarningResponse) is inferred rather than described in tool metadata. Error messages are informative ('Upstream returned no warning entries', 'Invalid contentId. Please provide a numeric value') but recovery guidance is minimal. The server handles upstream API errors gracefully but does not expose timeout or rate-limit semantics to the LLM. Composition is clean, three orthogonal tools with no overlapping responsibility. Overall, this is a well-structured prototype that prioritizes correctness over LLM discoverability.
Fetch one advisory (including content) by contentId.
List travel advisory metadata from the German Foreign Office OpenData API.
Basic health ping for this MCP server.
Parameter descriptions are terse and lack guidance on usage. 'country' parameter has no description of matching semantics (substring vs exact match); 'limit' accepts 1-250 but does not explain the clamp behavior; 'format' enum is constrained but lacks use-case guidance.
Output schemas (ListWarningsResponse, GetWarningResponse, DetailContent) are defined as Rust structs with serde/schemars derives but are NOT explicitly documented in tool metadata or descriptions. An LLM cannot infer the shape of the response without reading Rust source or reverse-engineering from examples.
Tool descriptions lack context on WHEN to use each tool. 'List travel advisory metadata' does not explain when to call list_warnings vs get_warning, or whether the list returns full content or just metadata.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling is basic. A string-based Result<T, String> error model provides no error classification (retryable vs fatal). Errors like 'Upstream request failed' do not suggest recovery steps to the LLM.
No pagination support. list_warnings clamps results to 250 but offers no offset/cursor mechanism or next_page token. Large result sets could exhaust the LLM context window.