Server Quality Checklist

Tool Scores

• read_sanitized_resultsB
  3.3/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 responsibility for behavioral disclosure. It mentions reading at most three results and labeling them as untrusted, but does not clarify whether the labeling is a side effect, whether the read is idempotent, or what authentication or access implications exist. This is a significant gap for a tool that appears to mark content.

  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 concise sentence that front-loads the verb and resource. It contains no filler words and every phrase earns its place, making it highly efficient.

  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 there is no output schema, no annotations, and only two parameters, the description leaves key context ambiguous: what 'sanitized' means, what a 'fixture result' is, what the return format looks like, and how the 'untrusted external content' label affects the agent's next steps. The tool appears part of a workflow but lacks enough context to be used effectively.

  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?

  The schema has 0% description coverage, so the description must compensate. It only hints at the 'limit' parameter via 'at most three' but does not explain the meaning or format of 'executionId'. The schema provides structural constraints but not semantic meaning, and the description adds minimal value beyond that.

  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 uses the specific verb 'read' with a clear resource ('locally generated fixture results') and an additional purpose ('label them as untrusted external content'). This distinguishes it from sibling tools that plan, approve, or execute 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 context of sibling tools (plan_operation, approve_operation, execute_approved_operation) implies this is used after execution, but the description does not explicitly state when to use this tool vs alternatives. No exclusions are given, so the usage context is only implied.

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

• execute_approved_operationA
  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. It discloses that execution happens once and that ambiguous submissions are never retried, which adds useful behavioral context. However, it does not mention side effects, permissions, or failure 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 sentence, front-loaded with the main purpose, and includes valuable details like 'once' and 'never retried'. It contains no unnecessary words.

  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?

  The tool is simple, but the description lacks explicit preconditions (e.g., plan must be approved) and return value information. It also introduces jargon ('injected local transport') without explanation. Overall, it is adequate but has gaps.

  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?

  The parameter planId is not mentioned in the description, and schema coverage is 0%. The description implicitly suggests the parameter identifies the plan to execute, but it adds no explicit meaning beyond the schema's name and constraints.

  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 tool executes an approved fixture plan, using a specific verb and resource. It distinguishes itself from siblings like plan_operation, approve_operation, and read_sanitized_results by being the execution step.

  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 name and context imply it should be used after approval, but the description does not explicitly state when to use it versus alternatives. It lacks clear exclusions or alternative tool references.

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

• plan_operationA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses useful behavioral traits: 'short-lived' (expiration), 'approval-required' (dependency on approval), 'bounded' (limits), and 'single owned fixture Actor' (scope restriction). However, it does not mention error conditions, side effects, or validation specifics.

  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 with active verbs and a clear front-loaded structure. Every word contributes meaning, with no redundancy or filler.

  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 six required parameters, no annotations, and no output schema, this description is under-specified. It covers the overall purpose and a couple of behavioral traits, but leaves out parameter semantics, return values, validation rules, and explicit workflow integration. The sibling names help but do not compensate for the gaps.

  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?

  The schema has 0% description coverage, and the description provides no parameter-specific meaning. It only refers to a 'bounded request' generically. None of the six required parameters are explained, failing to compensate for the lack of schema descriptions.

  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 tool validates a bounded request and creates a short-lived approval-required plan. It specifies the exact resource (single owned fixture Actor) and distinguishes itself from siblings (approve, execute, read) by describing a distinct planning phase.

  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 implies this is the initial step in a plan-approve-execute-read workflow, but it does not explicitly mention when to use this tool versus alternatives or state exclusions. Sibling names provide context, but the description itself lacks explicit guidance.

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

• approve_operationA
  3.9/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. It adds some behavioral context by noting 'M1 has no signed external approval mechanism,' implying the approval is internal and informal. However, it does not disclose side effects, permissions, or what happens to the plan upon approval, leaving gaps.

  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 exceptionally concise: two short sentences that state the action and a key environmental constraint. Every word earns its place, and the most critical information is front-loaded in the first sentence.

  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?

  For a single-parameter approval tool, the description covers core purpose and a key constraint, but it lacks details on return values, error behavior, or post-approval effects. With no output schema and no annotations, some information is missing, though the sibling tools provide workflow context.

  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 0%, so the description must compensate. It does clarify that planId refers to a 'known, unexpired low-risk plan,' which adds meaning beyond the bare schema property. However, it omits how to obtain or format the planId, leaving the parameter partially under-specified.

  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 uses a specific verb+resource pairing — 'Approve a known, unexpired low-risk plan' — and clearly indicates the object and its qualifying conditions. It also differentiates from sibling tools like execute_approved_operation by focusing on the approval step rather than execution.

  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 states that the plan must be 'known, unexpired low-risk,' which gives clear conditions for when this tool is appropriate. It doesn't explicitly name alternatives, but the sibling tool context implies a workflow where approval precedes execution, providing sufficient usage context.

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