Server Quality Checklist

Tool Scores

• get_schemaA
  3.6/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 behavioral disclosure. It adds useful context ('Runs in your Kuudo deployment, not here') and implies a read-only schema retrieval, but it does not describe return format, error behavior, or potential 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.

  Conciseness4/5

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

  The description is short and front-loaded with the core action. The three sentences each add some value, though 'Catalog entry' is slightly redundant with the tool's purpose.

  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 two-parameter schema-lookup tool with a complete input schema, the description is nearly sufficient. It explains the workflow position and the deployment context; no output schema exists, but the tool's return nature is implied by its name and 'get parameter schemas'.

  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 schema already documents both 'tools' and 'detail' thoroughly. The description adds only the ordering hint 'after searching' and does not meaningfully enrich parameter meaning beyond the schema.

  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 clear verb-resource pair: 'Get parameter schemas for specific tools,' which distinguishes it from search and execute. The opening phrase 'Catalog entry' is somewhat vague, but the main clause is unambiguous.

  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 explicit usage context: use it after searching to obtain the detail needed to call a tool. It does not mention when not to use it or name alternative tools, but the placement in the workflow is clear.

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

• searchA
  3.6/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 burden of behavioral disclosure. It adds useful context: the tool 'runs in your Kuudo deployment, not here' and returns results 'ranked by relevance.' It does not explicitly state that the operation is read-only or describe any side effects/auth requirements, but for a catalog search these are somewhat implicit. The provided context is meaningful but not comprehensive.

  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 concise and front-loaded: it opens with the category ('Catalog entry'), gives the execution context, states the primary action, and closes with the result format. No sentence is redundant.

  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 search tool with all parameters documented by the schema, the description covers the essential context: it runs remotely, searches the tool catalog, and returns relevance-ranked matches. It does not detail the result structure in the absence of an output schema, but 'Returns matching tools' is adequate for a discovery tool.

  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 baseline is 3 even without parameter details in the description. The description adds no parameter semantics beyond what the schema already provides for query, tags, limit, and detail.

  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 a specific verb and resource: 'Search for available tools by query' and states the output ('Returns matching tools ranked by relevance'). It clearly identifies the tool as a catalog search, but it does not explicitly differentiate from siblings such as get_schema or tags, so it falls 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.

  Usage Guidelines3/5

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

  The description implies when to use the tool ('Search for available tools by query'), which is appropriate for discovery. However, it does not explicitly state when not to use it or mention alternatives like get_schema for retrieving a tool's full schema. Usage context is implied rather than spelled out.

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

• tagsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It adds one useful behavioral detail: 'Runs in your Kuudo deployment, not here.' However, it does not say whether the operation is read-only, what the response looks like, or any side effects. This is a moderate disclosure.

  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 short and front-loaded with the key verb 'List available tool tags.' The 'Catalog entry' phrase is unnecessary and slightly confusing, but overall there is minimal waste.

  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 low-complexity tool with one optional fully-documented parameter and no output schema, the description provides essential context: purpose, when to use, and runtime location. No critical information is missing for an agent to call it correctly.

  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%, with the 'detail' parameter fully described via enum and its own description. The tool description adds nothing beyond the schema, 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 description states a clear purpose: 'List available tool tags.' It also indicates its role as a browsing step before searching, which helps differentiate it from search. However, the opening 'Catalog entry' is vague and could confuse, so it is not 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 Guidelines4/5

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

  Explicitly says 'Use to browse available tools by tag before searching,' providing clear context for when to use it. It does not name alternatives or exclusions, but the guidance is specific enough for an agent to select it.

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

• executeA
  4.7/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 burden of behavioral disclosure, and it is exceptionally transparent. It reveals that execution happens in a remote sandbox ('not here'), restricts the available function surface to only call_tool, lists supported imports, forbids collections, disables str.format, and states hard limits on time, memory, and recursion depth. This is far beyond a generic 'executes code' statement.

  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 dense but every sentence carries needed operational detail. The opening 'Catalog entry.' is mild noise, but the rest is front-loaded with the location and primary action, followed by requirements and limits. The length is justified by the number of constraints the agent must respect to successfully invoke the tool.

  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?

  For a 1-parameter code-execution tool with no output schema and no annotations, the description covers all known operational aspects: where code runs, the callable API, allowed imports, forbidden syntax, and hard limits. It even states that the code must return the final value. Nothing an agent needs to call it correctly is missing.

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

  Parameters5/5

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

  Although the schema already defines the code parameter (100% coverage), the description adds substantial semantics: the exact async style (await call_tool), the required use of f-strings instead of str.format, the allowed/intended import set, the function signature, and the resource limits. This tells the agent exactly how to write valid code and exceeds what the schema alone provides.

  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 clearly states what the tool does: it runs Python code in the user's Kuudo deployment, not in the AI's environment, specifically for chaining await call_tool(...) calls. The verb 'Chain' and the resource 'your Kuudo deployment' make the purpose concrete and distinguish it from the sibling tools (tags, search, get_schema), which are direct data-retrieval tools.

  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 explains when to use this tool: when you need to compose multiple call_tool invocations in a single Python block and return a final value. It does not explicitly state when not to use it or name alternatives, but the use case is unambiguously conveyed, so clear context is provided even without exclusions.

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