Server Quality Checklist

Tool Scores

• get_connector_statusB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of telling the agent what to expect, and it does mention returned content: states, workers, and failure traces. However, it does not disclose whether the call is read-only, how failures are represented, or any response shape/time behavior, so transparency is only partial.

  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 compact and front-loads the key output concepts in one clear phrase. It wastes no words, though it reads as a fragment rather than a complete sentence and could have included a simple verb such as 'returns' without hurting brevity.

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

  Completeness4/5

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

  For a one-parameter status retrieval tool with a fully described parameter, the description covers the main output categories and gives no output schema. It is reasonably complete for basic use, but it stops short of explaining output shape, error behavior, or how this relates to get_connector, so a little more context would be useful.

  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?

  The input schema already documents the single name parameter completely with 'Connector name'. The description adds nothing about how this parameter is used or formatted, so it does not enhance parameter understanding beyond the schema's 100% coverage.

  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 the specific resource and content: connector/task states, worker assignment, and failure traces. It goes beyond a vague restatement and distinguishes the tool from sibling list_connector_plugins and cluster_info, though it does not explicitly contrast it with the closely related get_connector.

  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?

  There is no explicit guidance on when to use this tool instead of get_connector, get_connector_config, or list_connectors. The description implies it is for status output, but it provides no exclusions, prerequisites, or decision criteria to help an agent select it confidently.

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

• get_connectorB
  3.4/5.0
  Behavior3/5

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

  The description adds the meaningful behavioral detail that 'Secret config values are redacted' and states the response includes config and tasks. Since no annotations are provided, however, it still does not disclose authentication, error behavior, or whether the operation is purely read-only beyond the 'get' wording.

  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?

  The description is two short sentences with no filler. The main outcome is front-loaded, and the redaction caveat is appended as a separate valuable detail without bloating the description.

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

  Completeness4/5

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

  For a one-param tool with 100% schema coverage, the description explains what is returned (config + tasks) and flags the redaction caveat, which is enough for an agent to invoke it correctly. It does not detail the exact output shape or error behavior, but those are not required for a quick probe.

  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?

  The schema fully documents the single intended parameter with 'Connector name', so schema coverage is 100%. The description adds no additional parameter-level detail, which is acceptable because the schema already carries that burden.

  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 states the operation clearly: fetch a connector and return 'Full connector info (config + tasks)'. The parenthetical scope distinguishes it from siblings like get_connector_config and get_connector_status, and the singular use implies one specific connector rather than a list.

  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 provides no explicit guidance about when to use this tool over siblings such as get_connector_config or get_connector_status. It only hints at the broader scope ('config + tasks'), leaving an agent to infer the use case without clear alternatives or exclusions.

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

• get_connector_configB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It adds a meaningful note that secret values are redacted, which is important for interpreting results, but it does not mention other behaviors such as failure modes if the connector does not exist or whether this is a strictly read-only operation.

  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?

  The description consists of two short, front-loaded sentences with no filler. It communicates the core result in the first sentence and an important caveat in the second.

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

  Completeness4/5

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

  For a simple single-parameter getter, the description is reasonably complete: it explains that the result is the configuration map and flags secret redaction. The lack of an output schema means some return-format detail would have been useful, but the existing text covers the critical information.

  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 the parameter 'name' is already documented as a connector name. The description adds no additional detail beyond that, so the baseline score of 3 applies.

  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 title and description clearly indicate that the tool returns a connector's configuration map, which distinguishes it from the sibling tools that return connector lists, status, or topics. However, it does not explicitly contrast with get_connector, which could also retrieve connector details.

  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 provided on when to select this tool over the sibling tools. The description simply states what it returns, leaving the agent to infer that it should be used when the connector's configuration map is needed.

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

• get_connector_topicsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries most of the behavioral disclosure burden. It does add a useful nuance: the result includes topics both read from and written to, not just one direction. However, it does not explicitly say the operation is read-only, explain what happens for an unknown connector name, or define whether the set is bounded by time or status.

  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?

  The description is a single sentence with no filler words, and its main behavioral qualification (read from or written to) is right at the center. Every word contributes meaning, making it highly efficient without being underspecified.

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

  Completeness4/5

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

  For a simple getter with one required parameter and a clear output statement, the definition is sufficient for an agent to select and invoke the tool. There is no output schema, but the description effectively explains the return concept. It could additionally describe failure modes or empty-result behavior, but these are minor gaps for this level of complexity.

  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?

  The input schema already fully documents the only parameter, "name", and describes it as "Connector name". Since schema description coverage is 100%, the baseline score of 3 is appropriate. The description adds no extra details about required naming formats, existence constraints, or case sensitivity.

  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 explicitly states what the tool returns: "The set of topics a connector has read from or written to." This distinguishes it from get_connector_config, get_connector_status, and list_connectors, which concern settings, health, and registered connectors rather than topic usage. It lacks a full action verb in the description itself, but the title 'Get connector topics' supplies the action.

  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 about when to use this tool versus get_connector, get_connector_config, get_connector_status, or list_connectors. It also does not mention prerequisites such as the connector already existing or being in a valid state. The only routing signal is the name itself.

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

