Loading ToolBench
A mock MCP server for delivery support assistance that retrieves delivery journey information and incident owner team data
Two tools with clear naming and some schema definition, but critical gaps in parameter descriptions, output documentation, and error handling. Both tools have proper Zod schemas and type definitions visible in code, but descriptions lack the depth needed for reliable LLM selection. No output schema documentation. Error handling is minimal (null checks with generic failure messages). This server shows basic competence but falls short of production quality.
Get deliveries count in a journey
finds which team and project is responsible for the support according to the words it contains
Tool descriptions lack WHEN to use them and what they return. 'Get deliveries count in a journey' and 'finds which team and project is responsible' do not explain selection criteria or expected output structure. Descriptions should be 50-200 chars and answer: what does it do? when to call it? what does it return?
Output schemas are not documented. Both tools return text content wrapped in MCP response format, but there is no documentation of the response structure, field types, or pagination. LLMs cannot plan downstream calls or extract specific data without knowing what fields are returned.
Error handling is generic and non-actionable. Both tools return 'Failed to retrieve [X] data' on null response and 'No active [data] for [X]' on empty features. These messages do not tell the LLM what to do next, whether to retry, or why the call failed. See pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Parameter 'journeyKey' description is overly prescriptive with example: 'a string of 9 characters, the first two characters are letters and the other 7 characters are numbers (e.g. SF2027019)'. Example values encourage LLMs to reuse them literally. Use a regex pattern constraint instead.
No documentation of what fields the response text contains or how to parse results. The formatting functions (DeliveriesInJourneyClarified, IncidentOwnerTeamFeatureAlert) are internal implementation details. LLMs receive plaintext with fields like 'Route:', 'DeliveryCount:', 'IncidentOwnerTeam:' but have no documented schema to expect these.
Tool 'get-incident-owner-team' naming is unclear. 'get-incident-owner-team' could mean retrieve the team that owns an incident, or find team ownership based on incident content. The description 'finds which team and project is responsible for the support according to the words it contains' clarifies it searches by text, but this should be in the name. Consider 'search-incident-owner-by-text' or 'find-incident-owner-team'.
Parameter 'text' in get-incident-owner-team lacks detail. Description is minimal: 'text to search for team and project'. What format? Keywords? Full sentences? Minimum length? Maximum length? Domain-specific terminology? LLM has to guess.