Synmerco

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

With no annotations, the description carries the full burden. It discloses how the score works ('measures trust transitively', 'your score rises when high-trust agents choose to work with you') and states it's 'Free, no auth required', adding meaningful behavioral context. It doesn't mention potential caveats like caching or response format, but for a lookup tool this is fairly 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 concise, with four short, information-dense fragments. Every clause adds value: the type of reputation, the contrast with SynmercoScore, the mechanism, and the access requirements. 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 simple one-parameter lookup, the description gives enough context: what it measures, how it works, and that it requires no auth. Although there's no output schema, the return value (a reputation score) is implied by the phrase 'reputation for any agent' and 'your score rises'. It's complete for the tool's 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?

The schema covers the only parameter (did) with a clear description and pattern. The tool description adds no extra parameter-specific detail, but the phrase 'for any agent' implies the did identifies an agent. This meets the baseline but doesn't add 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 it provides 'Graph-based EigenTrust reputation for any agent', which is a specific verb+resource. It also distinguishes itself from SynmercoScore by explaining the difference, 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?

It explicitly contrasts with SynmercoScore ('Unlike SynmercoScore (which counts your own transactions)'), indicating when to prefer this tool for transitive, Sybil-resistant reputation. It doesn't name sibling tools like lookup_trust_score, but the conceptual alternative is clearly given, providing solid usage 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 key behaviors: auto-matching, notifying top matches, and potential escrow creation, as well as the 'fire-and-forget' nature. However, it is ambiguous about when escrow is spun up (the word 'can' is vague) and does not mention persistence, failure modes, or whether this is a mutating operation beyond posting.

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 front-loaded with the core action. The second sentence is somewhat metaphorical and redundant ('A job that finds its own candidates' restates the first sentence), but it remains short and does not waste much space.

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-parameter tool with no output schema and no annotations, the description covers the core workflow but leaves gaps: no mention of return values, behavior when no agents match, or clear clarification of the escrow trigger. The 'can spin up escrow' phrase is particularly unclear and would benefit from more specificity.

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

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

Schema coverage is 100% and all 7 parameters have descriptions, so baseline is 3. The description adds value by explaining how parameters map to the matching algorithm ('capability + trust + price') and the resulting workflow (notifies top matches, can spin up escrow), which is not apparent from the schema alone.

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 ('Broadcast what you need done') and clearly states the resource and scope: auto-matching agents from the Build Hub by capability + trust + price. This distinguishes it from sibling tools like browse_intents or search_agents, which are for browsing/searching rather than broadcasting a need.

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 when you want to post once and let the marketplace find and notify qualified agents. It implies alternatives (manual search/browse) but does not explicitly name them or state when not to use this tool.

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

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

No annotations are provided, so the description carries the burden. 'Browse' and 'find' imply a read-only operation, but the description does not explicitly state that it does not modify state, nor does it mention return format or potential side effects. It adds some context about the intent stream and income, but falls short of full 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 front-loaded with the purpose and usage, but the third sentence ('Every match is a potential income event...') is motivational fluff that doesn't provide functional tool guidance. The first two sentences are clear 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 search tool with two optional params and no output schema, the description adequately conveys what the tool does and how to filter. It doesn't explicitly describe the return shape or whether it's read-only, but 'surface jobs' implies a list. The lack of annotations is a minor gap, 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?

Schema covers 100% of the parameters with descriptions (limit and capability). The description adds minor value by explaining that capability filters for jobs the agent can complete, but doesn't add beyond the schema's 'Filter by capability keyword'.

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 this tool finds paid work matching the agent's capabilities, with a specific verb ('Find') and resource ('paid work'). It distinguishes from siblings like broadcast_intent (which likely posts intents) by focusing on browsing the intent stream, though it doesn't explicitly name alternatives.

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 filtering by capability keyword to surface suitable jobs, and notes that regular browsing keeps agents utilized. This provides a clear usage context, but does not explicitly mention when to use this instead of marketplace_search or other search 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?

No annotations are provided, so the description carries the full burden. It discloses that no auth is required ('Free, no auth required') and explicitly lists the return data (trust scores, completed transactions, dispute rates, reputation tier). Though 'compare' implies a read-only operation, it does not explicitly state no side effects, but the information provided exceeds minimal 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 two sentences, immediately states purpose, and front-loads the action ('Compare two agents side-by-side'). Every phrase earns its place, with no filler 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?

The tool is simple (two parameters, no output schema), and the description covers purpose, timing, return data, and auth. It omits error behavior or protocol specifics, but those are not critical for a comparison tool. The listed data points make the response expectations 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?

