Datadog MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that custom metrics may return null for ingested volumes, which is a useful behavioral trait. However, it lacks details on permissions, rate limits, or other constraints implied by the HTTP responses (e.g., 403 Forbidden, 429 Too Many Requests). The description doesn't fully compensate for the absence of annotations, leaving gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, but it includes extensive, repetitive HTTP response details that could be condensed or omitted, as they don't add significant value beyond what might be inferred from structured fields. The 'Path Parameters' section duplicates schema info unnecessarily. While not overly verbose, it has wasted content that reduces efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter with full schema coverage and an output schema (implied by the response examples), the description is reasonably complete. It covers the purpose, a key behavioral note about null returns, and error responses. However, it could improve by adding more context on usage or constraints, but it's adequate for a read operation with structured support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter 'metric_name' documented as 'The name of the metric.' The description repeats this in the 'Path Parameters' section but adds no additional meaning, syntax, or format details beyond what the schema provides. According to the rules, with high schema coverage, the baseline is 3 even without extra param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'View distinct metrics volumes for the given metric name.' This specifies the verb ('view') and resource ('distinct metrics volumes'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'ListTagsByMetricName' or 'ListMetricAssets', which might handle related but different data, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions that 'Custom metrics generated in-app from other products will return `null` for ingested volumes,' which is a usage note but doesn't specify when to choose this tool over other list or get tools in the sibling set. No explicit when/when-not or alternative tools are named, leaving the agent without clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.