Loading ToolBench
MCP server for SecretSauce gateway that provides HTTP service access, credential management, and policy-based request authorization through gateway references and service requests
Strong foundation with explicit tool contracts, comprehensive schemas, and security-aware design. All 5 tools have descriptions (avg 180 chars), input/output schemas with Zod validation, and tool annotations (readOnlyHint, destructiveHint). However, parameter descriptions are sparse or missing in several tools (service_request lacks descriptions for headers/body; explain_denial has minimal context). Output schemas are defined but not visible in excerpt. Error handling guidance is implicit in descriptions but not explicit in tool contracts. HTTP transport with OAuth2 scopes is production-ready.
Describe configured destinations, service access methods, and ordered allow/deny policy rules for a service this authenticated user can access. Never returns protected backend values.
Explain why a gateway request was denied, including matched policy rule and suggested next step if available.
Get short-lived gref_ references for configured service access. Protected values remain on the gateway: references cannot reveal or export them, have no meaning outside this gateway, and creating a reference does not contact or modify the downstream service.
List the HTTP services and access methods available to this authenticated user through the gateway. Never returns protected backend values.
Send an HTTP request through the gateway. The backend resolves gateway references only after authorization, destination, reference-binding, and policy checks. Pass a gateway_access reference in service_reference; that gateway-only field is never forwarded downstream. Before the response reaches the agent, the backend scans it and replaces detected secrets with subject- and service-bound sec_ references. Cookie headers are not supported.
service_request tool has 5 parameters but only 2 have descriptions in visible schema (service_reference, method, path documented; headers and body lack descriptions). LLMs cannot infer what headers object structure is expected or body encoding.
explain_denial tool description (95 chars) is below baseline (194 chars avg for A+ tools). Lacks context on when to call it or what denial_id format is expected. No guidance on recovery steps.
No visible error handling guidance in tool contracts. Error responses should tell LLM what to do next (e.g., 'Service not found. Call list_services() first.'). Current design relies on implicit error recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2025-06-18+ | v2 |
service_request tool accepts 'headers' as free-form object with no schema constraints. LLMs may pass invalid headers (e.g., Cookie, which is explicitly unsupported per description). Should define allowed/forbidden header names.
Output schemas (listServicesOutputSchema, etc.) are referenced but not visible in excerpt. Cannot verify if responses include chaining IDs, pagination, or strip unnecessary metadata. Assume present but unverified.