Skip to main content
Glama
brukhabtu

Datadog MCP Server

by brukhabtu

ListLogsGet

Search, filter, and retrieve logs from Datadog’s observability platform using query parameters like timestamp, indexes, and storage tier. Paginate results for efficient log management.

Instructions

List endpoint returns logs that match a log search query. .

Use this endpoint to search and filter your logs.

If you are considering archiving logs for your organization, consider use of the Datadog archive capabilities instead of the log list API. See .

Query Parameters:

  • filter[query]: Search query following logs syntax.

  • filter[indexes]: For customers with multiple indexes, the indexes to search. Defaults to '*' which means all indexes

  • filter[from]: Minimum timestamp for requested logs.

  • filter[to]: Maximum timestamp for requested logs.

  • filter[storage_tier]: Specifies the storage type to be used

  • sort: Order of logs in results.

  • page[cursor]: List following results with a cursor provided in the previous query.

  • page[limit]: Maximum number of logs in the response.

Responses:

  • 200 (Success): OK

    • Content-Type: application/json

    • Response Properties:

      • data: Array of logs matching the request.

    • Example:

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

    • Content-Type: application/json

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 403: Not Authorized

    • Content-Type: application/json

    • Response Properties:

      • errors: A list of errors.

    • Example:

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

    • Content-Type: application/json

    • Response Properties:

      • errors: A list of errors.

    • Example:

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filter[from]NoMinimum timestamp for requested logs.
filter[indexes]NoFor customers with multiple indexes, the indexes to search. Defaults to '*' which means all indexes
filter[query]NoSearch query following logs syntax.
filter[storage_tier]NoSpecifies storage type as indexes, online-archives or flexindexes
filter[to]NoMaximum timestamp for requested logs.
page[cursor]NoList following results with a cursor provided in the previous query.
page[limit]NoMaximum number of logs in the response.
sortNoSort parameters when querying logs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoArray of logs matching the request.
metaNo
linksNo
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 behaviors: pagination of results (with a link to documentation), search and filtering capabilities, and error handling for common status codes (400, 403, 429). However, it doesn't mention rate limits, authentication requirements, or performance characteristics, 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.

Conciseness2/5

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

The description is overly verbose and poorly structured. It includes extensive HTTP response details (status codes, content types, examples) that are redundant with an output schema, and repeats parameter information already in the schema. The core purpose and usage guidance are buried among unnecessary details, making it inefficient for an AI agent to parse quickly.

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 (8 parameters, search functionality) and the presence of an output schema, the description is moderately complete. It covers purpose, usage guidelines, and basic behavior, but the excessive detail in responses and parameter repetition detracts from clarity. The output schema reduces the need for response documentation, yet the description still includes it, creating redundancy rather than adding value.

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 parameters thoroughly. The description includes a 'Query Parameters' section that repeats much of the schema information, adding minimal value beyond restating defaults and basic meanings. It provides some context like 'Defaults to '*' which means all indexes' for filter[indexes], but overall doesn't significantly enhance parameter understanding beyond 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 with specific verbs ('list', 'search', 'filter') and resources ('logs'), and distinguishes it from sibling tools by focusing on log search functionality. The first sentence explicitly defines it as returning logs matching a log search query, which is distinct from other log-related tools like GetLogsArchive or ListLogsArchives.

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 (to search and filter logs) and when not to use it (for archiving logs, directing users to Datadog archive capabilities instead). It clearly states an alternative (archive capabilities) and references documentation, offering comprehensive usage context.

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