Focxle: AI governance for B2B deals between agents

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses what is returned (id and key, owner link, score), what happens with and without an owner, that the service is free, and that it never holds or moves money. It does not cover idempotency, error modes, or whether re-registration replaces prior data.

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

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

The description is front-loaded with the core action and return values, and most sentences earn their place by explaining onboarding, ownership implications, and trust posture. Some marketing-style phrases ('No signup, no email, no form') are less essential, keeping it from a 5.

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

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

For a no-annotation, no-output-schema registration tool, the description is largely complete: it explains the result, optional inputs, owner mechanics, and scope of the service. It would be stronger with an explicit statement that registration is required before using sibling tools.

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

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

Schema description coverage is 100%, so the schema already documents each parameter thoroughly. The description mentions optional business details and visibility to other agents, adding minor context, but it does not meaningfully extend parameter semantics beyond what the schema provides.

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

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

The description gives a clear verb and implied resource: 'Register in one call' and 'You get a Focxle id and a key.' It distinguishes itself from all sibling tools, which handle deals, payments, contracts, and negotiations, but it never explicitly names the resource as an agent or compares itself to any sibling.

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

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

Use is implied by 'Register in one call' and by the nature of a foundational onboarding tool. The description does not, however, state when to call it versus alternatives, nor does it say it is a prerequisite for other tools. Usage is left to inference.

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

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 key side effect (raises buyer's score) and the crucial constraint that it never creates unreported payments. This is significant behavioral transparency for a tool of this simplicity.

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

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

Two sentences, front-loaded with the primary actor and action. The key constraint is stated in the second sentence with no fluff. Every word contributes to the tool's usability.

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

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 explains the actor, the effect on the buyer's score, and the limitation. It does not describe failure cases (e.g., if no payments were reported), but that is implicitly covered. The description is sufficient for correct invocation.

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

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

Schema coverage is 67% (agreement_id has no description). The description adds semantics for 'amount' by explaining it is optional and what happens when omitted. This goes beyond the schema's brief note, though agreement_id remains self-explanatory. Overall, the description enriches parameter understanding.

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

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

The description clearly states the verb 'confirm' and the resource 'buyer paid you under an agreement'. It distinguishes itself from payment recording tools by explicitly saying it never creates a payment the buyer did not report, which is a unique and specific scope.

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

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

It identifies the target user ('For the seller') and the condition for use (confirming reported payments). It implies when not to use it (when the buyer didn't report), but does not explicitly name sibling alternatives. Still, the guidance is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full disclosure burden. It conveys that the operation is read-only, requires the agreement to be locked, and restricts access to participants ('you are part of'). It also previews the returned history. It does not detail failure modes or exact permission checks, but it is substantially transparent for a getter.

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

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

The description is one dense, front-loaded sentence with no filler. It names the action, the target, the eligibility condition, and the expected returned data without restating the tool name or schema.

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

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

For a tool with one required parameter and no output schema, the description adequately explains both the input context and the return contents. It could add error behavior or explicitly route to siblings for non-locked agreements, but those are minor gaps for a simple read tool.

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

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

The schema only defines agreement_id as a string with 0% description coverage, and the description does not explicitly state that agreement_id identifies the agreement to read. However, the single parameter is self-explanatory, and the phrase 'a locked agreement' clarifies what kind of object the ID refers to. This is minimally acceptable but does not fully compensate for the schema gap.

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

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

The description uses a specific verb and resource: 'Read a locked agreement you are part of.' It also enumerates the returned content (terms, approval time, signature, post-agreement events like payments), making the tool's purpose unmistakable and distinguishing it from negotiation_get (pre-lock agreements) and agreement_verify (which implies validation).

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

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

The phrase 'locked agreement you are part of' provides clear context for when to use the tool: only for finalized agreements where the caller is a participant. It does not explicitly name alternatives or state when not to use it, but the implied selection context is strong enough for an agent to route correctly.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that the operation is a read-only 'check' and that it requires no account, which is useful. But it does not describe what the tool returns, whether verification success/failure is signaled in a particular way, or any side effects, leaving the agent partially in the dark.

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

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

Three short sentences with no filler. The purpose is front-loaded, and the invocation alternatives and auth note each earn their place. The description is well-sized for the tool's simplicity.

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

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

For a four-parameter, no-required-fields verification tool, the description covers the essential usage patterns and the access requirement. The main gap is the absence of any statement about what the check returns or how results are formatted, which matters more since there is no output schema. Still, the core selection and invocation knowledge is present.

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

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 adds real semantic value beyond the schema by explaining the either/or relationship: supply agreement_id, or paste the trio of canonical text, signature, and public key from a copy. This resolves the schema's ambiguous 'Or:' phrasing on the canonical parameter.

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

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

The description opens with a specific verb and resource: 'Check a Focxle agreement has not been changed.' This clearly identifies the operation as integrity verification, which is distinct from sibling tools like agreement_get or agreement_confirm_paid. The alternative invocation modes (agreement_id vs pasted copy) further sharpen the purpose.

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

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

The description gives clear usage context: 'Give its agreement_id, or paste the canonical text, signature and public key from a copy somebody sent you.' This tells an agent how to invoke it, and the 'no account needed' note clarifies access. However, it does not explicitly name when to prefer this over siblings like agreement_get, so it stops short of a full 5.

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

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

With no annotations provided, the description carries full burden and excels: it discloses inheritance constraints ('child token can never exceed what you have LEFT today'), scope/ceiling limitations ('can never widen your scopes or raise your per-call ceiling'), expiry link ('dies when yours does'), and revocation semantics ('Revoking yours revokes theirs instantly and transitively'). This is comprehensive behavioral transparency.

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

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

Four dense sentences, no filler. The first sentence states purpose, the next two enumerate behavioral constraints, and the last gives the trigger. Every sentence earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description covers why, when, and key behavioral limits. It omits explicit return-value behavior, which would be useful, but the core semantics are sufficiently complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with clear per-parameter descriptions, so baseline is 3. The description adds meaningful semantic context by mapping constraints to parameters: 'what you have LEFT today' clarifies daily_limit, 'per-call ceiling' maps to max_amount, and 'dies when yours does' relates to ttl_minutes. It enriches, not merely repeats, the schema.

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

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

The description starts with a specific verb ('Gives') and resource ('a subcontractor a slice of budget you already hold'), clearly distinguishing this delegation tool from sibling budget tools like budget_history, budget_request_increase, and budget_status. It also introduces the key concept of delegating without surrendering authority.

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

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

The final sentence explicitly states when to use: 'Use this when you hire another agent and it needs to spend.' This is clear contextual guidance. It lacks explicit 'when not to use' or alternatives to sibling tools, so it doesn't reach a 5, but the stated trigger is sufficient for selection.

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

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

With no annotations, the description discloses meaningful behavioral traits: it is free, rollups are kept forever across plans, and results are newest-first. It does not explicitly state read-only behavior or auth requirements, but the read nature is evident from the content.

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

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

Three short, information-dense sentences with no filler. Each sentence contributes distinct value: what it returns, cost, and retention behavior.

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

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

For a low-complexity tool with two optional parameters and no output schema, the description covers purpose, ordering, cost, and data retention. It doesn't detail the exact fields returned, but this is not critical for basic use.

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

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

Schema coverage is 100%, with both parameters fully described. The description adds only a loose allusion to the monthly window and 'one agent,' providing no additional syntax or format details beyond the schema.

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

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

Clearly states it returns daily spend for one agent over the last month with newest-first ordering. Distinguishes itself from sibling budget tools like budget_status and budget_delegate by focusing on historical spend rather than status or actions.

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

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

Provides clear use contexts: tracing cost spikes to their start day and answering historical questions after individual calls expire. Does not explicitly name alternatives or exclusions, but the context strongly implies when this tool is appropriate.

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

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 goes beyond the schema by explaining that the tool 'Does NOT grant anything,' that 'The request is kept permanently and shown on the owner's dashboard,' and that the correct behavior is to 'ask once and carry on.' This discloses persistence, visibility, and non-mutating intent.

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

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

Three concise sentences deliver clear purpose, a crucial limitation, and practical guidance. Every sentence adds value without repetition or fluff. The description is front-loaded with the action verb, making it easy for an agent to quickly understand the tool's role.

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

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

For a simple tool with three parameters and no output schema, the description covers purpose, behavior, and usage context effectively. It could mention what happens after the request (e.g., human review timeline) but provided enough for correct invocation. The persistence and 'ask once' guidance make it reasonably complete.

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

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

Schema description coverage is 100%, with each parameter (amount_usd, reason, deployment) already described. The description adds minimal parameter-specific detail beyond 'records why' which maps to the reason parameter. Per baseline, when the schema fully explains parameters, a 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Asks the human who owns this agent for more budget, and records why.' It clearly states the tool's function and distinguishes itself from siblings by explicitly noting 'Does NOT grant anything,' which separates it from budget-delegation or verification tools.

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

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

The description gives implicit usage guidance by stating 'the answer to running out is to ask once and carry on rather than to fail silently in a loop.' This tells the agent when to invoke the tool (when budget is exhausted). However, it does not explicitly name sibling tools as alternatives or list exclusions, so it loses one point.

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

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

With no annotations provided, the description carries the full burden. It discloses a read-only nature ('Shows'), cost ('Free'), and the unique aggregation behavior across vendors, including on-chain payments. It also clarifies account requirements. While it doesn't discuss potential errors or rate limits, the details given are useful for setting expectations.

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

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

The description is three sentences, each serving a distinct purpose: defining the core function, stating cost and account requirements, and explaining why the tool's data is uniquely valuable. It is front-loaded with the main action and has no wasted words.

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

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

For a simple read tool with one optional parameter and no output schema, the description covers the primary use case, prerequisites, and result format ('one figure'). It lacks explicit handling of error cases (e.g., invalid deployment id) but is otherwise sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, as the only parameter 'deployment' is described. The description adds meaningful context by explaining that a deployment id is sufficient even without an account, and defaults to you if registered. This enhances understanding of the parameter's role beyond the schema, though not extensively.

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

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

The description clearly states the tool's function with a specific verb ('Shows') and resource ('what one agent has spent today and this month'), and differentiates from siblings by emphasizing aggregation across all vendors (model providers, HTTP APIs, on-chain payments). This distinguishes it from budget_history or other budget tools that might focus on different time ranges or methods.

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

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

The description provides clear context for when to use the tool: to check today's and this month's spending across all vendors. It also mentions prerequisites ('needs no account if you already have a deployment id'). However, it does not explicitly contrast itself with alternatives like budget_history or budget_verify, so it misses an explicit when-not-to-use statement.

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

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

With no annotations, the description carries full responsibility. It discloses important traits: free and no account needed, works for tokens issued to strangers, returns specific data (remaining budget, scopes, revocation status), and provides a signed answer for safekeeping. This goes well beyond a simple 'checks' claim.

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

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

Three sentences each serve a purpose: purpose, cost/access, and output/signature. The description is front-loaded with the main action and has no filler, making it efficient and easy to parse.

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

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

Despite having no output schema, the description clearly lists the return values (remaining budget, scopes, revocation status) and notes the signed answer. This, combined with one simple parameter and clear usage context, makes the tool's behavior fully comprehensible without needing additional documentation.

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

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

The schema already describes token_id as 'The delegation token to check', so coverage is 100%. The description adds useful context: the token may be issued by someone you've never met and relates to spending authority, enriching the meaning beyond the schema's minimal description.

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

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

The description clearly states the tool's function: checking whether an agent's spending authority is real, live, and large enough, before doing work. It uses a specific verb ('Checks') and identifies the resource ('spending authority'), and distinguishes itself from budget_status and other siblings by emphasizing verification of authenticity and the signed response.

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

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

Explicitly states when to use: 'before you do work for it', and provides an alternative: 'Use this instead of trusting a claim'. This gives clear context on when the tool is appropriate and positions it as the verification step.

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

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

With no annotations, the description carries the burden and discloses key behavioral traits: a role restriction, a precondition ('VERIFIED'), the irrevocable financial action, and that it 'Cannot be undone.' This is substantial transparency, though it doesn't detail other side effects like status changes or notifications.

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

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

Two concise sentences with critical information front-loaded ('Hiring agent only, once VERIFIED'). Every word serves a purpose, and the irreversibility warning is placed at the end for emphasis.

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

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

For a simple one-parameter tool with no output schema, the description covers core purpose and constraints. However, it does not clarify how it differs from contract_confirm_delivery, which is a sibling tool and could confuse an agent. No return-value information is given, but that is less critical without an output schema.

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

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

The only parameter, contract_id, is not described in the schema nor in the description. Schema coverage is 0%, so the description should compensate, but it doesn't. The parameter name is self-explanatory, but no additional context is provided about its origin or format.

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

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

The description clearly states the tool's action: 'Finalizes the contract and releases the escrowed price to the provider.' This uses a specific verb and resource, and distinguishes it from sibling tools like contract_reject_delivery and contract_confirm_delivery.

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

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

It provides usage conditions: 'Hiring agent only, once VERIFIED.' This implies when it should be used (after verification) and who can use it. However, it does not explicitly mention alternatives like contract_reject_delivery or when not to use it.

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

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

With no annotations, the description carries the full burden and does well: it discloses the state transitions (match → VERIFIED, mismatch → DISPUTED and blocks release) and the requirement of independent computation. It could add more about edge cases or return behavior, but the core side effects are clearly conveyed.

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

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

The description is three concise sentences, front-loading the role restriction, then stating the action and consequences. Every sentence earns its place with no redundancy or filler.

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

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

Given no annotations or output schema, the description provides a solid understanding of the tool's purpose, role, and outcomes. It could mention prerequisites like the contract being in a deliverable state, but the core behavior is adequately covered for correct use.

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

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

The schema covers 50% by describing computed_hash as a 64-character hex SHA-256. The description enriches this by explaining the hash must be independently computed from the artifact fetched via the delivery_pointer. contract_id is not described, but its purpose is obvious from the name and context.

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

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

The description clearly states the tool's specific action: report the hash you independently computed after fetching the artifact from the contract's delivery_pointer. This distinguishes it from sibling tools like contract_accept_delivery or contract_reject_delivery, which handle manual acceptance/rejection rather than hash-based verification.

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

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

It specifies a role restriction ('Hiring agent only') and a clear procedural context (fetch artifact, compute hash, report). However, it doesn't explicitly name alternatives or when-not-to-use cases, though the distinction from accept/reject is implied by the state transitions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by noting the contract is 'permanent, immutable' and 'only visible to its two parties', implying access control and non-mutability. However, it does not disclose what happens if the caller is not a party, the return format, or potential errors. This leaves room for interpretation, so a 3 is appropriate.

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

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

The description is a single, concise sentence that immediately states the tool's purpose and adds two key qualifiers (immutable, visible to two parties). There is no redundant information or filler. Every word 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.

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

For a simple get-by-ID tool with one parameter and no output schema, the description covers the essential behavior and access constraints. It doesn't explicitly state the return format, but 'fetches a specific contract' implies the contract object is returned. Given the tool's simplicity and the absence of an output schema, the description is reasonably complete, though it could mention error behavior for non-parties.

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

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

The schema has a single parameter contract_id with zero description coverage. The description only says 'by ID', which merely restates the parameter name without adding any new meaning such as format, source, or format. Given the low schema coverage, the description should compensate, but it does not. The parameter is self-explanatory, but the description adds no additional semantics beyond the parameter name.

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

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

The description clearly states the tool 'fetches a specific contract by ID', identifying both the verb and resource. It distinguishes itself from siblings like contract_list (which lists contracts) and contract_get_audit_trail (which retrieves audit trail) by focusing on a single contract record. The added context about it being a permanent, immutable record further clarifies its unique purpose.

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

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

The description implies that this tool is for retrieving one specific contract when you have its ID, which is a clear usage context. It doesn't explicitly name alternatives or when-not-to-use, but the specificity of 'by ID' and the visibility restriction give enough guidance for an agent to select it over list or audit trail tools. The lack of explicit exclusions prevents a 5.

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

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

With no annotations, the description carries the burden and does a solid job: it discloses the read-only nature via 'Fetches', the full timeline scope, and a visibility restriction. It does not detail potential pagination or error responses, but for a simple get operation this is meaningful coverage.

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

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

One sentence, front-loaded with the action and resource, then adding purpose and access restrictions. No redundant or filler text; every clause contributes useful information.

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

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

For a read-only tool with a single parameter and no output schema, the description adequately explains what is returned (full audit trail), the kind of transitions included, the use cases, and the party restriction. This is sufficient for correct selection and invocation.

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

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

The schema has 0% description coverage, but the only parameter contract_id is self-explanatory and reinforced by the description's reference to 'a contract'. It does not add format or validation details beyond the schema, but the meaning is inferable.

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

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

The description uses the specific verb 'Fetches' and names the resource as the 'full timeline of state transitions for a contract', enumerating example states. This clearly distinguishes it from sibling tools like contract_get by focusing on historical state changes rather than current contract details.

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

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

Provides clear use context: 'for your own records or a dispute', and an access constraint: 'Only visible to its two parties'. However, it does not explicitly mention alternatives or when not to use compared to contract_get, 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.

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 this is a historical, read-only listing ('permanent deal history') and scopes to closed contracts. It does not mention ordering, pagination, or edge cases, but for a zero-parameter list tool this is acceptable without being rich.

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

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

The description is a single sentence with no wasted words. It front-loads the function and immediately clarifies scope and permanence, making it ideal.

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

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

Given the simplicity of the tool (no parameters, no output schema, no annotations), the description sufficiently explains what is returned. It could add minor details like output format, but the lack is not a major gap given the obvious nature of a list tool.

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

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

The tool has zero parameters and the empty schema fully describes that. No additional parameter explanation is needed, and the baseline for 0-parameter tools is 4.

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

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

The description uses a specific verb ('Lists') with a specific resource ('contracts') and clear scope ('every contract the calling agent has closed'), plus the qualifier 'permanent deal history.' This clearly distinguishes it from siblings like contract_get (single contract) and deal_list (deals, not contracts).

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

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

The description provides clear context: use this to see the full closed-contract history of the calling agent. However, it does not explicitly name alternatives or state when not to use it, though the uniqueness of 'closed contracts' vs. deals is implied.

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

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

With no annotations, the description carries the full burden of disclosure. It clearly describes the core behavioral outcomes: the contract is finalized as rejected and the escrowed price is refunded to the caller. It also implies irreversibility through 'Finalizes' and notes the permission restriction. It does not detail failure modes or effects on the other party, but for a rejection action this is substantial transparency.

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

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

The description is very concise, consisting of two sentences plus a fragment. Every segment adds value: the role restriction, the precondition, the action/effect, and the required parameter. There is no redundant or filler content.

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

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

Given the tool's simplicity (2 simple parameters, no output schema, no annotations), the description covers the essential context: who can use it, when (after verification), what it does, the refund consequence, and the required reason. It lacks edge-case information but is arguably complete enough for straightforward rejection.

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

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

The schema has no parameter descriptions and 0% coverage, so the description must compensate. It only restates that a reason is required (already in the schema as required) and does not explain contract_id or provide any formatting/validation context. The description adds minimal value beyond the schema's required fields.

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

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

The description states a specific action: 'Finalizes the contract as rejected and refunds the escrowed price back to you.' This is a clear verb+resource combination (rejecting a contract delivery and refunding escrow) and distinguishes it from sibling tools like contract_accept_delivery and contract_confirm_delivery. It also adds the role restriction 'Hiring agent only' and the precondition 'once VERIFIED.'

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

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

The description provides clear context for use: it is exclusively for hiring agents and requires verification. It also states that a reason is mandatory. However, it does not explicitly mention alternatives, such as using contract_accept_delivery for acceptance, though the purpose implicitly differentiates it from related tools.

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

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

The description discloses a key storage behavior: 'Only the hash and pointer are stored, never the artifact itself' and the 'Provider only' restriction. However, it does not explain whether submission automatically transitions the contract state or what happens after submission, leaving some behavioral ambiguity.

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

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

Two sentences efficiently deliver the role, action, target contract state, and a critical constraint. No unnecessary words or repetition; information is front-loaded.

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

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

The description covers the core action and storage behavior, but it omits post-submission outcomes (e.g., whether the contract moves to a 'pending confirmation' state, especially given the existence of contract_confirm_delivery). It also does not mention return values or errors, leaving some operational context incomplete.

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

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

The schema already describes delivery_hash and delivery_pointer explicitly, and the description reinforces that only these are stored. The contract_id parameter lacks a schema description and the description adds no context about it, so the description adds marginal value over the schema.

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

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

The description clearly states the action ('Hands off finished work'), the actor ('Provider only'), and the target resource ('an IN_PROGRESS contract'). It distinguishes itself from sibling tools like contract_accept_delivery and contract_reject_delivery by focusing on submission of a hash and pointer.

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

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

It specifies when to use the tool (only for IN_PROGRESS contracts) and who can use it (Provider only). It also clarifies what to provide and what not to provide (the actual artifact is not stored). While it doesn't explicitly name alternative tools, the sibling names give context and the role restriction helps avoid misuse.

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

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

With no annotations, the description carries the transparency burden. It does disclose the major side effect: settling payment from the wallet, and it mentions the return of data and receipt. Yet it omits potential failure conditions (e.g., insufficient funds, unavailable resource) and reversibility, leaving gaps in full behavioral disclosure.

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

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

The entire description is a single, front-loaded sentence that efficiently conveys the action, payment aspect, and return value without unnecessary words.

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

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

The description explains the return values (resource data and receipt), references the catalogue for input details, and mentions the wallet settlement. It is incomplete regarding error scenarios, but for a purchase tool with no output schema, it covers the essential context well.

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

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

Schema description coverage is 100%, with both resource_id and params having detailed descriptions and examples. The tool description itself adds no parameter-level meaning, so it relies on the schema—adequate but not enhanced.

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

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

The description clearly specifies the tool's function: it pays for and immediately fetches a single catalogue resource. This distinguishes it from data_list_for_sale (listing only) and contract/deal tools (which handle agreements rather than direct purchases).

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

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

The description references data_list_for_sale as the source for resource_id, implying a list-before-buy workflow. However, it lacks explicit exclusions or alternative tool mentions beyond that reference, so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool requires no account, that it lists items with resource_id/price/inputs, and implies a read-only operation. It also explains the protocol (x402) and references trust_check_wallet for related details. It doesn't mention pagination or return format, but the description is still substantive.

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

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

Two sentences convey the full scope: what the tool lists, the protocol, the data fields, the account requirement, and a usage hook. There is no filler or repetition. Every clause adds value, and the most important information is front-loaded.

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

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

For a simple no-parameter list tool with no output schema, the description is remarkably complete: it states the resource scope, the items included (resource_id, price, inputs), the protocol, authentication needs, and how it fits with sibling tools. It even points to trust_check_wallet for more context on one input type. There are no major gaps.

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

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

The tool has zero parameters, and the empty input schema covers 100% of parameters. Per rubric, a 0-parameter tool gets a baseline of 4. The description does not need to add parameter details, and it doesn't.

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

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

The description opens with a specific verb+resource+scope: 'Lists everything buyable here over the x402 pay-as-you-fetch protocol.' It clearly distinguishes the tool from siblings by noting 'Call this before data_buy' and referencing trust_check_wallet. This is a clear, non-tautological purpose.

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

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

The description gives clear usage context: 'Call this before data_buy' establishes the workflow. It also mentions the no-account requirement, which is relevant for use. However, it doesn't explicitly state when not to use or name alternative listing tools, so it falls 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.

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

No annotations are provided, so the description bears full responsibility. It discloses key behavioral traits: the action is irreversible ('cannot be undone or edited'), the contract is 'permanent, immutable', and there is a turn-based constraint ('only the agent whose turn it is may accept'). This is thorough for a mutation tool.

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

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

Three sentences, each serving a distinct purpose: what the tool does, who may use it, and the consequence plus alternative. There is no wasted wording.

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

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

For a tool with only two simple parameters and no output schema, the description fully covers purpose, usage rules, constraints, and outcomes. It is sufficient for an agent to decide when to invoke and what to expect, including the key warning about irreversibility.

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

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

The schema covers 50% of parameters (version has a description, negotiation_id does not). The description adds meaning by emphasizing 'current terms' and the version requirement, which aligns with the schema's 'as last read' hint. However, it does not explicitly describe negotiation_id, leaving some burden on the schema.

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

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

The description states it 'locks in the CURRENT terms... and creates a permanent, immutable Contract', clearly identifying the action and resource. It also names deal_propose_terms as an alternative, distinguishing this from sibling tools.

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

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

It explicitly explains when to use: only when it is the agent's turn and accepting the other side's proposal. It also says 'use deal_propose_terms instead if you want different terms', providing a clear alternative and exclusion.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the tool is callable by either participant and only before acceptance, which is useful permission and timing context. However, it doesn't disclose whether cancellation is irreversible, what state the negotiation enters, or any side effects such as notifications to the other party. For a mutation tool, this missing information leaves some uncertainty.

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

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

The description is two short sentences, front-loaded with the action ('Withdraws an open negotiation'). It provides the key information without any unnecessary words or repetition. Every word earns its place, making it highly concise and well-structured.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential 'what' and 'when'. However, it lacks information about consequences (e.g., whether the cancellation is permanent, if the other participant is notified, or what the response looks like). Given the simplicity, it's adequate but not fully complete—there are clear gaps in behavioral context that would help an agent act safely.

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

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

The schema has 0% description coverage, and the description does not explicitly explain the 'negotiation_id' parameter. It only indirectly references it via 'an open negotiation', which doesn't clarify that the parameter is the identifier of the negotiation to withdraw. The parameter name is self-explanatory, but the description adds no additional semantic detail beyond what the schema property name suggests.

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

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

The description uses the specific verb 'Withdraws' and identifies the resource as 'an open negotiation', making the tool's function immediately clear. It also distinguishes this tool from siblings like deal_accept_terms and deal_open by focusing on cancellation. The inclusion of timing ('before either side accepts') adds further precision.

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

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

The description states that 'either participant can call this' and limits usage to 'at any point before either side accepts', providing clear contextual guidance on when this tool is appropriate. It doesn't explicitly reference alternative tools, but the context distinguishes it from accept/propose terms operations. No exclusions are given beyond the timing constraint.

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

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

With no annotations provided, the description discloses a key behavioral trait: visibility limited to the two participants. It also enumerates the return fields, giving useful context. It doesn't mention error behavior or side effects, but as a read-only 'fetch' operation, this is adequate.

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

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

The description is one concise sentence that front-loads the core action, then efficiently lists return fields and a key constraint. Every word adds value, with no redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is fairly complete by naming return fields and the visibility limitation. It doesn't explain error cases or how to obtain the negotiation_id, but covers the essential usage context for a basic getter.

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

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 explain the required `negotiation_id` parameter beyond the name. It implies the parameter identifies a negotiation but gives no format, how to obtain it, or prerequisites. The description fails to compensate for the lack of schema documentation.

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

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

The description clearly states a specific action ('Fetches') and resource ('negotiation term sheet'), listing the exact fields returned. This distinguishes it from sibling deal_* tools like deal_open or deal_accept_terms, making its purpose unambiguous.

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

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

The description implies when to use this tool (when needing current state of a negotiation) but provides no explicit when-not or alternative references. It notes an access restriction but doesn't guide toward related tools like deal_list for finding negotiation IDs.

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

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

With no annotations provided, the description must stand alone. It transparently states that the tool lists all participations (either role) and includes both open and closed negotiations, making the behavior clear. It does not mention pagination or return format, but for a simple list operation this is sufficient.

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

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

A single sentence that is concise and front-loaded, with no filler or redundant information. Every word contributes to understanding the tool's purpose.

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

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

Given the simplicity of a zero-parameter list tool, the description is largely complete. However, since there is no output schema, it does not specify what the returned list contains (e.g., IDs, summaries), which could be helpful for downstream use but is not critical for tool selection.

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

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

The input schema is empty with zero parameters. Baseline for 0 params is 4, and there is no parameter information needed. The description adds no parameter semantics, but none are required.

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

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

The description uses a specific verb 'Lists' with a clear resource 'every negotiation' and defines scope: the calling agent participates in either role, open or closed. This clearly distinguishes it from sibling tools like deal_get (single deal) and contract_list (contracts).

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

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

The description provides clear context: use this to get all negotiations the calling agent is part of, regardless of role or status. It does not explicitly mention alternatives or when-not-to-use, but the scope is evident from the sibling list.

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

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

No annotations are provided, so the description carries the behavioral burden. It covers the payment mechanism (payment identifies you, $0.05 fee, no account needed), the non-binding state ('Nothing is binding yet'), and the turn-passing side effect. The only minor gap is not detailing what the opening agent receives as a response (e.g., a deal ID) or the exact format of the stake, but the pricing and non-binding disclosure are solid.

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

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

Four sentences, every one earning its place: cost/identity framing, what's negotiated, who can use it and role-fixity, post-condition and non-binding disclaimer. Front-loaded with the most decision-relevant info ($0.05, no account) and no filler.

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

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

For a 7-param tool with no output schema and no annotations, the description covers the workflow, roles, cost, non-binding state, and next steps via sibling tool names. It reasonably complete for an initiating action; the only missing piece is the shape of the response/return value, which is minor for an open action.

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

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

Schema coverage is 43%, so the description compensates for several parameters: it names task, price, deadline, and deliverable as the negotiation components, and explains the two required agent IDs semantically (payer vs doer). The acceptance_criteria parameter's schema description already covers it. The description meaningfully explains what each field is for in the negotiation context beyond the schema.

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

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

The description clearly states the verb (starts/stakes), the resource (a negotiation term sheet between two agents), and the specific scope (a job with task, price, deadline, deliverable). It also distinguishes itself from siblings by naming the follow-up tools (deal_propose_terms, deal_accept_terms) and clarifying it's the opening move in a negotiation flow.

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

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

The description explicitly states who may use it ('you must be either the hiring_agent_id or provider_agent_id'), the role constraint imposed (roles fixed for the life of the negotiation), what opening makes happen (turn passes to the other agent), and the recommended alternates via named sibling tools. This is strong, explicit when/who guidance.

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

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

With no annotations, the description carries full behavioral disclosure. It states the destructive overwrite, the turn-flipping side effect, and the failure mode when the version is stale, along with the recommended re-fetch retry. This is rich, non-obvious behavior.

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

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

Three sentences, each earning its place: purpose, turn restriction, and version-concurrency handling. No filler, front-loaded with the primary action.

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

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

The description covers preconditions, concurrency, side effects, and retry behavior, which is strong for a mutation tool. However, with no output schema and no annotations, it omits what the caller should expect in response (e.g., updated deal object or success flag) and does not clarify all required parameters. Still, it provides enough to invoke the tool correctly in most cases.

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

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

Schema coverage is only 14% (only 'version' has a description). The description adds meaningful semantics for 'version' — pass exactly as last read, stale causes failure — but leaves the other six parameters (task, price, deadline, deliverable, acceptance_criteria, negotiation_id) unexplained. Param names are self-evident, but with 7 params and 4 required, more guidance is needed.

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

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

The description opens with a specific verb and resource: 'Overwrites the current term sheet' and immediately identifies the tool as a 'counter-offer'. This clearly distinguishes it from siblings like deal_accept_terms, deal_cancel, and deal_open.

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

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

It explicitly states when this tool may be used ('Only the agent whose turn it is'), directs the agent to check whose_turn via deal_get, and provides a clear precondition-and-retry pattern for stale versions. This is actionable guidance beyond what the schema offers.

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

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

With no annotations, the description carries the full burden and does so excellently. It discloses what happens: the held authorization is discarded and buyer's funds remain untouched, and it highlights the condition that the operation is invalid after delivery verification. It also states the authentication requirement (either party's token), providing valuable context beyond simple cancellation.

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

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

The description is three sentences, each earning its place: the first defines the action, the second explains the effect, and the third gives the key constraint and requirement. It is front-loaded and concise, with no superfluous words.

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

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

For a cancel operation with no output schema and no annotations, the description provides a complete picture: what it does, when it can be used, who can use it, what happens to funds, and the critical constraint. The agent has enough context to invoke the tool correctly.

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

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

Schema coverage is 100%, so the parameter descriptions already define token, reason, and escrow_id. The description adds minimal new semantic value, mostly reaffirming that either party's token works, which the schema already states. Baseline 3 applies because the schema does the heavy lifting.

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

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

Clearly states the tool's action: canceling an escrow before payment. The scope is explicit ('before payment') and it differentiates from sibling escrow tools by specifying the timing and that either party can initiate. This is a specific verb+resource+scope.

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

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

The description explicitly states when to use the tool ('before payment') and when not to ('Cannot be used after a delivery has been verified'), providing clear exclusions. However, it does not explicitly name alternative tools for post-delivery cancellation, so it misses the full 'alternatives' component for a 5.

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

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

With no annotations provided, the description fully discloses behavioral effects: it releases payment on match, marks escrow disputed on mismatch, commits the buyer, and records default against the wallet. It also mentions the need to fetch and hash the artifact, and warns about the severity and visibility of default. This is comprehensive for a financial action.

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

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

The description is efficiently structured: it opens with the primary purpose, then outlines the verification process, and finally details consequences. Every sentence adds value and the length is justified given the high-stakes nature of the tool. It is front-loaded and well-organized.

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

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

For an action tool with no output schema, the description covers the key outcomes (payment on match, dispute on mismatch) and the severe consequence of default. It does not explicitly describe the response format or further escrow state after dispute, but it provides enough context for the agent to understand the tool's behavior and risks. A small gap remains regarding post-dispute handling, but overall it is reasonably complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context by explaining the verification process around computed_hash, but the schema already includes the critical 'Do not copy the seller's value' instruction. The description does not add significant new parameter-level meaning beyond what the schema provides.

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

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

The description clearly states the tool's function: 'Confirms a delivery and releases payment, as the buyer.' It uses a specific verb ('confirms') and resource ('delivery'), and explicitly frames it from the buyer's perspective, distinguishing it from seller-side tools like escrow_submit_delivery and other contract tools.

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

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

The description implies when to use this tool by specifying the buyer role and the requirement to have a buyer_token. It says 'Fetch the artifact, compute its hash yourself' indicating a prerequisite. However, it does not explicitly name alternatives or exclusions, though the role-based framing provides clear context.

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

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 live on-chain solvency check, including wallet amount and payment authorization validity, and notes the token requirement. It does not explicitly state whether the call is read-only, but 'reports' implies it. This is strong but not fully exhaustive.

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

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

The description is three sentences, each serving a distinct purpose: stating the function, providing usage timing and rationale, and noting the token prerequisite. No unnecessary words or repetition.

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

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

Given the absence of an output schema, the description adequately conveys what the tool reports (status and solvency). It covers the key scenario and prerequisites. However, it does not detail the exact output format or error conditions, which would be helpful for a monitoring tool.

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

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

The schema already describes both parameters (escrow_id and token) with 100% coverage. The description echoes the token requirement but adds no new semantic detail beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool reports an escrow's status and performs a live solvency check on the buyer. It is specific about what it does, but does not explicitly distinguish itself from sibling tools like escrow_get_quote or contract_get, so it misses the top score.

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

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

The description advises calling it 'while you work' to catch buyer defunding or authorization cancellation, providing clear contextual guidance. However, it does not mention alternatives or when not to use it, so it falls short of explicit exclusion or alternative naming.

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

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

With no annotations, the description carries the full transparency burden. It discloses the exact fee formula (1% min $0.10 max $25.00), that the fee is paid by the buyer when escrow opens, and that it's non-refundable if the deal falls through. It also clarifies the quote is non-binding ('without committing to anything'), though it does not spell out the response shape.

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

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

The description is three focused sentences, each carrying unique information: purpose and non-commitment, fee details, and practical pairing with trust_check_wallet. No filler or repetition of schema information.

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

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

For a simple one-parameter quote tool with no output schema, the description is complete: it gives the purpose, exact cost, payment timing, refund policy, account requirements, and a clear use case with a sibling tool. Nothing critical is missing for an agent to select and invoke it correctly.

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

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

The schema already documents amount_usd clearly, so baseline is 3. The description adds meaningful context by explaining how the fee depends on the amount (1% with min/max), which directly ties the single parameter to the tool's output. This raises it above the baseline.

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

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

The description clearly states the tool's purpose: it prices escrow protection for a payment to an untrusted counterparty without committing to anything. It distinguishes itself from related escrow tools like escrow_open by emphasizing the no-commitment quote nature and by pairing with trust_check_wallet.

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

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

The description explicitly says to pair this with trust_check_wallet: if that returns a low score, this tool tells you what protection costs. It also notes 'Needs no account,' which provides practical usage context for when this can be used.

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

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

With no annotations, the description fully discloses key behavioral traits: 'WITHOUT us ever holding your money', 'we hold the signature and do not broadcast it', 'If they never deliver, we discard the signature and your funds never moved', and the token return behavior. This is exceptional transparency for a financial tool.

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

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

The description is long but every sentence earns its place, covering purpose, mechanism, fee, token handling, and account requirement in a logical flow. It could be slightly more structured, but the density is appropriate for the tool's complexity.

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

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

The description covers the entire lifecycle relevant to opening an escrow: trust setup, signature holding, fee handling, token distribution ('buyer_token' and 'seller_token'), and confirms no account is needed. It adequately explains return values despite no output schema, making it complete for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds actionable guidance beyond the schema: term_hours is described as 'Shorter is safer', fee_authorization is 'settled immediately', and payment_authorization's holding semantics are reinforced. This enhances parameter understanding.

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

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

The description clearly states the tool's function: 'Protects a payment to a counterparty you do not trust yet' and explains the unique mechanism of holding a signature without broadcasting. It distinguishes itself from sibling escrow tools by describing the specific flow (broadcast on delivery, discard if not delivered) and references escrow_get_quote for the fee, making its purpose unambiguous.

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

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

The description provides clear context for when to use the tool: when you need to pay an untrusted counterparty, and it notes 'Needs no account' as a prerequisite. It doesn't explicitly mention when not to use it or list alternative tools for non-escrow scenarios, but the context is sufficiently clear for selection.

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

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

With no annotations, the description carries the burden. It explains the hash verification mechanism, that payment is released on a match, and that a seller_token is required. It does not cover failure modes or what happens on mismatch, but the core behavioral workflow is transparent.

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

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

Three sentences, front-loaded with the main action, followed by the mechanism and a critical prerequisite. Every sentence earns its place with no fluff.

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

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

The description gives enough to use the tool correctly: role, inputs, and expected outcome. It doesn't describe return values or edge cases, but with no output schema and a well-defined process, this is reasonably complete.

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

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 adds valuable context: delivery_hash must be independently recomputable by the buyer, and seller_token is the one given by the buyer. This goes beyond the schema's property descriptions.

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

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

The description opens with a specific verb and resource: 'Hands off finished work against an escrow, as the seller.' It clearly identifies the seller role and distinguishes this from buyer-side confirm tools like escrow_confirm_delivery and from contract_submit_delivery for contract escrows.

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

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

The description clearly sets the context: use when you are the seller finishing work on an escrow. It also states a prerequisite (seller_token) and warns not to start work without it. It does not explicitly name alternatives, but the role framing and sibling tool names imply when not to use it.

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

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

No annotations are provided, so the description must convey behavioral traits. The verb 'Fetches' clearly indicates a read-only operation, and listing the profile contents adds context about what the tool returns. However, it does not disclose error behaviors (e.g., missing agentID), authentication requirements, or potential side effects, which a more transparent description would include.

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

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

The description is a single, front-loaded sentence that efficiently conveys purpose and the key contents. Every word contributes value, with no redundancy or filler. It is appropriately concise for such a simple tool.

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

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

For a simple one-parameter getter, the description is fairly complete: it names the action, the resource, and the main data points returned. It does not describe the return format or error conditions, and 'resume metadata' is somewhat vague, but given the tool's simplicity and lack of output schema, this is a minor gap rather than a critical omission.

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

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

The schema defines agentID as a required string with no description, and the schema description coverage is 0%. The description implicitly ties agentID to 'a single agent' but does not explicitly state that agentID is the identifier or explain its format or origin. This adds some meaning beyond the schema but falls short of fully compensating for the missing schema descriptions.

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

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

The description clearly states a specific action ('Fetches a single agent's HR profile') and the resource ('agent's HR profile'), explicitly differentiating itself from sibling tools like hiring_search_agents or hiring_list_inquiries by emphasizing 'single'. It also details the content returned (job description, resume metadata, reputation score), leaving no ambiguity about the tool's purpose.

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

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

The phrase 'single agent's' implies this tool should be used when a specific agent's profile is needed, contrasting with list/search tools. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions. It lacks direct references to sibling tools or conditions for use, making the guidance somewhat implicit rather than stated.

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

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

With no annotations, the description carries the burden. It conveys the content scope (workflow stages) and the verb 'Explains' implies a non-mutating, informational response. However, it does not explicitly state that it returns a textual guide or that it has no side effects, leaving some ambiguity about the exact output format.

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

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

The description is two sentences, front-loaded with the core purpose and then a concise usage instruction. Every sentence adds value; there is no redundancy or filler.

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

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

For a zero-parameter informational tool with no output schema, the description covers the essential aspects: what workflow is explained, the key topics, and when to call it. It could be more explicit about the response type (e.g., 'returns a text summary'), but the given information is largely sufficient for an agent to select and use the tool correctly.

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

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

The tool has zero parameters, so the schema is trivially covered (100%). The baseline for no parameters is 4; the description does not need to add parameter details. It correctly omits any parameter discussion because none exist.

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

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

The description explicitly states the tool's purpose: 'Explains the HR workforce marketplace workflow' with specific components (profiles, search, inquiries, negotiation-to-contract). This clearly distinguishes it from action-oriented sibling tools like hiring_search_agents or contract_get, positioning it as the onboarding overview.

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

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

The description gives direct usage guidance: 'Call this first if you're new to the hr_* tools.' This tells the agent exactly when to invoke it, implying it is a prerequisite before using other hiring tools. No exclusions are needed for a purely informational tool.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Lists' and adds an important scope boundary ('received from other agents'), but it does not disclose return format, ordering, or any limitations. This is acceptable for a simple list tool but leaves some gaps.

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

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

The description is a single sentence that front-loads the verb and resource, with no unnecessary words. It is concise and immediately comprehensible.

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

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

Given the tool's simplicity (no parameters, no output schema), the description sufficiently defines the output conceptually and the ownership boundary. It does not enumerate return fields, but this is a minor gap for a straightforward list operation.

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

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

The tool has zero parameters and the schema description coverage is 100% by default. The description does not need to explain parameters, but it adds meaning by defining what is listed and for whom. Baseline 4 is appropriate.

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

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

The description employs a specific verb 'Lists' with a precise resource 'hiring inquiries (job applications)' and scopes it to 'the calling agent has received from other agents.' This clearly differentiates it from sibling tools like hiring_send_inquiry, which handles sending rather than listing.

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

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

The description provides clear context: use this tool to see inquiries received from other agents. It does not explicitly state exclusions or alternative tools, but the intended use is unambiguous given the straightforward phrasing and sibling tool names.

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

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 an excellent job. It discloses that the tool is free (no account needed), explains the bidding cost only charged when shown in the promoted slot at second-highest bid, and describes the verification status flow from 'self-declared' to 'verified' after payment, including ranking benefits.

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

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

The description is information-dense and well-structured, starting with the key benefit ('FREE'), then purpose, parameters, and verification status. It is slightly long but every sentence provides needed detail, with no redundancy or fluff.

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

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

The description covers the core mechanics: listing, optional parameters, promotion bidding, and verification. It is sufficiently detailed for an agent to decide whether to use the tool, though the reference to 'settle a payment here' is vague without context from related tools like escrow or budget, making it slightly incomplete.

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

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

The schema already describes all 5 parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema, particularly for max_bid_usd, explaining when it is charged and how the price is determined, and clarifies the job_description requirement. This enhances understanding, warranting a 4.

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

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

The description clearly states the tool lists the agent in a workforce marketplace so others can find and hire them. It uses a specific verb (publishes) and resource (marketplace), and it is distinct from sibling tools like hiring_search_agents by focusing on the agent's own services rather than searching for others.

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

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

It explains when to use this tool (to become hireable) and provides optional parameters like job_description and max_bid_usd. While it doesn't explicitly contrast with alternatives, the purpose is unambiguous, and the description includes usage context such as pricing and promotion mechanics.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently covers result provenance, payment-history verification, promoted-placement labeling, cross-platform rail support, and the auto-register side effect (including that no account is needed). This is rich, honest behavioral context beyond what the schema alone reveals.

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

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

The description is longer than average but every sentence adds value: search behavior, result details, promoted placements, cross-platform rails, and self-registration. It is front-loaded with the core purpose and remains dense without being padded. Slightly more structuring (bullets) would improve scanability, but it is justified in length.

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

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 a nested self-registration object, the description covers what an agent needs to invoke it successfully: what results contain, how promotion works, how rail filtering behaves, and how auto-registration works. It does not describe pagination or error cases, but the core decision-making context is complete enough.

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

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

Schema description coverage is 100% and each parameter already has detailed documentation, especially rail and auto_register_capabilities. The description adds some narrative context for min_score and query, but it does not materially go beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: "Finds agents that can do a piece of work." It then details the search scope (skills, job description, agent id, resume) and a reputation filter, making it clearly distinct from sibling tools like hiring_get_agent_profile.

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

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

The description gives clear context for when to use this tool: searching for agents across both platforms continuedly, filtering by payment rails, and optionally self-registering during the same call. It does not explicitly name alternatives or say when not to use it, but the usage context is strong enough for an agent to select it correctly.

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

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 requirement ($0.01) and that it's lightweight with no commitment, which is valuable behavioral context. It doesn't describe what happens after sending (whether the other agent receives a notification, response behavior, etc.), so there's minor depth missing, but the key cost and binding-behavior traits are disclosed.

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

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

The description is two sentences and mostly efficient, front-loading the payment context then the core action. The first clause ('$0.01, no account needed: the payment identifies you and keeps inboxes worth reading') is slightly dense/ornate but informative. No wasted words beyond that framing.

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

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

For a simple 2-parameter tool with 100% schema coverage and no output schema, the description covers the essential aspects: cost, purpose, optionality, and the distinction from deal_open. It doesn't explain response format but with no output schema and a lightweight inquiry action, this is acceptable. Minor gap in describing post-send behavior.

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

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

Schema coverage is 100% (both message and to_agent_id are described in the schema). The description adds that message is 'optional' and 'short,' slightly enhancing the schema. Since the schema already documents both parameters fully, the baseline of 3 applies; the description adds marginal value but doesn't go beyond what's in the schema.

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

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

The description states a specific verb+resource: 'Sends a lightweight hiring inquiry to another agent' with clear scope (optionally with a short message). It distinguishes from deal_open by explicitly contrasting 'for real terms use deal_open instead'. This is a clear, non-tautological purpose statement.

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

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

The description provides explicit when-to-use guidance: it frames the inquiry as 'lightweight,' no terms/no commitment, and explicitly names deal_open as the alternative for real terms. It also explains the cost context ($0.01, payment identifies you) which helps decide when this tool is appropriate versus a heavier workflow.

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

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

With no annotations, the description carries the full burden, and it does so well: it discloses irreversibility ('nobody can change, us included'), the returned agreement_id, and the private rule-break failure mode. This is transparent and actionable.

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

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

Two sentences, no filler, with the primary action first and consequences and failure modes second. Every sentence earns its place.

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

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

The description covers the main flow, side effects, and rule-based blocking. It does not explicitly say what happens when the user approves but the counterparty has not yet approved, which could matter for an agent interpreting the response. Overall, it is nearly complete.

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

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

Schema coverage is 100%, and the input schema already explains offer_seq's role and the default 'on the table' behavior. The description adds little beyond reinforcing that framing, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Approve the offer') and explains the unique outcome: both sides approving locks a signed agreement. This clearly distinguishes it from siblings like negotiation_close or negotiation_send.

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

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

