Kafka MCP

Overview Schema Source Related Servers Discussions Admin

open_transactions

Detect open Kafka transactions blocking read_committed consumers on up to 1000 topics, listing stalled partitions, hidden offsets, and the producer holding each transaction open.

Instructions

Find open transactions holding back read_committed consumers on 1 to 1000 topics in one call through items. A consumer with isolation.level=read_committed cannot read past the first message of a transaction that has not been committed or aborted, so a transactional producer that hangs or dies mid-transaction stalls every such consumer on that partition. In consumer_lag this looks exactly like a poison message: members present, nothing consumed.

For each topic, blocked says whether any partition's last stable offset trails its high watermark. Each such partition reports both offsets, how many messages read_committed consumers cannot see, and every producer with an open transaction there: producer id and epoch, the offset the transaction started at, and where the coordinator knows it, the transactional id (which names the application), state, when it started, how long it has been open and its timeout, after which the broker aborts it.

The fix is in the producer, not the consumer: restart or fence the producing application, or wait for the timeout. Skipping offsets does not help. Results follow items order, each carrying index with result or error. Needs DESCRIBE on the topic and on transactional ids.

Input Schema

Name	Required	Description	Default
`items`	Yes	The topics to check, 1 to 1000 of them. Checking one topic is an array of length one. Results follow this order and a missing topic is reported against its own item.

Output Schema

Name	Required	Description	Default
`atomic`	Yes
`failed`	Yes
`applied`	Yes
`results`	Yes
`succeeded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.7Oct 25, 2026

changedInput schema / properties / items / description

Previous value: -"The topics to check, 1 to 100 of them. Checking one topic is an array of length one. Results follow this order and a missing topic is reported against its own item."New value: +"The topics to check, 1 to 1000 of them. Checking one topic is an array of length one. Results follow this order and a missing topic is reported against its own item."

First observedv0.2.0Oct 7, 2026

TDQS

A4.6/5.0

Behavior5/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 so well: it discloses required DESCRIBE permissions, per-item success/error behavior, exact output fields (last stable offset, high watermark, producer id/epoch, transactional id, state, timing, timeout), and broker timeout-abort behavior. It also warns that skipping offsets does not help, which is valuable operational context.

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 core action and diagnostic scenario are front-loaded, and nearly every sentence adds operational value about symptoms, output, remediation, or permissions. It is dense and somewhat long for a single-parameter tool, but the length is largely justified by the complexity of the failure mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's diagnostic complexity, an output schema exists, and the description reinforces the key return concepts, permissions, and remediation guidance. An agent has enough information to select and invoke the tool correctly, including why a stalled consumer is not the cause.

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 the schema already documents the single items parameter and exact topic matching. The description still adds useful batch semantics: 1 to 1000 topics, result ordering following items order, and per-item error reporting for missing topics.

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 states a specific verb and resource ('Find open transactions') and precisely scopes it to read_committed consumers across 1 to 1000 topics via items. It explicitly distinguishes the symptom from consumer_lag's poison-message appearance, so an agent can route correctly 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?

It gives a clear diagnostic context (read_committed consumers stalled past the first message of an open transaction) and contrasts the presentation with consumer_lag. It also states the remediation path belongs to the producer, not the consumer. It stops short of an explicit 'when not to use' or a named alternative tool beyond the consumer_lag comparison.

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