Kafka MCP

Overview Schema Source Related Servers Discussions Admin

get_schema

Retrieve up to 100 schemas by subject or message ID from Kafka Schema Registry to see required fields and enums before producing to a schema-encoded topic.

Instructions

Read 1 to 100 schemas from this cluster's Schema Registry in one call through items, each by subject (latest version unless version is given) or by the schema id a message carries. Returns the schema text, its type (avro, protobuf or json_schema), id, version, every version of the subject, the schemas it references, and for an id the subject versions that use it.

Read the schema before producing to a schema-encoded topic: it names every field and enum a value needs, which a sampled message may not show. For Protobuf, message_types lists the names produce_message accepts as message_type. The subject for a topic's values is usually -value.

Results follow items order, each carrying index with result or error. Fails as a whole when the cluster has no schema_registry configured.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes	The schemas to look up, 1 to 100 of them. Looking up one schema is an array of length one. Results follow this order and a subject or id that does not exist 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.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden and largely does: it discloses the whole-call failure mode when no schema_registry is configured, per-item error reporting against each item, result ordering, and that every version of the subject plus referenced schemas are returned. Read-only behavior is only implied by 'Read,' not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action in the first sentence, then layers usage and failure context. Dense but every sentence carries operational information; no filler.

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 goes further by covering failure mode, per-item error semantics, and the pre-produce workflow step. Nothing needed to invoke it 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 baseline is 3, but the description adds meaning beyond it: it explains the subject-vs-id choice, the default-to-latest behavior unless version is given, the exact-match/case-sensitive convention, and the protobuf message_type linkage.

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 with explicit scope: 'Read 1 to 100 schemas from this cluster's Schema Registry in one call.' It names the two lookup modes (by subject/latest-version or by schema id), which no sibling tool offers, so an agent can distinguish it immediately.

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 a real when-to-use rule: 'Read the schema before producing to a schema-encoded topic,' plus practical routing hints (the <topic>-value convention, message_types for Protobuf). It doesn't name an alternative or an explicit when-not-to-use case, but no sibling competes for this job.

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