It gives clear context for when to use the tool: to approve the current offer and potentially finalize an agreement. It also covers the rule-check scenario, but it does not explicitly name alternatives or exclusions, 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.

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

With no annotations, the description carries the burden. It discloses a key behavior: the negotiation stays on record and cannot be added to. However, it does not mention reversibility, permissions, or what happens to existing data or pending actions. It gives 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.

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

Two concise sentences, front-loaded with the purpose, delivering the core action and a key consequence without waste.

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

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

For a simple two-parameter tool with no output schema, the description covers the core action but omits details like what room_id refers to, any prerequisites, or the nature of the result. It is adequate but not fully complete.

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

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

Schema coverage is 50% (room_id lacks description). The description does not explain any parameters, so the required room_id is left undocumented beyond the schema. The description adds no meaning to the parameters, failing to compensate for the schema gap.

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

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

The description clearly states 'End a negotiation without a deal' which specifies the action (end), the resource (negotiation), and the condition (without a deal). It also distinguishes from siblings like negotiation_approve which likely ends with a deal. The additional note about staying on record and no more additions clarifies the scope.

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

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

The description implies when to use (when no deal is reached) but does not explicitly name alternatives or provide when-not-to-use guidance. It does not mention the existence of other negotiation tools, leaving the agent to infer from the 'without a deal' phrase.

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

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

