Server Quality Checklist

Tool Scores

• coord_releaseD
  1/5.0
  Behavior1/5

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

  Tool has no description.

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

  Conciseness1/5

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

  Tool has no description.

  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?

  Tool has no description.

  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?

  Tool has no description.

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

  Purpose1/5

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

  Tool has no description.

  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?

  Tool has no description.

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

• delete_watchD
  1/5.0
  Behavior1/5

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

  Tool has no description.

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

  Conciseness1/5

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

  Tool has no description.

  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?

  Tool has no description.

  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?

  Tool has no description.

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

  Purpose1/5

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

  Tool has no description.

  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?

  Tool has no description.

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

• drain_eventsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects, but it does not clarify whether draining is destructive or whether events are removed from the mailbox. The word 'drain' implies consumption, but the description says 'Collect' without stating if repeated calls return the same events or if events are deleted.

  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 only two sentences and gets straight to the point, front-loading the main action. It avoids redundancy but includes a useful tip, making it 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?

  The tool has three parameters and no output schema, so the description should cover the return format and all parameter roles. It only partially addresses `since` and gives no indication of the response structure, making it incomplete for safe usage.

  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 description explains the `since` parameter as a 'last seen event id' for incremental drains, which is helpful. However, the required `watchId` and `secret` parameters are not described, leaving users to infer their roles from the tool's context.

  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 'Collect everything the watch caught' which clearly identifies the tool as a fetch/drain operation for watch events. The title 'Drain held events' reinforces the purpose, and the mention of 'watch' distinguishes it from coordinate-related siblings.

  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 description provides context that this works with 'zero infrastructure' and the 'mailbox pattern,' suggesting it is the lightweight option. It also gives a concrete usage tip for incremental drains via `since`, but does not explicitly contrast with alternatives like coord_events or state when not 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.

• watch_statusC
  2.9/5.0
  Behavior3/5

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

  The description states that 'Secret is looked up from local state if omitted,' which is a useful behavioral detail about parameter handling. However, it does not explicitly state that this is a read-only operation, nor does it cover error conditions or side effects. Given no annotations, the description provides only partial transparency.

  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 concise sentence with no filler words. It front-loads the main content (the list of status fields) and adds the secret fallback at the end. It is appropriately brief.

  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?

  Without an output schema, the description is responsible for explaining the return structure. It lists many fields but does not define their meaning or possible values. It also omits error behavior, authentication requirements beyond the secret note, and any prerequisites. This is insufficient for a tool with no output schema.

  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 description clarifies that the secret parameter is optional and has a fallback to local state. However, it does not explain watchId beyond the schema property name. With 0% schema description coverage, the description should offer more details about both parameters, but it only partially covers one.

  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 lists the fields that represent watch status (state, heartbeat, triggers, expiry, delivery stats, and dead-man switch details), making it clear this tool returns status information for a watch. However, it lacks an explicit verb like 'retrieves' or 'gets', which prevents it from being a fully specific statement of purpose. It differentiates from sibling tools by focusing on status rather than creation or deletion.

  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 alternatives such as create_watch, delete_watch, or payment_status. The description simply lists fields and the secret fallback, with no context about use cases or exclusions.

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

• coord_eventsB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects. It stays silent on whether collecting/draining events consumes or deletes them, and it does not mention authentication requirements (despite a 'secret' parameter). This leaves critical behavioral traits unknown.

  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 with no superfluous words. It front-loads the action and the context, making it easy to parse quickly.

  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?

  The description states purpose and timing but omits details on return value, whether events are consumed, and how parameters behave. For a 3-param tool with no output schema, this is insufficient for reliable 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 has 0% parameter coverage, and the description mentions none of the three parameters (since, secret, workspaceId). It provides no added meaning beyond their names, forcing an agent to guess their formats or purposes.

  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 ('collect') and resource ('barrier releases/partials'), and the phrase 'while nothing of yours was running' clearly distinguishes it from sibling tools like coord_release or coord_barrier. The title further clarifies its role as a mailbox for agents with no server.

  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 implies use after downtime ('while nothing of yours was running'), providing clear context for when to invoke it. However, it does not name alternatives or exclusions, so it lacks explicit when-not guidance.

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

