Loading ToolBench
A multi-org MCP proxy in front of the Datadog MCP server that exposes upstream Datadog tools over stdio, injecting a required 'org' argument into each tool to support multiple Datadog organizations
Single tool 'list_orgs' has a clear, action-verb name and adequate description (118 chars, within 10-1024 range). Input schema is properly defined as an empty object with additionalProperties=false. However, the tool lacks parameter descriptions (none exist), output schema is undocumented, and error handling is minimal. The server acts as a proxy to Datadog MCP servers, it wraps upstream tools by injecting an 'org' parameter, but the wrapped tools' schemas and descriptions are not visible in the source, making it impossible to assess their quality. The one native tool is functional but incomplete by production standards.
List the Datadog organizations configured in ddmcproxy. Use the returned names as the 'org' argument of the other tools.
Output schema not documented. Callers cannot predict the structure of the response (orgs array with name/endpoint fields). LLMs need explicit output schema to plan downstream operations.
Wrapped upstream tools' schemas and descriptions are not visible in source. Tool definitions are inferred from proxy logic rather than explicitly registered.
Error messages are generic and do not guide recovery. E.g., 'failed to encode orgs' or 'failed to parse arguments' do not tell the LLM what to do next or why the call failed.
No pagination support. If the number of configured organizations grows large, list_orgs returns all at once, potentially bloating the response and context window.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
Injected 'org' parameter description is dynamically generated and not visible in static schema inspection. LLMs see the enum constraint but may not understand the purpose without explicit description in the tool definition.