paycrow

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

With no annotations provided, the description carries the transparency burden and does well: it discloses that funds are locked on-chain, the release/dispute flow, and that an arbiter reviews disputes. It does not mention gas costs, reversibility, or required authentication, but the core lifecycle behavior is well described.

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 the second sentence adds relevant behavioral detail about dispute resolution. The marketing phrase 'the only escrow service with real dispute resolution on Base' is arguably fluff but also communicates a unique value proposition; overall, 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?

Given no output schema, the description could explain what the tool returns (e.g., escrow ID), but it doesn't. However, the tool's purpose and lifecycle are thoroughly described, and sibling tools cover status/dispute/release, so the description is largely sufficient for an agent to use it correctly.

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

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

The schema already provides full parameter descriptions with examples, bounds, and defaults (100% coverage). The description adds no additional parameter-level meaning—for instance, it doesn't explain how timelock_minutes interacts with the dispute flow beyond 'auto-refunds'. Thus the description does not exceed the schema 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 creates a USDC escrow with dispute resolution, using the specific verb 'Create' plus a specific resource. It distinguishes itself from sibling tools (escrow_dispute, escrow_release) by highlighting the built-in dispute resolution lifecycle, making the purpose unmistakable.

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

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

The description provides clear context for when to use the tool—when you want to lock funds in escrow with dispute resolution—and implies the flow (funds locked until release or dispute). However, it does not explicitly state exclusions or name alternatives like 'use safe_pay for simple payments', so it misses the full 'when-not-to-use' guidance.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: 'Locks escrowed funds' and 'triggers arbiter review,' and mentions on-chain dispute resolution. However, it does not address reversibility, fees, or the full arbitration process, leaving some behavioral aspects unspecified.

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 contains four sentences, with the third sentence ('Unlike other escrow services...') being marketing fluff that does not aid tool invocation. The first two sentences and the last usage sentence are useful, but the unnecessary promotional content lowers the conciseness score.

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 no annotations and no output schema, the description covers purpose, behavior, and usage adequately. It does not mention return values or post-dispute procedures, but these are not essential for basic invocation, making the description sufficiently 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 schema already documents both parameters. The description adds minimal value beyond the schema; it provides context for the 'reason' parameter by describing the typical problem scenarios, but no additional syntax or format details. This matches the baseline for high schema coverage.

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 with a clear verb and resource: 'Flag a problem with delivery' and 'Locks escrowed funds and triggers arbiter review.' This distinguishes it from sibling tools like escrow_release or escrow_status, and the intended use case is unmistakable.

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

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

The description provides explicit usage guidance: 'Use when service was not delivered or quality was unacceptable.' It clearly implies this is for dispute scenarios, but does not explicitly name alternative tools or state when not to use it, so it stops short of a perfect score.

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 the core behavior — releasing escrowed USDC to the seller — which is essential. With no annotations, it carries the full transparency burden, but it does not mention that the release is irreversible or that it finalizes/closes the escrow. This is a notable gap for a financial mutation 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 exactly two sentences. The first sentence delivers the purpose, and the second provides a usage condition. There is no wasted or redundant content, and it is well 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 tool with one parameter and no output schema, the description adequately covers the core purpose and usage guidance. It could be improved by noting that the release is final or that it closes the escrow, but the current description is 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?

The input schema provides 100% coverage with a clear description for escrow_id ('The escrow ID to release'). The tool description adds no additional parameter semantics 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 clearly uses specific verbs 'confirm delivery' and 'release' with a direct resource ('escrowed USDC to the seller'). It distinguishes this tool from siblings like escrow_create, escrow_dispute, and escrow_status by indicating it is the final settlement step after delivery confirmation.

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 instruction 'Only call this when you've verified the service/product was delivered correctly' provides an explicit when-to-use and an implicit when-not-to-use condition. However, it does not explicitly name an alternative tool (e.g., escrow_dispute) for cases where delivery was not correct, which would strengthen the 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?

