Skip to main content
Glama
brukhabtu

Datadog MCP Server

by brukhabtu

GetEstimatedCostByOrg

Retrieve estimated costs for multi-org and single root-org accounts within Datadog. Access data for the current or previous month, customizable by date range, view type, and connected accounts.

Instructions

Get estimated cost across multi-org and single root-org accounts. Estimated cost data is only available for the current month and previous month and is delayed by up to 72 hours from when it was incurred. To access historical costs prior to this, use the /historical_cost endpoint.

This endpoint is only accessible for parent-level organizations.

Query Parameters:

  • view: String to specify whether cost is broken down at a parent-org level or at the sub-org level. Available views are summary and sub-org. Defaults to summary.

  • start_month: Datetime in ISO-8601 format, UTC, precise to month: [YYYY-MM] for cost beginning this month. Either start_month or start_date should be specified, but not both. (start_month cannot go beyond two months in the past). Provide an end_month to view month-over-month cost.

  • end_month: Datetime in ISO-8601 format, UTC, precise to month: [YYYY-MM] for cost ending this month.

  • start_date: Datetime in ISO-8601 format, UTC, precise to day: [YYYY-MM-DD] for cost beginning this day. Either start_month or start_date should be specified, but not both. (start_date cannot go beyond two months in the past). Provide an end_date to view day-over-day cumulative cost.

  • end_date: Datetime in ISO-8601 format, UTC, precise to day: [YYYY-MM-DD] for cost ending this day.

  • include_connected_accounts: Boolean to specify whether to include accounts connected to the current account as partner customers in the Datadog partner network program. Defaults to false.

Responses:

  • 200 (Success): OK

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • data: Response containing Chargeback Summary.

    • Example:

{
  "data": [
    "unknown_type"
  ]
}
  • 400: Bad Request

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 403: Forbidden - User is not authorized

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 429: Too many requests

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateNoDatetime in ISO-8601 format, UTC, precise to day: `[YYYY-MM-DD]` for cost ending this day.
end_monthNoDatetime in ISO-8601 format, UTC, precise to month: `[YYYY-MM]` for cost ending this month.
include_connected_accountsNoBoolean to specify whether to include accounts connected to the current account as partner customers in the Datadog partner network program. Defaults to `false`.
start_dateNoDatetime in ISO-8601 format, UTC, precise to day: `[YYYY-MM-DD]` for cost beginning this day. **Either start_month or start_date should be specified, but not both.** (start_date cannot go beyond two months in the past). Provide an `end_date` to view day-over-day cumulative cost.
start_monthNoDatetime in ISO-8601 format, UTC, precise to month: `[YYYY-MM]` for cost beginning this month. **Either start_month or start_date should be specified, but not both.** (start_month cannot go beyond two months in the past). Provide an `end_month` to view month-over-month cost.
viewNoString to specify whether cost is broken down at a parent-org level or at the sub-org level. Available views are `summary` and `sub-org`. Defaults to `summary`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoResponse containing Chargeback Summary.
Behavior4/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 effectively describes key behavioral traits: data availability constraints (current/previous month only, 72-hour delay), access restrictions (parent-level organizations only), temporal limitations (cannot go beyond two months past), and error conditions (400, 403, 429 responses). It also mentions the response format (JSON with datetime-format=rfc3339). However, it doesn't explicitly state whether this is a read-only operation or discuss rate limits beyond the 429 error, leaving some behavioral aspects implicit.

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

Conciseness2/5

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

The description is overly verbose and poorly structured. It front-loads useful information but then duplicates the entire parameter documentation from the schema, followed by extensive HTTP response details that belong in an output schema. The 'Query Parameters' and 'Responses' sections are redundant given the structured fields, making the description unnecessarily long (over 500 words) with significant waste.

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 complexity (6 parameters, no annotations, has output schema), the description is mostly complete. It covers purpose, usage guidelines, behavioral constraints, and parameter documentation. The output schema existence means it doesn't need to explain return values in detail. However, the redundancy with structured fields and inclusion of HTTP response details that should be in the output schema slightly reduces completeness, though the core information is present.

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 already documented in the input schema. The description repeats the parameter documentation verbatim in the 'Query Parameters' section, adding no additional semantic value beyond what's in the schema. This meets the baseline of 3 for high schema coverage, but doesn't compensate with extra insights like usage patterns or constraints not in the schema.

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 purpose: 'Get estimated cost across multi-org and single root-org accounts.' It specifies the exact resource (estimated cost) and scope (multi-org/single root-org accounts), and distinguishes from sibling tools by explicitly mentioning the alternative '/historical_cost' endpoint for historical data, which helps differentiate it from tools like 'GetHistoricalCostByOrg' and 'GetCostByOrg'.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool vs. alternatives: it states that estimated cost data is only available for the current and previous month with up to 72-hour delay, and directs users to use '/historical_cost' for prior historical costs. It also specifies access restrictions (parent-level organizations only) and temporal constraints (cannot go beyond two months in the past), offering clear when-to-use and when-not-to-use criteria.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

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

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