Focxle: virtual cards and spend limits for AI agents

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

With no annotations, the description carries the full burden and it is unusually candid: one-call/no-signup behavior, no money custody, no storage of card/account numbers, and a portable identity that follows the agent because it self-reports. It also reveals the owner-approval follow-up, which materially affects what the caller should do after the call.

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 and every block adds some information, but the prose is promotional and wordy ('in ONE call with no signup, no email and no account', the long 'follows YOU' sentence). It could be tightened to two or three factual sentences without losing value.

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-required-parameter registration tool with no output schema, it tells an agent why to call it, what happens as a result, and the necessary follow-up (send the returned link to the owner). It leaves minor gaps around the exact response shape, but it is otherwise 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 baseline of 3 applies. The description adds no detail about name, purpose, or services beyond what the schema already documents.

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 opening verb 'Register' plus 'this agent for spending' identifies a specific action and target resource, and the rest clarifies it creates an agent identity and payment record. This clearly separates it from budget, card, and deal tools even without naming a 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?

It conveys a clear context—register once before spending so suppliers can read the agent's payment record—and it tells the caller to send the owner the resulting link. However, it never says when not to use it or names alternatives such as budget_request_increase or payments_how_it_works, so the use-vs-alternative guidance is only 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 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 at all, the description carries the full burden and does exceptionally well: it discloses card creation timing, hard amount cap, merchant lock, single-use behavior, issuer relationship, no retention of card numbers, registration side effect, and the budget-link fallback.

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 key purpose is front-loaded and the structure is logical (purpose → examples → behavior → trust → onboarding). It is longer than strictly necessary, with some redundancy like 'single-use' and 'cannot be spent twice', but every section adds relevant operational context.

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 tool with nested parameters, the description is complete about side effects, registration, budget handling, and trust boundaries. It does not describe the returned card payload, but the rest of the context is strong enough to make the tool callable.

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 already 75%, so the baseline is 3. The description adds meaningful context beyond the schema by tying 'payee' to the merchant lock and 'amount' to the hard cap, and by noting the reason is recorded but never used for the decision.

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 opening sentence names a specific verb ('Get'), a specific resource ('single-use virtual card'), and an immediate purpose ('buy something right now'). The following examples make the scope unmistakable and implicitly distinguish it from sibling approval/history/record 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 gives a clear 'when to use' with an extensive list of procurement scenarios (SaaS, domains, hosting, checkout). It does not explicitly say when not to use it or name an alternative, 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 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?

No annotations are provided, so the description carries the full burden. The verb 'Read' strongly implies a non-destructive operation, but the description does not explicitly state it is read-only or mention any side effects, auth requirements, or rate limits. It also doesn't clarify whether the 'next steps' are suggestions only. This is adequate but not 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 two sentences with no fluff. The first sentence front-loads the core purpose, and the second expands on the output details. Every phrase contributes to understanding the tool, 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 zero-parameter tool with no output schema, the description is remarkably complete. It covers what the tool does, what data it reveals, and even a use case (sharing the link). Nothing essential for an agent to decide to call it 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?

