A simple MCP server implementation with support for custom tools, resources, and LLM integrations (Google Gemini and OpenAI)
Server has 6 tools with basic schemas and descriptions present. However, multiple critical gaps reduce overall quality. Tool descriptions are present but vary in quality (range 38-92 chars, baseline is 34-392). All tools declare input schemas with type info, but parameter descriptions are minimal or absent in several tools. Parameter naming follows some conventions (x, y for math, message, delay for wait_and_echo) but lacks semantic clarity expected for LLM inference. No tool declares error recovery guidance, output schemas are not documented, and no tools include destructive/readonly annotations beyond the risk metadata provided externally. The server is functional but falls short of production-grade LLM tooling standards.
Adds two integer numbers.
Generate text using Google's Gemini API. Requires GOOGLE_API_KEY.
Generate text using OpenAI's API. Requires OPENAI_API_KEY.
Multiplies two integer numbers.
Returns information about the system.
Waits for a specified delay and then echoes the message.
Parameter naming lacks semantic clarity: 'x' and 'y' in add/multiply are mathematically generic and do not convey intent to an LLM. Should be 'first_number' and 'second_number' for better LLM inference.
Output schemas are not documented in code. Tools return values (int for add/multiply, dict for system_info/get_server_info, str for wait_and_echo and LLM tools) but LLMs cannot infer response structure from inspection. Tool definitions should include explicit 'returns' schema.
No error recovery guidance. LLM tools (generate_with_gemini, generate_with_openai) can fail due to missing API keys or API errors, but tool descriptions do not indicate what the LLM should do (retry, check configuration, try alternative tool). Descriptions mention 'Requires GOOGLE_API_KEY' but do not guide recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool schemas. External metadata marks all tools as READ_ONLY, but this should be declared within the tool definition itself for LLM visibility.
system_info tool has empty input schema (no parameters), but description does not clarify why no inputs are needed or what the output structure contains. Output will be a dict with 'platform', 'release', 'version', 'machine', 'processor' keys, but LLM cannot know this from the tool definition.
LLM tools expose error conditions (ConfigurationError, LLMError) that do not guide the agent toward resolution. If GOOGLE_API_KEY is missing, the tool raises ConfigurationError, but the error message format is not documented for the LLM to parse and recover from.