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

No annotations are provided, so the description carries the full burden. It does disclose the content of the read (cluster metadata plus broker node list) and implicitly signals a non-mutating info operation, but says nothing about permissions, failure modes for unreachable clusters, or whether results are cached/live.

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

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

A single front-loaded sentence with no filler; the parenthetical return-field list is compact and earns its place by telling the agent what comes back.

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

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

The tool is simple and an output schema exists, so return values need not be explained. However, the unexplained 'connection' parameter leaves a real ambiguity about which cluster is targeted, and no usage context is given.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions the single 'connection' parameter, so an agent gets no help choosing a connection target (e.g. named profile vs. default) for what is presumably a multi-cluster context. It fails the requirement that a low-coverage description compensate for the schema.

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

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

States a specific verb (获取/get) and resource (Kafka 集群整体元数据与 Broker 节点列表), and enumerates the returned fields (Cluster ID, 控制器, 节点地址). Its cluster-level scope naturally separates it from the topic/group/message siblings, though it never names them explicitly.

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

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

There is no guidance on when to call this versus kafka_list_topics, kafka_list_consumer_groups, or kafka_list_connections, and no stated prerequisites (e.g. cluster must be reachable, connection must be configured). The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden. It usefully discloses the read-only mode restriction and the mutation nature of the tool, but it omits idempotency behavior, what happens if the topic already exists, required permissions, and error semantics.

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

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

The description is a single, front-loaded sentence with no wasted text. The core action comes first, followed by supporting details in parentheses.

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

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 described. Still, with no annotations and 0% schema description coverage, the description omits connection semantics and failure behavior, leaving some invocation context underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate, but it only mentions partitions and replication factor without adding format, default, or constraint details. It does not explain the optional connection parameter, and topic_name is only implied by the tool purpose.

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

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

The description states a specific verb and resource: creating a new topic in a Kafka cluster. The parenthetical adds scope by naming supported settings and an availability condition. It is clearly distinguishable from sibling tools like list, describe, or delete topic.

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

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

It provides a clear when-not condition: unavailable in read-only mode. However, it does not name alternatives or give broader when-to-use guidance relative to siblings, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full burden. It correctly discloses that the operation is destructive/high-risk and requires explicit confirmation, which is valuable, but it omits other important behavioral details such as irreversibility, impact on running consumers, or permission requirements.

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

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

The description is a single, tightly written sentence that front-loads the action and then the critical safety constraint. Every clause earns its place with no redundancy.

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

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. However, for a destructive three-parameter tool with zero annotation and schema-description coverage, the description should do more to cover the connection parameter and the full consequences of deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% with three parameters, so the description must compensate. It explains the most critical parameter (confirm=True) beyond what the schema offers, but leaves topic_name and especially connection completely undocumented.

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

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

The description gives a specific verb (删除/delete) and resource (主题/topic in a Kafka cluster), making the core action unambiguous. It does not explicitly name or distinguish itself from siblings like kafka_create_topic or kafka_describe_topic, but the verb alone functionally separates it from the other tools.

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

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

It states a clear precondition for invocation: this is a high-risk destructive operation and the caller must pass confirm=True. It does not discuss alternatives or when-not-to-use scenarios, but the confirmation requirement is a concrete, actionable usage instruction.

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

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

With no annotations present, the description carries the full behavioral burden. It does disclose the substance of the operation (what data a describe returns), which is useful, but says nothing about read-only nature, permission requirements, cost/latency of a live describe, or behavior for non-existent or inactive groups.

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

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

A single front-loaded sentence with no filler, and the key noun ('指定 Kafka 消费组') appears early. It is slightly dense with the trailing enumeration but nothing is wasted.

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

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

An output schema exists, so the return shape need not be restated, and the description redundantly previews it. However the two zero-documented parameters and the complete absence of usage guidance leave real gaps for an agent deciding when and how to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so both parameters are undocumented in structured form and the description does not compensate. Neither group_id (format, e.g. plain name vs. fully qualified) nor the optional connection parameter is explained anywhere.

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

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

The description gives a specific verb ('查询' / describe) plus the exact resource (a designated Kafka consumer group) and even enumerates what the topology view contains: active members, committed offsets, LEO and lag. This clearly separates it from kafka_list_consumer_groups, though the contrast is implicit rather than stated by naming the sibling.

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

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

