Kafka MCP

Overview Schema Source Related Servers Discussions Admin

open_transactions

Detect uncommitted Kafka transactions blocking read_committed consumers on up to 100 topics, then report producer, offsets, and timeout to guide fixing the producer.

Instructions

Find open transactions holding back read_committed consumers on 1 to 100 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

TableJSON Schema

Name	Required	Description	Default
`items`	Yes	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.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does: it explains why the condition matters (consumers cannot read past the first message of an uncommitted transaction), details what each result field conveys (blocked flag, both offsets, hidden message count, producer id/epoch, transactional id, state, age, timeout), and states the required DESCRIBE permissions. This is far more than a restatement of the tool name.

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 purpose and the differential-vs-consumer_lag point are front-loaded, and subsequent sentences each carry operational payload (output fields, remediation, permissions). It is on the longer side and some sentences (e.g. the producer-side fix) are advisory rather than selection-critical, but nothing is truly wasted.

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?

For a read-only diagnostic tool, the description covers the trigger scenario, the output interpretation, the required permissions, and result ordering. An output schema exists, yet the description still maps the meaningful fields an agent needs for diagnosis, leaving no material gap.

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% for the single items/topic parameter, and the schema already documents exact case-sensitive matching and the order-preservation behavior. The description reinforces the 1-to-100 scope and per-item error reporting but adds little syntax or semantics beyond what the schema already states, so the baseline of 3 applies.

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 ('Find open transactions') plus the exact condition of interest ('holding back read_committed consumers'). It further differentiates itself from the sibling tool consumer_lag by noting how the symptom presents there ('members present, nothing consumed'). An agent can pick this out without opening any 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?

Provides strong differential-diagnosis context: read_committed consumers stall on uncommitted transactions, and 'In consumer_lag this looks exactly like a poison message,' which routes the agent from a lag symptom to this diagnostic tool. It also advises on the remediation path (producer-side, not consumer). It stops short of an explicit 'use X when, use this when not Y' statement, so not quite a 5.

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