No annotations are provided, so the description carries the full burden. It discloses the read-only nature via 'Check' and provides useful context by listing possible state values. It does not mention error conditions or permissions, but for a simple status query this is adequately 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 a single, front-loaded sentence that immediately states the verb and resource. Every word 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?

For a simple one-parameter read tool, the description covers the purpose and gives examples of expected return states. Since there is no output schema, a bit more detail about the exact response structure could be beneficial, but the description is still 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?

The schema already fully describes the only parameter (escrow_id: 'The escrow ID to check') at 100% coverage. The tool description adds no additional meaning beyond what the schema provides, 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 uses a specific verb 'Check' with a clear resource 'current state of an escrow' and enumerates example states (funded, released, disputed, expired), clearly distinguishing it from sibling tools like escrow_create, escrow_dispute, and escrow_release.

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 implies when to use this tool: whenever you need to know the current escrow state. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to select it over sibling mutation 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?

With no annotations, the description carries the full burden. It discloses that ratings are 'on-chain and permanent' and 'feed directly into trust scoring', which are important behavioral traits. It does not elaborate on return values or success/failure behavior, but the key permanence and impact are well 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 four concise sentences, each earning its place: main purpose, importance for trust scores, roles for each side, and permanent on-chain nature. It is front-loaded with the actionable purpose and avoids 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?

For a simple 2-parameter tool with no output schema, the description covers the purpose, timing, participating roles, and behavioral consequences. It lacks explicit return value or error conditions, but the core context is sufficiently complete, especially given the schema's parameter details.

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 has 100% coverage with descriptions for both parameters. The description adds meaning by explaining that stars represent 'seller's service quality' for buyers and 'buyer's conduct' for sellers, which enriches the schema's generic 1-5 scale. This goes beyond the baseline of 3.

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 'Rate a completed escrow', a specific verb and resource, and further clarifies the scope by specifying 'After escrow_release' and rating on a 1-5 star scale. This clearly distinguishes it from sibling tools like escrow_create, escrow_dispute, escrow_release, and trust_score_query.

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 on when to use the tool (after escrow_release) and who can use it (both buyer and seller with different rating criteria). It does not explicitly name alternative tools or exclusion conditions, but the precondition and role clarity provide solid 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 weight. It discloses the risk-based protection levels, payment caps, blocked unknown agents, and the flow including auto-release/dispute. However, it doesn't detail what happens after verification or error handling, so some gaps remain.

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 well-structured with a clear flow, bullet points for protection levels, and no redundant text. Every sentence adds value, and it's front-loaded with the core 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?

The description covers the key behavioral aspects necessary for an agent to decide and invoke the tool, including trust check, protection levels, and recommendation vs alternatives. Lacks return/output details, but since there is no output schema, a brief note on response format would elevate completeness. Still, it is solid.

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 explains each parameter. The description adds context about trust-based caps but doesn't elaborate on individual parameters like body or headers beyond what schema provides. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as a payment method for agents that includes trust checking and automatic escrow protection. It distinguishes itself from sibling tools like x402_protected_call by describing its automated risk-based flow and being the recommended 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?