With no annotations provided, the description must disclose behavioral characteristics. It mentions 'whether the record is still intact', which hints at integrity but does not clarify what happens if the record is not intact (e.g., error vs. partial data). It also doesn't state whether this is read-only (likely) or requires any authentication or permissions, though the description 'Read' implies no mutation.

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

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

The description is a single, fairly dense sentence that front-loads the core listing of returned content. However, it could be more concise by breaking into two sentences (e.g., first what it returns, then the integrity note). It is not excessively long, but the final phrase about integrity feels tacked on.

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

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

For a single-parameter read tool, the description is relatively complete on the return content, but given there is no output schema and no annotations, it should provide more context on the response format, any error conditions, or the nature of 'private notes'. The missing parameter semantics further reduce completeness.

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

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

Schema description coverage is 0%, meaning the parameter 'room_id' is entirely undocumented in both schema and description. The description fails to explain what 'room_id' is, its format, or its role in identifying the negotiation. Since there is only one parameter, the description should have at least mentioned that it identifies the negotiation.

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

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

The description explicitly states the verb 'Read' and the resource 'negotiation', and enumerates the specific content returned: entries in order, the offer, approval status, next steps, and private notes. This clearly distinguishes it from sibling tools like negotiation_list (listing negotiations) and negotiation_approve (acting on them).

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

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

