Server Quality Checklist

Tool Scores

• thunderclient_add_licenseC
  2.9/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 of behavioral disclosure. It states 'Add Thunder Client licenses', implying a write operation, but doesn't cover permissions required, whether it's idempotent, rate limits, error handling, or what happens on success (e.g., confirmation details). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  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, clear sentence with no wasted words, directly stating the tool's function. It's appropriately sized and front-loaded, making it easy to understand at a glance without unnecessary elaboration.

  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?

  Given the tool is a mutation (adding licenses) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral traits like side effects. For a tool that modifies state, more context is needed to ensure safe and correct usage, making this inadequate for its 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 schema description coverage is 100%, with the 'emails' parameter fully documented in the schema as an array of email addresses with a minimum of 1 item. The description adds no additional parameter semantics beyond implying the emails are for license assignment. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add value 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 clearly states the action ('Add') and resource ('Thunder Client licenses') with the target ('specified email addresses'), making the purpose evident. It distinguishes from sibling tools like 'thunderclient_get_licenses' (read) and 'thunderclient_remove_license' (delete), but doesn't explicitly differentiate beyond the verb. The specificity is good but lacks explicit sibling comparison.

  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 guidance on when to use this tool versus alternatives like 'thunderclient_get_licenses' or 'thunderclient_remove_license'. It doesn't mention prerequisites, such as whether licenses are available or if users must exist, nor does it specify scenarios like bulk onboarding. Without such context, usage is implied but not clearly defined.

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

• thunderclient_remove_licenseC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Remove') but doesn't clarify if this is destructive, requires admin permissions, has side effects (e.g., revoking access), or what happens on success/failure. This leaves critical behavioral traits unspecified for 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.

  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?

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, leaving significant gaps in understanding how to invoke it correctly and interpret results.

  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 description coverage is 100%, with the parameter 'emails' fully documented in the schema as an array of email addresses. The description adds no additional semantic context beyond implying the emails are targets for license removal, so it meets the baseline of 3 without compensating for gaps.

  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 clearly states the action ('Remove') and resource ('Thunder Client licenses') with the target ('for specified email addresses'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'thunderclient_add_license' beyond the verb, missing a direct comparison that would elevate it to 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 provides no guidance on when to use this tool versus alternatives like 'thunderclient_add_license' or 'thunderclient_get_licenses'. It lacks context about prerequisites, such as whether licenses must exist or if this is for revoking access, leaving the agent without usage direction.

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

• thunderclient_get_licensesA
  3.5/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 of behavioral disclosure. It adds useful context about the automatic pagination behavior when pageNumber is not provided, which isn't obvious from the schema. However, it doesn't cover other aspects like rate limits, authentication needs, or response format, leaving gaps for a tool with no annotation support.

  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 extremely concise—just two sentences—with zero wasted words. It front-loads the core purpose and efficiently explains the key behavioral nuance regarding pagination, making it easy for an agent to parse quickly.

  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?

  Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is adequate but not complete. It covers the main functionality and pagination behavior but lacks details on output format, error handling, or integration with sibling tools, which could help an agent use it more effectively.

  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 description coverage is 100%, so the schema already fully documents the single parameter (pageNumber). The description adds minimal value by restating that omitting pageNumber fetches all pages, which is already implied in the schema's description. This meets the baseline for high schema coverage without significant enhancement.

  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 clearly states the verb ('Get') and resource ('Thunder Client licenses'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'thunderclient_add_license' or 'thunderclient_remove_license' beyond implying this is a read operation versus their write operations.

  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 provides implied usage guidance by mentioning the automatic fetching of all pages when pageNumber is omitted, which suggests when to use this parameter. However, it lacks explicit guidance on when to choose this tool over siblings or any prerequisites, leaving the agent to infer based on tool names alone.

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