Server Quality Checklist

Tool Scores

• fence_abortA
  4.4/5.0
  Behavior5/5

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

  No annotations exist, so the description carries the full burden. It discloses the key behavioral trait: the intent remains fenced and subsequent fence_prepare calls for the same intent are rejected, preventing silent re-execution after a possible side effect. This adds crucial context beyond the schema's data definitions.

  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?

  Two sentences, front-loaded with the primary purpose and followed by the critical consequence. No filler or repetition; every clause earns its place.

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

  Completeness4/5

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

  The description covers the purpose and the significant blocking behavior, making it clear when to call and what will happen. It doesn't mention return values or explicit preconditions like a prior fence_prepare call, though those are implied by the 'prepared' parameter and the fencing behavior. Slightly more detail on the expected response or error cases would make it fully complete.

  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% for both parameters, and the description adds no additional parameter semantics beyond what the schema already provides. The baseline for high coverage is 3, and the description does not compensate with extra param-level detail.

  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 states it 'Report[s] that a prepared effect failed or its outcome is unknown,' naming a specific action and resource. This clearly distinguishes the tool from siblings by contrasting with commit/prepare semantics.

  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?

  It explicitly defines when to use: when 'a prepared effect failed or its outcome is unknown.' The description also explains the consequence of using it (intent stays fenced, later fence_prepare calls rejected), but it does not explicitly name fence_commit as the success-path alternative, leaving the contrast implicit rather than fully explicit.

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

• fence_commitA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does well. It discloses the re-validation of the read set, the rejection and fencing of the intent on conflict, and the replay behavior on success, which are critical side effects for an agent to know.

  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 two sentences with no waste. Each sentence conveys distinct information: the purpose and the two behavioral outcomes (rejection/fencing on conflict, replay on success).

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

  Completeness5/5

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

  The description covers the tool's purpose, failure condition, side effect on the intent, and success behavior, making it complete for a two-parameter tool with a rich schema and workflow context. No output schema exists, but return values aren't necessary to describe given the description's depth.

  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 coverage is 100%, so the baseline is 3. The description doesn't add detail beyond the schema's property descriptions for 'prepared' and 'result', but the schema already explains that prepared is the ticket from a prior call and result is the actual tool output.

  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's function: 'Report that a prepared effect finished, and mint its content-addressed EffectCert.' This distinguishes it from siblings fence_prepare and fence_abort by covering the commit/terminal success step in the workflow.

  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 says to use this after a prepared effect has finished, and clarifies that if a dependency moved, the commit is rejected and the intent is fenced as failed. It also explains that successful commits cause later fence_prepare calls to replay the cert, which gives clear usage context, though it doesn't explicitly mention alternatives like fence_abort.

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

• fence_prepareA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It discloses idempotency semantics, single-execution guarantees, replay behavior, and four distinct failure modes. This is exactly the behavioral context needed for a fencing primitive.

  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?

  Three focused sentences covering purpose, return states, and error handling. No filler; every clause serves a decision the agent must make.

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

  Completeness5/5

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

  Given the tool's complexity, the description fully captures usage protocol, including consequences for each outcome and required follow-up actions (fence_commit/fence_abort). Output schema absent, but return values are described in prose.

  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 covers all 8 parameters with descriptions (100% coverage), so baseline 3 applies. Description reinforces intent's stable-id semantics but doesn't add new parameter-specific detail beyond schema; the protocol context (fresh/already_done) supplies useful surrounding semantics but not per-parameter meaning.

  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?

  Description uses a specific verb ('Ask permission') and identifies the resource (side-effecting tool call execution). It clearly differentiates from sibling tools fence_commit/fence_abort by framing this as the preparation/reservation step.

  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?

  Description explicitly specifies action based on return: on fresh, run then call fence_commit/fence_abort; on already_done, do NOT run; on errors, do not run and reconcile. It names error types for further guidance, making it superior for an agent to decide when to use this tool.

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