The description clearly conveys that this is the tool to use when you want to read a negotiation's full state, including private notes. It does not explicitly name alternative tools or exclusions, but given the sibling set, the read vs. list vs. act distinction is implied strongly enough that an agent would infer when to use it.

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

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

With no annotations provided, the description carries the full burden, and it does meaningfully: it discloses that new users get registered, that the call produces a key, and that the operation is free. These side effects go beyond anything the schema states. It does not cover failure behavior (e.g., invalid join code), but the main behavioral consequences are transparent.

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

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

The purpose is front-loaded in the first sentence, and each clause earns its place. The standalone 'Free.' sentence is terse but conveys a distinct cost signal. Nothing is wasted, though it could be slightly tighter as prose.

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

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

Against moderate complexity (3 params, one nested object) with no annotations and no output schema, the description covers the action, trigger condition, side effects (registration, key issuance), and cost. The 'gives you a key' effectively hints at the return outcome. Missing are failure semantics and what the key is used for, but these are minor for a join tool.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description and schema jointly reinforce that name and business are only used when the user is new, but the description adds no parameter-specific meaning beyond what the schema already conveys.

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

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

The description names a specific verb (join), resource (negotiation), and mechanism (join code sent by the inviting agent), which clearly separates it from siblings like negotiation_open (create) and negotiation_list (view). The conditional registration note further distinguishes it from agent_register.

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

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

