MCP Datadog Server

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

The description adds two important behavioral constraints beyond what annotations provide: API key requirement and the 10-minute past submission limit. However, it doesn't disclose other critical behavioral aspects like rate limits, authentication scope, whether this is idempotent, or what happens on submission failure. With no annotations provided, the description carries the full burden and provides only partial behavioral context.

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 appropriately concise with a clear main statement followed by bullet-pointed notes. Every sentence adds value: the first states the core action, and the notes provide essential constraints. However, the structure could be slightly improved by front-loading the most critical information more explicitly.

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's complexity (data submission with timing constraints), lack of annotations, and no output schema, the description is incomplete. It covers authentication and timing constraints but misses critical context like expected response format, error handling, rate limits, and how this tool differs from other data submission tools in the sibling list. For a submission tool with no structured safety annotations, more behavioral disclosure is needed.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters since there are none, and the schema already fully documents the empty input structure. The description correctly focuses on behavioral aspects rather than parameter documentation.

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 with a specific verb ('Submit') and resource ('Service Checks'), making it immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'create_events' or 'create_monitor' that also create/submit data, leaving some ambiguity about when to use this specific tool.

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. With many sibling tools that create/submit various types of data (events, monitors, logs, etc.), there's no indication of when service checks are appropriate versus other monitoring data types. The notes about API keys and timing constraints are operational prerequisites, not usage guidance.

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