There is no when-to-use / when-not-to-use guidance. It does not say to call this after listing groups, when a group looks lagging, or that it requires an existing group_id, so the agent must infer the usage context from the sibling list alone.

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

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

No annotations are provided, so the description carries the full burden. '查询' signals a read-only operation and the parenthetical discloses what data comes back, but there is no mention of auth requirements, behavior when the topic does not exist, or connection handling. For a read tool this is adequate but thin.

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

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

A single front-loaded sentence that names the action, target, and returned fields with zero filler. Nothing in it is wasted.

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

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

An output schema exists, so the return values need not be detailed. However, with 0% schema coverage and an entirely undocumented connection parameter, an agent still lacks enough guidance about how to parameterize the call for a tool with two inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only indirectly references topic_name via '指定 Kafka 主题'. The second parameter, connection, gets no explanation at all in either schema or description, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (查询) and resource (指定 Kafka 主题), and enumerates the returned topology details (分区分布, Leader 节点, ISR 同步副本, 配置). This differentiates it implicitly from kafka_list_topics by promising per-topic detail, though no sibling is named explicitly.

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

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

Usage is only implied: the phrase '指定 Kafka 主题' suggests it applies to one named topic, which is the natural counterpart to kafka_list_topics. There is no explicit when-to-use, when-not-to-use, or alternative named, so it stays at the minimum-viable level.

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

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

No annotations are supplied, so the description carries the full burden. 'Enumerate' implies a safe read operation and it names some returned information, but it does not explicitly state the read-only nature, authentication requirements, pagination, or side effects.

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

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

A single front-loaded sentence that names the operation, scope, and returned details without filler. Every element contributes to identifying the tool.

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

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

For a zero-parameter list tool with an output schema, the description is largely sufficient: it identifies the resource and indicates the kind of connection metadata returned. It is slightly incomplete on usage routing and explicit read-only assurance, but the output schema covers return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero input parameters, so the schema has nothing to document; the baseline for 0 params is 4. The description does not need to add parameter meaning beyond that.

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

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

States a specific verb (enumerate/list) and resource (named Kafka cluster connections configured on the current server), and specifies returned details (broker bootstrap addresses and read-only protection status). This is clearly distinct from sibling tools that list topics, groups, messages, or manipulate topics.

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

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

There is no guidance on when to use this tool instead of siblings such as kafka_cluster_info or kafka_list_topics. The purpose implies a read/list scenario, but no conditions, prerequisites, or exclusions are provided.

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

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

With no annotations, the description carries the full burden, and it partially does so by enumerating the status values (Stable/Empty/Dead) and fields returned, which is genuine behavioral context. However, it omits whether this is a read-only operation, what cluster/connection scope it applies to, or any auth/permission requirements.

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

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

A single, front-loaded sentence with no wasted words that names the resource and its key attributes up front. It is appropriately sized for a simple list operation.

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

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

For a read-only list tool with an output schema, the description needn't explain return values, and it correctly focuses on scope. The main gap is the unexplained 'connection' parameter and the absence of any routing hint versus the describe/list-topic siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'connection' parameter is undocumented in the schema (0% coverage) and is also unmentioned in the description, so an agent has no explanation of what connection means or how it is resolved. With low coverage the description should compensate, and it does not.

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

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

The description gives a specific verb (列出/list) and resource (消费组清单/consumer groups in a Kafka cluster), and even previews the returned fields (Group ID, protocol type, status). It does not explicitly differentiate itself from the sibling kafka_describe_consumer_group, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as kafka_describe_consumer_group for inspecting a single group. The listing intent is only implied by the verb.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two real behaviors beyond the schema: name-pattern filtering is supported and internal system topics are excluded by default, which adds value. However it says nothing about the connection parameter, auth/permissions, or any operational constraints.

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

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

A single front-loaded sentence with no filler, and the filtering/scope caveat is bundled inline rather than buried. Efficient, though it is arguably under-specified rather than optimally concise.

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

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, but with no annotations and 0% schema coverage the description should do more. The connection parameter is never explained and there is no permission or scope context, leaving the agent guessing on a 3-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only loosely gestures at two of the three parameters (pattern filtering, internal exclusion) without specifying pattern syntax (glob? regex?) and completely omits the connection parameter, leaving a third of the surface undocumented.

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

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