• service_healthA
  3.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 itself must convey safety and side effects. It does not explicitly state that this is a read-only operation, what happens on failure, or what the response looks like. The technical phrasing 'Scanner cursor lag vs chain head' hints at a metric but leaves the behavioral implications unclear.

  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, well-structured sentence with no filler. It front-loads the key metric and then states the purpose, making it extremely concise and effective.

  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?

  The tool has no output schema, and the description does not describe what the agent should expect in the response or how to interpret the lag metric. For a health check, this lack of return-value information leaves a significant gap in understanding the tool's behavior.

  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 zero parameters and schema description coverage is 100%. With no parameters to explain, the description cannot add parameter semantics, and the baseline for zero-parameter tools is 4.

  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 function: verifying the watcher is alive by comparing scanner cursor lag to chain head. It has a clear verb ('verify') and resource ('watcher'). However, it does not explicitly distinguish from sibling tools like ping_heartbeat, which also sounds like a health check, so it stops short of a 5.

  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 phrase 'before you buy' provides a clear and specific usage context: use this tool to confirm the service is healthy before making a purchase. It does not, however, mention when not to use it or reference alternative tools, which would be needed for a 5.

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

• coord_workspaceA
  4/5.0
  Behavior3/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 the payment model (paid via x402, $0.25/7 days, 1000 ops) and the benefit ('every barrier and lock operation is FREE and FAST'). However, it omits details about what happens after expiry, renewal, or payment failure. Partial transparency.

  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 sentences, front-loaded with purpose and price. Each sentence adds value: pricing, benefit, and use cases. No fluff or repetition.

  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?

  For a purchase tool with one optional parameter and no output schema, the description covers purpose, cost, duration, ops limit, and specific use cases. It lacks lifecycle details like renewal/expiry behavior, but sibling tools (payment_status, verify_receipt) may cover those. Complete enough for agent decision-making.

  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% with webhookUrl described as 'default webhook for coordination events.' The description does not mention the parameter, but the schema already provides sufficient semantic meaning. Baseline 3 is appropriate.

  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 'Bups a coordination workspace' with specific pricing and duration. It distinguishes itself from siblings like coord_barrier and coord_lock by being the purchase step that unlocks free operations. The verb+resource+scope is unambiguous.

  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 provides explicit use cases: 'fan-in sub-agents (coord_barrier)' and 'stop two agents doing the same irreversible thing (coord_lock).' It implies this should be used before those operations, though it doesn't explicitly contrast with payment_status or verify_receipt. Clear context, no exclusions.

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

• pause_watchA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does well by disclosing a non-obvious side effect: 'The expiry clock keeps running.' It also signals non-destructiveness ('without deleting it') and the dead-man switch context. It falls short of mentioning reversibility or any required permissions.

  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, front-loaded with the action, and every word adds value. The use case and side effect are included without fluff.

  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 core behavior is well covered, including scope, non-deletion, and expiry behavior. However, parameter semantics are missing, and there is no information about return values, errors, or whether the operation is reversible. The tool is simple, so a 3 reflects the gaps that remain.

  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 tool description does not explain any parameters. 'watchId' is inferable but 'secret' is ambiguous and could be a password, token, or other value. The description adds no meaning beyond the bare parameter names.

  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 action ('Stop a watch firing') with a specific resource and scope (chain, web, heartbeat, schedule). It explicitly contrasts with deletion, distinguishing it from sibling tools like delete_watch.

  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?

  Provides a concrete use case ('Use before a planned agent shutdown so your dead-man switch does not cry wolf') and clarifies it does not delete the watch. However, it does not mention when not to use it or point to resume_watch as the opposite action.

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

• resume_watchA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden. It reveals key behavioral traits: deadlines restart, schedules jump to future slots, and no elapsed time replays. This goes beyond a simple 'resumes a paused watch' and gives the agent a concrete mental model of the operation's effects.

  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, well-structured sentence that immediately states the core concept ('Backlog-free resume') and then elaborates with specifics. There is no filler or redundant phrasing, making it highly efficient.

  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 description explains the central behavior clearly, but it omits parameter details and any mention of return values or error conditions. Since there is no output schema and no annotations, the description is not fully complete for an agent to invoke the tool correctly without additional inference, though the primary semantics are covered.

  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 input schema defines 'secret' and 'watchId' with no descriptions, and the tool description does not mention either parameter. With schema coverage at 0%, the description should have compensated by explaining what these parameters mean, but it fails to do so, leaving the agent to infer from names alone.

  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 'resume' and names the resource 'watch', clearly indicating the action. It further clarifies scope by stating 'heartbeat deadlines restart from now and schedules jump to their next FUTURE slot', distinguishing it from pause_watch and other lifecycle tools.

  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 does not explicitly mention when to use the tool or contrast it with alternatives, but the behavior is clearly contextualized as a resume operation that is 'backlog-free'. This gives enough context for an agent to infer it is the counterpart to pause_watch, though no direct exclusions or alternatives are stated.

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

