Datadog MCP Server

Server Quality Checklist

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

Latest release: v0.0.6
Disambiguation4/5
Most tools have distinct purposes, but there is some potential for confusion between get_logs and get_metrics, as both involve data retrieval with filtering, though they target different data types (logs vs. metrics). The get_metric_fields and get_metric_field_values tools are also closely related, but their descriptions clarify the distinction between listing fields and their values.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, with clear prefixes like 'get_' for retrieval actions and 'list_' for listing actions. This consistency makes it easy to predict tool functionality and navigate the set without confusion.
Tool Count5/5
With 13 tools, the count is well-scoped for a Datadog integration, covering key areas like logs, metrics, services, monitors, and SLOs. Each tool appears to serve a specific purpose without unnecessary duplication, fitting the server's monitoring and observability domain appropriately.
Completeness4/5
The tool set provides good coverage for data retrieval and listing in Datadog's core areas, but there are minor gaps such as the lack of update or delete operations for resources like monitors or SLOs, which might limit full lifecycle management. However, the available tools support essential discovery and querying workflows effectively.
Average 3.1/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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 provided, the description carries the full burden of behavioral disclosure but only states what the tool does without mentioning permissions, rate limits, pagination behavior (beyond the cursor param in schema), or output format. This is inadequate for a tool with 5 parameters and no output 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, output format, and usage context, making it insufficient for an agent to fully understand how to invoke and interpret results effectively.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying filtering by repositories/services, which is covered in the schema. This meets 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 action ('Get') and resource ('unique pipeline fingerprints for specific repositories/services'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'list_ci_pipelines' or 'get_logs', which might also retrieve pipeline-related data, so it misses 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.
Usage Guidelines2/5
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 like 'list_ci_pipelines' or 'get_logs'. It mentions 'specific repositories/services' but doesn't clarify prerequisites, exclusions, or comparative contexts, leaving usage ambiguous.
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 mentions 'optional filtering' but doesn't describe key behaviors like pagination (implied by the cursor parameter but not explained), rate limits, authentication requirements, or what the output looks like (especially given no output schema). For a list operation with 6 parameters, this leaves significant gaps in understanding how the tool behaves.
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 core purpose ('List CI pipelines from Datadog CI Visibility') and adds a useful qualifier ('with optional filtering'). There is no wasted language, and it's appropriately sized for a list operation with filtering capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain the output format (e.g., what data is returned, structure), pagination behavior (cursor usage), or error handling. For a tool that likely returns structured data from a CI system, more context is needed to help the agent use it effectively.
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%, meaning all parameters are well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'optional filtering,' but it doesn't provide additional context like typical use cases for filters or interactions between parameters. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 ('List') and resource ('CI pipelines from Datadog CI Visibility'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_pipeline_fingerprints' or 'list_metrics', which could also relate to pipelines or CI data. The optional filtering mention is helpful but doesn't provide sibling 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 provides no guidance on when to use this tool versus alternatives like 'get_pipeline_fingerprints' or other sibling tools. While it mentions optional filtering, it doesn't specify scenarios where this tool is preferred over others, nor does it mention any prerequisites or exclusions. The agent receives no contextual usage instructions.
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 full burden for behavioral disclosure. It states this is a list operation but doesn't mention pagination behavior (though the schema does), rate limits, authentication requirements, or what happens when no monitors match filters. It only provides basic functional context about monitors.
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 appropriately concise with two sentences. The first sentence states the core purpose, and the second adds helpful context about monitors. There's no wasted text, though it could be slightly more structured for tool selection.
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 list tool with no annotations and no output schema, the description provides basic functional context but lacks important behavioral details like pagination handling, error conditions, or output format guidance. The 100% schema coverage helps, but the description itself is incomplete for agent usage.
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 already fully documents all 6 parameters. The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.
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 ('List') and resource ('all monitors from Datadog'), and provides context about what monitors are used for. However, it doesn't specifically differentiate this tool from sibling tools like 'list_metrics' or 'list_slos' beyond mentioning monitors are for alerting.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or any specific contexts where this tool is preferred over others. The only usage context is the generic explanation of what monitors are used for.
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 describes what SLOs are but doesn't cover key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or the structure of returned data. For a tool with no annotations, this is a significant gap in transparency.
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 appropriately concise with two sentences: one stating the tool's purpose and another explaining SLOs. It's front-loaded with the core functionality. However, the second sentence, while informative, could be considered slightly extraneous if the agent already understands SLOs, but it doesn't significantly detract from efficiency.
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 tool's complexity (5 parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects, usage context, and output format. Without annotations or an output schema, the description should do more to compensate, but it meets a basic threshold without being 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 description coverage is 100%, meaning all parameters are well-documented in the input schema. The description adds no additional parameter information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 ('List') and resource ('Service Level Objectives (SLOs) from Datadog'), and provides a brief explanation of what SLOs are. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_monitors' or 'list_metrics', which could also involve listing Datadog resources. The purpose is clear but lacks sibling 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts where listing SLOs is appropriate. Usage is implied by the name and description but not explicitly stated, leaving gaps for an AI agent to infer.
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 states the tool retrieves 'possible values' but doesn't clarify whether this is a read-only operation, if it requires specific permissions, how it handles large datasets, or what the output looks like (e.g., format details beyond the 'format' parameter). For a tool with 5 parameters and no annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does and its utility, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.
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 tool's moderate complexity (5 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output expectations. Without annotations or an output schema, the agent must infer too much, making this minimally viable but 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?
Schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself (e.g., 'field_name' includes examples, 'time_range' has an enum). The description adds minimal value beyond this, as it doesn't explain parameter interactions or provide additional context like why certain fields are listed. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Get possible values for a specific log field to understand filtering options'. It specifies the verb ('Get'), resource ('possible values for a specific log field'), and context ('to understand filtering options'). However, it doesn't explicitly differentiate from sibling tools like 'get_logs' or 'get_metric_field_values', which prevents a perfect score.
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 provides minimal guidance, mentioning only that it helps 'understand filtering options'. It doesn't specify when to use this tool versus alternatives like 'get_logs' (which might retrieve actual logs) or 'get_metric_field_values' (for metrics), nor does it mention prerequisites or exclusions. This lack of explicit context limits its utility for an agent.
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 states the tool retrieves values for discovery, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or response format details. This is a significant gap for a tool with no annotation coverage.
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 core action and purpose without any wasted words. It directly communicates what the tool does and why, making it highly concise and well-structured.
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 no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It clarifies the tool's purpose but lacks behavioral details like response format or operational constraints. For a tool with moderate complexity (3 parameters, no output schema), it should provide more context to be 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?
Schema description coverage is 100%, so the schema fully documents all three parameters with descriptions and an enum for 'format'. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 ('Get all possible values') and resource ('for a specific field of a metric from Datadog'), with the purpose 'to discover available dimensions'. It distinguishes from siblings like 'get_metric_fields' (which likely lists fields rather than values) and 'list_metrics' (which lists metrics). However, it doesn't explicitly contrast with 'get_logs_field_values' for logs versus metrics, keeping it from a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_metric_fields' (for listing fields) or 'get_logs_field_values' (for logs), nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context for selection.
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 states the tool 'execute[s] metric queries' which implies a read operation, but doesn't disclose important behavioral traits like whether it requires specific authentication, has rate limits, returns paginated results, or what happens on errors. The description mentions building and executing the query but lacks operational context needed for safe and effective use.
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 appropriately concise with two sentences that efficiently convey the core functionality. The first sentence states the purpose, the second provides basic parameter guidance. No wasted words, though it could be slightly more front-loaded with key behavioral information given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters including nested objects), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (metrics data in various formats), doesn't mention authentication requirements, rate limits, or error handling. For a query tool with this parameter complexity and no structured safety/behavior annotations, the description should provide more operational context.
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 already documents all 6 parameters thoroughly with descriptions, enums, defaults, and examples. The description adds minimal value beyond the schema - it mentions 'metric name and optional filters/aggregations' which is already clear from the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Execute metric queries on Datadog' with specific verb ('execute') and resource ('metric queries'). It distinguishes from some siblings like 'list_metrics' (which likely lists available metrics rather than querying them) but doesn't explicitly differentiate from 'get_metric_fields' or 'get_metric_field_values' which are related to metric metadata.
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 implied usage guidance by mentioning 'Specify the metric name and optional filters/aggregations' which suggests when to use this tool (for querying metrics with specific parameters). However, it doesn't explicitly state when to use this vs. alternatives like 'list_metrics' (for listing available metrics) or 'get_metric_fields' (for discovering queryable fields). No explicit exclusions or prerequisites are mentioned.
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. While it indicates this is a retrieval operation (implying read-only), it doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens when the service doesn't exist. The description is too minimal for a tool that interacts with an external API.
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 perfectly concise - two sentences that efficiently convey the tool's purpose and what the retrieved definition contains. Every word earns its place with no redundancy or unnecessary elaboration.
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 read operation with good schema coverage but no annotations or output schema, the description is minimally adequate. It explains what the tool retrieves but lacks important context about the return format (despite the 'format' parameter), error handling, or relationship to sibling tools. The absence of an output schema means the description should ideally provide more guidance about what to expect from the response.
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% description coverage, providing clear documentation for all three parameters. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation but doesn't provide additional value.
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 ('Retrieve') and resource ('definition of a specific service from Datadog'), and specifies what the definition contains ('metadata, ownership, and configuration details'). However, it doesn't explicitly differentiate this tool from its sibling 'list_service_definitions', which appears to be a related listing operation.
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 provides no guidance on when to use this tool versus alternatives like 'list_service_definitions' or other sibling tools. It mentions what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
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. While 'Get' implies a read operation, the description doesn't mention authentication requirements, rate limits, pagination behavior (beyond what's in the schema), error conditions, or what happens when no teams match the criteria. For a tool with 5 parameters and no annotation coverage, this is insufficient.
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 gets straight to the point with zero wasted words. It's appropriately sized for a listing tool and front-loads the essential information without unnecessary elaboration.
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 read-only listing tool with comprehensive schema documentation (100% coverage) but no output schema, the description is minimally adequate. It identifies the resource but doesn't explain what the return values look like, how results are structured, or provide context about the Datadog teams concept. The absence of annotations means more behavioral context would be helpful.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'teams and their members' which aligns with the 'include_members' parameter, but adds no additional semantic context beyond what's already in the parameter descriptions. This meets 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 action ('Get') and resource ('Datadog teams and their members'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_monitors' or 'list_slos' in terms of what makes team retrieval distinct from other listing operations in the Datadog context.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_monitors' and 'list_slos' available, there's no indication of whether this is the primary team listing tool or if there are specific scenarios where it should be preferred over other listing operations.
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 mentions 'search and retrieve' and 'flexible filtering,' but doesn't disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (beyond the cursor parameter in schema), or what the output looks like. For a tool with 6 parameters and no annotations, this is a significant gap in 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 appropriately sized and front-loaded: it states the core purpose in the first sentence and adds sibling differentiation in the second. Every sentence earns its place with no wasted words, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain return values, error handling, or behavioral constraints, leaving gaps that could hinder correct tool invocation. For a search tool with multiple parameters and no structured output documentation, more context is needed to be 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 description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds minimal value beyond the schema by implying flexible filtering but doesn't provide additional syntax, format details, or usage examples for parameters. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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's purpose: 'Search and retrieve logs from Datadog with flexible filtering parameters.' It specifies the verb (search and retrieve), resource (logs from Datadog), and scope (with flexible filtering). It distinguishes from sibling 'get_metrics' by specifying 'for log data.' However, it doesn't explicitly differentiate from other log-related siblings like 'get_logs_field_values,' so it's not a perfect 5.
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 implied usage guidance by mentioning it's 'similar to get_metrics but for log data,' which helps differentiate from one sibling. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_logs_field_values' or other log-related tools, nor does it provide context on prerequisites or exclusions. This is basic differentiation without comprehensive 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 full burden. It mentions the tool helps with aggregation queries, but doesn't disclose behavioral traits like whether it's read-only, rate limits, authentication needs, or what the output looks like (e.g., list of fields). This leaves gaps for a tool with no annotation coverage.
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 purpose and includes the key details (action, resource, purpose). There's no wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is incomplete. It doesn't explain the return values, behavioral constraints, or fully compensate for the lack of structured data, leaving the agent with insufficient context for safe and effective use.
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 all three parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the 'time_range' parameter's limited use or 'format' implications. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Get available fields/tags'), the resource ('for a specific metric from Datadog'), and the purpose ('to help with aggregation queries'). It distinguishes itself from siblings like 'get_metrics' (list metrics) and 'get_metric_field_values' (get values for fields), though it doesn't explicitly name these 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 implies usage for aggregation queries, suggesting when to use it, but doesn't provide explicit guidance on when not to use it or name specific alternatives like 'get_metric_field_values' for field values. It lacks prerequisites or exclusions.
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 full burden but only states it's for 'discovering metrics' without disclosing behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what the response format looks like. It mentions pagination indirectly through the cursor parameter but doesn't explain the pagination behavior.
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 with zero waste - the first states the purpose, the second provides usage guidance. Every word earns its place, and the most important information (what the tool does) is front-loaded.
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 tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has gaps. It explains the purpose and relationship to get_metrics, but doesn't address behavioral aspects like safety, performance, or response format that would be helpful given the lack of annotations.
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 already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does all the work.
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's purpose: 'List all available metrics from Datadog' with the specific verb 'List' and resource 'metrics'. It distinguishes from sibling 'get_metrics' by noting it's for discovery before querying, but doesn't explicitly differentiate from other list_* tools like list_monitors or list_slos.
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 clear context: 'Useful for discovering metrics before querying them with get_metrics.' This gives explicit guidance on when to use this tool versus its sibling 'get_metrics', but doesn't mention when not to use it or alternatives among other list_* tools.
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 full burden. It mentions 'List all' which suggests a read-only operation, but doesn't disclose behavioral traits like pagination details (implied by parameters), rate limits, authentication needs, or what happens with large datasets. The description adds basic context about what service definitions are, but lacks operational guidance.
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, front-loaded with the core purpose ('List all service definitions from Datadog') followed by explanatory context. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 4 parameters with full schema coverage but no annotations and no output schema, the description is adequate for a list operation but lacks completeness. It doesn't cover output format details (e.g., what 'table' vs 'json' returns), error handling, or integration with sibling tools, leaving gaps for an agent to infer behavior.
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 parameters are well-documented in the schema. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how pagination works or format differences). Baseline score of 3 is appropriate since the schema handles parameter documentation effectively.
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 verb ('List all') and resource ('service definitions from Datadog'), and explains what service definitions are ('describe the structure, ownership, and metadata of services in your organization'). It distinguishes from siblings like 'get_service_definition' (singular) by emphasizing 'all' and listing rather than retrieving a specific one.
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 for retrieving service definitions broadly, but doesn't explicitly state when to use this tool versus alternatives like 'get_service_definition' (for a specific service) or other list tools (e.g., 'list_monitors'). No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.
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:

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

Score Badge

Copy to your README.md:

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

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/shelfio/datadog-mcp'

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