Loading ToolBench
MCP server that detects whether a call/message intent is spam.
Single tool with clear naming (detect_call_intent) and well-structured JSON Schema. Description is adequate (118 chars, within 10-1024 range). Input schema is complete with 5 parameters, all typed and described. However, output schema is not documented, LLMs cannot predict response structure. Error handling returns JSON but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Baseline: 194 chars avg description, 100% A+ tools document output; this server documents neither output schema nor error recovery paths.
Analyzes call or message text to determine if the intent is spam/scam, with confidence and reasons.
Output schema not documented. LLMs cannot predict response structure (isSpam, confidence, reasons, matches fields). Agents must infer from examples.
Error responses lack recovery guidance. 'Missing required text string' tells LLM nothing about next steps. Should suggest 'Provide a non-empty call transcript or message text.'
No tool annotations. Tool is read-only (analysis only, no side effects) but lacks readOnlyHint annotation. Agents cannot distinguish safe tools from destructive ones.
Parameter 'direction' enum lacks description context. Why is direction relevant? When should inbound vs outbound change behavior? Undocumented dependency.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No pagination or result limits documented. If analysis.reasons or analysis.matches arrays grow large, response could bloat context. No guidance on max size.