The description gives clear context for when to use the tool: when another agent has invited you and sent a join code. It also implicitly addresses the alternative of separate registration by clarifying that new users are registered 'in the same call,' so no separate agent_register step is needed. It stops short of explicitly naming alternatives or exclusions.

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

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

With no annotations provided, the description carries the full burden. 'List' clearly indicates a read-only operation, and 'your' conveys user scope, but the description does not disclose authentication requirements, pagination behavior, or what exactly 'what happens next' includes.

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

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

A single sentence that front-loads the action and resource, then adds ordering and the distinguishing next-step detail. There is no filler or redundant restatement of the tool name.

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

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

For a zero-parameter list tool, the description is largely complete: it specifies scope, ordering, and included content. The main gap is the vague 'what happens next' and lack of output-schema detail, but the operation is simple enough that an agent can still select and invoke it correctly.

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

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

The tool has zero parameters and an empty schema, so there are no parameter semantics to explain. The description reinforces that the tool takes no arguments and simply returns the caller's negotiations and agreements; baseline 4 is appropriate.

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

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

The description uses a specific verb ('List') and names the exact resources ('negotiations and locked agreements'), adding ordering ('newest first') and a distinguishing payload detail ('what happens next in each'). This clearly differentiates it from single-item sibling tools like negotiation_get and agreement_get.

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

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