• renew_watchA
  4.1/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 the period extension, pricing, budget reset, and reactivation behavior—substantial detail beyond a simple 'renews a watch.' It does not cover payment flow or failure states, but the disclosed traits are meaningful.

  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 tightly written sentences with no filler. The first sentence covers the core action and effects; the second adds an important edge case. Each clause earns its place.

  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 a mutation with no output schema and no annotations. The description covers the main effects but omits return values, payment details (despite the x402 mention in the title), and error scenarios. Given the complexity, this is adequate but has clear gaps.

  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?

  The schema has 0% coverage from the description, so the description must compensate. It implies watchId as the target and explains tier affects duration and price, adding meaning to the enum values. However, it never explicitly links these to the parameter names or mentions 'tier' and 'watchId' directly, so it only partially compensates.

  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 verb 'Extends' with a specific resource (a watch) and the specifics of duration (7 days, or 30 on *30 tiers), price, budget reset, and reactivation. This sharply distinguishes it from siblings like create_watch, pause_watch, and delete_watch.

  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 provides clear context for when to use (renewing a watch for an additional period) and includes an edge case (reactivating paused watches). However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

• coord_lockA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses auto-expiry after ttlSeconds, the 409 behavior with holder info, and the consequence for crashed agents (no deadlock), which is strong behavioral context. It doesn't detail renewal or permission requirements, but that's minor for a lock tool.

  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 sentences, front-loaded with the core purpose ('LOCK'), and every sentence adds value—behavior, return, and usage handoff. No wasted words.

  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?

  For a lock tool, the response format and expiration behavior are covered. It doesn't discuss renewal or retry logic, but given its simplicity, the description is adequate, especially with the sibling release tool named for the 'done' case.

  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 only 40%, but the description explains the purpose of ttlSeconds (auto-expiry) and the meaning of leaseId/409. However, it doesn't clarify workspaceId, holder, or secret parameters, so it doesn't fully compensate for the schema gaps.

  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 acquires a lock/lease ('LOCK'), specifying it returns a leaseId or 409, and distinguishes it from siblings like coord_release and coord_barrier by its mutual-exclusion role.

  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 gives explicit context: use it for 'only one agent does this irreversible thing' and recommends 'Call coord_release when done (or just let it expire).' This names the complementary tool, though it doesn't discuss when a barrier or other coordination tool would be more appropriate.

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

• coord_arriveA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds key behavior: idempotent per part, so retrying agents cannot inflate the count. It also clarifies the ctx is handed to the consumer of the released barrier. It does not mention error behaviors, but the disclosed idempotency is valuable.

  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. Every word earns its place, including the idempotency note and the source of arriveUrl. No fluff.

  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?

  For a simple 3-parameter tool with no output schema and no annotations, the description covers the essentials: purpose, parameters, idempotency, and relationship to coord_barrier. It doesn't explain return values or failure modes, but given low complexity and sibling context, this is adequate.

  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?

  Schema coverage is 67%, with arriveUrl lacking a description. The description compensates by explaining arriveUrl comes from coord_barrier and elaborates on ctx as 'whatever you want handed to whoever consumes the released barrier'. The part parameter's example is also reinforced. This adds meaning beyond the schema.

  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 a specific verb 'report' and resource 'this part is done', and clearly distinguishes from siblings by referencing coord_barrier as the source of arriveUrl. It signals arrival at a barrier, which is distinct from coord_barrier (creation) and coord_release (release).

  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 explains how to use: pass the arriveUrl from coord_barrier plus a part name and optional ctx. The context of when to use is implied ('report that this part is done') and the reference to coord_barrier indicates the prerequisite. No explicit exclusions are given, but the guidance is sufficient for a simple tool.

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

