Skip to main content
Glama

describe_consumer_group

Describe 1–1000 Kafka consumer groups in one call: members, partition ownership, committed offsets and lag, to find which consumer instance owns a stuck or lagging partition.

Instructions

Describe 1 to 1000 consumer groups in one call through items: state, assignor, coordinator broker, every running member (member_id, client_id, host and the partitions assigned to it), and for every partition the group owns or has committed on, the committed offset, end offset, lag, and the member, client id and host consuming it. Partitions and members are sorted.

Use it to find which consumer instance owns a stuck or lagging partition, so the operator knows which pod or host to inspect. has_commit false means the group owns the partition but never committed there, so its starting point is decided by the consumer's auto.offset.reset rather than by an offset. An Empty group has no members but keeps its commits.

sample_seconds watches the group for that long first and reports observation: the states it passed through and the members that joined or left. A group that keeps cycling through PreparingRebalance, or whose members keep changing, is rebalancing; the departing members' client_id and host point at the consumer that keeps leaving.

Results follow items order, each carrying index with result or error.

Input Schema

NameRequiredDescriptionDefault
itemsYesThe groups to describe, 1 to 1000 of them. Describing one group is an array of length one. Results follow this order and a group that does not exist is reported against its own item.

Output Schema

NameRequiredDescriptionDefault
atomicYes
failedYes
appliedYes
resultsYes
succeededYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.7
    • changedInput schema / properties / items / description
      Previous value: -"The groups to describe, 1 to 100 of them. Describing one group is an array of length one. Results follow this order and a group that does not exist is reported against its own item."New value: +"The groups to describe, 1 to 1000 of them. Describing one group is an array of length one. Results follow this order and a group that does not exist is reported against its own item."
    • addedInput schema / properties / items / items / properties / sample_seconds
      Added value: +{
      +  "description": "Optional number of seconds, at most 60, to watch the group before describing it. The group is read every second; observation then reports every state it passed through, and the members that joined or left. Use it when a group seems to keep rebalancing. The call blocks this long. Defaults to 0, no observation.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / results / items / properties / result / properties / observation
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "joined": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "assignments": {
      +            "items": {
      +              "additionalProperties": false,
      +              "properties": {
      +                "partitions": {
      +                  "items": {
      +                    "maximum": 2147483647,
      +                    "minimum": -2147483648,
      +                    "type": "integer"
      +                  },
      +                  "type": [
      +                    "null",
      +                    "array"
      +                  ]
      +                },
      +                "topic": {
      +                  "type": "string"
      +                }
      +              },
      +              "required": [
      +                "topic",
      +                "partitions"
      +              ],
      +              "type": "object"
      +            },
      +            "type": [
      +              "null",
      +              "array"
      +            ]
      +          },
      +          "client_id": {
      +            "type": "string"
      +          },
      +          "host": {
      +            "type": "string"
      +          },
      +          "instance_id": {
      +            "type": "string"
      +          },
      +          "member_id": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "member_id",
      +          "client_id",
      +          "host",
      +          "assignments"
      +        ],
      +        "type": "object"
      +      },
      +      "type": [
      +        "null",
      +        "array"
      +      ]
      +    },
      +    "left": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "assignments": {
      +            "items": {
      +              "additionalProperties": false,
      +              "properties": {
      +                "partitions": {
      +                  "items": {
      +                    "maximum": 2147483647,
      +                    "minimum": -2147483648,
      +                    "type": "integer"
      +                  },
      +                  "type": [
      +                    "null",
      +                    "array"
      +                  ]
      +                },
      +                "topic": {
      +                  "type": "string"
      +                }
      +              },
      +              "required": [
      +                "topic",
      +                "partitions"
      +              ],
      +              "type": "object"
      +            },
      +            "type": [
      +              "null",
      +              "array"
      +            ]
      +          },
      +          "client_id": {
      +            "type": "string"
      +          },
      +          "host": {
      +            "type": "string"
      +          },
      +          "instance_id": {
      +            "type": "string"
      +          },
      +          "member_id": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "member_id",
      +          "client_id",
      +          "host",
      +          "assignments"
      +        ],
      +        "type": "object"
      +      },
      +      "type": [
      +        "null",
      +        "array"
      +      ]
      +    },
      +    "samples": {
      +      "type": "integer"
      +    },
      +    "seconds": {
      +      "type": "integer"
      +    },
      +    "states": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": [
      +        "null",
      +        "array"
      +      ]
      +    },
      +    "unstable": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "seconds",
      +    "samples",
      +    "states",
      +    "joined",
      +    "left",
      +    "unstable"
      +  ],
      +  "type": [
      +    "null",
      +    "object"
      +  ]
      +}
  2. First observedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it explains 'has_commit false' semantics, what an Empty group means, that sample_seconds blocks the call while observing, and that members/partitions are sorted with results returned in items order plus index. It omits cost/read-only framing and limits on describing 1000 groups at once, so it stops short of full disclosure.

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?

Front-loaded with the verb, resource, and payload, then usage, then edge-case semantics. Mostly earns its length, though a few clauses (sorting, result indexes) are minor and the second paragraph could be tightened.

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?

An output schema already exists, yet the description still explains the domain interpretation of results (has_commit, Empty groups, rebalance detection), which is genuinely useful for a Kafka operator. Gaps are minor: no statement of read-only safety or the latency cost of large items arrays with sample_seconds.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains what sample_seconds observation reports (states passed through, members joined/left) and how to read it as a rebalance signal. Items ordering and per-item result/error behavior are also clarified beyond the schema text.

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?

States a specific verb and resource ('Describe 1 to 1000 consumer groups in one call') and immediately enumerates the returned facts (state, assignor, coordinator, members, offsets, lag), which clearly separates it from list_consumer_groups or consumer_lag. An agent can identify the tool without opening the schema.

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?

Gives an explicit operational scenario: 'Use it to find which consumer instance owns a stuck or lagging partition, so the operator knows which pod or host to inspect.' However, it never names alternatives (consumer_lag, list_consumer_groups) or states when to use those instead.

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