Loading ToolBench

Reading the current corpus…

mcp-gateway MCP server · F · ToolBench

← Browse

mcp-gateway

github.com/HarrisonCN/mcp-gateway

A lightweight, open-source gateway for managing, routing, and monitoring multiple MCP (Model Context Protocol) servers.

<=2025-11-25STREAMABLE_HTTP7 tools

38/100

Definition Quality33

Protocol Readiness52

SupportabilityNot measured-

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

mcp-gateway exposes 7 tools via HTTP REST API. Most tools lack input schemas entirely (health, servers, servers/:id, tools, requests have no visible schema definitions). Descriptions are present but generic and lack LLM-optimization guidance. The tools/call endpoint accepts arguments as free-form objects with no schema validation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Error handling is not documented. Tool naming follows REST conventions (health, metrics, servers) rather than action-verb patterns (get_health, list_servers). No parameter descriptions for optional filters. Output schemas are not documented.

Tools (7)

healthread only37/100

Returns gateway health status, version, uptime, and server summary

metricsread only50/100

Returns aggregated metrics for requests, latency, success rates, and top tools/servers. Supports Prometheus text format.

requestsread onlyauth43/100

Retrieves recent request metrics and logs

serversread onlyauth37/100

Lists all registered MCP servers with their health status and tool counts

servers/:idread onlyauth40/100

Retrieves details for a specific MCP server including its configuration, health status, and available tools

toolsread onlyauth43/100

Discovers all available tools across registered servers, with optional filtering by server ID or tag

tools/callwriteauthsource verified40/100

Invokes a tool on a registered MCP server with provided arguments

Issues (5)

CRITICALtool ↗

No input schemas visible for 5 of 7 tools (health, servers, servers/:id, tools, requests).

healthserversservers/:idtoolsrequests

CRITICALconstrained-input ↗

tools/call accepts 'arguments' as free-form object with no schema validation. LLM cannot infer valid argument structure for arbitrary tools.

tools/call

HIGHtool ↗

Tool names use REST resource naming (health, metrics, servers) instead of action-verb patterns (get_health, list_metrics, list_servers). LLMs infer intent from verb-noun naming.

healthmetricsserversservers/:idtoolsrequests

HIGHtool ↗

No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields.

healthmetricsserversservers/:id

Recommendations

Add explicit JSON Schema input definitions for all 7 tools. Example: health should have schema {} (no params); servers/:id should have {type:'object', properties:{id:{type:'string', description:'Server ID'}}, required:['id']}.
Rename tools to action-verb patterns: health→get_health, metrics→get_metrics, servers→list_servers, servers/:id→get_server, tools→list_tools, tools/call→call_tool, requests→list_requests.
Document output schemas for each tool. Example: get_health returns {status:string, version:string, uptime:number, servers:{[id:string]:{status:string, toolCount:number}}}.
Add tool annotations: mark get_health, get_metrics, list_servers, get_server, list_tools, list_requests with readOnlyHint=true; mark call_tool with destructiveHint=true (since it invokes arbitrary tools).
Enhance parameter descriptions with constraints. Example: tools filter 'server' should say 'Filter by server ID (optional; if omitted, returns tools from all servers)'; 'tag' should say 'Filter by server tag (optional; exact match)'.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

38/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	38	<=2025-11-25	v2