• coord_barrierA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavioral traits: the arriveUrl is a capability that lets sub-agents arrive but not read/delete the workspace, exactly one webhook fires with all collected context, and a partial event names missing agents on TTL expiry. It also clarifies that timeout is intended behavior, not an error.

  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 compact yet packs essential information: the core purpose, the security model, the webhook behavior, and the timeout semantics—all without unnecessary words. It's front-loaded with a clear summary and then adds specifics in a structured flow.

  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 key operational details: the arrival capability, webhook aggregation, partial events, and timeout semantics. However, it omits any explanation of the return JSON structure (beyond 'arriveUrl') and leaves several parameters (label, secret, workspaceId) semantically undefined. Given no output schema, these omissions prevent a perfect score.

  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 only 17%, so description must compensate. It explains the meaning of 'parts' (how many sub-agents) and ttlSeconds (timeout), and implies webhookUrl (fires one webhook). However, label, secret, and workspaceId are left unexplained, and webhookUrl isn't explicitly linked to the parameter, leaving gaps despite partial compensation.

  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 creates a barrier/fan-in, with a concrete use case ('wake me when all N of my sub-agents finish') and returns an arriveUrl. It distinguishes this parent-side coordination tool from siblings like coord_arrive by describing the barrier-creation role and the capability it hands out.

  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 provides a clear context for use: coordinating N sub-agents and receiving their aggregated context when all finish. It doesn't explicitly mention when-not-to-use or name alternatives, but the usage intent is unambiguous, earning a 4 rather than a 5.

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

• cron_nextA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses key behavioral traits: timezone support (any IANA), the computation of seconds until next, and that it is a pure computation (not an action trigger). It does not mention return format or errors, but for a simple compute tool the description is adequate and adds value beyond the schema.

  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, front-loaded with the core purpose. The second sentence introduces the alternative without excess wordiness. Every sentence earns its place, with no redundant or filler content.

  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?

  For a tool with no output schema and no annotations, the description gives a reasonable overview: it states the output type (next run times, seconds-until-next) and mentions timezone handling. It could be more explicit about the exact return structure (e.g., list of timestamps) and the cost (mentioned only in the title). However, the description is sufficiently complete for a moderate-complexity compute tool, especially with the clear sibling distinction.

  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 only 33% (only cron is described). The description adds some parameter meaning by mentioning 'any IANA timezone' (for tz) and 'Next N' (for count), but it does not clarify defaults, ranges, or formats beyond what the schema already provides. It partially compensates but does not fully carry the burden for the undocumented parameters.

  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 computes next N run times for a cron expression in any IANA timezone, plus seconds until the next run. It uses a specific verb-resource pairing and explicitly distinguishes itself from create_watch, which is a sibling tool for scheduling actions.

  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: if the goal is for something to happen at the computed times, use create_watch with a schedule condition instead. This clearly states when not to use cron_next and names the alternative tool, fulfilling the when/when-not/alternatives requirement.

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

• ping_heartbeatA
  4.4/5.0
  Behavior3/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 the dead-man switch behavior and the 'at least once per intervalSeconds' constraint, which is useful. However, it does not mention idempotency, error handling, or consequences of missing pings, which would be valuable for a heartbeat tool. The description gives some context but is not comprehensive.

  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, front-loaded with a memorable metaphor, and every phrase carries necessary information. No wasted words; it efficiently conveys purpose, parameter logic, and timing requirement.

  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?

  For a simple heartbeat tool with two optional params and no output schema, the description is complete. It explains the purpose, the parameter semantics, and the required call frequency. No critical information is missing for an agent to invoke the tool correctly.

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

  Parameters5/5

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

  Schema coverage is 0% and there are only two string parameters. The description adds significant meaning by explaining that pingUrl comes from create_watch and that watchId alternatively refers to ping URLs in local state. It clearly clarifies the source and trade-off between the two parameters, fully compensating for the lack of schema documentation.

  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 identifies the tool's purpose with a specific metaphor: 'Keep a dead-man switch alive.' It distinguishes itself from sibling tools like create_watch (which creates watches) and watch_status (which checks status) by indicating this is the periodic check-in mechanism that must be called regularly.

  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 provides clear usage context: pass pingUrl from create_watch or watchId, and call at least once per intervalSeconds. It names the source parameter and the frequency, giving clear when-to-use guidance. However, it does not explicitly mention alternatives or exclusions, such as using watch_status for status checks.

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

• verify_receiptA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It explains the receipt's cryptographic nature (Ed25519 attestation) and the verification action, implying read-only behavior. It does not discuss error handling or side effects, but for a stateless verification, this is adequate; the 'free' in the title hints at no cost.

  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 provide background and action without fluff. The first sentence defines the receipt, the second explains the verification and use case. No wasted words.

  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?

  For a single-parameter verification tool with no output schema, the description covers the purpose, the input structure, and the intended scenario. It does not explicitly state return values or error behavior, but the verification context makes those predictable. A 4 reflects the small gap.

  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 schema only describes 'receipt' as 'the receipt object from an event', but the description specifies the expected fields {alg, keyId, statement, sig}, adding meaningful structure. With 100% schema coverage, baseline is 3, but the added field detail elevates it to 4.

  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 explicitly states the tool 'checks' a receipt 'against the service key', clearly identifying it as a signature verification tool. The title 'Verify a signed observation receipt' reinforces the verb and resource, and the receipt structure is defined, distinguishing it from the coordination/health sibling tools.

  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 explains when to use it: to validate evidence from another agent without trusting that agent. It does not name alternative tools, but the context is clear and no sibling offers the same verification capability, so it earns a 4 rather than a 5.

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

