Loading ToolBench
A fraud scoring and screening service for checkout transactions that evaluates transaction scores and approves or denies based on fraud thresholds
This MCP server has a single tool 'check_fraud' with critical deficiencies in naming, description quality, parameter documentation, and output schema definition. The tool name lacks a clear action verb, the description is minimal (60 chars, below the baseline of 194 chars for production tools), parameters lack descriptions, and there is no documented output schema. The implementation is a trivial wrapper around a single comparison operation without production-grade error handling, validation, or security considerations.
Evaluates a fraud score and returns approval status based on threshold
Tool name 'check_fraud' lacks action verb. Should start with 'evaluate_', 'assess_', or 'screen_' to clearly signal intent (e.g., 'evaluate_fraud_score', 'assess_checkout_fraud'). Current name is ambiguous, does it check if fraud exists, check a fraud score, or return a fraud status?
Tool description is only 60 characters ('Evaluates a fraud score and returns approval status based on threshold'). Baseline for production tools is 194 chars (p10=34, p90=392). Current description lacks context on WHEN to use this tool, what constitutes 'threshold' (is it configurable?), and what happens if score is invalid. Does not answer: What is a fraud score? What thresholds apply? What should the agent do with the result?
Parameter 'score' lacks description entirely. Missing: valid range (0-100?), units (risk points? percentile?), interpretation (higher=more fraudulent?), and constraints. LLM cannot reliably infer these from name alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 24 | 2026-07-28+ | v2 |
Output schema is not documented. Return type is inferred from code as {"approved": boolean}, but no JSON Schema is provided in tool definition. LLMs need to know what fields to expect so they can plan downstream tool calls.' LLM must guess that the response structure is {approved: bool}; if additional fields are added later (e.g., confidence, risk_level), the agent has no way to discover them.
No error handling or validation. Code accepts any integer without bounds checking. What happens if score is negative? > 100? Non-integer? Tool provides no recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next.
Hardcoded threshold value (60) in implementation prevents configuration. Tool description mentions 'threshold' but does not state what it is or whether it's configurable. If different merchants need different thresholds, this tool cannot serve them. No parameter to override the threshold.
Tool lacks context about fraud scoring domain. What does a score of 45 vs 75 mean in the fraud domain? Is 60 a standard threshold across industry? State WHAT the tool does, WHEN to use it, and any prerequisites.' Current description omits domain context, forcing the LLM to invent assumptions.
No information about tool behavior or side effects. Does calling this tool modify any state (e.g., logging the fraud check for audit)? Is it idempotent? Per pattern:command-tool, if the tool logs or modifies state, the description must say so. Agents need to know which calls are safe to retry.