MCP CV Server has significant gaps in definition quality. Tool naming follows verb patterns (get_, search_, query_, send_) which is good, but descriptions are universally too brief (under 50 chars) and lack LLM-optimization guidance. Input schemas are present for all tools but mostly lack parameter descriptions beyond the required 'query' and 'category' fields. Most critically, tools with empty input schemas (get_personal_info, get_work_experience, get_education, get_skills) lack any documentation of what they return or why an LLM should call them. Error handling is basic and does not guide recovery. No output schemas are documented. The send_email tool lacks any mention of side effects or irreversibility. Tool descriptions fail to explain WHEN to use each tool vs alternatives (e.g., search_cv vs query_cv distinction is unclear).
Get education information from CV
Get personal information from CV
Get skills from CV
Get work experience from CV
Query CV information by category
Search CV content for specific information
Send email notification
Four tools (get_personal_info, get_work_experience, get_education, get_skills) have empty input schemas with no properties. Per hard scoring rules, schema score MUST be 0 for these tools.
No output schemas are documented for any tool. LLMs cannot infer what fields will be returned (e.g., does get_personal_info return {name, email, location} or {success, data, summary}?). This violates the pattern requirement that output structures must be documented so LLMs can plan downstream calls.
Ambiguous tool overlap: search_cv and query_cv both retrieve CV information but their distinction is unclear. The description 'Query CV information by category' vs 'Search CV content for specific information' does not explain when to use each. This violates composition rule requiring clear, distinct tool purposes.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
send_email tool description does not indicate it modifies state (sends irreversible message). Per pattern:command-tool, destructive/irreversible tools must explicitly declare this in the description so agents understand retry semantics and consequences.
Error handling in src/mcp-tools.js returns generic error objects like {error: 'No personal information available'} without recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next (e.g., 'No education found. Check that CV data was loaded via configuration.').
query_cv 'query' parameter lacks a description ('Specific query within the category'), leaving LLMs guessing how to format the query. Is it a free-text search, a structured field name, or a constraint expression?
search_cv does not document expected result limits or pagination. The tool may return unbounded results, risking context-window exhaustion. Per pattern:paginated-result, list-returning tools must accept limit/offset and return a total count.