Skip to main content
Glama
brukhabtu

Datadog MCP Server

by brukhabtu

ListUsers

Retrieve and manage a comprehensive list of all users in your organization, including deactivated or unverified accounts, with customizable filtering, sorting, and pagination options.

Instructions

Get the list of all users in the organization. This list includes all users even if they are deactivated or unverified.

Query Parameters:

  • page[size]: Size for a given page. The maximum allowed value is 100.

  • page[number]: Specific page number to return.

  • sort: User attribute to order results by. Sort order is ascending by default. Sort order is descending if the field is prefixed by a negative sign, for example sort=-name. Options: name, modified_at, user_count.

  • sort_dir: Direction of sort. Options: asc, desc.

  • filter: Filter all users by the given string. Defaults to no filtering.

  • filter[status]: Filter on status attribute. Comma separated list, with possible values Active, Pending, and Disabled. Defaults to no filtering.

Responses:

  • 200 (Success): OK

    • Content-Type: application/json

    • Response Properties:

      • data: Array of returned users.

      • included: Array of objects related to the users.

    • Example:

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

    • Content-Type: application/json

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 403: Authentication error

    • 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
filterNoFilter all users by the given string. Defaults to no filtering.
filter[status]NoFilter on status attribute. Comma separated list, with possible values `Active`, `Pending`, and `Disabled`. Defaults to no filtering.
page[number]NoSpecific page number to return.
page[size]NoSize for a given page. The maximum allowed value is 100.
sortNoUser attribute to order results by. Sort order is ascending by default. Sort order is descending if the field is prefixed by a negative sign, for example `sort=-name`. Options: `name`, `modified_at`, `user_count`.name
sort_dirNoDirection of sort.desc

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoArray of returned users.
metaNo
includedNoArray of objects related to the users.
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 of behavioral disclosure. It effectively describes the tool as a read operation ('Get') and includes pagination details (page size/number), sorting, and filtering capabilities. However, it lacks information on authentication requirements, rate limits, or error handling specifics beyond HTTP codes, leaving some behavioral aspects unclear.

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 the purpose but then redundantly lists parameters already covered in the schema and includes extensive HTTP response details that could be omitted or summarized. The inclusion of full JSON examples for error responses adds unnecessary length without proportional value.

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 (6 parameters, pagination, filtering), the description is reasonably complete. It explains the scope (includes all users), parameter usage, and response structure. With an output schema likely present (implied by context signals), the detailed response documentation is somewhat redundant but still contributes to completeness for a list operation.

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 repeats parameter details in the 'Query Parameters' section, adding no significant meaning beyond what the schema provides. This meets the baseline score of 3 for high schema coverage, but doesn't enhance understanding.

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 ('Get') and resource ('list of all users in the organization'), specifying it includes deactivated or unverified users. This distinguishes it from potential sibling tools like 'GetUser' which likely retrieves a single user, making the purpose specific and well-differentiated.

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. While it mentions including deactivated/unverified users, it doesn't specify scenarios where this is preferable or when to choose other tools like 'GetUser' or 'ListUserOrganizations'. No explicit when/when-not statements or alternative recommendations are present.

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