The context is clear: use this to get an overview of the user's negotiations and locked agreements. However, it does not explicitly state when not to use it or mention alternatives like negotiation_get/agreement_get for single-entity details, so the guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries full behavioral disclosure. It reveals that offers are written down and immutable ('nobody can edit it'), that rules set by a human operator are checked privately and never revealed to the other side, and that the service is 'Free'. These are significant behavioral traits that go beyond simple function statements.

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

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

The description is a single coherent paragraph that front-loads the core action and then flows into usage details. Each sentence adds information: what it does, how to specify parties, the join-code alternative, optional first offer, immutability, rule checking, and cost. It's not overly verbose and is well-structured.

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

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

For a tool with a nested offer object and five parameters, the description covers the essential flow: initiating negotiation, choosing counterpart, offering, and rule enforcement. It doesn't describe the response format (e.g., returned negotiation ID), but without an output schema that's not required. It adequately prepares an agent to call the tool correctly.

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

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

Schema coverage is 100%, so all parameters are already documented in the schema. The description adds marginal context: it explains the role and subject in plain terms, and notably clarifies the behavior of with_agent_id (leave it out to get a join code). However, most parameter semantics are already covered by the schema's detailed descriptions, so the description adds limited extra value.

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

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

The description clearly states the tool's purpose: 'Start a negotiation with another business's AI agent.' It specifies the verb 'start' and the resource 'negotiation', and differentiates from sibling tools like negotiation_send (for subsequent offers) and negotiation_join (for joining an existing negotiation). The mention of buyer/seller and deal subject makes the action unmistakable.

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

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

The description provides clear instructions on how to use the tool: specify role and subject, optionally provide an agent_id for Focxle members, or omit it to receive a join code. It also mentions the option to include a first offer. While it doesn't explicitly state when NOT to use this tool (e.g., for sending follow-up offers), the flow is clear and the distinction from siblings is implied.

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

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 meaningful behavior: a new offer replaces the current one, totals are computed, sent content persists ('kept for good'), the other side reads it, and messages are screened for wording that instructs the other agent. It could add auth or error behavior, but the core side effects are transparent.

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

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

Five short sentences, front-loaded with the tool's purpose. Each behavioral detail earns its place, though 'We work out the total' is slightly redundant with the schema's note about Focxle calculating the total. Overall tight and readable.

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

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

Given the lack of annotations and output schema, the description covers the important behavioral guarantees: offer replacement, persistence, visibility to the other side, and message screening. It doesn't explicitly describe return values, confirmation, or error cases, but for a send action with a well-documented schema this is a reasonably complete picture.

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

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

Schema description coverage is 100%, so the schema already documents room_id, message, and every field of the nested offer object. The description adds context about offer replacement and total calculation but does not materially clarify individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Send an offer, a counter-offer or a message in a negotiation.' It also clarifies the immediate effect ('A new offer replaces the one on the table'), which distinguishes it clearly from the sibling negotiation_* tools like get, close, approve, and list. Even without naming a sibling, an agent can tell what this tool is for.

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

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

The intended use is implied by the first sentence: use this tool when you need to send something in a negotiation. However, there is no explicit 'when not to use' or routing to alternatives such as negotiation_get for reading or negotiation_approve for accepting. This is adequate but leaves guidance to inference.

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

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 the tool returns a link and a short message, that the page asks for no password and no bank details (reassuring safety), and that the owner writes rules in their own words. It doesn't mention rate limits or whether the link expires, but the key behavioral traits are covered.

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

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

The description is concise and front-loaded: it states the primary action first, then explains the flow and the return value. Every sentence adds value, and there's no fluff. It's appropriately sized for a tool with no parameters.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description covers the essential context: what the tool does, what the owner does, what the agent receives, and a safety note. It could mention whether the link expires or if there's a follow-up step, but for a simple link-generation tool, this is nearly complete.

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

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

The input schema has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds context about what the tool does with no inputs, which is sufficient. No parameter documentation is needed.

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

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

The description clearly states the tool's purpose: generating a link to send to the owner/principal so they can set spending rules. It uses a specific verb ('Get a link'), identifies the resource (the person or business that runs you), and explains the outcome (Focxle checks deals and payments against those rules). This distinguishes it from sibling tools like agreement_get or negotiation_open, which serve different purposes.

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

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

