Server Quality Checklist

Tool Scores

• api_putC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden, but 'guarded' is the only behavioral hint and it is not explained. The description does not disclose side effects, idempotency, error behavior, or what the guard protects against. This is insufficient for a mutating operation.

  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 compact and front-loaded with the operation, but the words 'generic' and 'guarded' add little concrete meaning. It is concise but under-specified, so the brevity does not meaningfully support correct invocation.

  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?

  The tool has three parameters, no annotations, no output schema, and zero parameter coverage, yet the description only states that it is a generic PUT to API_BASE. Essential context about path construction, payload expectations, header behavior, and return values is missing. The description is far from complete for safe invocation.

  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 provides no information about path, headers, or payload. An agent must infer parameter semantics solely from the property names in the schema. The description adds no 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 states a clear operation: a generic PUT request against API_BASE. It distinguishes itself from siblings (api_get, api_post, api_delete, api_probe) by the HTTP method. The qualifiers 'generic' and 'guarded' add some ambiguity but do not obscure the core purpose.

  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 given on when to use this tool versus the sibling HTTP-method tools. The description relies entirely on the name and method to imply suitability for update operations. It does not state prerequisites, alternatives, or conditions where another tool should be chosen.

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

• api_postC
  2.6/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full behavioral disclosure burden. It only says 'guarded', which is too vague to convey auth requirements, side effects, idempotency, error behavior, or whether the call modifies data, and POST's mutation semantics are left implicit.

  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 and front-loaded, stating the method and target in one sentence. However, the parenthetical 'guarded' is vague and its brevity comes at the expense of missing details that other dimensions 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?

  For a 3-parameter generic HTTP tool with no annotations and no output schema, the description leaves path construction, headers/payload semantics, response handling, and the meaning of 'guarded' unspecified. It gives the agent only enough to know that a POST request is made.

  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 compensate. 'Against API_BASE' hints that 'path' is relative to the base URL, but headers and payload are entirely unexplained in both the schema and description, forcing the agent to rely on HTTP conventions.

  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 a concrete operation—sending a POST request to API_BASE—and the HTTP verb distinguishes it from the GET/PUT/DELETE siblings at a basic level. However, it remains generic and doesn't specify the kind of resource or action POST is used for beyond the method 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?

  There is no explicit guidance about when to use this tool versus api_get, api_put, api_delete, or api_probe. The verb 'POST' implies use for POST-style requests, but no context, prerequisites, or exclusions are provided.

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

• api_deleteC
  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 the full burden of behavioral disclosure. 'Guarded' hints at access protection, but the tool does not disclose that DELETE is destructive, what happens on success or failure, whether authentication is required, or any side effects. The transparency is minimal.

  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 very short and front-loaded with the core action, containing no fluff or repetition. However, it is so terse that it sacrifices useful context, resembling under-specification rather than deliberate efficient structuring.

  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 three parameters, nested objects, no output schema, and no annotations, the description is insufficient for an agent to invoke the tool with confidence. It lacks parameter semantics, return-value expectations, error behavior, and clearer auth or safety guidance. The word 'guarded' raises more questions than it answers.

  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%, so the description should compensate for the three parameters. It does not explain the path format, how headers should be structured, or what payload is expected. The only implicit clue is 'against API_BASE', which suggests path is relative to a base URL, but headers and payload remain completely unexplained.

  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 a specific verb ('DELETE') and a resource scope ('API_BASE'), and the word 'Generic' indicates it is a general-purpose delete wrapper. It is distinguishable from siblings like api_get, api_post, api_put, and api_probe by the HTTP method, so an agent can infer what this 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 Guidelines3/5

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

  The phrase 'Generic DELETE' implies the tool is for performing HTTP DELETE requests against the base API, which gives some usage context relative to the sibling method-based tools. However, there is no explicit guidance on when not to use it, no mention of alternatives by name, and no conditions or prerequisites beyond the vague 'guarded'.

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

• api_probeC
  2.9/5.0
  Behavior2/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, but the only behavioral claim is the vague word 'safe'. It does not clarify whether arbitrary methods can still cause mutations, what the response looks like, how max_bytes affects the response, authentication requirements, or error behavior.

  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. Every phrase carries meaning, but it is so brief that it sacrifices critical behavioral and parameter context.

  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 no annotations, no output schema, and four parameters, the description is too thin. It omits return semantics, the meaning of 'safe', response size behavior, header usage, and explicit guidance for choosing between this and sibling tools. An agent could select the tool but would not know what to expect from calling it.

  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%, so the description must compensate, but it only adds minimal meaning: 'path' is an API path and 'method' can be anything. The headers and max_bytes parameters are completely unexplained, leaving the agent to guess their purpose and interaction with the request.

  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 a specific action ('Probe') and resource ('API path') and stresses that any HTTP method is accepted. The 'any method' qualifier distinguishes it from the fixed-method sibling tools (api_get, api_post, etc.), though 'probe' is somewhat generic and does not fully define the operation's outcome.

  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 phrase 'with any method (safe)' implies this tool is for flexible or non-standard HTTP method probing, contrasting with the specific method siblings. However, it never explicitly states when to prefer this over api_get/api_post/etc., nor does it mention exclusions or caveats for potentially destructive methods.

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

• api_getB
  3.1/5.0
  Behavior3/5

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

  With no annotations present, the description carries the behavioral transparency burden. It adds only the claim '(safe)', which is useful for a GET-based tool, but it does not explain API_BASE resolution, response behavior, error handling, or whether authentication is required.

  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 one compact sentence with no filler. 'Generic' and '(safe)' add useful meaning, though the overall brevity sacrifices informational richness.

  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 three parameters, no output schema, no annotations, and zero schema description coverage, this description is far from complete. It never defines API_BASE, explains how path/query/headers are combined, or describes what the response looks like, leaving the agent to guess at important invocation details.

  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 direct guidance for 'path', 'query', or 'headers'. The phrase 'against API_BASE' weakly implies that path is relative to the base URL, but query and header semantics are left entirely to inference.

  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 a concrete operation: a generic GET against API_BASE, which distinguishes it from the method-specific siblings api_post, api_put, and api_delete. However, API_BASE is left undefined and the relationship to api_probe is not addressed, so the purpose is clear but not fully specified.

  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 word 'Generic' implies this is the catch-all for raw GET requests, and '(safe)' suggests it is appropriate for read-only operations. Still, it provides no explicit guidance about when to use this tool versus api_probe, nor any exclusions or conditions.

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