Schema description coverage is 100%, so the schema fully documents did1 and did2. The description adds the cross-protocol context, but otherwise does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Compare') and resource ('two agents side-by-side'), clearly distinguishing it from single-agent lookup tools like agent_rank_lookup or lookup_trust_score. It also lists the specific metrics returned, 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 phrase 'before picking one' situates the tool in a decision-making context, and 'across protocols' signals its cross-protocol applicability. However, it does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to choose it over 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 burden of disclosing behavior. It adds useful context about Synmerco's round limits and auto-accept thresholds, but does not explain the immediate side effects of submitting a counter-offer (e.g., response format, whether it's final, or what happens on acceptance/rejection).

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

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

The description is two concise sentences, front-loaded with the core purpose. The second sentence adds behavioral context without unnecessary fluff. 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 2-parameter tool with no output schema, the description is fairly complete. It establishes the negotiation context and a key behavior (termination), though it does not mention the response or any required prerequisites beyond an active negotiation. Acceptable given the low 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 50%: counterCents has a clear schema description, but negotiationId is undocumented. The description does not explicitly explain either parameter, though 'counter-offer' implies counterCents is the amount and 'active negotiation' implies negotiationId is the identifier. The description adds limited value 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 uses a specific verb ('Submit') and resource ('counter-offer'), and clearly scopes it to an active negotiation. This distinguishes it from sibling tools like 'start_negotiation'.

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 the tool: during an active negotiation to make a counter-offer. It provides context but does not explicitly mention alternatives or exclusions.

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

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

With no annotations, the description must disclose behavioral traits, but it only states high-level guarantees (buyer/seller protections). It doesn't clarify whether this call actually moves funds (sibling fund_escrow suggests the flow may be split), nor mention fees, failure behavior, or the dispute/auto-release mechanics already present in the schema.

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

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

The description is four concise sentences that front-load the core action and then explain value. It is slightly promotional with claims like "can't be stolen" but every sentence contributes to understanding purpose and 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 7-parameter financial tool with no output schema or annotations, the description is too high-level. It omits what the tool returns, whether funding is part of this call, and how the payment method/chain relate to the escrow lifecycle. This leaves critical operational gaps for an agent.

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 100% coverage with detailed descriptions for all 7 parameters, so the description is not required to explain each field. The text adds the fiat/crypto context that aligns with paymentMethod and chain, but no parameter-specific semantics beyond that.

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+resource pair ('Lock funds in escrow') and clearly conveys the tool's role in escrow creation. It doesn't explicitly contrast with siblings like fund_escrow or release_escrow, but the initial locking action makes 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 implies use when a buyer and seller need a neutral trust layer for a job, mentioning fiat/crypto bridging. However, it provides no explicit guidance on when to use create_escrow versus related tools like fund_escrow or predict_escrow, nor any when-not-to-use conditions.

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 adds useful behavioral context (works across 4 chains, 6 protocols, all payment rails), but does not disclose important traits like idempotency, error conditions, or whether it overwrites an existing wallet. This leaves significant behavioral 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?

Two concise sentences. The first sentence is front-loaded with the verb and resource ('Create your agent's wallet'), and the second adds value by explaining the universal scope. No filler or 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 (0 params, no output schema), the description adequately covers its purpose and key differentiator. It could be enhanced with a note about idempotency or prerequisites (e.g., whether registration is required), but it is sufficient for most use 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?

The tool has zero parameters, so the baseline is 4. The description adds context about the wallet's role and scope, though no parameter-specific semantics are needed. It does not need to compensate for missing schema details.

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

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

The description uses a specific verb and resource ('Create your agent's wallet') and clearly explains its purpose: holding balances, funding escrows, and receiving payouts. It also differentiates from sibling tools like deposit_wallet and get_wallet_balance by positioning it as the universal wallet layer.

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

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

The context is clear: this is the wallet creation tool, implied as a prerequisite for holding balances and interacting with escrows. However, it does not explicitly name alternatives or state when not to use it (e.g., if a wallet already exists), so it falls short of a 5.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does disclose a key behavioral trait: each task creates its own escrow that auto-unlocks when predecessors complete. However, it omits other side effects, failure handling, or permission requirements, leaving notable 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 two sentences, front-loaded with the core purpose, and every sentence adds value. The Unix pipes simile and the 'hire 5 agents' phrasing are memorable and aid understanding without bloat.

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 moderate complexity and lack of both annotations and output schema, the description covers the core concept, usage context, and key behavioral mechanics. It does not explain return values or failure modes, but the essential mental model is complete enough for selection and initial understanding.

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 baseline is 3. The description adds meaningful conceptual semantics beyond the schema by explaining that tasks become escrows and dependencies control auto-unlocking, which clarifies the purpose of the tasks and dependsOn 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 uses a specific verb ('Compose') and resource ('multi-agent pipelines with chained escrows'), clearly distinguishing it from sibling tools like create_escrow (single escrow) and post_job. The Unix pipes analogy reinforces the orchestration 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?

It provides clear context for when to use the tool: when you need multi-agent pipelines with chained escrows, and the closing line 'Hire 5 agents to do what 1 agent can't' implies collaborative scenarios. It does not explicitly mention alternatives or exclusions, 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?

With no annotations, the description carries the full burden. It discloses the key behavior: returns a URL the buyer or operator visits, and that the deposit is not immediate ('Once deposited'). This is valuable context, though it omits details about authentication requirements, failure modes, or settlement time.

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 avoids redundancy. The second sentence provides useful context about the deposit's purpose without unnecessary detail.

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 the essential context: what it does, what it returns (URL), and how it fits into the wider workflow (funding escrows). It could be slightly more explicit about the asynchronous nature of the payment, but overall it is complete for this complexity level.

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 the single parameter (amountCents with min/max and unit explanation). The tool description adds no additional parameter semantics beyond confirming the top-up action, so the 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's function: 'Top up your agent wallet via Stripe checkout.' It uses a specific verb ('Top up'), names the resource ('agent wallet'), and specifies the method (Stripe checkout), distinguishing it from siblings like create_wallet or fund_escrow.

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 the tool should be used when needing to add fiat funds to the agent wallet, and explains the downstream benefit ('Once deposited, your wallet can fund any escrow'). However, it does not explicitly mention when not to use it or name alternative tools for this purpose.

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 states 'Free, no auth required', which implies a safe, non-destructive operation. It also explicitly lists the fee components and net amount shown, giving a clear picture of what the tool does. However, it does not explicitly confirm that it is read-only or describe the return 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?

Two sentences total: the first is a motivational hook, the second is dense with factual details. There is no fluff, though the first sentence could be seen as slightly redundant with the tool name.

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

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

For a simple one-parameter estimator, the description covers purpose, key fee components, authentication requirements, and cost. It lacks an explicit return format, but since it enumerates exactly what is shown, the tool is sufficiently understandable.

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 100% of the parameter, with a clear description ('Amount in cents ($1.00 = 100)'). The tool description adds no extra parameter semantics beyond implying the amount is what fees are calculated on, which is already obvious from 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 function: estimating earnings/payments by showing platform fee, Shield insurance, referral split, and net amount. It distinguishes itself from sibling tools by focusing on fee calculation rather than actions like escrow or marketplace transactions.

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 'before you commit' provides clear when-to-use context, indicating it should be used prior to financial transactions. However, it does not explicitly mention alternatives 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?

No annotations are provided, so the description must carry the burden. It does disclose key behavior: it aggregates trust signals from external platforms and the signal strengthens with more vouching platforms. However, it does not mention the response format, whether the operation is read-only, or any latency/error behavior, which are typical 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 four sentences and mostly direct. The final sentence ('Trust agents from outside your silo with the same confidence as native ones.') is somewhat promotional and redundant, but it does reinforce the value proposition without much waste.

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

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

Given the tool has only one parameter and no output schema, the description adequately covers its purpose and the federated aggregation model. It lacks an explicit statement of what the return value looks like (score, confidence interval, list of signals), which would improve completeness for a simple lookup 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 provides 100% coverage for the single 'did' parameter, including format, pattern, and example. The tool description itself adds no parameter-specific guidance beyond what the schema already states, so 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?

The description uses a specific verb+resource: 'Cross-platform reputation' for any agent, and explains it aggregates trust signals from external platforms, clearly distinguishing it from local trust tools like lookup_trust_score. The purpose is 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: use this for any agent, even ones you've never interacted with, and specifically for trust from external platforms. It implies a contrast with native reputation tools but does not explicitly name alternatives such as lookup_trust_score or agent_rank_lookup.

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 transparency burden. It discloses meaningful behaviors: funding source (agent wallet), binding commitment ('commit the buyer side'), side effects (seller notified), and payment rail abstraction. However, it does not disclose failure modes, reversibility, or prerequisites (e.g., escrow state), leaving gaps for a financial mutation.

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

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

Two sentences, front-loaded with the core action and purpose. The second sentence adds relevant context about payment rails without waste. 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 only one parameter, no output schema, and no annotations, the description covers the essential context: what the tool does, the funding source, the outcome (seller notified, work can start), and the payment abstraction. It lacks some depth on failure/return behavior, but the simplicity of the tool and presence of get_escrow as a sibling mitigate this.

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 the single parameter (escrowId), so the baseline is 3. The description does not add any detail beyond the schema about what escrowId is or how to format it, but it doesn't need to since the schema already provides that.

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 ('Fund an escrow') and identifies the resource (escrow) with an explicit purpose ('to commit the buyer side'). It clearly distinguishes from sibling tools like create_escrow, release_escrow, and start_work by defining the funding step.

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 states the action occurs 'from your agent wallet' and the consequence ('Once funded, the seller is notified and can start work'), implying this is the step between escrow creation and work start. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context about translation ('translates the call, signature, and payment'), which implies side effects like payment processing. However, it does not disclose potential failure modes, authentication requirements, asynchronous behavior, or whether the operation is reversible—gaps that are significant for a cross-protocol bridge 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—four sentences with no fluff. It front-loads the core purpose, then explains the mechanism and supported protocols. The only minor issue is the slightly marketing-oriented opening ('The bridge to every agent in the world'), but this does not significantly harm clarity.

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 moderate complexity (cross-protocol translation, 5 parameters) and no output schema, so the description should explain return values or success criteria. It covers the why and what, but omits what the agent should expect as a result or what prerequisites (e.g., payment setup) are needed. The schema covers parameters, but the absence of output behavior leaves the description 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?

Schema description coverage is 100%, so the baseline of 3 applies. The description adds a little context about protocols ('Your agent speaks MCP, the target speaks A2A') but does not explain parameter-level details beyond what the schema already provides. There is no additional meaning attached to specific fields like targetDid or capability.

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 ('Send a message to any agent') and resource ('every agent in the world'), and it differentiates the tool from siblings by emphasizing cross-protocol translation ('regardless of which protocol they speak', 'Supports A2A, MCP, REST, x402'). It loses a point due to somewhat hyperbolic marketing language ('bridge to every agent in the world') rather than a plain, exact specification.

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

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

The description gives clear context for when to use the tool: when the target agent speaks a different protocol ('Your agent speaks MCP, the target speaks A2A') or when reaching agents outside the ecosystem ('Reach agents outside this ecosystem without rewriting your agent'). It does not explicitly name sibling tools as alternatives or list exclusions, but the context is strong enough for an agent to infer appropriate usage.

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?

There are no annotations, so the description carries the transparency burden. It discloses that the tool is free and requires no auth, and it states what the tool returns. While it doesn't mention rate limits or failure behavior, it clearly implies a read-only status check, which is adequate for this tool's scope.

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, return value/usage context, and auth/free status. The description is front-loaded with the verb and resource, and there is no wasted text.

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

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

For a simple one-parameter read-only health check, the description covers purpose, when to use, auth/free status, and return contents. No output schema is present, but the description lists the key return fields, so the agent has enough context to invoke and interpret the result.

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 a clear enum and description for the single 'chain' parameter. The tool description adds contextual value by explaining that the goal is picking the fastest rail, but it doesn't add details about how the chain value affects the output beyond what the schema already 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 uses the specific verb 'Check' with a clear resource ('crypto payment infrastructure status') and states what is returned (chain health, RPC latency, settlement times). It also frames the tool's purpose in a decision-making context ('picks the fastest rail'), making it clearly distinct from the broader set of 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?

The description explicitly says to use the tool 'before initiating high-value transfers' and explains why (to pick the fastest rail). This gives clear usage context, though it doesn't name specific alternatives or excluded 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 must carry the full behavioral burden. It adds transparency by disclosing the type of information returned (tier, submitted evidence, projected timeline) and describes the data as 'live', conveying freshness. However, it does not explicitly state that the operation is read-only or discuss authorization, error behavior, or side effects.

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 states the core action and then lists three specific data points (tier, evidence, timeline). It is efficient and contains no wasteful filler, earning a high score for conciseness.

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-only tool with one parameter and no output schema, the description provides a solid overview of what the agent will learn (tier, submitted evidence, resolution timeline). It lacks details on prerequisites or error conditions, but given the low complexity, 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?

The input schema defines a single `disputeId` parameter with zero description coverage. The tool description never mentions the parameter, how to obtain it, or any constraints beyond the schema's min/max length. An agent can infer it is the dispute identifier from the tool name, but the description adds no explicit semantic value.

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

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

The description clearly identifies the tool as fetching live dispute status and resolution progress using the specific verb 'Get' and resource 'dispute'. It distinguishes itself from siblings like raise_dispute and submit_evidence by focusing on retrieval rather than creation or submission.

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 for checking a dispute's current status, but it does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites like needing a disputeId from raise_dispute. No alternatives or exclusions 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 the scope ('any escrow your agent is involved in'), the data returned (state, amounts, proof details, timeline), and the performance benefit ('without polling multiple endpoints'). It does not mention error conditions or authorization, but the read-only nature is clear from 'pull' and the get prefix.

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

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

Two sentences, no excess. The first sentence states the core action; the second elaborates on content and purpose. Every clause earns its place, and the key info 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 one-parameter read tool with no output schema, the description is nearly complete: it explains purpose, scope, and the kind of data returned. It could add a note about return format or failure modes, but given the simplicity and the lack of annotations, it offers sufficient operational context.

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 has full 100% coverage for escrowId ('Escrow ID'), so baseline is 3. The description adds meaning by indicating the ID must belong to an escrow the caller's agent is involved in, effectively constraining valid inputs. This supplements the minimal schema 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 opens with 'Pull the live status of any escrow your agent is involved in' – a specific verb ('pull'), resource ('escrow'), and scope ('agent is involved in'). It further distinguishes from sibling tools like get_dispute or get_workflow by listing the data categories: state, amounts, proof details, and timeline.

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: 'everything needed to decide the next action without polling multiple endpoints.' This implies the tool is the go-to for a consolidated escrow status check. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide an agent.

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 discloses the return content (profile, protocols, chain records, keys) and implies read-only behavior, but it does not mention error conditions, availability, or any side effects. This is minimal but not misleading for a simple lookup 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?

Two sentences, no filler. The first sentence states the action and deliverables; the second gives a concrete use case. Information is front-loaded and 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?

For a single-parameter tool with a clear schema and no output schema, the description sufficiently covers what the tool returns and when to use it. It could optionally mention whether the DID must be pre-registered or how outputs are structured, but this is not required 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%, and the schema already describes the 'did' parameter with a pattern, length, and example. The description adds no new parameter semantics beyond reinforcing 'DID', so it stays at the baseline for fully described schemas.

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 begins with a specific verb and resource: 'Resolve a DID into full identity details,' and enumerates the exact contents (profile, supported protocols, on-chain registry entries across 4 chains, public keys). This clearly distinguishes the tool from siblings like resolve_agent or search_agents by emphasizing cross-chain and full-identity 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?

Provides explicit when-to-use guidance: 'Use to verify any agent you're about to transact with — even an agent first encountered through another platform.' This sets clear context but does not mention when not to use or name alternatives, 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 exist, so the description carries full burden. It doesn't explicitly state read-only behavior, sorting, or what happens when inbox is empty, and the motivational sentence adds no behavioral detail.

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, but the second sentence is motivational filler that doesn't aid selection or invocation. The core function is stated in the first sentence.

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 annotations and no output schema, the description is incomplete—it doesn't describe the return format, read-only nature, or any pagination/ordering behavior. However, the tool is simple with one parameter.

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 covers 100% of the single parameter with description. The tool description adds no additional parameter semantics 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 tool checks the inbox for hire requests, job invitations, counter-offers, and dispute notices, which is a specific verb+resource. It doesn't explicitly name alternative tools, but the purpose is distinct from siblings like send_message or counter_offer.

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?

No when-to-use guidance is provided. The motivational sentence about earning opportunities implies frequent checking but doesn't specify contexts or alternatives.

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 'Free, no auth required,' which is important behavioral info about permissions and cost. It also notes it is a single call, implying no side effects. However, it could mention response format or rate limits, but the key traits are covered.

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

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

The description is two compact sentences. The first sentence front-loads the core value proposition with specific, scannable details; the second provides a clear use case. Every word 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?

Given the tool has no parameters, no annotations, and no output schema, the description does a good job of explaining what to expect: chains, fees, tools, and protocols. It also covers cost and auth. It could be slightly more explicit about the response structure, but it is sufficient for a simple info 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, so the baseline is 4. The description adds meaningful context about what the response includes, which indirectly explains why no parameters are needed. It doesn't need to add parameter-level detail since 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 clearly states the tool's purpose: 'Get the full Synmerco surface in one call' and enumerates exactly what is included (chains, fees, MCP tools, protocols). This distinct resource and specific verb differentiate it from sibling tools, which are all focused on narrower operations.

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: 'Use this to teach your agent what Synmerco can do.' This implies the tool is for onboarding or overview purposes, and it is distinct from the more specific sibling tools. It doesn't explicitly mention when not to use it, but the context is strong enough.

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. The verb 'Check' strongly implies a read-only, non-mutating operation. It also adds useful context about earnings accruing without further user action. It does not explicitly state 'does not modify anything' or mention permissions, but the read-only intent is 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?

Two sentences, front-loaded with the direct purpose, and the second adds contextual value about the passive income stream. No redundant or extraneous 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 simple getter with one well-documented parameter, the description is largely complete. It clearly states what the tool does and the context of referral earnings. It does not explicitly describe the return format or units, which is a minor gap, but the overall purpose and usage are well covered.

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 'did' parameter with a regex pattern and example, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema provides, which is sufficient given the 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 clearly states the tool's function with a specific verb ('Check') and resource ('accumulated referral earnings'), including the scope ('from every agent you've onboarded'). This distinguishes it from siblings like register_referral and get_wallet_balance.

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 this tool: to check accumulated referral earnings. It provides context that earnings accrue passively, implying it can be used anytime. While it doesn't explicitly name alternatives or exclusions, the use case is unambiguous for a simple getter.

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

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

With no annotations, the description carries the burden. It discloses that the tool shows recent transactions, denominates balances in fiat (cents) and crypto (USDC), and positions itself as 'one truth source.' This adds meaningful context beyond the tool's name and schema, though it doesn't explicitly state auth requirements or side effects.

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, all valuable: purpose, usage timing, and return details. Front-loaded with the main action, no fluff or redundant repetition of schema fields.

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 1-parameter read tool with no output schema, the description covers purpose, usage context, and return contents (fiat/crypto balances, transactions). It is sufficiently complete given the low complexity and clear sibling differentiation among wallet-related tools.

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

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

Schema coverage for the single parameter 'did' is 100%, so the baseline is 3 per the rubric. The description adds no additional meaning about the parameter itself, relying entirely on the schema definition.

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') and clearly identifies the resource ('your agent wallet balance and recent transactions'). It distinguishes this from sibling tools by emphasizing it reads both fiat and crypto balances, unlike create_wallet or deposit_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?

Explicitly states when to use: 'before funding new escrows or to verify incoming payouts from completed work.' This provides concrete use cases, though it does not mention when not to use or name alternatives.

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 the burden. It adds useful behavioral context: 'live status,' comprehensive entity coverage, and bottleneck identification. However, it does not explicitly confirm non-mutating behavior, authorization requirements, or response format, which would strengthen transparency for a read operation.

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 deliver the core purpose and practical value without redundancy. Leading with the main action, then elaborating with specific insight (bottleneck detection) and downstream use (reroute/top up) makes it compact and 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?

With no output schema, the description compensates by naming the expected content: tasks, escrows, dependencies, and bottleneck. Given the tool's simplicity (one required parameter) and clear use case, this is nearly complete, though it omits potential caveats like error scenarios or status interpretation.

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 the single parameter (workflowId), so the schema fully documents the parameter. The description adds no parameter-specific meaning beyond what is already in the schema, matching the baseline for high 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 clearly states the tool's function: 'Get live status of a multi-agent workflow' and specifies the scope (every task, escrow, dependency, bottleneck). This distinguishes it from sibling tools like get_escrow (single escrow) and create_workflow (creation).

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 for monitoring workflows and deciding on rerouting or budget top-ups ('so your agent can reroute or top up budgets'), but it does not explicitly state when to avoid this tool or provide alternative tool suggestions. No exclusions or when-not-to-use guidance is present.

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 emphasizes benefits (passive income, 24/7 availability) but never states that the tool will create a permanent or public marketplace listing, nor does it mention costs, permissions, or return behavior. The language is promotional rather than transparent about side effects.

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 opening sentence is efficient and front-loaded, but the subsequent two sentences ('Your agent earns when work is verified...' and 'Idle agents earn nothing...') are largely redundant marketing phrases that don't add technical value. The description is not overly long, but it contains filler that could be trimmed for clarity.

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 five parameters, no output schema, and no annotations, the description should explain what happens after listing (e.g., listing ID returned, visibility, duration) and any prerequisites. It only covers the value proposition and omits crucial mechanics, making it incomplete for a listing-creation 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?

All five parameters (title, description, capabilities, rateCents, turnaroundHours) are already fully described in the schema, with 100% coverage. The description adds no extra parameter-level guidance, so it appropriately stays at 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 states a specific verb-resource pair ('List a service') and explains the intended outcome: making the agent discoverable and hireable. However, it does not explicitly distinguish itself from sibling tools like marketplace_post_listing, leaving minor ambiguity about unique positioning.

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 publish a service so buyers can find and hire the agent automatically. It does not offer explicit exclusions or compare with alternatives, but the use case is well implied and understandable.

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 must carry the burden. It discloses that it's free, requires no auth, and returns specific data types across 4 chains, which is helpful. Still, it does not detail behaviors like error handling, rate limits, or whether data is live/cached, leaving some uncertainty for a tool with no safety annotations.

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, each informative and free of filler. The main action is front-loaded, making it easy for an agent to scan.

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 tool, the description covers purpose, output, scope, and authentication, which is quite complete. The lack of an output schema is compensated by listing the returned fields. Minor gaps like data freshness or failure modes prevent a 5.

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 explains the 'did' parameter with a pattern and example. The description does not add extra semantics beyond implying cross-ecosystem support, so it stays at 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 a specific purpose ('Vet any AI agent before transacting') and enumerates concrete return values (trust score, reputation tier, transaction history, on-chain verification) and scope (4 chains, cross-ecosystem). This distinguishes it from sibling tools like agent_rank_lookup or federated_reputation.

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 context for when to use ('before transacting') and notes it works for both internal and external agents, making it the 'bridge' for on-chain agents. However, it does not explicitly mention alternatives or when not to use this tool relative to 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 provided, the description carries the full burden. It discloses that the tool is free and requires no authentication, and adds context on how to interpret listing counts (supply/demand). This goes beyond the schema, though it stops short of discussing rate limits or pagination.

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

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

Two sentences, front-loaded with the primary action, and every clause earns its place. The interpretation guidance is woven in without clutter.

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, parameterless exploration tool with no output schema and no annotations, the description is quite complete. It covers purpose, interpretation, and auth. A minor gap is that it doesn't specify the exact return shape, but the use case is well covered.

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 baseline is 4. The description still adds value by explaining what the output represents (listing counts per category) even though it doesn't explicitly list return fields. Schema coverage is trivially 100%.

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: to explore Build Hub categories and identify which capability markets are hottest right now. It distinguishes itself from sibling tools like marketplace_search, marketplace_get_listing, and marketplace_post_listing by focusing on category-level market conditions rather than individual listings.

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 see where supply is thin (premium rates) and where demand is heavy (fast work). It does not explicitly mention alternatives or exclusion scenarios, but the use case is well implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds valuable context by stating 'Free, no auth required' and enumerates the type of data returned. It does not cover error cases, but for a read-only retrieval tool 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 concise and front-loaded with the primary action. Two sentences convey purpose, contents, and safety information without waste.

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

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

For a simple single-parameter get tool, the description adequately covers what the tool does and what it returns. It does not describe output format or error behavior, but the low complexity and explicit content list make it sufficiently complete for actual 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 description coverage is 100% with a single 'id' parameter described as 'Listing UUID.' The description does not add extra parameter semantics beyond the schema, so the 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 'Get the full record of a Build Hub listing' with a specific verb and resource. It enumerates the contents (pricing, protocols, chains, rate cards, trust signals) and distinguishes itself from related marketplace tools like search or post by focusing on the full record retrieval.

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 usage context by stating 'Everything your agent needs to decide whether to hire or skip,' implying when to use this tool for decision-making. However, it does not explicitly name alternatives or exclusions, so it falls just 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 carries the full burden for behavioral disclosure. It does reveal that the listing is permanent ('appears in every search match forever') and that pricing can be set across multiple models, adding meaningful context. However, it omits important details such as whether the listing can be edited/removed, whether approval is required, any permission requirements, or what the API returns.

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 compact at three sentences and each sentence adds information: the first frames the monetization goal, the second explains permanent discoverability, and the third lists pricing/protocol options. The first sentence is somewhat promotional rather than purely functional, but the overall structure is efficient and readable.

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

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

The description covers the core behavior (posting a marketplace listing that appears forever in searches) and highlights pricing/protocol flexibility, while the schema covers all parameter details. However, with no output schema, it fails to mention what the API returns (e.g., listing ID) and does not address lifecycle concerns like editing, deletion, moderation, or charges, leaving the agent without a full picture for a 10-parameter creation 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 input schema provides descriptions for all 10 parameters, so the schema already documents semantics thoroughly. The description reinforces the enum values for pricing and protocols, but it does not go beyond the schema to explain parameter relationships, conditional requirements, or specific formatting beyond what the schema says. 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 clearly indicates this tool creates/posts a marketplace listing to monetize tools and services, stating the listing will appear in search results. It differs from retrieval/search siblings like marketplace_get_listing and marketplace_search by focusing on the creation/posting action.

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 the tool is used when an agent wants to monetize a tool or service, emphasizing discoverability and pricing options. However, it gives no explicit guidance on when to use this over alternatives like list_service or post_job, and it does not state exclusions 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 provided, the description carries the full burden of behavioral disclosure. It adds 'Free, no auth required,' which informs the agent of cost and authentication requirements—valuable context not found in the schema. It does not describe rate limits or response format, but the auth/cost disclosure is a meaningful addition.

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 but remains efficient. The first sentence is front-loaded with the main purpose, and later sentences add useful details (filters, cost/auth). The second sentence is somewhat stylistic but not excessive. No redundancy significant enough to drop below 4.

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 search tool with 3 optional parameters and no output schema, the description covers the core purpose, filtering options, and auth/cost traits. It lacks explicit mention of return format or pagination behavior, but the simplicity of the tool makes this acceptable. Sibling tools like marketplace_get_listing could be referenced for follow-up actions, but that is not essential.

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 only restates 'Filter by category and search query' which adds no new meaning beyond the schema's parameter descriptions. It does not explain parameter interactions or provide additional examples, so it stays at 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 browses the Build Hub for tools, APIs, and services to hire, with a specific verb ('Browse') and resource ('Build Hub'). It distinguishes itself from sibling search tools by emphasizing hiring rather than building, and mentions filtering capabilities.

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 when you want to hire an existing capability instead of building it. It does not explicitly mention alternatives or exclusions, but the 'hire the how' phrasing gives a strong usage signal. Sibling tools like search_agents are not referenced, so a slight deduction for missing explicit alternatives.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the key filtering behavior and bridge compatibility, which goes beyond the basic 'post a job' action. However, it does not reveal what happens after posting (e.g., where bids appear, whether there are fees, or if it's mutable). This is a moderate level of 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 description is three concise sentences, front-loaded with the primary action in the first sentence, then adding filtering and bridge context. Every sentence earns its place with 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 tool with 5 parameters, no output schema, and no annotations, the description adequately covers the tool's purpose, filtering behavior, and target audience. It lacks operational details like return values or post-posting workflow, but given the moderate complexity, the context 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 value by linking parameters to the filtering mechanism ('capability, trust score, and availability'), giving semantic meaning to fields like requiredCapabilities and minTrustScore. This justifies a small boost above 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 action ('Post a job') and the outcome ('let qualified agents bid'), distinguishing this tool from siblings like broadcast_intent or marketplace_post_listing by emphasizing Synmerco's filtering capability and cross-bridge support. This is a specific, 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 provides clear usage context: use this to post jobs that will be bid on by agents, with automatic filtering by capability/trust/availability. It also notes compatibility with both internal and bridged agents. However, it does not explicitly mention when not to use it or name alternative 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 carries the full burden of behavioral disclosure. It explains the analysis inputs (completion rates, AgentRank, transaction history, Sybil risk) and frames the tool as a pre-commitment analysis, which implies read-only behavior. However, it doesn't explicitly state whether the tool has no side effects, requires specific permissions, or how the result is delivered, leaving some ambiguity about its operational 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?

The description is three sentences, each serving a distinct purpose: it opens with a clear usage directive, explains what the tool does and the inputs it analyzes, and closes with a benefit statement. There is no redundancy, and the front-loaded phrase 'Run a credit check before committing money' immediately communicates the core intent.

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 (2 required params, no output schema, no annotations), and the description covers purpose, timing, and analysis factors. The phrase 'predicts the success probability' sufficiently conveys the expected return type. There are no critical gaps that would prevent an agent from selecting and invoking the tool correctly.

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

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

Schema coverage for parameters is 100%, with each DID parameter already well-described with pattern and example. The description adds context by referring to 'both agents' and the analysis factors, linking the parameters to their role in the prediction. However, this is complementary rather than essential, so the baseline of 3 holds.

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 ('predicts') and resource ('success probability of an escrow'). It explicitly differentiates from the sibling tool 'create_escrow' by stating 'before you create it' and 'before any funds are locked', making the tool's unique role 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 strong context on when to use the tool: 'before committing money' and 'before you create it'. It clearly implies a pre-check step, though it doesn't explicitly mention alternatives or exclusions. The timing guidance is specific enough to guide the agent to use this prior to create_escrow.

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 available, the description carries the full burden. It discloses that raising a dispute triggers a 3-tier resolution and locks funds until resolved, protecting both parties. This goes beyond a simple 'raise dispute' statement, though it does not cover every possible side effect or edge case.

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

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

The description is concise and front-loaded: the first sentence states the purpose, and the second adds valuable behavioral context. No wasted words and all sentences earn their place.

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

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

The description covers the essential context: trigger condition, resolution process, and fund-locking behavior. With no output schema, it could have added what response to expect, but the overall description is sufficiently complete for a dispute-raising 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 input schema provides 100% parameter coverage with descriptions for all four parameters (escrowId, raisedBy, respondent, reason). The description adds no additional meaning 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 uses a specific verb and resource: 'Raise a dispute when an escrow goes wrong.' This clearly states the action and context, and distinguishes it from siblings like get_dispute (viewing) and release_escrow (releasing funds).

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 a clear context for when to use the tool ('when an escrow goes wrong') and explains the resulting resolution process. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for basic 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 key consequence of not registering (invisibility in search) but does not mention side effects, possible overwriting, fees, or any return behavior. For a registration action, it gives some useful context but lacks depth (e.g., whether registration is persistent, modifiable, or requires authentication).

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 short, front-loaded with the primary benefit, and uses every sentence to convey essential information (discoverability, consequence, prerequisite). No filler or redundant content. It is appropriately sized 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 tool has 3 parameters with full schema coverage, and the description explains the purpose and context. However, there is no output schema, and the description does not describe what the agent should expect as a return value (e.g., success confirmation, agent ID). It also doesn't mention any relationship with other prerequisites (like identity or wallet). For a registration tool, the description is adequate but not fully complete regarding outcome and prerequisites.

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%: each parameter (displayName, description, capabilities) has its own description. The tool description does not add extra meaning beyond stating the overall purpose. It does not explain how the parameters interact or any format constraints, but the schema already covers that. 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 a specific action: 'Make your agent discoverable by every buyer searching the marketplace.' It distinguishes from sibling tools like search_agents and list_service by focusing on discovery, and it explains the consequence of not registering ('never appear in search results').

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: 'Required before listing services or earning passive income from incoming hire requests.' It also states the downside of skipping registration, implying it is a prerequisite. However, it does not mention alternatives or cases where this tool should not be used, so it lacks a bit of explicit 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 must carry the burden of disclosing side effects and behavioral traits. It adds useful context by stating 'No signup, no KYC, no human in the loop,' indicating this is a fast, automated process. However, it does not disclose that this is a state-changing operation (creating an API key) or address potential issues like key expiry, revocation, or multiple calls.

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. The first ('Turn your agent on for income.') and last ('Your agent moves from idle to earning in one tool call.') are redundant marketing fluff. The middle two sentences are informative but the repetition wastes space. The structure is front-loaded with a hook rather than the core statement.

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 only 2 parameters and no output schema. The description adequately explains the purpose and prerequisite (required for earning actions). However, it does not specify the format of the returned API key, how to pass it to subsequent operations, or any error conditions. For a simple tool, this is adequate but not comprehensive.

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 parameters (ownerDid and label) already described inline. The tool description adds no additional parameter-level semantics, so it stays at the baseline of 3 since 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?

The description clearly states that this tool returns an API key and lists the specific actions it unlocks (posting jobs, listing services, funding escrows, earning). This is a specific verb-resource pairing. However, it does not explicitly differentiate from sibling tools like register_agent or register_referral, which share the 'register' prefix.

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 context: 'required to post jobs, list services, fund escrows, or earn from completed work.' This tells the agent when to use it (before engaging in these income-generating activities). It does not mention exclusions or alternatives, but the prerequisite nature is clear.

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 financial incentive but omits operational details such as whether registration is a one-time write, requires authentication, or produces a specific response.

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 only three sentences, but it leads with a marketing benefit rather than the action itself. The final sentence 'The most leveraged tool in this toolkit' is fluff that adds no operational 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 simple tool with one parameter and no output schema, the description provides the core purpose and incentive, but it lacks usage guidelines and behavioral transparency. The schema covers the parameter, making it minimally viable but not comprehensive.

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 does not explain the referrerDid parameter, but the schema includes a clear description and pattern, so schema coverage is 100%. 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 tool registers the user as a referrer and explains the benefit (0.25% of escrow from referred agents). It distinguishes from siblings like get_referral_earnings by focusing on the registration action.

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

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

The intended use (earning passive income by referring agents) is implied, but there is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusionary conditions.

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 reveals key side effects: multi-modal payout (fiat, crypto, Lightning), on-chain recording across 4 chains, and reputation score updates. This goes beyond a generic 'release' statement, though it could additionally mention irreversibility or permission requirements.

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, front-loads the core action, and efficiently lists side effects in two sentences. The final sentence about both agents becoming richer is slightly informal but not wasteful; minor redundancy exists but overall structure is clean.

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 moderate complexity and lack of output schema or annotations, the description adequately covers the action, prerequisite (proof review), and consequences (payout, on-chain record, reputation update). It could mention potential error states or finality, but it provides sufficient context 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 schema fully covers the single parameter escrowId with description 'Escrow ID', so the parameter meaning is already clear. The description does not add further parameter-specific semantics, but that is unnecessary given 100% schema coverage. 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 action (release escrow funds to the seller) with a specific verb and resource, and distinguishes itself from sibling tools like fund_escrow by detailing downstream effects (automatic payout, on-chain recording, reputation updates).

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 the tool by stating 'after reviewing proof', which provides clear sequencing within the escrow workflow. It does not explicitly name alternatives or exclusions, but the condition gives sufficient guidance for choosing this tool over 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 provided, the description carries the full burden. It discloses the tool's broad aggregation behavior and that it works across internal/external agents, but does not mention potential errors, side effects (though none expected), or operational concerns like rate limits. 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 compact and front-loaded: 'Agent DNS' sets an instant mental model, followed by a concise enumeration of return values and the key internal/external scope. Every sentence earns its place, with 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?

Despite having no output schema, the description lists the major content areas that will be returned, giving a solid expectation of the response. It also clarifies the tool's reach (internal and external). A slightly longer list of exact field names or a note on failure modes would make it 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?

The schema already provides 100% coverage for the single 'did' parameter with a clear description and pattern. The tool description adds no extra detail about the parameter beyond calling it an 'addressable agent' identifier, 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 states a specific verb ('returns') and resource ('everything about any agent'), enumerating concrete data categories (profile, trust scores, listings, protocols, payment methods, rate cards, referral attribution). This distinguishes it from sibling tools like agent_rank_lookup or lookup_trust_score, which are more specialized.

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 when you need a unified, comprehensive view of any agent, whether internal to Synmerco or external. It implies a contrast with narrower sibling tools, but does not explicitly name alternatives or state when not to use them.

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 that the tool is free and requires no auth, and lists the filter dimensions. However, it doesn't describe return format, ordering, or any side effects, leaving behavioral traits incomplete.

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 short sentences, front-loaded with purpose and then details. The first and third sentences are somewhat redundant, but overall it's 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 search tool with no output schema and no annotations, the description covers the purpose, filters, and cost/auth model. However, it omits details about the response shape or ordering, which would be helpful for a complete picture.

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

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

Schema coverage is 100%, so each parameter already has a description. The description reinforces the three filter names but adds no new syntax or constraints 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 tool finds agents by capability, trust score, and availability, with a specific verb ('Find') and resource ('agents'). It differentiates by scope, though it doesn't explicitly name sibling alternatives.

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 implies when to use: when your agent lacks a capability and you need to hire an agent. It adds 'Free, no auth required' as a prerequisite, but doesn't explicitly exclude alternative tools like marketplace_search or browse_intents.

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 explaining behavior. It discloses the key semantic matching behavior across vocabularies and ecosystems, which is valuable. However, it omits operational details such as whether the tool is read-only, how results are ranked, or what the return payload contains. The description adds 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 first sentence is a crisp, front-loaded summary of the tool's essence. The subsequent example and explanation each add distinct value, illustrating the semantic concept without redundancy. The entire description is concise and well-structured, earning every sentence.

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 params, no output schema, no annotations), the description covers the core differentiator effectively. It does not explicitly describe the return format or ranking behavior, but 'Find agents' implies the result. The description is reasonably complete for the tool's complexity, though it could mention result characteristics for full clarity.

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 well (100% coverage). The description adds meaningful context to the 'q' parameter by explaining that natural language queries should describe capabilities, not keywords, and provides a concrete example. This goes beyond the schema's 'Natural language search query' and justifies a score above 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 a specific action: 'Find agents by what they DO', clearly distinguishing this tool from keyword-based search. The example with 'Audit my Solidity for reentrancy' vs 'EVM security analysis' vividly illustrates the semantic capability matching, leaving no doubt 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 description conveys a clear use case: use semantic search when you know the capability you need but not the exact vocabulary. It contrasts with word-based search ('not by which words they used'), implying when to use this over a keyword search. However, it does not explicitly name alternative sibling tools or state when NOT to use it, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the transparency burden. It discloses meaningful behavioral traits: 'Stake-gated to filter spam' indicates anti-spam and possible cost, and 'Bridges across A2A doorbells, MCP transports, and direct webhooks' reveals transport mechanisms. It doesn't cover failure modes or side effects, but for a send action this is fairly 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 short, information-dense sentences. The first sentence front-loads the action, the second explains the anti-spam mechanism, and the third lists transport bridges. Every sentence earns its place with zero 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 send-message tool with complete schema coverage and no output schema, the description is adequate. It covers the purpose, scope, and key behavioral context (stake-gating, transport bridges). It doesn't mention return values or detailed failure behavior, but these are not critical for this tool's simple nature.

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 describes all three parameters with 100% coverage, including examples and constraints. The description adds no additional per-parameter meaning beyond the term 'doorbell message', which relates to the message type but doesn't enhance parameter understanding. 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 function with a specific verb and resource: 'Send a doorbell message to any agent'. It also adds scope ('even ones outside Synmerco') and distinguishes it from sibling tools like broadcast_intent by focusing on direct one-to-one messaging rather than broadcasting.

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 context: it is for sending direct doorbell messages to any agent, and it mentions the 'Stake-gated' mechanism which suggests a prerequisite or condition. However, it does not explicitly mention alternatives or when not to use it, though 'even ones outside Synmerco' clarifies scope.

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 transparency burden. It does disclose the autonomous closing behavior via max rounds and an auto-accept threshold. However, it omits important behavioral details such as side effects, permissions required, or what happens when the negotiation ends, 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 first two sentences are concise and front-loaded with useful information. The third sentence ('Agents that negotiate close more deals...') is a marketing claim that does not help an agent select or invoke the tool, so not every sentence earns its place.

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

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

The tool is moderately complex (negotiation rounds, auto-accept thresholds) and has no output schema, but the description doesn't mention return values, whether it creates a persistent negotiation session, or how the negotiation is carried out. This leaves significant gaps for an agent deciding whether and how to invoke it.

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 100% description coverage for all five parameters, so the schema already does the heavy lifting. The description only reinforces maxRounds and autoAcceptWithinPct without adding new semantic details. This matches the baseline of 3 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 clearly identifies the verb and resource: 'Open a price negotiation'. It also specifies the trigger condition ('when the initial offer doesn't fit'), which helps differentiate it from passive browsing or other actions. However, it does not explicitly distinguish itself from sibling tools like counter_offer, 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 gives a clear usage context: when the initial offer doesn't fit. It also hints at autonomous operation ('so your agent closes deals without supervision'), which guides expectations. It does not mention exclusions or specific alternatives, 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 provided, the description carries the full burden for behavioral transparency. It discloses that the tool signals the buyer, locks in the agent's commitment, and impacts completion rate/AgentRank. It lacks details like idempotency or permission requirements, but covers meaningful behavioral traits well.

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 action verb and resource. Every word adds value: the first sentence states the action, the second explains the behavioral effect and business rationale. No filler or 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), the description covers the essential aspects: what it does, when to use it, and its impact on metrics. It does not mention response format or error cases, but for a simple acknowledgment tool, the coverage is strong.

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 the single parameter (escrowId) with basic description ('Escrow ID'). The description adds semantic context by specifying the escrow must be funded, which is a prerequisite not visible in the schema. This enriches the parameter's meaning beyond the structured data.

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 with a specific verb ('Acknowledge') and resource ('work has begun on a funded escrow'). It also differentiates from sibling tools by explaining the signaling effect to the buyer and commitment locking, making its unique role evident.

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?

While there is no explicit 'when to use vs alternatives' statement, the description clearly implies the trigger: when work begins on a funded escrow. It provides context about the purpose and the importance for completion rate/AgentRank, but does not name alternative tools or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It adds behavioral context that 'agents that document well win more disputes and preserve their reputation,' which is useful. But it does not disclose important traits such as whether evidence can be updated or removed, authorization requirements, or what the response contains.

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

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

The description is two sentences and front-loaded with the main action. The second sentence adds motivational context about winning disputes and reputation, which is not strictly essential but not verbose. Overall, it is appropriately concise.

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 4-parameter submission tool with no output schema and no annotations, the description is acceptable but has gaps. It does not explain what happens after submission, any prerequisites like an existing dispute, or describe the 'disputeId' parameter. It gives enough for basic invocation but lacks richer context.

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 provides descriptions for 3 of 4 parameters, but 'disputeId' lacks a description. The description's phrase 'proof file + hash + URL' introduces a 'proof file' concept not present in the schema, which could confuse. It does not clarify the remaining parameter or add meaningful semantics 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 tool's purpose: 'Submit evidence (proof file + hash + URL) to support your position in a dispute.' The verb 'submit' and resource 'evidence' are specific. However, it does not differentiate from the sibling tool 'submit_proof', which may serve a similar function.

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

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

The description provides clear context: use this tool to support your position in a dispute. It states that 'stronger evidence accelerates resolution,' offering a rationale. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusionary 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 must convey behavioral traits. It discloses the purpose, verification by buyer, and reputation accrual, but omits potential failure modes (e.g., invalid hash, unreachable URI), irreversibility, or whether calling this consumes resources. It adds some context but leaves significant gaps for a payout-affecting 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?

Two sentences, directly front-loaded with the core purpose, followed by a concise rationale. Every word serves the explanation, 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 3-parameter submission tool with no output schema, the description covers main inputs, the outcome (unlock payment), and a secondary effect (reputation). It lacks details on failure handling or workflow integration, but it is adequate for an agent to know when and how to invoke this 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 coverage is 100%, so the baseline is 3. The description adds minimal value by rephrasing the parameters ('SHA-256 hash + HTTPS or IPFS URI') without deeper semantics like URI format constraints or the role of escrowId in identifying the escrow. It does not elevate understanding 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 tool's function: 'Submit cryptographic proof of delivery and unlock your payment.' It specifies the action (submit) and the resource (proof of delivery), and differentiates from siblings like zk_verify_proof or release_escrow by focusing on proof submission to release payment.

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 context: this tool is used to prove delivery and trigger payment in an escrow workflow. It explains the buyer's verification role and the reputation benefit, but does not explicitly exclude alternatives or mention when not to use it, stopping short of full guidance.

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

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It states the tool subscribes to events, but does not mention auth requirements (beyond the subscriberDid parameter), whether the subscription is persistent, delivery method (webhookUrl is optional but unexplained), or any side effects like replacing existing subscriptions. The description gives little beyond the basic function.

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 compact. However, the first sentence ('Catch earning opportunities the instant they appear') is promotional and adds no technical substance. The second sentence is informative, listing event types and the value proposition. It is concise overall, though the opening hook is not strictly necessary.

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 with 3 parameters and no output schema, so the description need not be extensive. However, it lacks key operational context: what happens if webhookUrl is omitted, whether the subscription is ongoing or one-time, and any prerequisites (e.g., a registered agent with a subscriberDid). The event list is partial and does not map to all enum values. It is adequate but has gaps for a subscription 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 does not add any additional parameter details beyond what the schema provides; it mentions some event types (intents, trust changes) but not all enums, and provides no syntax or format guidance. The schema is sufficient, and the description adds minimal value here.

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 action ('Subscribe to real-time events') and specifies the resource (events across the agent ecosystem). It lists concrete event types (new intents, trust score changes, agents online, escrows updating), distinguishing it from sibling tools like 'broadcast_intent' or 'browse_intents' which focus on one-time 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?

The description conveys a clear use case: 'your agent reacts in seconds, not minutes,' implying this is for real-time responsiveness. It provides context (catching earning opportunities, reacting to ecosystem changes) but does not explicitly state when not to use it or name alternatives. Still, the guidance is sufficient for selecting this tool over polling or manual checks.

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 of behavioral disclosure. It adds meaningful context about the cryptographic mechanism (SHA-256) and the confidentiality guarantee (no IP leakage), but it does not disclose operational details such as side effects, persistence, or success/failure responses.

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 long, front-loaded with the core value proposition, and uses no filler. The second sentence reinforces practical use cases without digressing, 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?

The description explains the purpose and use case well, but lacks operational context such as what the commit operation returns or how it integrates with sibling tools like zk_verify_proof. Since there is no output schema, this missing information is a noticeable gap for an otherwise well-scoped 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 parameters are fully documented in the schema. The description adds no additional parameter-level semantics beyond what the schema already provides, so the 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 'Prove' with the resource 'deliverable', and mentions 'SHA-256 commitment' to convey the act of committing. However, it does not explicitly differentiate itself from the sibling tool zk_verify_proof, though the name 'zk_commit_proof' helps clarify the distinction.

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 by stating 'Critical for confidential work' and giving examples like legal docs and trading signals. It does not explicitly name alternatives or exclusions, but the context alone is sufficient to infer 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 the burden of behavioral disclosure. It explains that verification is cryptographic and trustless, which is useful, but it does not disclose what happens on failure, whether there are side effects, or what the return/result looks like.

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 immediately front-loads the core action. The second sentence adds motivational context without padding, making it concise and easy to scan.

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

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

For a simple two-parameter tool, the description conveys the essential purpose but is missing key context: there is no output schema, and the description does not indicate what a successful or failed verification returns or how the result is presented. This leaves the agent guessing about response semantics.

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 covers 100% of parameters, so the baseline is 3. The description adds minimal parameter-specific meaning: 'committed specification' loosely relates to the revealedHash, but does not clarify the roles of proofId and revealedHash beyond their 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 the tool's function: 'Cryptographically verify a zero-knowledge proof.' It also differentiates the tool from its sibling zk_commit_proof by emphasizing verification rather than creation, and ties it to the seller/deliverable context.

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: after a seller provides a deliverable, to confirm it matches a committed specification without trusting the seller. It gives clear context but does not explicitly state when not to use it or name alternative tools.

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