Loading ToolBench
A Spring Boot application that integrates Spring AI with MCP (Model Context Protocol) to provide product-aware AI assistants with database context
This Spring Boot MCP server implements 4 AI query tools with basic HTTP transport. All tools are present and callable, but definition quality is substantially below production standards. Tool descriptions are present but generic and lack the LLM-optimization guidance required by the rubric. Parameter schemas are minimal, only 'userQuery' or 'query'/'text' with type string and trivial descriptions. No output schemas are documented. Error handling, parameter constraints, and composition patterns are absent from visible code. The server relies on Spring AI framework abstractions that hide MCP protocol details, making it difficult to verify full spec compliance. Tools exhibit naming confusion (getAiResponse vs getSimpleAiResponse duplicates functionality without clear distinction) and lack the verb_noun clarity pattern. No pagination, rate limiting, audit logging, or permission gates are evident.
Processes a user query using AI, with context from the product database. The method formats product information and passes it to the AI model along with the user query.
A simpler AI interaction without explicit database context in the prompt. Sends the user query directly to the AI model without product context.
Endpoint to get an AI response based on a user query. Accepts a JSON request with a query field and returns an AI-generated response with product context.
A simpler endpoint for testing AI responses without explicitly passing database context. Accepts a text query parameter and returns an AI response.
Duplicate tool functionality: getAiResponse and getSimpleAiResponse differ only in whether database context is passed. This violates the single-responsibility principle and forces LLMs to reason about subtle distinctions. Should be one parameterized tool with an optional 'include_context' boolean.
No output schemas documented. Tools return AI responses but the structure (plain text? JSON with metadata? tokens used?) is not specified. LLMs cannot plan downstream actions or parse results without knowing the response format.
Parameter descriptions are trivial ('The query from the user', 'The customer's question about products'). They do not specify format, length constraints, language requirements, or when to use each tool. Descriptions should be 50 - 200 characters and answer WHAT/WHEN/HOW.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
No error handling guidance. Tools do not document what happens if the AI service is down, the query is malformed, or rate limits are hit. Responses lack recovery hints ('Try again in 30 seconds' or 'Rephrase your question with more context').
No pagination or result-limiting mechanism. If AI responses or product context become large, there is no way to paginate or cap results. Large responses can exhaust context windows and degrade LLM reasoning.
Naming does not follow verb_noun convention. 'getAiResponse' starts with a verb but 'handleQuery' and 'handleSimpleQuery' use the vague 'handle' verb. Consider 'get_ai_response' (snake_case for consistency) or 'generate_response' (more descriptive).
Parameter names are inconsistent: getAiResponse uses 'userQuery', handleQuery uses 'query', handleSimpleQuery uses 'text'. The same concept has three different names, forcing LLMs to infer equivalence and risking copy-paste errors.
No audit logging or permission gates visible. AI tools should log who called them, with what parameters, and what response was generated (for compliance and debugging). No evidence of role-based access control.