Kafka MCP

Overview Schema Source Related Servers Discussions Admin

get_schema

Read up to 1,000 Schema Registry schemas by subject or ID to inspect fields, versions, references, and compatibility; optionally test a candidate schema before registering it.

Instructions

Read 1 to 1000 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. A subject lookup also reports the compatibility level in force. check_schema tests a candidate schema against the subject's latest version without registering it, returning whether it is compatible and the registry's reasons if not.

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

Name	Required	Description	Default
`items`	Yes	The schemas to look up, 1 to 1000 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.2.7Oct 25, 2026

changedInput schema / properties / items / description

Previous value: -"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."New value: +"The schemas to look up, 1 to 1000 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."

addedInput schema / properties / items / items / properties / check_schema

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional candidate schema to test against the subject's latest version under the subject's compatibility level, without registering it. Needs subject. Returns check.compatible and the registry's reasons in check.messages.",
+  "properties": {
+    "schema": {
+      "description": "The candidate schema text.",
+      "type": "string"
+    },
+    "type": {
+      "description": "Optional: avro (default), protobuf or json_schema.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "schema"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

addedOutput schema / properties / results / items / properties / result / properties / check

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "compatible": {
+      "type": "boolean"
+    },
+    "messages": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    }
+  },
+  "required": [
+    "compatible",
+    "messages"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

addedOutput schema / properties / results / items / properties / result / properties / compatibility
```
Added value: +{
+  "type": "string"
+}
```

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 behavioral burden and does so: it discloses wholesale failure when the cluster has no schema_registry configured, partial failure semantics (results follow items order, each carrying index with result or error, a missing subject/id reported against its own item), that check_schema does not register anything, and that a subject lookup additionally reports the compatibility level in force.

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?

Purpose, return shape, usage trigger and failure behavior are all front-loaded before details, and each paragraph is topical. It is somewhat long, and the check_schema sentence reads like a separate tool blurb, which slightly blurs that it is an items-level option.

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 an output schema exists, return values need not be spelled out, yet the description covers them; combined with the per-item error semantics, the Protobuf message_type hint for produce_message, and the subject naming convention, an agent has everything needed to call this correctly and interpret partial failures.

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 description coverage is 100%, so the baseline is 3; the description adds genuine semantics beyond the schema — the schema id is 'the schema id a message carries' (linking to get_message's schema_id), latest is the default unless version is given, version is ignored when id is used, and the <topic>-value subject naming convention. It stops short of elaborating on the check_schema result fields beyond what the nested schema states.

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 opening sentence names a specific verb (read), resource (schemas from this cluster's Schema Registry), scope (1 to 1000 in one call via items) and the two lookup keys (subject or schema id). It also enumerates what comes back — schema text, type, id, version, all subject versions, references, and the compatibility level. No sibling tool in the list does this, so the agent can route unambiguously.

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 concrete trigger: read the schema before producing to a schema-encoded topic, because a sampled message may not reveal every field or enum — this implicitly positions it against sample_messages. It also clarifies that check_schema (a nested option here) verifies a candidate without registering it. It lacks an explicit 'when not to use' or a direct pointer to an alternative sibling for plain message inspection.

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