Explicit usage guidance is given: 'This is the recommended tool for paying any agent' and alternative 'use x402_protected_call instead' when manual control is needed. The flow description also clarifies when it applies.

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 a good job: it explains the decision logic (high trust → shorter timelock, low trust → longer timelock, caution → don't proceed) and the type of output (go/no-go with escrow parameters). It clearly frames the tool as a pre-payment check. It does not explicitly state whether the call has side effects or requires special permissions, but the description implies it is an advisory read-only check.

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

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

The description is concise and well-structured: a hook question, a clear statement of what it returns, bullet points for the decision tiers, and a direct usage directive. Every sentence earns its place, and the key 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?

Given the lack of an output schema, the description adequately explains the return type (go/no-go with escrow parameters) and the three possible outcomes. It also provides usage sequence relative to sibling tools. It does not give an exact output format or error handling, but for a simple query tool 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% for both parameters, so the description adds minimal semantic value. The intended_amount_usdc is described in the schema as 'helps calibrate the recommendation,' and the description does not add further detail about how it affects the recommendation or the escrow 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 function: a pre-payment trust check that returns a go/no-go decision with recommended escrow protection parameters. It uses a specific verb ('Check', 'Returns') and resource (payment decision), and distinguishes itself from sibling tools by positioning it as the tool to call before escrow_create or safe_pay.

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 call this tool BEFORE escrow_create or safe_pay, providing clear usage context. It also notes that it is 'Unlike other trust services,' which helps differentiate it. However, it does not explicitly mention when to use the other trust-related siblings (e.g., trust_score_query, trust_onchain_quick) instead, leaving some ambiguity.

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 carry the full burden. It discloses that only the PayCrow Reputation contract is used, that the operation is free, and that no API keys are required. However, it does not mention the output format, error possibilities, or any side effects, leaving some 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?

The description is two sentences, front-loaded with the primary purpose ('Quick on-chain reputation check'), and followed by useful caveats (free, no API keys) and an alternative. Every sentence earns its place 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 single-parameter tool, the description gives the purpose, scope, cost, and an alternative, which is helpful. However, with no output schema, the agent remains unsure about the return value or result format, which is a notable gap.

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 fully documents the only parameter ('address' with description). The description does not add meaning beyond the schema, but given the high schema coverage (100%), 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 a specific verb and resource: 'Quick on-chain reputation check using only the PayCrow Reputation contract.' It also distinguishes itself from sibling 'trust_score_query' by noting it is the quick version and that the full composite score requires the other 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?

The description communicates when to prefer this tool ('Quick', 'Free, no API keys needed') and explicitly recommends 'trust_score_query' for a full composite score, providing an alternative. It does not spell out when not to use it, but the context is sufficient.

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 burden. It discloses the data sources (4 on-chain sources) and the return format (0-100 score with per-source details), which is strong for a read-only query. It does not mention potential caveats like rate limits, but given the simplicity of the 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?

Two sentences, front-loaded with purpose and key details, and ends with an explicit alternative. Every word earns its place; 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?

For a single-parameter lookup with no output schema, the description provides essential information: what it returns (score and per-source details) and how it differs from trust_gate. It could mention error behavior or exact response structure, but the description is 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?

The input schema has one parameter with full coverage (100% description). The description adds 'agent address' but the schema already provides the same meaning. Thus the description adds no significant value beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Full trust score breakdown for an agent address' with a specific verb 'breakdown' and resource. It also distinguishes itself from the sibling tool trust_gate by noting when to use each.

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 provides an alternative for a different use case: 'For a quick go/no-go decision, use trust_gate instead.' This tells the agent exactly when to use this tool vs. the alternative.

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 discloses manual escrow protection, full control over verification and timelock, and that it overrides safe_pay's trust-based limits. While it doesn't detail side effects like fund movement or failure outcomes, it adds meaningful behavioral context beyond the schema, though not exhaustive 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 concise (~70 words) and well-structured: a one-sentence purpose, a clear comparison to safe_pay, and a bulleted list of use cases. Every sentence earns its place, with no redundant information or overly verbose explanations.

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 complex tool with 9 parameters, no annotations, and no output schema, the description covers selection criteria comprehensively and gives enough context about verification and timelock to guide invocation. It doesn't specify return values or error handling, but the 100% schema parameter coverage compensates. The description is adequate for an agent to choose and correctly invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the verification strategies ('Custom JSON Schema verification (not just "valid JSON + 2xx")' and 'Hash-lock verification (exact response match)'), which deepens understanding of verification_data and verification_strategy. It also frames timelock_minutes and amount_usdc in the context of overriding safe_pay constraints.

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: 'Make an HTTP API call with manual escrow protection.' It specifies the resource (HTTP API call with escrow) and distinguishes it from safe_pay by noting full control over verification and timelock parameters. The bullets further clarify specific use cases, making the 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 explicitly says 'For most payments, use safe_pay instead' and then lists concrete scenarios for using x402_protected_call (custom JSON Schema verification, hash-lock, specific timelock durations, overriding amount limits). This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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