This evaluation covers 10 tool instances across the MCPServer.cpp repository. The codebase demonstrates a C++ MCP framework (cxxmcp) with multiple transport options (STDIO, HTTP, WebSocket) and support for prompts, resources, and logging. However, the tool definitions are severely deficient: most tools lack meaningful descriptions, input schemas are missing or incomplete, and parameter documentation is absent. Multiple tools are duplicates (5 'echo' tools, 2 'greet' tools) with inconsistent metadata. The source code visible in the repository shows protocol infrastructure (tool.hpp, schema definitions) but actual tool implementations are scattered across example files (echo_server.cpp, oauth_authorization_server.cpp, typed_stdio_server.cpp) without comprehensive schema visibility. Per the hard scoring rules, tools with missing descriptions score 0 on description, and tools without visible input schemas score 0 on schema. This results in a very low overall definition quality score.
Duplicate and conflicting tool names (5 'echo' variants, 2 'greet' variants) with inconsistent descriptions and no discriminating metadata. LLMs cannot differentiate between them.
Consolidate duplicate 'echo' tools into a single, well-defined tool with clear naming (e.g., 'echo_json', 'echo_string', or task-specific names like 'echo_async' if task support differs). Each tool name must be unique and unambiguous.
Rename 'shout' to 'append_exclamation' or 'add_exclamation_mark' to follow verb_noun convention and clarify intent.
Rename both 'greet' tools to disambiguate: e.g., 'send_greeting' for one, 'send_greeting_with_name' for the other; or combine them if the difference is only parameter presence.
Rename 'search' to 'search_local_documents' to clarify what is being searched.
For every tool, add a description of 100-300 characters explaining WHAT it does, WHEN to use it (vs. similar tools), and WHAT it returns. Example for 'search_local_documents': 'Search the local document repository by keyword. Returns up to 20 matching documents with titles, summaries, and URIs. Use this to find reference materials before composing a response. Supports pagination via offset/limit parameters.'
For every parameter, add a description explaining its purpose, valid format, and constraints. Example: 'name (string, required): The person's first and/or last name to greet. E.g., "Alice" or "Alice Smith". Used to personalize the greeting message.'
Add input schemas with full JSON Schema for every tool: include 'type', 'properties', 'required' arrays, and per-property descriptions. Example for 'greet': { 'type': 'object', 'properties': { 'name': { 'type': 'string', 'description': 'The person's name...' } }, 'required': ['name'] }
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 0 points across a rubric change (v1 → v2)
35/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
F
35
2026-07-28+
v2
2026-03-09
F
35
-
v1
read only
source verified
Append an exclamation mark.
5 out of 10 tools have no description or descriptions under 20 characters. LLMs cannot determine when or why to select these tools.
No parameter documentation visible for any tool. Even tools with input schemas (e.g., 'greet' with 'name' parameter) lack descriptions explaining what the parameter controls, valid format, or constraints.
Document the output schema for every tool. Include field names, types, and what data they contain. Example for 'search_local_documents': 'Returns an object with properties: documents (array of {title, summary, uri, relevance_score}), total_count (integer), has_more (boolean).'
Add parameter constraints where applicable: enums for known values, min/max for numbers, regex patterns for strings. Update descriptions to reference constraints formally rather than via examples.
For 'search_local_documents', add pagination support: accept 'limit' (1 - 100, default 20) and 'offset' (0+, default 0) parameters; return 'total_count' and 'has_more' fields so agents can iterate.
For any tool that modifies state or calls external services, document error cases and recovery steps. Example: 'If a search times out (> 5 sec), the tool returns error code TIMEOUT with message 'Search service unavailable. Try a simpler query or retry in 30 seconds.'
Review the cxxmcp protocol headers (tool.hpp) and ensure all tool registrations use the full metadata available: name, description (100+ chars), inputSchema with properties and descriptions, outputSchema, and error examples.
If 'echo' and task-based variants are intentional, document the distinction: e.g., 'echo' is synchronous; 'echo_async' (via long.echo) requires task-based invocation per Tasks extension. Make this explicit in descriptions.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to each tool definition. All current tools appear read-only, so set 'readOnlyHint': true to signal safety.