Loading ToolBench
An MCP server that analyzes influencer content performance by ranking records based on query term matching
Single tool 'analyze_content_performance' has critical deficiencies across naming, description quality, and schema completeness. The tool name lacks a clear action verb and is overly generic. Description is present but under-specifies the algorithm and use cases. Input schema exists but is minimal, no parameter descriptions, no output schema documentation, no error handling guidance. The implementation is basic keyword matching that does not match the sophisticated description ('ranking records based on query term matching', 'relevance scores'). No field-level documentation, no pagination support, no constraints on input sizes. This server would require substantial rework to meet production standards.
Analyzes influencer content performance by ranking records based on query term matching. Takes a list of records and a query string, calculates relevance scores based on term frequency, and returns ranked results with scores and evidence snippets.
Tool name does not start with a clear action verb. 'analyze_content_performance' is vague; should be 'search_content_by_relevance', 'rank_content', or 'find_matching_content'. LLMs cannot infer intent from 'analyze_content_performance' alone.
Input schema provides no parameter descriptions. The 'records' parameter lacks guidance on expected record structure, field names, or size limits. The 'query' parameter has no examples of valid input or splitting rules.
Output schema is not documented. The tool description and source code show the tool returns 'status', 'query', 'matches' (array), and 'count', but this structure is not formally declared in the tool definition. LLMs cannot plan downstream operations without knowing output fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
No input validation constraints. Records can be arbitrarily large (no limit documented), query can be arbitrarily long, no regex patterns or format specifications. Unbounded numbers let LLMs pass absurd values that break APIs or cause timeouts.'
No error recovery guidance. The implementation returns generic error messages ('records must be a list', 'query must be non-empty') but no actionable next steps. A raw error code or stack trace gives the agent nothing to act on.'
No pagination or result limiting. The tool returns all matches without limit, which can exhaust context windows.
Mismatch between description claims and implementation. Description says 'ranking records based on query term matching' and 'calculates relevance scores based on term frequency', but the code uses naive substring matching (not proper term frequency analysis) with no sophisticated ranking algorithm. This misleads LLMs about tool capabilities.
Record structure is opaque. No specification of expected fields in each record dict. The code concatenates 'all values' from the record, but the description does not explain what fields are expected, required, or how they contribute to scoring. This forces agents to guess.
Evidence snippet is truncated at 300 chars with no indication of truncation or link to full text. The rubric requires 'Rich text formats or deeply nested content' be stripped, but this is not documented, and the truncation is silent.