The description implies when to use this tool: when you need to invite the owner to define purchasing rules. It doesn't explicitly name alternatives or state when not to use it, but the context is clear enough given the sibling list. A slight gap is the lack of explicit exclusion (e.g., 'use this instead of X when...'), but the purpose is specific enough that an agent can infer the right context.

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

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

With no annotations, the description carries full responsibility, and it does this well. It discloses side effects (every heads-up is kept on record), conditional outputs (signed approval only when checking is on and answer is yes), registration behavior, and financial safety (Focxle never holds or moves money).

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

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

The description is front-loaded with the core action and then explains behavior, outputs, side effects, and reassurance. It is longer than typical but each sentence adds relevant context for a tool with no annotations. Minor extras like 'Free.' and final reassurance slightly reduce conciseness but still serve behavioral transparency.

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

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

There is no output schema, so the description must explain what the caller gets back. It does: a yes/no answer with plain-word reason and a signed approval when applicable. It also covers side effects, registration, no-rules behavior, and the fact that money is not handled. For a tool with this complexityessing and branch logic, nothing essential is missing.

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

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

Schema description coverage is 83%, so the schema already documents most parameters well. The description adds high-level meaning by mapping to 'who you are paying, how much, and what it is for' and mentions agreement checks, but it does not substantially explain parameter formats, defaults, or idempotency beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Tell Focxle before you pay anyone.' It clearly states what is sent, what Focxle does with it, and what the caller gets back. 'Before you pay' and 'heads-up' differentiate it from record-keeping or verification siblings like payment_record and trust_check_agent.

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

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

It explicitly says to use this when you are about to pay someone and before the payment happens. It also explains behavior in different circumstances: rules set vs no rules set, registered vs not registered. It does not name alternative tools directly or give explicit when-not-to-use guidance, so it falls 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.

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

With no annotations, the description carries the full burden. It explicitly uses the verb 'Read', implying read-only behavior, and details the returned content (payments, confirmations, score, tips) and the public link. It adds meaningful context beyond the empty schema, though it does not mention side effects or authentication requirements, which are likely implied for a self-service read tool.

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

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

The description is two concise sentences, front-loaded with the core purpose ('Read your own record'). Every clause adds value: contents, confirmations, score, and the public link. There is no wasted text.

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

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

For a no-parameter, no-output-schema tool, the description covers the essential behavior: what data is returned (payments, confirmations, score, tips) and the public link. It does not specify the link format or error conditions, but given the tool's simplicity, it is sufficiently complete for an agent to understand the expected return.

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

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

There are zero parameters, so the schema is trivially covered (100%). The baseline for 0 parameters is 4, and the description adds no parameter-related meaning because none exist. No compensation is needed.

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

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

The description opens with 'Read your own record', a specific verb and resource. It then enumerates the contents: payments, confirmations, score, and improvement tips, plus a public link. This clearly distinguishes it from sibling tools like payment_record (recording) and trust_check_agent (checking others).

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

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

The description clearly states 'Read your own record', indicating it's for viewing one's own payment history. It also provides a concrete use case: sending the public link to businesses. However, it does not explicitly name alternatives or when not to use this tool, 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.

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

With no annotations, the description fully carries the disclosure burden and does so well: it states the payment is stored on the user's record, affects their score, generates a confirmation link to the business, and grants additional score weight only after confirmation. It also explicitly discloses that sensitive card numbers, account numbers, and keys are stripped before saving.

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

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

Four sentences, all information-bearing and front-loaded. The core action is the first clause, and every subsequent sentence adds a distinct behavioral fact (no connection needed, score impact, confirmation link, data privacy) without repeating schema content.

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

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

For a tool with 8 parameters, nested objects, no annotations, and no output schema, the description covers the what, why, and consequences. It does not explain the response/return value or the confirmation-link mechanics in detail, but those are not required for selecting and invoking the tool correctly.

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

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

Schema description coverage is 75%, so the schema already documents most parameters with meaningful descriptions. The tool description adds general context (record, score, confirmation link, data stripping) but does not add per-parameter meaning beyond the schema, so a baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Write down a payment you already made,' and immediately broadens scope with 'anywhere: a bank transfer, a card, any payment app, any supplier's portal.' It clearly distinguishes the tool as a manual record-keeping action rather than a connected or initiated payment, and the sibling list contains no other tool with this exact record-a-completed-payment function.

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

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

Usage context is explicit: this is for payments already made, and 'We do not need to be connected to it' tells the agent connection is not a prerequisite. It does not name a specific sibling alternative or an explicit 'do not use when...' condition, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It describes the tool as explanatory and enumerates the topics covered, implying a read-only, informational behavior. However, it doesn't explicitly state 'no side effects' or 'read-only', though the verb 'explains' makes this largely clear.

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

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

The description is two sentences, front-loaded with the core purpose, then lists covered topics and provides a usage directive. Every sentence adds value with no redundancy.

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

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

For a simple informational tool with no parameters and no output schema, the description is complete: it explains what the tool covers and when to call it. It also references related tool groups (wallet_* and data_*), providing sufficient context for an agent to use it appropriately.

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

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

The tool has 0 parameters, so the baseline is 4. The description doesn't need to add parameter details since none exist, and the schema already covers the empty parameter set.

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

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

The description clearly states the tool explains how the payment rail works, listing specific topics (paying from own wallet, managed wallets, spend mandates, reputation, receipts, intent enforcement). It distinguishes itself from sibling tools like hiring_how_it_works by focusing on payments and explicitly referencing wallet_* and data_* tools.

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

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

Provides explicit usage guidance: 'Call this first if you are new to the wallet_* and data_* tools.' This tells the agent when to invoke it and implies it should be used before those tools, offering clear contextual direction.

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

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

With no annotations, the description carries the full burden and does an excellent job. It discloses that this is a real charged transaction, settles through a mandate-checked payment path, requires a funded wallet, and describes the failure behavior (no summary, no charge). This goes far beyond the schema and provides vital behavioral context.

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

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

The description is four sentences, somewhat longer than strictly minimal, but every sentence adds value: explaining the paid nature, the return type, when to use, and failure conditions. It is front-loaded with the core purpose and remains readable.

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

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

Given that this is a paid transaction tool with no annotations and no output schema, the description is remarkably complete. It covers the payment side effects, prerequisites (funded wallet), failure behavior, and usage guidance, making it sufficient for an agent to select and invoke the tool correctly.

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

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 adds little parameter-level detail beyond what the schema already provides; it mentions 'any block of text' and 'concise extractive summary' but does not elaborate on max_sentences or other parameter semantics. The schema already documents both parameters adequately.

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

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

The description clearly states the tool purchases a real, paid text-summarization service and returns a concise extractive summary. It uses a specific verb ('purchases') and resource ('text-summarization service'), and distinguishes this from siblings by emphasizing it is a paid marketplace transaction rather than a free utility.

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

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

Explicitly directs use 'whenever the user asks you to summarize, condense, or buy/purchase a summary of some text using your Focxle tools.' It offers clear context, but does not mention when not to use it or provide alternatives, so it falls short of a full 5.

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

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 score's limitation ('stops at 450 and says so'), states that it is free and requires no account, and details what the returned record contains.

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

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

Every sentence earns its place: the primary purpose, the return fields, the score limitation, the access requirement, and the sibling alternative. It is front-loaded and free of filler.

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

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

The tool is simple, the schema covers both parameters, and the description fully covers return contents, limitations, access constraints, and the main alternative. No critical operational context is missing.

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

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

Schema description coverage is 100%, so the parameters are already documented in the schema. The description reinforces agent_id as the core lookup key but adds no new parameter-level semantics beyond what the schema provides.

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

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

States a specific verb and resource: 'Check an AI agent before you deal with it.' It enumerates the returned record fields and explicitly distinguishes the tool from trust_check_wallet, making its scope unmistakable.

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

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

The description says when to use this tool ('before you deal with it') and names the alternative for crypto wallets. It also notes there is no account requirement, giving practical entry guidance.

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

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

With no annotations, the description carries full behavioral burden. It discloses return structure (two separate blocks), the fact that public facts are never blended with witnessed behavior, the $0.02 cost, no-account callability, listing side-effect, and the free credit score mechanism via header. This goes far beyond typical disclosure and is highly transparent.

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

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

The description is ~200 words, which is lengthy but every sentence earns its place. It is front-loaded with the core purpose and then systematically covers outputs, pricing, no-account usage, listing, and free credit. The structure is logical and not repetitive, though it could be slightly tightened by moving the free credit score explanation to a separate note.

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

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

Given the tool's complexity (nested object, 2 params, no output schema), the description is remarkably complete. It explains return blocks, pricing, callability without account, listing, and the free credit score. Nothing an agent needs to invoke it correctly is missing; even the alternative wallet identifier is documented.

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

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

The schema already describes both parameters thoroughly (100% coverage), so baseline is 3. The description adds meaning beyond the schema: it clarifies that wallet can be a Focxle agent id, explains the auto_register_capabilities purpose and side-effect, and introduces the x-focxle-agent-wallet header behavior not in the schema. This added semantic context justifies a 4.

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

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

The description states a specific verb and resource: 'Checks whether a counterparty is safe to transact with, given nothing but its wallet address.' It distinguishes itself from siblings by explicitly noting it works for ANY address on Base, including non-Focxle users, which is a unique capability not implied by other tools. This clarity lets an agent select it correctly without inspecting the schema.

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

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

The description provides clear context: it's for checking a counterparty before transacting, and explicitly says it's usable on a counterparty you just met. It implies when to use it but doesn't name alternatives or explicitly state when not to use. The pricing and no-account call options also guide usage, but the lack of explicit exclusions keeps it slightly below a 5.

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

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

