Kafka MCP

Overview Schema Source Related Servers Discussions Admin

produce_message

Publish up to 20 new messages with keys, values and headers to existing Kafka topics, encoding to registry schemas when needed. Set confirm to true to write.

Instructions

Write 1 to 20 new messages in one call through items, to existing topics on this or another configured cluster. The caller supplies the key, value and headers, so unlike copy_message this can write content no producer ever sent. Writing one message is an items array of length one.

Every message carries provenance headers naming this tool, the time and the principal, so a fabricated message stays distinguishable from a genuine one.

Nothing is written unless confirm is true; one confirm covers the whole batch, and writing is not atomic because Kafka cannot retract a record produced before a later item failed. Results follow items order, each carrying index with result or error.

A produced message cannot be deleted: it stays until retention removes it, and any consumer reading the topic will process it. The destination must be writable and requires Kafka write permission; the endpoint you call may itself be read-only.

Omit partition unless the exact partition matters. The key decides placement, and naming a partition puts a keyed message where its key does not hash to, which breaks ordering for that key.

A topic whose consumers read Avro, Protobuf or JSON Schema needs value_schema: give the value as JSON and it is encoded to the destination registry's schema, refused with the offending field when it does not fit. A topic with a format configured in topic_formats is encoded to it without being asked. Check get_message or sample_messages first: a schema_id on the existing messages means the topic needs value_schema, and writing plain JSON there breaks its consumers.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes	The messages to write, 1 to 20 of them. Writing one message is an array of length one. Two identical items mean two messages, which is allowed: appending the same payload twice is a real request.
`confirm`	No	Optional. When false or omitted, nothing is written and the response shows the messages that would be produced. Must be true to actually write them. One confirm covers the whole batch.

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.8/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 discharges it: nothing is written unless confirm=true, one confirm covers the batch, the write is non-atomic (Kafka cannot retract), produced records cannot be deleted and will be consumed, destination must be writable and needs write permission, the endpoint may be read-only, and provenance headers make fabricated messages distinguishable. This is exactly the operational context an agent needs before a destructive-adjacent write.

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?

Six paragraphs is long, but the length is justified by the tool's complexity and each paragraph carries distinct semantics (purpose, provenance, confirmation/atomicity, retention, partitioning, schema encoding). Purpose is front-loaded in the first sentence; a little tightening in the schema paragraph would make it a 5.

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?

An output schema exists so return values need not be explained, yet the description still tells the agent results follow items order with index and result/error — the one structural fact worth knowing. Combined with permission, schema-encoding, and confirmation guidance, nothing needed to call this correctly is missing.

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 baseline is 3; the description goes beyond it by explaining the confirm gating semantics, the partition/key-hashing ordering trap, and the decision rule for when value_schema is required (schema_id present on existing messages). Some overlap with schema text remains, but the cross-parameter interplay and when-to-set reasoning add real value.

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?

Opens with a specific verb and resource ('Write 1 to 20 new messages ... to existing topics') and immediately bounds scope (batch size, this or another configured cluster). It explicitly distinguishes itself from the sibling copy_message, so an agent can route between them without opening either schema.

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?

Gives explicit when-to-use and when-not-to guidance: use copy_message for existing content, 'Omit partition unless the exact partition matters', and 'Check get_message or sample_messages first' before writing to a schemaed topic. Alternatives and their selecting conditions are named, not implied.

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