A Spring Boot starter that fronts multiple MCP (Model Context Protocol) servers behind a single gateway, handling routing, auth/policy enforcement, observability and rate limiting.
This gateway server exposes 7 tools for aggregating and routing calls to upstream MCP servers. Tool naming follows verb_noun convention (tools_list, tools_call, prompts_list, etc.), which is good. However, critical gaps emerge: (1) Input schemas are not visible in the provided source code for most tools, only tools_call and prompts_get show partial schema hints in the description. (2) Tool descriptions are present but generic and lack LLM-optimized detail (e.g., 'Lists all tools aggregated from upstream MCP servers, filtered by caller policy' does not explain WHEN to call this vs alternatives, what the output structure is, or how filtering works). (3) No output schemas are documented, agents cannot know what fields to expect from list operations or how to chain results. (4) Error handling is not visible, no guidance on what happens when an upstream server is unreachable, a tool call fails, or policy denies access. (5) Parameter descriptions are minimal (e.g., 'Namespaced tool name (serverId__toolName)' lacks format validation rules, length constraints, or examples of valid names). This is a functional gateway but lacks the polish needed for confident LLM integration.
Retrieves a specific prompt from an upstream MCP server, enforcing policy
Lists all prompts aggregated from upstream MCP servers, filtered by caller policy
Lists all resources aggregated from upstream MCP servers, filtered by caller policy
Reads a specific resource from an upstream MCP server, enforcing policy
Lists all resource templates aggregated from upstream MCP servers, filtered by caller policy
Routes tool calls to the appropriate upstream MCP server based on namespaced tool name, enforcing policy and rate limits
Lists all tools aggregated from upstream MCP servers, filtered by caller policy
No output schemas documented for any tool. Agents cannot infer what fields list operations return, breaking tool chaining and forcing discovery detours.
Input schemas not visible in source code for 5 of 7 tools. Only tools_call and prompts_get show partial hints. Cannot verify parameter types, required fields, or constraints.
Tool descriptions are generic and lack LLM-optimized guidance. No explanation of WHEN to call each tool, what distinguishes it from similar tools, or how filtering/policy works. Descriptions average ~60 chars; baseline is 194 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2025-06-18+ | v2 |
No error handling guidance visible. Agents cannot know what to do if an upstream server is unreachable, a tool call fails, or policy denies access. No recovery hints provided.
Parameter descriptions lack actionable constraints. 'Namespaced tool name (serverId__toolName)' does not specify format rules, length limits, or valid character sets. LLMs will hallucinate invalid names.