MCP Datadog Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools are distinct, but the three service dependency tools (get_apm_service_dependencies, get_service_dependencies, get_service_dependencies_multi_env) have highly overlapping purposes and could be easily misselected by an agent. Other tools like list_metrics vs query_metrics are clearly separated, but the dependency trio introduces ambiguity.
Naming Consistency4/5
Tool names consistently use snake_case with a verb_noun pattern (get_, list_, search_, query_, aggregate_). The verbs are predictable and align with their actions. Minor deviation: get_ prefixes are used for both single items (get_metric_metadata) and collections (get_service_dependencies), but this is not overly confusing.
Tool Count4/5
16 tools is on the higher end of the recommended range, but it covers multiple Datadog features (metrics, logs, events, monitors, APM, dependencies) reasonably. Each tool serves a distinct function within these domains, so the count is justified, though it feels slightly heavy for a single server.
Completeness3/5
The set provides broad read-only coverage for Datadog's main observability areas, but it lacks any write operations (create, update, delete monitors, events, etc.). There are also gaps like dashboards and trace detail. The service dependency trio is overrepresented while monitor management is incomplete, leaving agents unable to perform lifecycle actions.
Average 3.6/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool 'returns all services and their relationships', implying a read-only query, but does not explicitly confirm it is safe, mention rate limits, pagination, or the fact that an optional serviceName filter changes the result. The behavior is only partially disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action verb, and contains no superfluous content. Every word earns its place, making it efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 params, no output schema), but the description is incomplete in context: it omits any mention of the optional serviceName filter, does not clarify what 'relationships' means or the return structure, and fails to position the tool against the similar sibling tools. It provides only a high-level summary, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters (env and serviceName), each with descriptions. The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'service dependencies for a given environment', specifying the scope (environment). However, it does not explicitly distinguish this tool from closely related siblings like get_apm_service_dependencies or get_service_dependencies_multi_env, so it misses the opportunity for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a generic use case ('useful for understanding service architecture and dependencies') but provides no guidance on when to use this tool versus the similar sibling tools, no exclusions, and no mention of when not to use it. It fails to address the presence of overlapping alternatives in the tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination, rate limits, authentication, or the exact return format. It only restates the core action and filters, which are already evident from the schema, leaving agents without critical execution context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and direct, with no filler. The second sentence adds a use-case insight, though it is somewhat generic. It is appropriately sized and front-loaded, though not as information-dense as high-scoring examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and 2 well-documented parameters, the description covers the core purpose. However, it does not specify what fields the returned monitors include, pagination behavior, or error handling, leaving some gaps for an agent to handle correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have detailed descriptions in the schema (100% coverage), so the baseline is 3. The description only restates 'filtering by status and tags' without adding syntax, formatting, or edge-case behavior beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Datadog monitors') and scope ('all monitors in your account'), with optional filters by status and tags. It implicitly distinguishes from 'search_monitors' by focusing on a broad listing, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Useful for getting an overview of all monitors in your account'), implying it is a broad listing tool. However, it does not explain when to use this over 'search_monitors' or other alternatives, offering only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose whether the operation is read-only, what the return format is, or any limitations or side effects. It only restates the aggregation operation, leaving key behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action ('Aggregate log data') and includes essential scoping (time range, aggregation type). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers all parameters. However, with no annotations or output schema, the description lacks information about return values (e.g., single value vs. time series) and any operational constraints. It is adequate for basic selection and invocation but has clear gaps for a fully informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema, such as listing aggregation types already in the enum. It does not clarify how filter interacts with aggregationType or the exact format of time parameters, but the schema already covers these.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates log data for a time range using a specified aggregation type, providing a specific verb and resource. It implicitly distinguishes from search_logs by focusing on aggregation rather than raw retrieval, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for statistical analysis of logs' implies when to use the tool, but it does not explicitly contrast with alternatives like search_logs or query_metrics, nor does it provide exclusions or prerequisites. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it returns matching log entries, which is basic. It does not mention any constraints like result ordering, pagination, or the fact that it is a read-only operation. The behavior is largely implicit from the verb 'Search' and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences totaling 18 words. It front-loads the verb 'Search' and provides essential context. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters and defaults. The description captures the core function but does not differentiate from sibling log tools or explain the output format. For a simple search tool with no output schema, it is adequate but could be improved with usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the description is not required to add much. It mentions 'filters and a time range' which maps to filter, from, and to, but adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Search' with 'Datadog logs' as the resource, clearly indicating the action. It includes filters and time range as parameters, and states it returns matching log entries. It could better distinguish from sibling tools like aggregate_logs or get_log_details, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'useful for debugging and log analysis,' implying when to use it, but does not provide explicit guidance on when not to use it or mention alternatives such as get_log_details or aggregate_logs. This is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists metric types returned. It does not state that it is a read-only operation, mention authentication or rate limits, or clarify whether data is aggregated over the time range or returned as a time series.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no filler. The first sentence front-loads the action and resource, while the second adds a use case, making every sentence meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with four parameters and no output schema or annotations. Although the description lists the health metrics returned, it does not explain the response structure (e.g., snapshot vs. time series) or behavior over time ranges, leaving notable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters with 100% coverage, so the description does not need to repeat parameter details. The mention of latency, error rate, and throughput adds context, but it does not enhance parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'health metrics for a service', listing concrete metrics like latency, error rate, and throughput. It is clear and specific but does not explicitly distinguish itself from sibling tools such as query_metrics or get_monitor_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for monitoring service performance and health status' provides clear context for when to use this tool. However, it does not mention when not to use it or suggest alternatives, such as query_metrics for broader metric analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the search intent without mentioning result limits, matching behavior (partial/fuzzy), pagination, or any side effects. For a search tool, this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the primary action and resource, and provides a clear use case. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema and no annotations, the description is adequate but sparse. It explains what it does and when to use it, but does not describe return format or any behavioral quirks, which could be relevant given the absence of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both 'query' and 'tags.' The description adds no additional parameter meaning beyond what the schema already provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'searches for monitors by name or other criteria,' using a specific verb and resource. It distinguishes itself from 'list_monitors' by focusing on search, but does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'useful for finding specific monitors when you don't remember the exact ID.' This gives the agent a concrete scenario, though it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses the return content (timestamps, comments, metadata) but does not explicitly confirm read-only nature or handle edge cases. However, the verb 'Get' implies a read operation, and the simplicity mitigates the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no redundant information. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get tool, the description adequately explains the purpose and return value. It mentions key output fields, but lacks explicit error/not-found behavior. Given its low complexity, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for eventId with a clear description. The tool description does not add additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a specific event, using a specific verb and resource. It distinguishes from list/search tools by implying singular retrieval, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit. It suggests using when full event details are needed for a known event ID, but doesn't provide when-not conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return contents ('full log data including all attributes and metadata'), but does not mention error behavior, permissions, or any side effects (though 'get' implies read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler, front-loading the action and quickly conveying the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the small parameter count and lack of output schema or annotations, the description gives a high-level return description but omits details about return structure, error handling, or usage context. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—the schema already clearly documents logId as 'Unique identifier of the log entry to retrieve'. The description adds no parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource 'log entry' and scope ('specific', 'full log data'), clearly distinguishing it from sibling search or aggregation tools. It is precise and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific log ID is known and full details are needed, but it offers no explicit when-to-use/when-not-to-use guidance or references to alternative tools like search_logs or aggregate_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that the search is a read-only operation, nor does it mention pagination, response format, or any limitations. The description mostly repeats the purpose without adding behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the core action, and the second adds useful context about event types and use cases. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the basic purpose and use case but omits details about return values, pagination, or how to handle results. It is a minimal viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with 100% coverage. The description adds context about event types, but it does not provide additional per-parameter meaning beyond what the schema includes, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search for events') and a clear resource ('events in Datadog'), followed by concrete examples of event types. This clearly distinguishes it from sibling tools like search_logs, which deal with a different data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that it is 'useful for understanding system changes and incidents,' providing a clear use case context. However, it does not explicitly mention when not to use it or suggest alternative tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load. It usefully discloses the data source (trace data), time range, and bidirectional dependency scope. However, it does not mention potential errors, return format, or any limitations, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and scope with all key details, and the second adds a brief use case. No filler or redundancy, appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only dependency map tool, the description clearly defines resource, time range, and included relationships, which is sufficient despite no output schema. It slightly loses a point for not stating what happens if no dependencies exist or if the service is not found, but overall it adequately prepares the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all three parameters with descriptive text, including examples and format notes. The description adds no extra parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the APM service dependency map for a service over a time range, specifying both incoming and outgoing dependencies. This specific verb+resource+scope distinguishes it from siblings like get_service_dependencies or get_service_dependencies_multi_env.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general use case ('Useful for understanding service interactions') but does not explicitly contrast with sibling tools such as get_service_dependencies or query_traces. Guidance is implied rather than explicit, so it lacks clear alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the type of data returned (units, description, tags, integration information) but does not explicitly state that the operation is read-only, mention any required permissions, or describe error behavior. The read-only nature is logical but not explicitly stated, so it falls short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that front-loads the verb and resource. It is concise without unnecessary words and effectively communicates the tool's purpose in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers the return values by listing what metadata is included. It doesn't explain response format or error cases, but given the low complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter (metricName is described as 'Name of the metric to get metadata for'). The description adds no additional meaning or syntax details beyond what's in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('metadata about a Datadog metric'), with specific content areas ('units, description, tags, and integration information'). This is specific enough to distinguish from sibling tools like query_metrics (which queries time-series data) and list_metrics (which lists metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (retrieving metadata rather than querying metric data) but does not explicitly state when to prefer this tool over alternatives such as query_metrics or list_metrics. No exclusions or context are provided, so it only partially guides the agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the response includes alert status, downtime, and historical state changes, which adds insight beyond the tool name. However, it does not mention permissions, rate limits, failure behavior, or the exact response format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes valuable specifics without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one required parameter and no output schema, so the description is largely responsible for conveying what the agent can expect. It covers the key data points (alert status, downtime, historical state changes), which is sufficient for a straightforward status retrieval tool, though a brief note on response shape would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the single parameter monitorId with a clear description. The tool description adds no additional parameter-level detail beyond implying the monitor must be identified, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'status information for a specific monitor'. It also lists concrete details (alert status, downtime information, historical state changes), which clearly distinguishes it from sibling tools like list_monitors or search_monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need detailed status for a single monitor (as opposed to listing or searching monitors), and the 'specific monitor' wording signals that a monitorId is required. However, it does not explicitly state when not to use it or mention alternative tools for related needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful context by noting the return is time-series data aggregated over the period. However, it omits behavioral details such as pagination, error conditions, rate limits, or how aggregation is computed, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the action and output. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the well-documented schema and the tool's straightforward nature, the description is sufficient for basic invocation. It mentions the return type, which is helpful, though without an output schema, a bit more detail on the response format would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all four parameters. The description's reference to 'specified time range' adds no additional semantic value beyond what the schema already specifies, so the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries Datadog metrics data for a specified time range, with a specific verb and resource. It distinguishes from sibling tools like query_traces (traces) and get_metric_metadata (metadata), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (querying metrics over a time range) but does not explicitly mention when to prefer this over alternatives like list_metrics or get_metric_metadata. No exclusions or prerequisites are stated, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the tool is a 'Get' operation (implying read-only) and says it 'returns service relationships,' but it does not detail potential errors, permission requirements, or output structure. This is acceptable for a simple read tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose. It wastes no words and effectively communicates the tool's function and typical use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is sufficiently complete for basic understanding. However, it leaves out details such as the exact return format and behavior for invalid environments, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the parameter documentation, including an example. The description adds no additional parameter detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('service dependencies') plus the distinguishing scope ('across multiple environments'). This differentiates it from siblings like get_service_dependencies and get_apm_service_dependencies by emphasizing multi-environment support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating it is 'useful for comparing architectures across prod, staging, dev, etc.', which implies when to use it. However, it does not explicitly mention alternative tools or when not to use it, stopping short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the optional filtering behavior but does not mention authentication requirements, response format, pagination, or other behavioral traits. For a listing tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and the schema covers everything. The description provides purpose and usage context. It lacks a note about return format, but with no output schema and a low-complexity tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both 'limit' and 'query' are fully described. The description adds no information beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List available Datadog metrics', which is a specific verb+resource, and clarifies the optional search filter. This clearly distinguishes it from sibling tools like query_metrics and get_metric_metadata, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for discovering what metrics are available in your environment' provides clear context for when to use this tool. However, it does not explicitly name alternatives or give exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It explains the return data (trace data with latency and span details), which is helpful. However, it does not explicitly mention that the operation is read-only, nor does it discuss any limitations such as sampling, pagination, or required permissions. The description is adequate but not comprehensive in disclosing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short, purposeful sentences: the action, the output, and the use case. It is front-loaded with the core verb and resource, contains no redundant information, and every clause earns its place. This is an excellent example of concise, well-structured writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description provides enough context: it identifies what the tool does, what it returns, and a typical use case. It doesn't enumerate the required time range or filter syntax, but those are already detailed in the schema. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so each parameter is already fully documented. The description does not add meaning beyond the schema, instead focusing on the tool's purpose and output. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting, and the description doesn't compensate with extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Query Datadog APM traces for a service.' It specifies the resource (APM traces), the scope (for a service), and the output (trace data with latency and span details). This distinguishes it from sibling tools like query_metrics or search_logs, which operate on different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for performance debugging.' This gives context on when to use the tool. It doesn't explicitly name alternatives or state when not to use it, but the sibling tools are so distinct that the intended usage is clear. A brief exclusion would make it perfect, but the current guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-datadog MCP server](https://glama.ai/mcp/servers/micaelmalta/mcp-server-datadog/badges/card.svg)](https://glama.ai/mcp/servers/micaelmalta/mcp-server-datadog)

Score Badge

Copy to your README.md:

[![mcp-server-datadog MCP server](https://glama.ai/mcp/servers/micaelmalta/mcp-server-datadog/badges/score.svg)](https://glama.ai/mcp/servers/micaelmalta/mcp-server-datadog)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/micaelmalta/mcp-server-datadog'

If you have feedback or need assistance with the MCP directory API, please join our Discord server