• create_watchA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden, and it excels. It discloses the payment mechanism (gasless USDC signed locally), billing semantics (failed calls never billed), delivery pathways (HMAC-signed webhook and server-side mailbox), cryptographic receipts (Ed25519), and local storage of credentials. This is far beyond typical transparency and gives the agent a complete behavioral model.

  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 dense paragraph, but every sentence earns its place, providing cost details, delivery routing, receipt handling, and billing guarantees. It is front-loaded with the purpose and immediately gives actionable pricing. While a bulleted structure would improve scannability, the prose is efficient and free of fluff.

  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?

  For a creation tool with no output schema, the description covers the essential outcomes: it returns/remembers an id and secret, specifies event delivery, and explains billing failure behavior. It does not explicitly state the response shape, but the local storage phrase implies what the agent receives. Overall, it provides a complete mental model for invoking the tool.

  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?

  Schema description coverage is low (0% per context), so the description compensates for tier and webhookUrl: tier is explained with prices and limits, webhookUrl is noted as HMAC-signed. Conditions are partially described via examples like 'heartbeat dead-man switches' and condition counts, but the detailed condition shapes are left to the schema, which already contains them. This is adequate compensation overall.

  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 opens with 'Buy a standing watch from DataSieve' – a specific verb and resource. It clearly distinguishes this creation tool from siblings by detailing the purchase aspect, tier pricing, and what constitutes a watch. The inclusion of concrete dollar amounts and trigger limits leaves no ambiguity about the tool's function.

  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 when to use this tool (to create a new watch) and even addresses the renewal scenario by explaining the 30-day tiers for agents 'that will not be awake to renew weekly.' It mentions complementary tools like drain_events but doesn't explicitly contrast with management siblings such as renew_watch or watch_status, so it stops short of full guidance.

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

• x402_pingA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It states the cost ($0.001), the fact that it's a real purchase, that failures are never billed, and the return value (payer + network). This covers key behavioral traits, though it omits potential side effects like transaction logs 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose, and no wasted words. It includes return values and failure billing in a compact manner.

  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?

  For a zero-parameter tool with no output schema, the description is complete: it covers what it does, why to use it, cost, success/failure behavior, and return fields. No additional context is needed.

  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 tool has zero parameters, and the schema coverage is 100% (empty). The description does not need to explain parameters, and the baseline for a no-parameter tool is 4. It provides no misleading parameter information.

  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 a specific action ('test the payment stack end-to-end') with a clear resource (x402, production seller) and distinguishes itself from siblings by emphasizing it's the cheapest possible real purchase. It also clarifies its role as a pre-flight check before expensive operations.

  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 phrase 'before you point it at anything expensive' clearly indicates when to use the tool. It does not name explicit alternatives or exclusions, but the context is sufficient for an agent to choose it as a preliminary payment test.

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

• payment_statusA
  4.9/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 the full burden of behavioral disclosure. It explicitly states 'never spends anything,' which is a strong safety guarantee, and outlines the specific information reported (wallet address, USDC balance, tier costs). This provides clear expectations about side effects and return 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 two sentences long and highly efficient. The first sentence states the core purpose (checking affordability), the second adds usage guidance and safety context. Every word contributes value; no filler or redundant information.

  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 that the tool has no parameters and no output schema, the description still manages to be complete: it states what is checked, what is reported, when to use it, and the key behavioral guarantee. No critical information is missing for an agent to use it correctly.

  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 tool has zero parameters, so schema coverage is trivially 100%. The description doesn't need to explain parameter semantics and doesn't waste space doing so. Baseline is 4 for zero-parameter tools, and the description adds no unnecessary parameter 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 starts with a specific verb 'Check' and identifies the resource (buying key affordability for a watch). It goes beyond a bare restatement by naming the exact outputs (wallet address, USDC balance, tier costs) and explicitly distinguishes itself from sibling tools by referencing create_watch. This fully clarifies what the 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 Guidelines5/5

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

  The description gives explicit usage guidance with 'Call this before create_watch; it never spends anything.' This tells the agent exactly when to invoke it (as a precondition to create_watch) and provides a key exclusion (never spends), clearly differentiating it from mutation tools.

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