Loading ToolBench
Scores and ranks influencer/creator records based on query term matching and relevance
This server has a single tool with moderate naming but severe documentation and schema gaps. The tool name 'score_and_rank_records' is verb-noun compliant and clear, but lacks parameter descriptions, output schema documentation, error recovery guidance, and input validation. The description is adequate length (118 chars) but does not explain when to use the tool or what it returns. Schemas for input parameters ('records' and 'query') lack critical descriptive text. No error handling, no output schema documented, no handling of edge cases (empty records, invalid query formats). The implementation is functional but falls well short of production-grade quality baselines. Compared to the rubric baseline of 194 chars for tool descriptions and 100% of A+ tools having parameter descriptions, this server meets neither.
Scores and ranks influencer/creator records based on query term matching. Calculates relevance score by counting matching query terms in record text, sorts by score and index, and returns ranked results with evidence snippets.
Missing parameter descriptions in input schema. 'records' and 'query' parameters have descriptions but are minimal (18 and 49 chars respectively) and lack format/constraint guidance. Rubric baseline: 100% of A+ tools have comprehensive param descriptions (avg 72 chars).
No output schema documented. The tool returns a dict with 'status', 'query', 'matches' (array), and 'count' fields, but this structure is completely undocumented. Agents cannot know what fields to expect or how to chain results to downstream tools. LLMs need to know what fields to expect.'
Minimal error handling and recovery guidance. The mcp_server.py catches generic exceptions and returns {'status':'error','error':str(error)}, but provides no actionable recovery steps. Rubric requires: 'Error responses must tell the LLM what to do next' and 'Categorize errors as retryable, user-fixable, or fatal.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Tool description does not answer 'What does it return?' The 118-char description explains the algorithm but omits what fields are in the response and how to use them downstream. Rubric: 'A tool description must answer: What does it do? When should the LLM call it? What does it return?'
No input validation error messages. If 'records' is not a list or 'query' is empty, the tool raises ValueError, but the error message is generic. Should return structured errors like 'Invalid records: must be a list of dicts' with the invalid value and constraint. Rubric: 'Include the invalid value and the constraint it violated.'
Parameter 'query' lacks format/constraint documentation. Should specify: 'Space-separated search terms (1-100 terms, case-insensitive). Empty query is rejected.' Current description is only 49 chars and omits these constraints.
No guidance on result limits or pagination. The tool returns all ranked results without limits. If records array has 10,000 items, all are scored and returned, bloating the response. Rubric: 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination.' Should add limit/offset parameters.
Scoring algorithm lacks documentation. Why divide hits by max(1,len(terms))? What does a score of 0.5 mean? Should explain the relevance formula so agents understand how to interpret results. Include example: 'If query="creator audience" (2 terms) and record matches 1 term, score=0.5.'