Loading ToolBench
An MCP server implementation for AWS Lambda that provides tools for weather data retrieval and personalized greetings, integrated with AWS Bedrock AgentCore Gateway and Azure Entra authentication.
Critical gaps across all dimensions. Tool definitions are inferred from Makefile and test files rather than explicit MCP registration code. No visible input schemas in source, only JSON objects mentioned in the evaluation prompt. Descriptions are minimal (10-15 chars each). No parameter descriptions. No output schemas documented. No error handling guidance. The server appears to be a Lambda wrapper without proper MCP tool registration visible in provided source.
Generates a personalized greeting for a user.
Fetches weather data from the Open-Meteo API.
No input schemas visible in source code. Tool definitions appear inferred from Makefile/tests rather than explicit MCP registration. Cannot verify JSON Schema compliance.
Tool descriptions are extremely brief (10-15 characters). Descriptions must be 50-200 chars to guide LLM selection. Current descriptions lack context on WHEN to use each tool and WHAT it returns.
No parameter descriptions visible. 'location' and 'user_id'/'user_name' parameters lack explanations of expected format, constraints, or examples. LLMs cannot infer parameter semantics from names alone.
No output schemas documented. Callers cannot know what fields get_weather or get_personalized_greeting return, breaking downstream tool composition and forcing LLMs to guess response structure.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2025-06-18+ | v2 |
get_personalized_greeting has ambiguous parameters: 'user_id' and 'user_name' are both optional with no guidance on which is required or how they interact. Undocumented parameter relationships cause silent misuse.