• list_connector_pluginsB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of explaining behavior. The description clearly indicates a non-mutating list operation via 'List' and adds useful scope: 'installed on the worker' and '(incl. Debezium connectors)'. However, it does not explicitly state that it is read-only or describe how the returned plugin classes are structured, so some behavioral aspects remain undisclosed.

  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?

  A single, front-loaded sentence that directly states the action and scope. There is no fluff, the phrase 'installed on the worker' is useful, and the parenthetical is a notable exception detail. Highly economical.

  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?

  The description states what is listed and the scope, but there is no output schema, and the description does not specify the return format (e.g., names only, full class structure, or metadata). For a zero-parameter tool, the information is adequate, but an agent cannot anticipate whether the output is a list of strings, objects, or a keyed map.

  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?

  The input schema has zero parameters and the context signals confirm no required parameters, so there are no parameter semantics to document. The baseline of 4 applies here, and the description's scope comment is enough.

  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 states a specific verb and resource: 'List the connector plugin classes installed on the worker' — this is precise and distinguishes it from listing actual connector instances, like list_connectors. However, it does not explicitly name that sibling in the description, so differentiation is implied rather than stated, keeping it below a 5.

  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 explicit guidance on when to use this tool versus alternatives. It says what it returns (connector plugin classes) but does not mention the relationship to list_connectors or any selection criteria like 'use this when you need available plugin types'. The usage context is only implied by the word 'classes'.

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

• cluster_infoA
  3.5/5.0
  Behavior2/5

  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 indicates what information will be returned but does not explicitly state that this is a read-only operation, that no authentication or config is required, or whether the worker version and cluster id are safe to access without side effects. The absence of an output schema also leaves the return format unexposed.

  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?

  The description is a single, efficient sentence that names exactly what the tool surfaces. Every word is relevant, and there is no filler or redundant restating of the title.

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

  Completeness4/5

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

  For a parameterless metadata retrieval tool, the description is essentially complete: it lists the three values an agent will receive. It would be slightly improved by explicitly stating the operation type, such as 'retrieves' or 'returns,' but given the trivial interface, nothing else is truly needed beyond the field list.

  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?

  There are zero parameters, so the schema already provides 100% coverage. The description is not required to explain any parameter behavior. A baseline of 4 is appropriate because the description adds no unnecessary parameter detail and the tool needs none.

  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 names the specific resource (Kafka Connect cluster) and the concrete fields returned: worker version, commit, and Kafka cluster id. It is clear what information is being requested, though it lacks an explicit verb and does not directly differentiate itself from the sibling tools, which are all connector-focused.

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

  Usage Guidelines3/5

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

  The context of this tool is reasonably implied by its name and field list: it is used when cluster-level metadata is needed. However, there is no explicit guidance on when to choose it over alternatives, nor any exclusions such as 'use this when you need connector details rather than cluster info.'

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

• list_connectorsA
  4.3/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the burden of behavioral disclosure. It does reveal a meaningful behavioral trait: connectors outside the allowlist are filtered out. However, it doesn't mention output format, pagination, ordering, or any other side effects, though 'list' implies a read-only operation.

  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?

  Two short sentences with no unnecessary words. The essential action 'List connector names' comes first, and the allowlist filter follows immediately as important behavioral context. Every sentence earns its place.

  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?

  With zero parameters, no output schema, and a straightforward list-only operation, the description is fully adequate. It tells the agent exactly what will be listed and notes the relevant filtering rule, which is the only behavioral nuance an agent needs to call it correctly.

  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?

  The input schema has zero parameters, so there is nothing incomplete about parametric documentation. The description appropriately says only what is needed; no parameter description is required or expected.

  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 description states a specific verb ('List') and resource ('connector names'), making the tool's scope clear. It also distinguishes itself from sibling get_* tools by focusing on names, and from list_connector_plugins by specifying connectors rather than plugins. No ambiguity remains about what the tool does.

  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?

  The description gives clear context by indicating the output is limited to connector names and that an allowlist filter applies. It doesn't explicitly state when to avoid this tool and use a sibling, such as get_connector_config or list_connector_plugins, but for a simple list operation the intended use is evident.

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