An open-source Model Context Protocol (MCP) Gateway for secure, scalable AI model interactions with service discovery, rate limiting, authentication, and monitoring capabilities
Bridge MCP Gateway presents as an HTTP-based MCP server with 11 tools. However, critical examination reveals significant structural and documentation issues. The server uses FastAPI and exposes tools via HTTP, which is positive for protocol readiness. However, the tool definitions provided in the submission lack explicit JSON Schema structures, parameter type declarations, and comprehensive descriptions that meet production standards. Most tools have only brief descriptions (20-80 chars) without actionable context for LLM decision-making. Parameters are listed but lack formal type definitions and constraints. Error handling guidance is absent. The 'sampling_callback' parameter in connect_server is particularly problematic, it accepts a callable object, which cannot be serialized in JSON Schema and suggests architectural confusion about MCP protocol boundaries. The 'root' tool appears to be a dashboard endpoint, not an MCP tool definition. Overall, this reads as an early-stage gateway wrapper rather than a production-grade MCP server.
Tools (11)
call_toolwriteauthsource verified48/100
Call a tool on an MCP server with circuit breaker protection
connect_serverwriteauthsource verified42/100
Connect to an MCP server with specified transport configuration, optional session ID, and sampling callback
disconnect_serverwriteauthsource verified53/100
Disconnect from an MCP server by session ID
get_promptread onlyauthsource verified52/100
Get a prompt from an MCP server with circuit breaker protection
get_server_inforead onlyauthsource verified57/100
Get information about the connected MCP server
health_checkread onlysource verified62/100
Health check endpoint for monitoring and load balancers. Accessible without authentication.
Tool definitions lack formal JSON Schema constraints. Parameters are documented as strings/objects with minimal type, format, length, or pattern constraints. This violates the MCP protocol requirement for structured input schemas.
No output schemas documented for any tool. LLMs cannot determine what fields to expect, what IDs to extract for chaining, or how to parse results. This breaks tool composition and forces agents to guess at response structure.
Add formal JSON Schema definitions for all tool inputs. For each parameter, declare type (string, number, object, array), enum constraints (if applicable), minLength/maxLength, pattern (regex), and format (e.g., uuid, uri, email). Example: session_id should be {"type": "string", "description": "Unique session identifier (UUID format)", "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"}.
Document output schemas for every tool. Specify the structure of the response object, including all field names, types, and descriptions. For list tools, include 'total_count' and 'next_cursor' for pagination. Example for list_tools: {"type": "object", "properties": {"tools": {"type": "array", "items": {"type": "object", "properties": {"name": {"type": "string"}, "description": {"type": "string"}}}}, "total_count": {"type": "integer"}}}.
Expand tool descriptions to 100-200 characters with explicit WHEN/WHY/HOW guidance. Example: 'connect_server: Establishes a session with a remote MCP server using HTTP or STDIO transport. Call this first to initialize communication before listing tools or resources. Returns session_id for all subsequent calls.' Include a statement about idempotency and side effects.
Remove 'sampling_callback' parameter from connect_server. Sampling should not be exposed as a tool parameter, it is server-level configuration. If sampling is needed, document it in server initialization configuration, not as a callable parameter.
Add pagination support to list_tools, list_resources, and list_prompts. Include limit (default 20, max 100) and offset/page_size parameters. Document in descriptions: 'Results are paginated. Use limit and offset to retrieve large result sets. Default limit is 20; max is 100.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 48 points across a rubric change (v1 → v2)
48/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
48
<=2025-11-25
v2
2026-03-09
F
0
-
v1
58/100
List available prompts from an MCP server with circuit breaker protection
list_resourcesread onlyauthsource verified58/100
List available resources from an MCP server with circuit breaker protection
list_toolsread onlyauthsource verified58/100
List available tools from an MCP server with circuit breaker protection
read_resourceread onlyauthsource verified53/100
Read a resource from an MCP server with circuit breaker protection
rootread onlysource verified23/100
Root endpoint with gateway information and available endpoints
connect_server accepts 'sampling_callback' parameter typed as 'callable'. Callable objects cannot be serialized in JSON and should never appear as tool parameters. This suggests architectural confusion, sampling should be handled at the server level, not as a tool parameter passed by the agent.
List tools (list_tools, list_resources, list_prompts) lack pagination parameters (limit, offset, page_size) and do not document result limits. Without pagination, large result sets can exhaust context windows and cause agent reasoning failures.
Descriptions across all tools are brief (40-100 chars) and lack actionable context. They do not explain WHEN to use a tool instead of alternatives, WHAT the prerequisites are, or HOW to interpret results. This prevents LLMs from selecting tools confidently.
No error handling guidance. Tools provide no recovery hints (e.g., 'Session not found. Try connect_server() first.' or 'Invalid arguments. Call list_tools() to see available parameters.'). This forces agents to blindly retry without understanding what went wrong.
'root' tool is inferred from dashboard code, not visible as explicit MCP tool registration. Cannot verify it follows MCP protocol patterns or has proper schema.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are defined. Tools like disconnect_server and call_tool have side effects, but this is not signaled to clients. Agents cannot determine which tools are safe to retry.
No parameter validation rules documented. Params like session_id, tool_name, and uri lack format constraints, length limits, or pattern descriptions. This invites invalid input from LLMs.
Add tool annotations: Mark disconnect_server and call_tool with destructiveHint: true (side effects). Mark list_tools, list_resources, read_resource, get_prompt with readOnlyHint: true. Mark connect_server with idempotentHint: false (creates sessions).
Add error recovery guidance to every tool description. Examples: 'If session_id is invalid, call list_server_sessions() to find active sessions.' or 'If the resource cannot be read, check that the URI is valid using list_resources() first.'
Document return values explicitly. For connect_server, specify: Returns {"session_id": "<uuid>", "server_name": "<name>", "capabilities": [...]}. For call_tool, specify: Returns {"result": <tool-specific output>, "execution_time_ms": <number>} or error {"error": "<message>", "recovery_hint": "<guidance>"}.
Add per-parameter validation rules and constraints. For tool_name, add pattern to match tool naming (e.g., '^[a-z_][a-z0-9_]*$'). For uri, add format: uri. For session_id, add format: uuid and minLength/maxLength.
Create a discovery tool (describe_gateway) that returns the gateway's configuration, supported transports, authentication requirements, and rate limits. This helps agents understand the gateway's capabilities upfront.
Replace brief parameter descriptions with actionable ones. Instead of 'Tool arguments', write: 'Arguments as a JSON object. Keys and types depend on the tool, call list_tools() with the tool_name to see available arguments and their types.'
Add error classification to tool outputs. Return structured errors with categories: {"error": {...}, "category": "retryable|user_fixable|fatal", "recovery_hint": "..."}. Enables agents to decide next steps automatically.