Server Quality Checklist

Tool Scores

• tasks_getC
  2.4/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. 'List tasks' conveys a read-only collection operation and little else; it does not mention filtering, pagination, authentication, or any other behavioral traits.

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

  Conciseness3/5

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

  The description is concise at two words, but it is under-specified rather than efficiently complete. It earns its place as a minimal label, yet it does not provide enough structured meaning for a helpful tool definition.

  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?

  For a tool with one optional parameter and no output schema, the description should at least mention the filtering capability and what the response represents. 'List tasks' leaves critical invocation context unexplained, so the definition is incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention the 'completed' parameter at all. The schema only reveals a boolean property, but the description adds no meaning about whether it filters tasks by completion status, leaving the agent to guess.

  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 ('List') and resource ('tasks'), making the collection-level intent clear. It is not a tautology, though it does not explicitly differentiate from the sibling tasks_id_get beyond implying a list-versus-single distinction.

  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 guidance on when to use this tool versus tasks_post, tasks_id_get, or tasks_id_delete. The description implies listing as opposed to creating, fetching, or deleting, but provides no explicit usage context, exclusions, or alternatives.

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

• tasks_id_getC
  2.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 of behavioral disclosure. It only implies a read-only action via the verb 'Get'; it does not describe return format, error behavior, authentication needs, or idempotency.

  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, front-loaded sentence with no filler or redundancy. It is appropriately sized for a one-parameter tool, though adding 'by id' would make it slightly more informative without harming conciseness.

  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?

  With no output schema and no annotations, the description is the only source of context, and it is minimal. It does not mention what a successful response contains, error cases, or any behavioral caveats, leaving the agent with incomplete information for fully reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the 'id' parameter beyond what the schema shows (integer, required). The parameter name is somewhat self-explanatory, but the description adds no meaning about how the id is used or validated.

  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 uses a specific verb ('Get') and resource ('a task'), which clearly indicates a retrieval operation and helps differentiate from sibling tools like tasks_post and tasks_id_delete. However, it does not explicitly mention that retrieval is by id, which is only evident from the tool name.

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

  Usage Guidelines1/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 its siblings. Sibling tools such as tasks_get, tasks_post, and tasks_id_delete are present, but the description does not mention any of them, nor does it state conditions, exclusions, or alternate scenarios.

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

• tasks_id_deleteC
  2.6/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 discloses that the operation is a delete (destructive), but gives no information about permanence, idempotency, authorization requirements, or whether deletion cascades to related data. This is a minimal statement of effect, nothing more.

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

  Conciseness3/5

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

  The description is appropriately short for a simple tool and front-loads the action. However, it is closer to under-specification than effective conciseness, as it omits necessary behavioral context that an agent would need.

  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 destructive, has no annotations, and no output schema, the description is incomplete. It does not mention return values, error behavior (e.g., 404 if task not found), or side effects, leaving significant operation details to inference.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain what the 'id' parameter refers to beyond the schema's type and required flag. Although the single integer parameter is intuitive from the tool name, the description adds no semantic value over 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 specific verb ('Delete') and a resource ('task'), which clearly distinguishes it from the siblings tasks_get, tasks_post, and tasks_id_get. The operation is unambiguous, although it adds no detail about scope or type of task.

  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 on when to use this tool versus alternatives like tasks_post for creation or tasks_get for retrieval. There are no exclusions, prerequisites, or conditions stated.

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

• tasks_postB
  3.2/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 only says 'Create a task' and does not explain side effects, persistence, authentication needs, idempotency, or what the response contains.

  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 an extremely short, front-loaded phrase with zero redundant words. Every word earns its place for such a simple create operation.

  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?

  Fora one-parameter create operation, the schema plus description provide enough to make a basic call. However, the definition is only minimally complete: it provides no response expectations, no behavioral notes, and no relationship to the sibling tools.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description adds no parameter-level meaning. The required 'title' parameter is left entirely to the schema, with no explanation of what a valid taskt itle should look like beyond being a string of at most200 characters.

  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 a specific verb and resource: 'Create a task'. This unambiguously identifies a creation operation and distinguishes it from the sibling tools that get or delete tasks, even without naming them.

  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 guidance about when to use this tool versus alternatives. It does not mention siblings such as tasks_get or tasks_id_delete, nor any conditions, prerequisites, or context that would help an agent choose it.

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