Loading ToolBench
Spring Boot-based MCP server that integrates Groq AI for chat-based interactions with tools for MongoDB searches and flight API searches
This server exhibits critical gaps in tool definition quality. Both tools have minimal, uninformative descriptions (under 20 characters after 'Search' verb), no visible input parameter descriptions, and tool definitions appear to be inferred rather than explicitly registered with proper schemas. The code sample shows ToolsSelectorService is entirely commented out, raising doubts about whether tool registration is even implemented. The two tools (mongoSearchTool, flightSearchTool) are mentioned in comments as being in a Map, but no actual registration code, schema definitions, or parameter documentation is visible in the provided source. Without seeing explicit tool registration with complete schemas, parameter types, and descriptions, scores are capped at per-pattern maximums.
Search for flight offers based on free text queries processed through Groq AI to extract flight search parameters
Search MongoDB collections based on free text queries processed through Groq AI to extract search parameters
Tool descriptions are critically short and lack context. 'Search MongoDB collections based on free text queries processed through Groq AI to extract search parameters' (17 chars before first description sentence) provides minimal guidance on WHEN to use this tool vs alternatives, WHAT it returns, or HOW to use it. Baseline for A+ tools: 50-200 chars with clear intent, timing, and output summary.
No visible parameter descriptions. The input schema shows only {'text': {'type': 'string', 'description': 'Free text search query to be processed by Groq AI'}} but provides NO guidance on format, length limits, example valid inputs, or failure modes. Rubric requires: 'Every parameter needs a description explaining what it controls. Describe the expected format, range, and allowed values directly in the parameter description.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Tool definitions appear inferred rather than explicitly visible in source code. ToolsSelectorService is commented out entirely. No @Bean registration, no explicit tool registration with MCP server framework visible.
No output schema documentation. Neither tool specifies what fields are returned, data types, pagination support, or total result count. Rubric states: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' This blocks downstream tool composition.
Generic naming without clear action differentiation. Both tools use 'Search*Tool' suffix which is redundant. Names should follow 'verb_noun' pattern (e.g., 'search_mongodb_collections', 'search_flights'). Current naming does not distinguish database search from flight API search clearly enough for LLM disambiguation.
No error handling guidance. No documentation of failure modes (e.g., 'what if no results found?', 'what if Groq AI fails to parse?', 'what if MongoDB is unavailable?').
No idempotency guidance. If these tools execute searches that have side effects (e.g., logging, analytics), the idempotency contract is undefined. Agents will retry on ambiguous failures, lack of idempotency documentation risks duplicate operations.
No pagination or result limit constraints documented. If these tools return large result sets, no mention of max results, page size, offset, or cursor support. Rubric: 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination.'