An MCP server that ranks and matches product records against search queries using evidence-backed scoring based on term frequency across record fields
Single tool with severely limited documentation and schema definition. The compare_products tool has a reasonable description (88 chars, within baseline 34-392 range), but input parameters lack individual descriptions, they only have type and high-level summary. No output schema is documented, violating the 'Document the output schema' critical check. The tool definition is visible in client.py, so not inferred, but the absence of parameter-level descriptions and output schema documentation places this well below production standards.
Ranks and matches product records against a search query using evidence-backed scoring. Returns matched records ranked by relevance score (term frequency divided by query term count), with evidence excerpts from matching record text.
No output schema documented. Tool response structure is inferred from code (status, query, matches array with rank/record_index/score/evidence fields) but not declared in tool definition. LLMs cannot predict response shape or plan downstream tool chains.
Input parameters lack individual descriptions. 'records' parameter has only a type (list) and vague summary; no description of expected dictionary structure, required keys, or format. 'query' parameter similarly has minimal guidance. Rubric requires 'Every parameter needs a description explaining what it controls.'
Tool name 'compare_products' lacks action verb prefix. Follows verb_noun convention minimally ('compare' is a verb), but 'search_products' or 'rank_products_by_relevance' would be more explicit about the actual operation (ranking/matching against a query).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
No pagination or result limiting documented. Tool accepts unbounded 'records' list and returns all matches. If called with 10,000 product records, response could exceed context limits. Rubric requires 'cap results at a reasonable limit (e.g. 20-50) and offer pagination.'
Evidence excerpt field ('evidence': text[:300]) is raw concatenated text, not cleaned or structured. No description of what 'evidence' contains or how to interpret it. Rubric requires 'Return structured objects with typed fields' and 'Rich text formats... convert to markdown or plaintext.'
Error handling is minimal. Validation catches type errors (records not list, empty query) but returns bare error strings. Rubric requires 'Error responses must tell the LLM what to do next' and 'Include the invalid value and the constraint it violated.'