Loading ToolBench
MCP server for fault-tolerant German address capture over the phone. Provides top-3 candidates, confidence scores, escalation flags, and TTS-ready confirmation sentences. Available as both MCP tools and REST API with demo web interface.
Strong domain-specific tool design with clear conversation flow and well-structured parameters. All 7 tools have descriptions (194 - 280 chars, within baseline 34 - 392 range) and input schemas with types. Language enum parameters are well-constrained. However, output schemas are not documented in the source code provided, and tool names use verb_noun pattern inconsistently (resolve_* vs generate_* vs list_* vs describe_*). Error handling descriptions are present but lack explicit recovery guidance. No tool annotations (readOnlyHint/destructiveHint) visible despite clear risk classifications in metadata.
Returns the documentation of this server: conversation flow, response format, thresholds and the OpenAPI description of the equivalent REST API.
Marks the call as uncertain and hands over to a human. Call it as soon as the caller confirms no suggestion, the address fails for the third time, or the data sources are down. Never accept the most likely candidate instead.
Builds a keyterm list for the Deepgram transcriber from the service area, prioritized by error-proneness, including a ready-made configuration block. Once during setup, not during a call.
Returns the street list for a confirmed postal code (optional prefix and limit). For setup, debugging, and rare clarification – do not read the full list aloud; the response is structured (streets, count, truncated).
Matches a heard street name against the official street directory of the postal code. Returns up to three candidates with confidence, the confirmation sentence (speech) and needsHuman. Never accept a street name unverified.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'returns up to three candidates with confidence, the confirmation sentence (speech) and needsHuman') but no formal JSON Schema for response structure is visible in source. LLMs cannot plan downstream calls without knowing response field names and types.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent despite metadata clearly marking risk levels (READ_ONLY, WRITE). These hints are required by current MCP spec (2026-07-28) to enable agent safety policies and proper retry logic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Checks a spoken postal code against the official directory and returns the matching places. Always use as the first step of address capture.
After a choice question: confirms one of the candidates that were read out and returns the normalized address plus the closing sentence. Only then does the address count as captured.
Naming inconsistency: resolve_* (resolve_postal_code, resolve_address) vs select_* (select_candidate) vs flag_* (flag_for_human) vs generate_* (generate_keyterms) vs list_* (list_streets) vs describe_* (describe_api). While each name is clear in isolation, the lack of consistent verb_noun pattern across the tool set increases LLM disambiguation overhead.
Error recovery guidance is implicit in descriptions ('Never accept...', 'Call it as soon as...') but not explicit in error response format. No visible error classification (retryable vs user-fixable vs fatal) or structured error messages with actionable next steps.
Parameter 'language' is optional with server-side default, but the default value is not stated in the parameter description. LLMs cannot reliably infer defaults, this should be explicit: 'Language for speech and reason: "de" or "en". Defaults to server language (de).'