Loading ToolBench
A Spring Boot MCP server that exposes tools for weather forecasts, country information, and custom services using Spring AI's tool annotation framework
This is a minimal, poorly-documented MCP server. Of the 3 tools, all lack meaningful descriptions and only 1 has a proper input schema. Tool descriptions average 5-13 words, far below the 194-character baseline for production tools. No output schemas are documented. No error handling guidance. The tools are READ_ONLY simple lookups and one WRITE operation, but no safeguards, confirmation steps, or error recovery paths are visible in the code. The server uses Spring AI's MethodToolCallbackProvider to expose service methods as tools, but the underlying service implementation (CustomeService) is not shown, so actual behavior cannot be fully verified. Names follow a verb_noun pattern (getWelcomeMessage, getSamplePersons, scheduleMeetingPerson) which is acceptable, but descriptions are generic placeholders that would not guide an LLM effectively in multi-tool scenarios.
Get a sample list of persons
Get a welcome message
Schedule a meeting with a person
Tool descriptions are trivial placeholders (5 - 13 words each). LLMs cannot distinguish when to use getWelcomeMessage vs scheduleMeetingPerson, or understand the difference in side effects. Descriptions must be 50 - 200 characters and explain WHAT the tool does, WHEN to use it, and any prerequisites or state changes.
getSamplePersons has NO input schema (empty `{}` input). The tool callback registration lacks visible schema definition. Without a schema, the LLM cannot reason about required vs optional inputs or validate output structure.
No output schemas documented for any tool. LLMs cannot predict what fields will be returned (e.g., does getSamplePersons return a list of Person objects with id, name, email? Does it include counts or pagination info?). Without output documentation, downstream tool chaining is error-prone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
scheduleMeetingPerson is marked WRITE (has side effects) but has no confirmation step, dry-run option, or recovery guidance. If an LLM schedules a meeting in error, there's no visible tool to cancel it. Irreversible operations should offer confirm_before_execute or undo paths.
No error handling guidance. If getWelcomeMessage receives an invalid userName or if scheduleMeetingPerson fails (e.g., meeting time conflict), what should the LLM do? Retry? Ask the user? The tools provide no recovery hints.
Parameter 'userName' in getWelcomeMessage and scheduleMeetingPerson lacks constraints. Is it case-sensitive? Min/max length? What happens if the user is not found? No validation rules or error examples are provided.
Tool names use camelCase (getWelcomeMessage) rather than snake_case (get_welcome_message). While camelCase is acceptable in Java, MCP tooling conventions typically expect snake_case for LLM tool selection. This is a minor stylistic inconsistency.