Self-hosted MCP aggregator gateway with a spec-compliant client-facing OAuth 2.1 authorization server (DCR + CIMD + PKCE)
Single tool 'gateway_status' has minimal definition. Description is present (47 chars) but lacks actionable context for LLM selection. Input schema is empty object with no parameters documented. No output schema visible in source. Tool does not follow verb_noun naming (should be 'get_gateway_status' or 'list_gateway_backends'). No error handling guidance, no parameter descriptions (none exist), no composition hints. This is a read-only discovery tool but lacks the detail needed for reliable LLM invocation.
List the backends configured in this gateway and their connection state.
No input schema visible; tool definition appears incomplete. Input is empty object {} with no documented parameters or constraints.
No output schema documented. LLM cannot infer what fields to expect (backend names, connection states, timestamps, etc.) or plan downstream operations.
Tool name 'gateway_status' is vague. Does not start with action verb. Should be 'get_gateway_status', 'list_gateway_backends', or 'describe_gateway_health' to signal intent clearly.
Description (47 chars) is too brief and lacks context. Does not explain WHEN to call this tool, what the response structure is, or how to interpret connection states. Should be 50-200 chars with actionable guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | <=2025-11-25 | v2 |
No error handling guidance. What happens if a backend is unreachable? Does the tool return partial results or fail entirely? LLM needs recovery hints.