Loading ToolBench
Front API client with Model Context Protocol support
Single-tool server with a well-structured schema and clear naming. Tool name 'getConversations' correctly uses verb_noun convention. Input schema is comprehensive with proper Zod definitions (types, enums, min/max, defaults). Description is adequate at 37 chars but could be more contextual. Parameter descriptions are present and descriptive (avg ~80 chars). However, output schema is only documented implicitly in the implementation, there is no explicit return type schema visible, and the response is stringified JSON rather than structured typed output. Error handling is basic (missing recovery guidance). No tool annotations (readOnlyHint, idempotentHint). Lacks idempotency declaration despite READ_ONLY risk classification.
Get conversations from a Front inbox
Output schema is not explicitly documented. Response is stringified JSON text rather than structured typed output. LLMs cannot parse the nested structure reliably or chain downstream tools without interpreting JSON strings.
Tool description is brief (37 chars) and lacks context about use cases, when to call it, or what the response structure contains. Does not guide LLM selection vs similar discovery tools.
Error handling provides only generic error wrapping ('Front API error: ...'). Does not guide LLM recovery: should suggest next steps like 'verify FRONT_API_TOKEN' or 'check inboxId validity'.
Missing tool annotations. Tool is READ_ONLY but has no readOnlyHint annotation to signal to the client that it is safe to call without mutation concerns. Tool is also idempotent but lacks idempotentHint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Response includes stringified JSON text field instead of structured typed objects. Baseline patterns expect nested objects with explicit field types (e.g., {type: 'text', text: ...} wrapping structured {conversations: number, messages: [...]}). This forces LLM string parsing.
Parameter 'limit' has min=1, max=100, default=10, but description does not state the range constraint explicitly. LLMs may not detect the bounds from schema alone and should see 'max 100' in description text.
Tool does not document pagination. If conversations can exceed the limit, there should be a cursor or offset mechanism and a next_token in the response. Currently returns only count + messages array without continuation support.