With zero parameters, the schema is empty and the baseline is 4. The description adds value by explaining the tool's output and purpose, compensating for the lack of any parameter information. It clearly describes what the user will see, which is more than a generic placeholder.

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 reads your own payment record and score, with a specific verb and resource. It goes beyond a simple definition by listing what it shows (logged entries, confirmations, ceiling, shareable link), distinguishing it from generic payment tools. Though it doesn't name a sibling, the scope ('your own') and purpose ('raise it') are 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 it: when you want to view your personal payment record and get actionable advice. It doesn't explicitly contrast with siblings like payment_record or payments_how_it_works, but the self-referential language ('your own', 'share with anyone deciding whether to deal with you') gives clear context. No exclusions are stated, but the use case is evident.

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, and it does well: it reveals that account numbers, card numbers, and keys are stripped before persistence, that each payment affects the user's score, and that a confirmation link is returned for the payee. It does not mention rate limits or authorization, but the data-handling and scoring side effects are clearly stated.

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 purpose and then uses each subsequent sentence to add a distinct piece of behavioral context: platform flexibility, score impact, confirmation workflow, and data scrubbing. It is slightly wordy in the 'any procurement system nobody has heard of' phrase, but no sentence is wasted.

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 8 parameters, nested objects, no output schema, and no annotations, yet the description supplies enough operational context to call it correctly: what counts as a valid submission, how platform is handled, the confirmation flow, and privacy safeguards. It only partially describes the return value (one-click link, ceiling rise), but the essential invocation context 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 75%, so the baseline is 3. The description reinforces the purposeful use of platform and external references ('any payment provider', 'you tell us') and warns against sensitive identifiers, but it does not add substantial parameter-level semantics beyond the schema's own 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: 'Submit a receipt or invoice for a payment you already made' and clarifies the cross-platform scope. This clearly distinguishes it from siblings like payment_history_mine (reading history), spend_request_approval (approving before spending), and card_get_virtual (issuing cards).

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 a clear trigger: use this for payments already made on any platform, regardless of integration. It does not explicitly name sibling alternatives or give 'when not to use' exclusions, so it stops short of a 5, but the context is unambiguous for an agent choosing among the listed siblings.

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. It discloses the tool returns only an eligibility decision (no payment side effect) and describes the watch-only mode behavior ('we always allow and tell you what would have been stopped'). This goes beyond a generic 'check' and signals it is non-destructive. It doesn't explicitly state auth requirements or that it never executes a payment, but the contrast with card_get_virtual and the 'safe to call' wording make this clear enough.

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 purpose and then adds usage guidance and edge-case behavior. It is slightly wordy (the first two sentences are similar), but every sentence contributes meaning: scope, output, when to use, alternative, and watch-only safety. No filler, though it could be tightened slightly.

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 output schema, the description compensates by stating the return shape ('allowed or not, and which limit or rule stopped it'). It covers the key use case, prerequisites (watch-only mode adds a safety net), and differentiates from the payment card tool. It does not describe how to construct the nested payee/amount objects or the exact response format, but the schema and the high-level output hint are sufficient for correct invocation in most agent workflows.

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 60%, with some parameters (payee.ref, intent, idempotency_key) already described. The description adds context that amount and payee are used to assess limits/rules, and that replies are idempotent for the same payment. However, it doesn't elaborate on structure for nested objects (e.g., how payee.name/category or amount.value/currency are interpreted) or on the format of the idempotency key beyond what the schema says. This is adequate but not a strong supplement to 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 opens with a clear verb and resource ('Check your budget before you buy') and then specifies exactly what it checks: 'daily spend limit and the procurement rules your owner set.' It states the output ('allowed or not, and which limit or rule stopped it') and differentiates from card_get_virtual, a key sibling. An agent can tell this is an eligibility check, not a payment tool.

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: 'Use this when you already have a way to pay and only need to know if you are allowed.' It names the alternative, card_get_virtual, for when a card is needed. It also covers a special case (watch-only mode) and explicitly says it's safe to call before checking is enabled, leaving no ambiguity about prerequisites.

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 flow (returns a link and words to send), the owner's process (writing rules in plain English), and security reassurances (no password or bank details). However, it does not mention potential failures (e.g., approval being denied) or side effects beyond the request creation, so it is thorough but not 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 a single paragraph that is front-loaded with the core purpose and then explains the process. It is efficient, with no redundancy, and every sentence contributes to understanding the tool's functionality and safety. It is slightly longer than necessary but remains readable 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?

The description explains the return value (a link and words), the owner's interaction, and the ongoing enforcement of rules. It covers the essential aspects for an agent to invoke the tool correctly. However, it does not address edge cases like what happens if the owner rejects the request or how to interpret the response, which would be useful but not critical given the tool's simplicity.

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 does not need to explain parameter semantics. The baseline for 0 params is 4, and the description adds context about what the tool achieves without needing parameter details. It appropriately focuses on behavior rather than 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 states a specific verb ('Ask your owner') and resource ('bigger budget' or 'permission to buy something they have not allowed yet'). It clearly distinguishes itself from sibling tools like budget_request_increase by covering both budget increases and approval for unallowed purchases, and it describes the expected outcome (link and words to send). The purpose is unambiguous and actionable.

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 indicates when to use the tool (when you need budget or permission for an unallowed purchase), but it does not mention any alternatives or explicitly state when not to use it. While the context is clear, it lacks exclusions or comparisons to sibling tools like budget_request_increase, leaving some ambiguity about edge 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, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains the return payload (payment record details and a 0–1000 score), and crucially discloses a behavioral limitation: records not confirmed by others are capped at 450 and the tool explicitly states this to avoid false confidence. It also mentions being free and requiring no account. While it does not explicitly state it is read-only, that is implied by the nature of a check. Missing explicit mention of data freshness or potential errors, but the disclosed cap and scoring logic add significant 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 moderately long but every sentence carries value: purpose, return contents, the scoring limitation, the free/no-account note, and the sibling alternative. It is front-loaded with the core purpose and maintains focus. While not the shortest possible, it is appropriately structured 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?

Given that this is a read-oriented check with no output schema, the description covers everything an agent needs to call it correctly: the purpose, the data returned, the scoring behavior, the cap on unconfirmed data, the cost/friction (free, no account), and the alternative for a different input type. No critical operational detail 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?

The schema has 100% description coverage for both parameters (agent_id and limit), so the description does not need to elaborate. The description adds no additional meaning about the parameters themselves—it does not mention how limit affects results or any format specifics. Per the rubric, with high schema coverage the baseline is 3, and the description does not exceed it.

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 identifies the tool's purpose with a specific verb ('Check whether'), a precise resource ('an AI agent'), and the decision contexts ('before you sell to it, extend terms to it, or take work from it'). It explicitly distinguishes itself from the sibling trust_check_wallet by stating the alternative for crypto wallets. This fully disambiguates it from nearby 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 states explicit usage contexts (before selling, extending terms, or taking work) and provides an alternative ('For a crypto wallet rather than a registered agent, use trust_check_wallet instead'). It also includes operational guidance: 'Free, no account.' This leaves no ambiguity about when to invoke this tool versus its sibling.

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.