AKHQ MCP Server

post_schema

Create a new schema in a Kafka Schema Registry by specifying cluster, subject, schema definition, and optional type (AVRO, JSON, PROTOBUF).

Instructions

Create a new schema

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cluster": "<cluster>",
      "subject": "<subject>",
      "schema": "<schema>"
    },
    "name": "post_schema"
  }
}

Input Schema

Name	Required	Description
`schema`	Yes	Schema definition (JSON string)
`cluster`	Yes	Cluster name
`subject`	Yes	Schema subject
`schemaType`	No	AVRO, JSON, PROTOBUF

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 5, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds no behavioral context beyond the word 'create', such as what happens if the schema subject already exists, whether this is a full replacement, or any authentication requirements. It does not contradict the annotations, but it provides no additional value beyond them.

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 description is extremely concise and front-loaded: 'Create a new schema' is a single clear phrase with no filler. It loses a point for being so terse that it borders on restating the tool name, but it is not bloated or poorly structured.

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

Completeness2/5

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

The description is four words and omits critical context for a write operation: expected return value, error behavior, whether existing schemas are overwritten or rejected, and how schemaType interacts with the schema string. The input schema covers parameter meaning, but the absence of output schema and any behavioral notes leaves the tool under-specified for an agent to invoke confidently.

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%, so all four parameters already have descriptive text in the input schema (e.g., 'Schema definition (JSON string)', 'Cluster name', 'Schema subject'). The description 'Create a new schema' adds nothing about parameter semantics, but the schema fully compensates for this, justifying the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new schema' states a specific verb and resource, making it clear that this tool creates a schema. However, it does not explicitly distinguish itself from sibling tools like get_schemas or delete_schema, though the verb 'create' provides reasonable differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives, such as when to post a new schema versus retrieving or deleting one. There are no exclusions, prerequisites, or context about the intended workflow.

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

Deploy Server