States a specific verb (列出/list) and resource (Kafka 集群中的主题/topics in a Kafka cluster), which cleanly distinguishes it from the single-topic sibling kafka_describe_topic. It does not explicitly name or contrast with any sibling, so it falls just short of a 5.

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

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

The description implies the obvious use case (enumerate topics) but offers no when-to-use versus kafka_describe_topic, no prerequisites, and no exclusions. The only usage-adjacent detail is the default internal-topic exclusion, which is a behavior, not routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the read-only mode restriction and the supported payload forms, which is useful, but omits failure semantics, permission/auth requirements, and delivery guarantees expected of a mutation tool.

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

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

A single compact parenthetical sentence front-loads the core action and appends supported features and the constraint. No wasted wording, though it is quite terse for a mutation tool.

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

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. For a 6-parameter write tool with zero annotation coverage, the description is minimally adequate but leaves partition and connection handling, error behavior, and permissions unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 6 parameters. The description compensates partially by clarifying key, JSON/text payload, and headers, but the topic, partition, and connection parameters remain undocumented in both places.

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

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

The description states a specific verb and resource: sending a message to a designated Kafka topic. This clearly separates it from read/list siblings like kafka_list_topics and kafka_sample_messages, though it does not explicitly name a sibling to avoid.

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

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

It provides one meaningful when-not condition ('unavailable in read-only mode'), which guides the agent away from calling it in read-only environments. However, it offers no guidance on when to prefer this tool over alternatives (e.g., create_topic) or prerequisites for use.

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

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

With no annotations, the description carries the full burden, and it does meaningfully disclose the destructive/high-risk nature and the dry-run safety mechanism — the most important behavioral facts for this tool. It stops short of explaining the confirm/force interplay or what a non-dry-run call irreversibly changes.

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

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

A single dense sentence, front-loaded with purpose followed by risk and capability notes. No wasted text, though the parenthetical packs several ideas together.

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

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 no explanation, and the description covers purpose, risk and strategy options. But for a complex 10-param destructive tool with no annotations, the confirmation semantics (confirm/force) and required-param expectations are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 10 params, so the description must compensate. It only names the strategy values (earliest/latest/to_offset/to_datetime, which the schema lacks) and dry-run; 8 params such as offset, confirm, force, partitions and datetime_val remain unexplained anywhere.

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

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

The description states a specific verb+resource+scope: reset a given consumer group's offsets on a target topic. No sibling tool (list/describe/produce/create/delete) performs offset reset, so the purpose is unambiguous and easily distinguished.

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

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

It flags this as a high-risk operations action and notes Dry-Run pre-check support, implying 'use carefully / run dry-run first', but gives no explicit when-to-use vs when-not guidance or prerequisites beyond that. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses zero-commit-offset semantics (consumer group positions are unaffected), read-only operation, adaptive decoding, and large-message truncation protection. It omits auth/permission requirements and any limits on sampling cost or pace.

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

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

A single densely packed sentence that front-loads the core purpose (read-only topic sampling) and relegates qualifying details to a parenthetical. No wasted words, though the parenthetical crams several distinct behaviors together.

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

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 described. However, for a 7-parameter tool with zero annotation and zero schema-description coverage, the description leaves half the parameters undocumented, which is a meaningful gap even though the behavioral picture is solid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, so the description must compensate. It valuably names the strategy values (latest/earliest/offset) not present in the schema and implies max_bytes_per_message via 'large message truncation', but leaves limit, offset, partition, and connection entirely unexplained.

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

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

States a specific verb and resource: read-only sampling of messages from a named Kafka topic. This is clearly distinct from write-oriented siblings like kafka_produce_message and from metadata tools like kafka_list_topics. It stops short of an explicit naming of a sibling to contrast against, so it lands at 4 rather than 5.

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

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

Usage is only implied by the tool's own behavior ('sample messages'); there is no statement of when to choose this over kafka_describe_topic or other read tools, nor any when-not-to-use condition. Adequate but leaves the agent to infer the selection context.

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