Loading ToolBench
HTTP server for proxying and observing MCP traffic. Acts as a gateway between MCP clients and servers with built-in request/response capture, health checks, and server registry management.
MCP Gateway exposes 4 well-documented management tools via HTTP. Tool definitions show strong naming conventions (verb_noun pattern), comprehensive descriptions with context and use cases, and detailed input schemas with type constraints and enums. Output schemas are not explicitly documented in the source provided, which is a moderate gap. Error handling guidance is present in descriptions but not formalized as structured error responses. The tools follow composition patterns well, each has a single responsibility and clear chaining semantics. All parameters have descriptions and appropriate types (string, number, enum). No parameter is left ambiguous. Security model relies on server-side credential handling (implied by HTTP transport and no secrets in params). Overall quality is above the median for community MCP servers; falls into the 'good' range with room for documented output schemas and formalized error structures.
Adds a new MCP server to the gateway's registry, making it accessible for proxying requests. This tool validates the server configuration and ensures the server name is unique within the registry. The gateway will route MCP requests to registered servers based on the URL pattern /:serverName/mcp. For example, a server named 'weather' will be accessible at /weather/mcp on the gateway. Prerequisites: - The target MCP server must be running and accessible at the provided URL - The server name must be unique (case-insensitive) within the gateway registry - The URL must be a valid HTTP/HTTPS endpoint that responds to MCP requests Use this tool when you need to connect the gateway to a new MCP server. The server will be immediately available for use once added. If headers are provided, they will be included with every request to that server (useful for authentication). Common use cases: - Adding a newly deployed MCP server to the gateway - Registering third-party MCP services with authentication - Setting up development/testing servers with custom configurations The tool will return success confirmation with the server's configuration details, or an error if the server name already exists or the URL is invalid.
Lists all MCP servers registered with the gateway, providing an overview of the current server configuration and status. This is essential for understanding what servers are available and their operational state. The tool supports filtering and formatting options to optimize the response for different use cases: **Filter Options:** - 'all' (default): Shows every registered server regardless of activity - 'active': Shows only servers that have processed requests recently (within the last hour) - 'inactive': Shows servers that haven't been used recently or have never processed requests **Format Options:** - 'concise' (default): Returns essential information (name, URL, status) for quick overview - 'detailed': Returns comprehensive information including configuration, statistics, headers, and timing data Use this tool to: - Get an overview of all configured MCP servers in the gateway - Check which servers are actively processing requests - Identify servers that may need attention (inactive or misconfigured) - Prepare for server management operations (add/remove decisions) - Monitor the overall health of your MCP server ecosystem The response includes operational metrics like request counts, last activity timestamps, and configuration details to help you understand server usage patterns and identify potential issues. For large deployments, use the 'concise' format first to get an overview, then query specific servers in 'detailed' mode for deeper analysis.
Output schemas not explicitly documented in source. While tools accept well-defined input schemas, the response structure for each tool is described only in narrative prose, not as formal JSON Schema. LLMs need structured response schemas to plan downstream tool calls and extract typed fields reliably.
Error handling guidance is embedded in descriptions but not formalized as structured error categories (retryable vs user-fixable vs fatal). The descriptions mention 'will return success confirmation with the server's configuration details, or an error if the server name already exists', but do not classify error types or suggest recovery steps in a machine-parseable format.
Destructive operations (remove_server) lack confirmation or dry-run capability. The description notes this is 'destructive' and 'cannot be undone', but no confirmation_required hint or dry-run parameter is present. Agents could accidentally delete servers without a safety gate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 86 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Removes an MCP server from the gateway's registry, making it no longer accessible for request proxying. This is a destructive operation that immediately disconnects the server from the gateway. When a server is removed: - All incoming requests to /:serverName/mcp will return 404 Not Found - The server's configuration and statistics are permanently deleted - Any active sessions to that server will be terminated - Captured request/response data is preserved in storage for analysis Use this tool when: - Decommissioning an MCP server that's no longer needed - Cleaning up test/development servers from the registry - Preparing to reconfigure a server (remove then add with new settings) - Removing servers that are permanently offline or misconfigured Safety considerations: - This operation cannot be undone through the gateway tools - Ensure no clients are actively using the server before removal - Consider the impact on any automated systems that depend on this server - Historical capture data will remain available for analysis even after removal The tool will confirm successful removal or provide an error if the server doesn't exist. After removal, the server name becomes available for reuse with add_server.
Search captured MCP traffic records with filtering and pagination. Filters: - serverName: Filter by server name (exact match) - sessionId: Filter by session ID (exact match) - method: Filter by JSON-RPC method (partial match) - limit: Maximum number of records to return (default: 100, max: 1000) - order: Sort order by timestamp ('asc' or 'desc', default: 'desc') Returns: - Paginated list of capture records with request/response data - Each record includes: timestamp, method, request, response, metadata (server, session, duration, HTTP status) Examples: - Search all records: {} - Search by server: { "serverName": "my-server" } - Search by method: { "method": "tools/call" } - Search recent errors: { "order": "desc", "limit": 50 }
Parameter 'headers' in add_server (type object with additionalProperties: string) has minimal constraint documentation. The description mentions 'authorization tokens, custom headers' but does not specify whether certain headers are forbidden, size limits, or format validation rules for sensitive values.