Server Quality Checklist

Tool Scores

• load-routinesD
  1.8/5.0
  Behavior1/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. 'Load routines' gives no insight into what the tool does behaviorally—whether it's a read-only operation, requires authentication, has side effects, or handles errors. It fails to describe any behavioral traits, leaving the agent with no understanding of how the tool behaves beyond its vague name.

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

  Conciseness2/5

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

  The description is overly concise to the point of under-specification. 'Load routines' is a two-word phrase that lacks necessary detail for effective tool use. While it avoids verbosity, it fails to provide essential information, making it inefficient rather than appropriately concise. Every word should earn its place, but here the description is too sparse to be useful.

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

  Completeness1/5

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

  Given the lack of annotations and output schema, the description is incomplete for a tool that likely performs a data retrieval operation. It doesn't explain what 'load' entails (e.g., returns a list, fetches details), how results are structured, or any operational context. With no structured fields to compensate, the description fails to provide the necessary completeness for an agent to use the tool effectively.

  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 0 parameters with 100% description coverage, meaning no parameters need documentation. The description doesn't add parameter details, which is acceptable given the absence of parameters. Since there are no parameters to explain, the description adequately avoids unnecessary complexity, aligning with the schema's completeness.

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

  Purpose2/5

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

  The description 'Load routines' is a tautology that essentially restates the tool name without adding meaningful context. While it indicates the action ('load') and resource ('routines'), it lacks specificity about what 'load' means in this context (e.g., retrieve, fetch, list) and doesn't distinguish it from sibling tools like 'create-routine' or 'update-routine'. This minimal description provides only basic purpose without clarity on scope or differentiation.

  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 alternatives. There is no mention of prerequisites, context for usage, or comparison with sibling tools such as 'create-routine', 'delete-routine', or 'update-routine'. Without any usage instructions, an agent cannot determine appropriate scenarios for invoking this tool over others.

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

• create-routineC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers limited behavioral information. It mentions inspecting recently run tools but doesn't disclose what 'create' entails - whether this persists routines, requires permissions, has rate limits, or returns any confirmation. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.

  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 brief but somewhat vague - 'inspect recently run tools' could be more specific. While concise, it's not optimally front-loaded with the most critical information about what creation entails. The two clauses could be better structured for clarity.

  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 creation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, how routines are stored/accessed, or provide enough context about the 'steps' parameter's relationship to 'recently run actions.' The description should do more to compensate for missing structured 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 67%, and the description adds no parameter-specific information beyond what's in the schema. The description doesn't explain what 'recently run actions' means in relation to the steps parameter or provide context about parameter relationships. Baseline 3 is appropriate since the schema does most of the documentation work.

  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 tool creates a custom routine from recently run actions, specifying both the verb ('create') and resource ('custom routine'). It distinguishes from siblings by focusing on creation rather than deletion, loading, or updating. However, it doesn't explicitly contrast with siblings in the description text itself.

  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 minimal usage guidance - only mentioning 'inspect recently run tools' as a prerequisite. It doesn't specify when to use this versus alternatives like update-routine for modifying existing routines, or provide context about when routine creation is appropriate versus direct tool execution.

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

• update-routineA
  3.8/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 valuable context: it mentions updating only the portion specified by the user (partial updates), confirming with the user before proceeding, and handling inexact name matching. However, it doesn't cover critical aspects like whether this is a destructive operation, what permissions are required, error handling, or what happens to unspecified fields.

  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 appropriately sized with four sentences, each adding value: the core purpose, partial update behavior, user confirmation requirement, and prerequisite tool usage. It's front-loaded with the main action. However, the last sentence about name matching could be integrated more smoothly, and some redundancy exists (e.g., 'by name' is implied in the schema).

  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 no annotations and no output schema, the description provides moderate context: it covers the update operation, partial updates, user confirmation, and prerequisite steps. However, for a mutation tool with three required parameters, it lacks details on error conditions, side effects, return values, and security implications. The schema handles parameter documentation well, but behavioral aspects are incomplete.

  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 all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema—it mentions 'name' and 'portion specified by the user' but doesn't clarify parameter interactions or usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('update') and resource ('routine by name'), making the purpose immediately understandable. It distinguishes from siblings by focusing on updating rather than creating, deleting, or loading routines. However, it doesn't explicitly contrast with 'create-routine' beyond the verb difference.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool vs alternatives: it mentions using 'load-routines' to get the list of all routines first, which implies this tool should be used after identifying the routine to update. It also specifies that the user may supply a name that's not exactly as stored, indicating a prerequisite step of name matching.

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

• delete-routineA
  4/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 mentions the need for user confirmation and potential name mismatches, adding useful context. However, it lacks details on permissions, error handling, or irreversible effects, leaving gaps for a destructive operation.

  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 front-loaded with the core action ('Delete a routine by name') and efficiently includes essential usage notes in two additional sentences. Each sentence earns its place by providing critical guidance without redundancy or unnecessary elaboration.

  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 destructive nature and lack of annotations or output schema, the description is partially complete. It covers purpose and usage well but misses details on behavioral aspects like confirmation mechanisms, error responses, or side effects, which are important for such an operation.

  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 the 'name' parameter fully. The description adds marginal value by noting that 'User may supply a name that's not exactly as how it's stored,' but this doesn't provide additional syntax or format details beyond the schema's 'Exact name' description.

  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 the specific action ('Delete') and resource ('a routine by name'), distinguishing it from sibling tools like create-routine, load-routines, and update-routine. It precisely defines what the tool does without being vague or tautological.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: 'Always confirm with user that they want to delete it' and 'Use the load-routines tool to get the list of all routines.' It also addresses an alternative (load-routines) for verification, making usage context clear and comprehensive.

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