With no annotations, the description carries the full burden. It transparently explains the semantics of the threshold, the context of micro-payment settlement mode, and how it differs from the safety-net sweep. It also discloses whether the value is an agent override or platform default. No side effects or hidden behaviors are relevant, and nothing is misleading.

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

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

Two sentences, front-loaded with the main action ('Returns your threshold'), then concise explanatory details. Every word adds value; no redundancy or fluff. The structure is efficient and clear.

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

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

The tool is simple (0 params, no output schema, no annotations), and the description provides sufficient context: what is returned, what it means, and how it relates to the broader payment system. It could mention return format or error conditions, but for a getter of this simplicity, the description is adequately complete.

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

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

The tool has zero parameters, so the schema trivially covers all parameters (100%). The description adds no parameter details, but none are needed. Per the rubric, a baseline of 4 is appropriate for zero parameters.

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

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

The description clearly states the tool returns the calling agent's micro-payment settlement threshold, explains what that means (accrued debt amount for immediate settlement), and distinguishes it from sibling tools like wallet_set_autopay_threshold. It is specific about the resource and the verb 'Returns', with full differentiation.

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

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

Usage is implied rather than explicitly guided. The description conveys this is a read-only inspection tool for the autopay threshold, and the sibling setter exists, but it does not explicitly state 'use this when you need to check your threshold' or mention when not to use it. No alternatives are named.

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

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

With no annotations, the description carries the full burden. It discloses 'real-time' behavior and the inclusion of 'accrued micro-payment debt' as a returned element, but does not mention authentication requirements, potential errors, or explicitly confirm read-only status. The verb 'Returns' implies safety but could be more explicit.

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

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

The description is a single, front-loaded sentence that names three specific data points (balance, status, debt) with zero wasted words. It is highly concise and well-structured.

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

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

For a simple getter with no output schema, the description lists the returned elements but leaves the format of 'status' and 'accrued micro-payment debt' undefined. Given the absence of annotations, slightly more detail on the output structure would improve completeness, but the core purpose is clear.

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

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

The schema fully describes the single parameter agentID ('The agent whose wallet to query.'), so the description adds no additional parameter semantics. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description uses the verb 'Returns' with specific resources (wallet balance, status, accrued micro-payment debt) and scope ('for an agent'), clearly distinguishing it from sibling tools like wallet_list_transactions and wallet_get_autopay_threshold. This matches the high standard of specificity.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. Usage is implied by the purpose—querying a wallet's real-time balance—but no explicit comparison to siblings like trust_check_wallet or wallet_list_transactions is provided.

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

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 useful details by specifying the entry types (deductions and micro-payments) and implies read-only via 'Returns,' but it does not disclose ordering, time range, or potential side effects. The description gives a basic read operation with some behavioral context, but not comprehensive transparency.

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

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

The description is a single sentence that is front-loaded with the action and resource. It contains no wasteful words and delivers the core meaning effectively.

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

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 explain the structure of the returned ledger entries (e.g., fields like amount, timestamp, type). While the tool is simple and the description gives basic context, an agent would be left inferring the return format, making it adequate but not fully complete.

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

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

Schema coverage is 100% with both parameters (agentID, limit) already described in the input schema. The description does not add any extra parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the action ('Returns'), the resource ('recent ledger entries'), and the scope ('deductions and micro-payments', 'for an agent'). This specific wording distinguishes it from sibling tools like wallet_get_balance, which would focus on current balance rather than transaction history.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as wallet_get_balance or wallet_get_autopay_threshold. It implies usage for transaction history but does not mention exclusions or name alternative tools for different use cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what happens when the threshold is reached ('it settles immediately instead of waiting for the periodic safety-net sweep'), and clarifies the effect of amount <= 0 ('clear your override and fall back to the platform default'). This is meaningful behavioral context beyond a simple setter. The only minor gap is the lack of information about return values or confirmation, but for a one-parameter mutation, this is acceptable.

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

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

The description is two sentences, but every phrase earns its place. The first sentence packs essential context: the action, the condition, the behavior, and the rationale (avoiding transaction fees). The second sentence clearly and concisely explains the override clearing behavior. There is no redundancy or filler; it is highly efficient while remaining readable.

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

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

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is remarkably complete. It explains what the tool does, when to use it, how the threshold behaves, and how to clear it. It also provides the strategic context of fee avoidance, which is sufficient for an agent to select and invoke the tool appropriately in the broader payment system.

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

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

The input schema already covers the parameter ('Settlement threshold in the platform's currency unit. <= 0 clears your override'), giving baseline 3. The description adds extra meaning by explaining how the threshold triggers settlement ('once your accrued micro-payment debt reaches this amount') and the purpose of batching, which helps the agent understand the semantics of 'amount' beyond the schema's dry description. This pushes it above baseline to 4.

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

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

The description clearly states the tool's function: 'Sets your (the calling agent's) micro-payment settlement threshold.' It uses a specific verb ('Sets') and a distinct resource ('micro-payment settlement threshold'), making it easy to distinguish from sibling tools like wallet_get_autopay_threshold (which reads the threshold) and wallet_get_balance (which reads balance). The detailed explanation of why this threshold matters further anchors its purpose.

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

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

The description provides clear context on when to use the tool: 'this is how two agents transacting in tiny increments avoid paying real-payment transaction fees on every micro-payment, by batching many into one settlement.' It also explains the behavior for positive values and the clearing behavior for <= 0. However, it does not explicitly name alternative tools or state 'use this instead of X,' though the context strongly implies the use case.

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

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 only states the action and a precondition; it does not disclose permissions, side effects, return behavior, or any operational constraints. This is thin disclosure for a tool that creates feed posts.

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

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

The description is two concise sentences that are front-loaded with the core action. Every word earns its place and there is no fluff or repetition.

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

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

Given three required parameters, no annotations, and no output schema, the description leaves many operational questions unanswered (e.g., what happens on success, how the feed updates, any further prerequisites). It is too sparse to serve as the sole guide for correct invocation.

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

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

Schema description coverage is only 33% (only 'kind' is described). The description mentions 'question or answer' and references the contract's feed, which partially illuminates 'kind' and 'contract_id', but 'text' remains fully unexplained. With low coverage, the description should compensate more than it does.

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

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

The description clearly states the action: 'Posts a question or answer into the contract's workroom feed.' It names the resource (contract workroom feed) and the specific content type (question/answer), making the purpose evident. However, it doesn't explicitly distinguish this from sibling tool workroom_post_input, so it falls short of full differentiation.

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

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

The description gives clear contextual guidance: 'Either party, any time the contract is still active.' This establishes when the tool is applicable, but does not mention alternatives or exclusion conditions, so it's not a full 5.

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

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

No annotations are present, so the description carries full responsibility. It discloses useful behavioral traits: ordering ('oldest first'), comprehensive contents ('every entry... inputs, deliverables, questions, answers'), and access restriction ('only visible to its two parties'). This adds substantial context beyond the tool name.

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

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

The description is a single, well-structured sentence that front-loads the action ('Lists every entry'), then specifies types, ordering, and a visibility constraint. Every clause adds value and there is no redundancy.

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

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

For a simple read tool with one parameter and no output schema, the description covers the essential aspects: what is listed, the ordering, and the access restriction. It does not explicitly describe return format, but 'lists' implies a list output, and the tool's simplicity reduces the need for more detail.

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

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

The description references 'a contract' connecting contract_id to the intended resource, but it does not add details about ID format or required format beyond the schema's string type. Since there is only one required parameter and schema coverage is 0%, the description provides minimal compensatory meaning.

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

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

The description clearly states the tool lists every entry (inputs, deliverables, questions, answers) in a contract's workroom feed, oldest first. This is a specific action and resource, clearly distinguishing it from sibling write tools like workroom_post_input and workroom_ask_question.

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

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

The description implies usage when an agent needs to review the complete workroom thread for a given contract, but it does not explicitly mention alternatives or define when not to use it. The 'only visible to its two parties' hints at access scope but not alternative-tool guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does add useful context: role-based posting rights and assurance that contract terms remain unchanged. However, it does not describe the side effects (e.g., visibility to both parties, notifications), potential errors, or whether the action is reversible. This is adequate but not rich.

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

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

The description is two sentences, front-loaded with the primary action, and contains no redundant information. The first sentence conveys the core purpose and roles, while the second clarifies a critical boundary. Every word earns its place.

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

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 no annotations, so the description must cover essential context. It does: it explains what is posted, by whom, and explicitly negates contract modifications. However, it omits what happens after posting (e.g., feed visibility, notifications) and does not distinguish from sibling tools like workroom_ask_question. For a simple posting tool, this is nearly complete but leaves a few questions unanswered.

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

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

The schema has 50% description coverage for parameters. The description adds meaning for the 'kind' parameter by explaining the role-based values ('input' vs 'deliverable'). It implicitly ties 'text' and 'pointer' to the content, but does not explicitly define them. 'contract_id' is left self-explanatory. Overall, the description partially compensates for schema gaps but does not fully elaborate all parameters.

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

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

The description clearly states the tool's action: 'Drops a task input (hiring agent only) or a deliverable (provider only) into the contract's shared workroom feed.' It specifies the resource (workroom feed), the actor roles, and disambiguates from negotiation with 'Not a renegotiation.' This effectively distinguishes it from sibling tools like workroom_ask_question and contract_submit_delivery.

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

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

The description provides clear context on when to use the tool: it is for posting inputs or deliverables into the workroom feed, with explicit role restrictions ('hiring agent only' / 'provider only'). It also states a when-not ('Not a renegotiation'). However, it does not name alternative tools for formal delivery submission, such as contract_submit_delivery, leaving some ambiguity for edge cases.

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