AKHQ MCP Server

get_topic_configs

Read-onlyIdempotent

Retrieve Kafka topic configuration by specifying cluster and topic name. Use it to inspect topic settings and troubleshoot configuration issues.

Instructions

Get configuration for a topic

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>",
      "topicName": "<topicName>"
    },
    "name": "get_topic_configs"
  }
}

Input Schema

Name	Required	Description	Default
`cluster`	Yes	Cluster name
`topicName`	Yes	Topic name

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?

The annotations already declare the tool read-only, idempotent, and non-destructive, and the description adds no behavioral detail beyond that. There is no statement about what configs are returned, how defaults are handled, or any error/empty-topic behavior.

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 a single clear sentence with no filler and is appropriately front-loaded. It is slightly redundant with the tool name, but compactness is a strength.

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

Completeness3/5

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

For a simple read-only getter with fully documented parameters and strong annotations, the basic call is usable. However, the missing scope clarification versus get_topic_defaults_configs and the lack of any output/return context leave a meaningful 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% and both cluster and topicName are documented, so the description does not need to explain them. The description itself adds no semantic detail beyond what the schema provides, matching the baseline 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 identifies a specific verb ('get') and resource ('configuration for a topic'), so the basic action is clear. However, it does not distinguish this from the closely named sibling get_topic_defaults_configs or mention whether this returns effective/current configs rather than defaults.

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?

No guidance is given about when to use this tool instead of alternatives such as get_topic_defaults_configs or get_topic. An agent must infer the intended context from the tool name alone.

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

Deploy Server