Synmerco

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

With no annotations, the description discloses key behavioral traits: graph-based computation, transitive trust, resistance to Sybil attacks, and free/no auth. It does not specify error handling or latency, but for a simple lookup this is acceptable.

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

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

The description is three concise sentences that front-load purpose, differentiate from alternatives, and state value. Every sentence adds value; 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?

Given the tool's simplicity, the description covers core purpose and differentiation, but it omits details about the output format (e.g., score range or structure) since there is no output schema. It is adequate but could be more 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% for the single parameter 'did', and the description does not add additional semantics beyond the schema's existing description. 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 it is a graph-based reputation lookup for any agent, contrasting with SynmercoScore. However, it does not explicitly differentiate from sibling trust tools like lookup_trust_score or federated_reputation, leaving room for ambiguity.

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 transitive trust measurement and mentions being free/no auth, but lacks explicit when-to-use vs alternatives or exclusion criteria. It relies on implicit context rather than direct 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 provided, so description carries full burden. It discloses auto-matching, notification, and escrow creation, but omits side effects (e.g., whether repeated broadcasts create duplicates), permissions required, or idempotency. For a creation tool, this is insufficient.

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?

Very concise: three sentences that front-load the core purpose, supported by a concrete example of workflow. Every sentence adds value with no redundancy.

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

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

Despite good purpose clarity, the description lacks output semantics (e.g., returns intent ID), lifecycle information (e.g., how to track the broadcast), and interaction with siblings like 'browse_intents'. With no output schema and 7 parameters, it is incomplete for an agent to fully understand the tool's behavior.

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

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

Schema description coverage is 100%, providing baseline meaning. The tool description does not repeat parameter details (good) but also does not add new context beyond what the schema offers, such as explaining the interplay between 'minTier' and 'minTrustScore'.

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 broadcasts a need and auto-matches agents, with a specific verb 'Broadcast' and resource 'intent'. It differentiates from siblings like 'post_job' by emphasizing automated matching and marketplace orchestration, though not explicitly naming 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?

No explicit guidance on when to use this tool versus alternatives like 'post_job' or 'browse_intents'. The description implies a set-and-forget pattern but does not state when-not-to-use or provide context for choosing among 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?

No annotations provided, and the description lacks behavioral details such as side effects, authorization needs, or return format. It implies a read-only search but doesn't confirm.

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 with clear front-loading of purpose. The third sentence is slightly motivational but not excessive.

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

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

Given no output schema and simple parameters, the description covers purpose and filtering. Missing mention of the limit parameter and result format, but adequate for basic 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 coverage is 100%, and the description adds value for 'capability' by explaining its purpose. However, 'limit' is not mentioned beyond what's in the schema.

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

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

The description clearly states the tool finds paid work matching agent capabilities, with a specific verb ('find') and resource ('intents'). It distinguishes from siblings like broadcast_intent, but doesn't explicitly differentiate.

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?

Implied usage is to surface jobs by capability keyword. No explicit when-to-use or when-not-to-use, but the context is clear for agents seeking work.

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 provided, so description carries the burden. It discloses it's free and requires no auth, but doesn't mention side effects, error handling for non-existent DIDs, or that it's a read-only 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, front-loaded with action and purpose. First sentence clearly states the tool's function. Second sentence lists attributes and adds cost/auth info. 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?

The description lists the returned data fields (trust scores, etc.), which is helpful without an output schema. However, it doesn't specify the output structure or format, which would be useful for a comparison 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% with parameter descriptions already explaining DIDs. The description adds context that the DIDs are for agents to compare, but no additional 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 compares two agents side-by-side, listing specific attributes like trust scores and dispute rates. It distinguishes from sibling tools like agent_rank_lookup (single rank) and search_agents (search 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 says 'before picking one,' indicating when to use: when deciding between two agents. It also mentions 'Free, no auth required.' It doesn't explicitly exclude alternatives, but the purpose 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?

Describes submission behavior and platform enforcement of limits, but lacks details on authentication, idempotency, or what happens on success. No annotations provided.

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 tight sentences: first states purpose, second adds behavioral context. No unnecessary words.

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

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

Adequately covers purpose and safety for a simple tool with two params and no output schema. Could mention what happens after submission (e.g., next steps).

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 described, negotiationId not). Description does not add parameter details beyond schema, leaving negotiationId unexplained.

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

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

Clearly states 'Submit a counter-offer in an active negotiation' with a specific verb and resource, and distinguishes from siblings like start_negotiation and send_message by mentioning negotiation termination behavior.

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?

Implies the tool is for active negotiations and assures clean termination, but does not explicitly state when to use versus alternatives (e.g., accept offer, start negotiation) or prerequisites.

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

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

With no annotations, the description must disclose behavioral traits. It mentions trust guarantees but omits important details like prerequisites (e.g., existing wallet), failure modes, or what the return value is. The description focuses on benefits rather than behavioral specifics.

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 three sentences, front-loading the main action. No unnecessary words, but it could be slightly more structured with explicit outcome details.

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 6 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on what the tool returns (e.g., escrow ID), prerequisites, and step-by-step workflow, leaving gaps for an AI agent to use 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?

All parameters have descriptions in the input schema (100% coverage). The tool description adds no additional meaning to parameters beyond the schema, so 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 purpose: locking funds in escrow until work verification. It differentiates from siblings like fund_escrow, release_escrow, and get_escrow by focusing on creation and trust guarantees.

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 (i.e., when needing to lock funds for a job) but provides no explicit guidance on when not to use or mentions alternatives. It lacks usage context beyond the general 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 provided, the description must fully disclose behavioral traits. It states the wallet creation and its capabilities but does not reveal potential side effects (e.g., overwriting an existing wallet), required permissions, error scenarios, or whether the operation is idempotent. This lack of detail could lead to misuse by the agent.

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 exceptionally concise, consisting of two sentences that immediately state the purpose and benefits. Every word serves a purpose, with no redundancy or filler. It is well-structured and front-loaded with the core action.

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

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

Given the absence of parameters and output schema, the description provides a solid overview of what the tool accomplishes and why it is useful. However, it does not mention what the tool returns (e.g., wallet address, status) or whether it can be called multiple times. A mention of the return value would improve completeness.

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

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

The tool has zero parameters, so the schema covers 100% of parameter information trivially. The description does not need to add parameter details. Per calibration guidelines, a baseline of 4 is appropriate for tools with no parameters, as the description adds no further parameter-related value.

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

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

The description clearly states the tool creates an agent's wallet and enumerates its use cases (hold balances, fund escrows, receive payouts). It also highlights the wallet's universality across chains and protocols. However, it does not explicitly differentiate from sibling tools like deposit_wallet or get_wallet_balance, which could clarify when to use this tool over others.

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

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

The description implies that creating a wallet is a prerequisite for using escrows and receiving payouts, but it does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, and there is no discussion of prerequisites or conditions such as whether a wallet already exists.

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: each task creates its own escrow that auto-unlocks when predecessors complete, and tasks are chained. This goes beyond a simple creation description.

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

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

The description is front-loaded with the core purpose and is concise at two sentences plus an analogy. The metaphor adds value but could be shortened. Every sentence contributes meaning.

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

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

For a complex tool with 4 parameters and no output schema, the description explains the high-level pipeline concept and auto-unlock behavior. However, it does not specify the return value (e.g., workflow ID) or mention prerequisites, errors, or additional behavioral context like handling of dependencies outside of the schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds the concept of chained escrows and auto-unlock, but does not explain individual parameters beyond the schema. It provides overall context but limited parameter-specific semantics.

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: composing multi-agent pipelines with chained escrows. It uses a strong verb ('compose', 'define') and specifies the resource (workflows with tasks and dependencies). The Unix pipes analogy effectively distinguishes it from sibling tools like create_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 usage for orchestrating multiple agents with dependencies through the analogy 'Hire 5 agents to do what 1 agent can't.' It contrasts with single-escrow tools but does not explicitly state when not to use it or provide alternative tools, though the context is sufficient for most agents.

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

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

The description discloses that a URL is returned for the buyer to visit or hand to an operator, hinting at human involvement. However, it does not address potential issues like URL expiration, payment failures, or processing time, leaving 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?

Three concise sentences covering action, output, and benefit. No fluff, front-loaded with key information.

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

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

The description covers input, output, and high-level purpose well. Lacks details on URL expiration or payment lifecycle, but overall sufficient for a simple tool with no output schema.

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

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

Schema coverage is 100% with a clear parameter description. The description adds no extra semantic detail beyond the schema, only contextualizing it as a Stripe checkout amount. 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 deposits money into an agent wallet via Stripe checkout and returns a URL. It distinguishes itself from siblings like get_wallet_balance and fund_escrow by specifying the platform (Stripe) and the action (top up wallet).

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

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

The description implies usage when the agent needs fiat funds, but lacks explicit when-not-to-use guidance or alternatives among siblings. No mention of when to use get_wallet_balance or create_wallet instead.

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 states 'Free, no auth required,' which is helpful, but it does not explicitly confirm read-only behavior or mention side effects. The word 'shows' implies it returns information without modification, but this is indirect.

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: the first sets context ('know exactly before you commit'), the second lists specific fee components. No unnecessary words, perfectly front-loaded.

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

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

The tool has one parameter and no output schema. The description lists the fee components (3.25% platform fee, $1K Shield insurance, 0.25% referral split, net amount), which gives the agent a clear idea of what will be returned. It doesn't specify the exact output format, but the listed components are sufficient for an agent to understand the tool's purpose.

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 fully describes the parameter amountCents with a clear description. The description adds context about what the fee breakdown includes, but does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate given 100% 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 estimates fees for a transaction, listing specific components (platform fee, insurance, referral split, net amount). It distinguishes itself from sibling tools like create_escrow or fund_escrow by focusing on pre-commitment estimation.

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

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

The description says 'before you commit' which implies use prior to finalizing a transaction, but it does not explicitly name alternatives or state when not to use this tool. Context from sibling names suggests it's for estimation, but no direct comparison.

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 explains the mechanism ('aggregates trust signals from external platforms') and implies a read-only nature, but does not explicitly state whether it is read-only, destructive, or what side effects may occur. It provides moderate behavioral context.

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

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

The description is four sentences, front-loaded with the main purpose, and each sentence adds value. It is concise and well-structured without redundancy.

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

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

For a simple tool with one parameter and no output schema, the description explains the core functionality and data source. However, it lacks description of the output format or whether a score, report, or other data is returned, which leaves some incompleteness.

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 description coverage is 100% for the single parameter 'did', which is already described in the schema. The tool description adds no additional meaning beyond the schema, so it meets 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 clearly states that the tool provides 'Cross-platform reputation for any agent' by aggregating trust signals from external platforms. It is specific about the data source (Synmerco's federated layer), but does not differentiate from the sibling tool 'lookup_trust_score' which may serve a similar purpose for internal trust.

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

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

The description implies usage when needing reputation from external platforms ('Trust agents from outside your silo'), but offers no explicit guidance on when not to use or alternatives like 'lookup_trust_score'. The context is clear but lacks exclusion criteria.

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

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

With no annotations, the description carries full burden. It discloses that funding deducts from the agent wallet, notifies the seller, and integrates multiple payment rails. However, it does not clarify error conditions, refund policies, or whether the action is idempotent, leaving some 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?

The description is three sentences with no filler. The core action is stated first, followed by the consequence and the integration detail. Every sentence adds value, making it efficient 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?

Given the tool has one parameter and no output schema, the description covers purpose, effect, and payment options. However, it omits information about the return value (e.g., transaction ID) and potential errors. For a funding action in a payment system, this is a moderate gap.

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

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

The input schema has 100% description coverage with the one parameter 'escrowId' described as 'Escrow ID'. The tool description adds context about the wallet and payment rails but does not enhance the meaning of the parameter beyond what the schema provides, so baseline 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 funds an escrow from the agent wallet, specifying the verb 'fund', the resource 'escrow', and the context 'commit the buyer side'. It differentiates from sibling tools like 'create_escrow' and 'release_escrow' by describing the specific action and its effect.

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 context that funding is a buyer-side commitment and triggers seller notification, but does not explicitly state when to use this tool versus alternatives such as 'counter_offer' or 'start_work'. There is no mention of prerequisites like having created the escrow first, though it is implied.

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

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

No annotations provided, so description carries full burden. Mentions translation of call, signature, and payment, providing some behavioral insight. Lacks details on error handling, side effects, or authentication requirements, which are important for a bridging 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?

Four sentences, front-loaded with the core concept, each sentence adds value without fluff. Efficient 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 5-parameter tool with no output schema, description explains the purpose but omits return format, error indications, and prerequisites like authentication. Lacks completeness for a reliable invocation.

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

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

Schema coverage is 100% with clear parameter descriptions. Description adds minimal extra meaning beyond schema, e.g., example protocol mapping. Baseline of 3 is appropriate as schema already does heavy lifting.

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

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

Clearly states the tool translates messages between protocols, distinguishing it from siblings like send_message which are likely MCP-only. Uses specific verb 'bridge' and 'translate' and describes resource: messages across protocols.

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?

Implies usage when target agent uses a different protocol; says 'Reach agents outside this ecosystem without rewriting your agent.' Does not explicitly name alternatives or state when not to use, but context from siblings suggests this is for cross-protocol communication.

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 provided, so description bears full burden. It discloses that the tool is free, requires no authentication, and returns chain health, RPC latency, and recent settlement times. This fully informs the agent of behavioral traits.

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 two sentences, front-loading the purpose and usage context. Every word adds value; 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?

For a simple tool with one parameter and no output schema, the description covers purpose, usage context, output nature, and cost/auth. It is fully complete for an agent to decide when and how to invoke.

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 one enum parameter 'chain'. The description adds context for why to check multiple chains (fastest rail), but does not add meaning beyond the schema for the parameter itself. Baseline 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's purpose: 'Check crypto payment infrastructure status before initiating high-value transfers.' It uniquely identifies the tool as a health checker for crypto rails, distinct from sibling tools which are about agents, escrows, marketplaces, etc.

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: 'before initiating high-value transfers' and 'so your agent picks the fastest rail.' It implies the use case but does not explicitly state when not to use or list 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 must carry the full burden of behavioral disclosure. It explains what the tool returns (tier, evidence, timeline), which adds value beyond the name. However, it does not state that it is a read-only operation (no side effects), nor does it mention authentication requirements, rate limits, or error conditions.

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. Every sentence adds necessary information: what the tool does and what details it returns. No extraneous content.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the main return values (tier, evidence, timeline). It lacks mention of error handling or existence prerequisites, but is largely sufficient for an agent to understand the tool's function.

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 0% description coverage, meaning no parameter descriptions exist. The tool's description does not mention the single parameter 'disputeId' or provide additional meaning beyond the schema (type, length constraints). For a low-coverage scenario, the description should compensate but fails to do so.

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 live dispute status and resolution progress.' It uses a specific verb ('Get') and a clear resource ('dispute status and resolution progress'). It also distinguishes itself from sibling tools 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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the dispute must exist) or scenarios where other tools like 'get_escrow' might be more appropriate. The agent is left to infer 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 indicates a read-only operation ('Pull the live status') and lists returned data, but does not disclose authentication requirements, rate limits, or consequences of incorrect usage. It adds some context beyond the name.

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

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

Two sentences, tightly focused. The first sentence states the core purpose, and the second lists key outputs. No extraneous information.

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

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

For a simple read tool with one parameter and no output schema, the description is fairly complete. It covers what the tool does, what data it returns, and the context of use. Minor gaps: no error handling or rate limits, but not essential for a straightforward get operation.

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

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

Schema coverage is 100% for the single parameter 'escrowId'. The description does not add any new information about the parameter itself beyond what the schema provides (just 'Escrow ID'). The baseline score 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 retrieves live escrow status and enumerates specific data fields (state, amounts, proof details, timeline). It distinguishes itself through context but does not explicitly differentiate from sibling tools like fund_escrow or release_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 this tool is for checking escrow status without polling multiple endpoints, providing a use case. However, it lacks explicit guidance on when not to use it (e.g., for creation or funding) and does not mention 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 exist, so the description carries the burden. It describes the output but does not disclose permissions, rate limits, or side effects. For a read-only resolution tool, this is adequate but not thorough.

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 extremely concise with two sentences, the first stating the core functionality and the second providing usage guidance. No unnecessary words.

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

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

Given the single parameter (fully documented in schema), the description sufficiently explains the tool's purpose and output. No output schema exists, but the description covers what the tool returns. 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 input schema already describes the parameter 'did' with format and constraints. The description adds context by explaining what the tool does with that DID and provides an example format, enriching the semantic understanding.

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

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

The description explicitly states the action 'Resolve a DID' and the resource 'full identity details', listing specific components (profile, protocols, registry entries, public keys). It clearly distinguishes from sibling tools by focusing on identity resolution.

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 guidance on when to use the tool: 'to verify any agent you're about to transact with'. It also mentions cross-platform usage. However, it does not explicitly mention when not to use it or suggest alternative tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only specifies the types of messages and implies read-only behavior. It does not mention pagination, message ordering, or whether it returns all messages or only unread ones, which are important for correct usage.

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 two sentences; the first clearly states the purpose. The second sentence, while motivational, does not add functional value but is not overly verbose. It could be tighter but is acceptable.

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 simple nature of the tool (one parameter, no output schema), the description covers the basic purpose and message types. However, it lacks details on what the response contains, such as message structure or count, leaving some ambiguity for the 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 already provides a description for the 'did' parameter ('Decentralized Identifier'), achieving 100% coverage. The tool description adds no additional context about the parameter, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool checks the inbox for specific types of messages (hire requests, job invitations, counter-offers, dispute notices) using the verb 'check' and resource 'inbox', making the purpose precise and unambiguous. It distinguishes itself from sibling tools like 'send_message' by focusing on reading incoming messages.

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 guidance is provided on when to use this tool versus alternatives (e.g., when to check inbox vs. search messages). There is no mention of prerequisites, limitations, or exclusions, leaving the agent to infer 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?

No annotations are provided, so the description must cover behavioral traits. It adds that the call is 'Free, no auth required,' disclosing access constraints. However, it doesn't mention rate limits or data freshness, which would be beneficial. Overall, adequate transparency for a read-only info 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 extremely concise, consisting of two clear sentences. Every piece of information earns its place, with no redundancy or fluff.

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

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

Given zero parameters, no output schema, and low complexity, the description is fully complete. It explains what the tool returns, its use case, and access requirements. No gaps remain for an AI agent to invoke the tool correctly.

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

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

The tool has zero parameters, and schema coverage is 100% (empty schema). With no params to document, the description doesn't need to add param semantics. The baseline score for zero parameters is 4, and no additional value is required.

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

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

The description clearly states it retrieves the comprehensive Synmerco surface including chains, fees, tools, and protocols. It uses the verb 'Get' with specific resources, effectively distinguishing it from sibling tools that focus on individual 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 explicitly says 'Use this to teach your agent what Synmerco can do,' providing a clear usage context. While it doesn't mention when not to use it or alternatives, the context is clear enough for an AI agent to understand its purpose for discovery.

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 provided, so description bears full behavioral burden. It indicates a read-only operation (check) and mentions passive accrual, which is helpful. It lacks specifics like authorization but is adequate for a simple query.

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, concise and front-loaded with the action. Every word adds value, 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's simplicity (one parameter, no output schema), the description is fully complete. It tells what it does, why use it, and the implied return value.

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% for the single parameter 'did'. The description does not add meaning beyond the schema, as it does not explain the parameter's role in context. 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 that the tool checks accumulated referral earnings, using specific verb 'Check' and resource 'referral earnings'. It distinguishes from siblings like register_referral by focusing on querying existing earnings.

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 (to see passive income from referrals) and is self-explanatory. However, it does not explicitly mention when not to use or provide alternatives, though the context 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 provided, so description carries full burden. It discloses what it shows (fiat and crypto balances) but does not mention permissions, side effects, or limitations. 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?

Three concise sentences, front-loaded with purpose, no unnecessary words. Every sentence earns its place.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, usage context, and what data it shows. Could elaborate on return format but sufficient overall.

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 description for the did parameter. The tool description adds no additional meaning beyond the schema, meeting 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 checks wallet balance and recent transactions. It distinguishes from sibling tools like create_wallet and deposit_wallet by specifying it's for checking, not modifying.

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 use cases: before funding escrows and verifying payouts. Lacks explicit exclusions or alternatives, but the context is clear enough for selection.

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

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

No annotations provided, so the description bears full responsibility. It discloses the tool is read-only ('get live status') and lists output components, which is transparent for a non-destructive 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, each earning its place: first sentence states purpose, second adds actionable value (bottleneck identification). No superfluous content.

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

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

For a simple one-parameter read tool, the description adequately conveys what the tool does and what it returns (tasks, escrows, dependencies). No output schema exists, but the description hints at return structure.

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 one parameter described as 'Workflow ID'. The description does not add additional semantic meaning beyond the schema, so 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 retrieves live workflow status, listing specific elements (tasks, escrows, dependencies) and identifies bottlenecks. This distinguishes it from sibling tools like create_workflow or get_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 usage for checking workflow progress and identifying bottlenecks to reroute or top up budgets. However, it lacks explicit when-not-to-use or alternative tools, though the context 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?

With no annotations, the description should disclose behavioral traits. It focuses on benefits ('passive income', 'earn while they sleep') rather than operational details like whether listings are mutable, idempotent, or what side effects occur. Essential behavioral context is missing.

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 overly verbose with marketing language ('Your agent earns... passive income that runs 24/7'). It could be reduced to a single function-focused sentence. Not 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?

Given 5 parameters, no output schema, and no annotations, the description should provide more context about the listing lifecycle, prerequisites, or what happens after listing. It fails to cover these aspects, leaving the agent underinformed.

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

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

Schema description coverage is 100% with each parameter having a description. The tool description adds no further meaning beyond the schema, which is adequate but not enhanced. 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 'List a service' indicating the verb and resource, and explains the purpose is for buyers to find and hire agents. However, it does not differentiate from sibling tools like 'marketplace_post_listing' which may have overlapping functionality.

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 explicit guidance on when to use this tool versus alternatives such as 'marketplace_post_listing'. The description implies use for listing a service but fails to mention any exclusions or context for 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 provided, so description carries full burden. It discloses key behaviors: 'Free, no auth required.' and describes the return output (trust score, reputation tier, etc.). Lacks details like rate limits or error handling, but the 'Free, no auth' is a strong behavioral signal.

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 packed with value: the first states the use case and output, the second clarifies cross-ecosystem reach and adds 'Free, no auth required.' 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?

Tool has one parameter and no output schema. The description covers all necessary information: purpose, input, output, and access conditions. Complete 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?

Schema coverage is 100% with one parameter 'did' already described as 'Decentralized Identifier (e.g. did:key:z...)'. The description does not add extra meaning beyond the schema, so 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?

Clearly states the tool's purpose: 'Vet any AI agent before transacting. Returns trust score, reputation tier, transaction history, and on-chain verification across 4 chains.' This specific verb+resource combination distinguishes it from siblings like federated_reputation or resolve_agent 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?

Explicitly states when to use: 'Vet any AI agent before transacting.' Also clarifies scope: 'Works for agents inside Synmerco AND agents discovered from outside ecosystems.' While it doesn't explicitly say when not to use, the directive is strong and covers broad applicability.

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 provided, so description carries full burden. It discloses read-only nature, free access, and no auth needed. However, it lacks details about response format, pagination, or any side effects. 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?

Two sentences, front-loaded with purpose, followed by benefit. Every sentence adds value. 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?

Given no output schema and simple nature, description explains purpose but does not specify return structure (e.g., list of categories with counts). Could be more complete about expected output.

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?

Tool has zero parameters, so baseline is 4. The description adds meaning by stating it explores categories, which is sufficient for a parameterless tool. No schema info needed.

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

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

The description clearly states the verb 'Explore' and the resource 'Build Hub categories', and explains the purpose: to see market hotness and supply/demand via listing counts. It is distinct from siblings like marketplace_search which searches specific 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 implies usage for initial market exploration, mentioning 'Free, no auth required'. However, it does not explicitly compare to alternatives like marketplace_search or provide when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the burden. It clarifies this is a read operation ('Get'), lists the data returned, and states no authentication is needed. It does not disclose error handling or rate limits, but for a simple read tool this is sufficient.

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

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

The description is two sentences long, front-loading the core purpose in the first sentence. It efficiently lists key data fields and the use case without extraneous details.

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 purpose, specific data fields, free usage, and no authentication requirement. It gives sufficient context for an agent to decide when 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 the single parameter 'id', describing it as 'Listing UUID'. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline for full 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?

Description clearly states the tool retrieves the full record of a Build Hub listing and lists specific data fields like pricing, protocols, and trust signals. It distinguishes itself from siblings (marketplace_search, marketplace_post_listing, marketplace_categories) by focusing on a single listing's detailed record.

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 an agent has a listing ID and needs complete details to decide on hiring. It mentions 'Free, no auth required' but does not explicitly contrast with alternative tools like marketplace_search or state 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 provided, so description carries full burden. Only mentions permanence ('appears forever'), but omits side effects, auth requirements, rate limits, or update semantics.

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 wasted words. Front-loaded with purpose, followed by key details.

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?

Lacks explanation of return values (e.g., listing ID) and prerequisites. For a complex tool with 10 parameters and no output schema, description is insufficient.

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 parameters, baseline 3. Description adds value by explaining pricing models and protocols, providing useful context beyond schema enum labels.

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

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

Clearly states the action ('post a listing') and the resource ('marketplace listing'). Distinguishes from sibling tools like marketplace_search and marketplace_get_listing by focusing on 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?

Implies usage for creating a listing to gain discoverability. Lacks explicit when-not-to-use or alternatives, but context is sufficient given sibling tool names.

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

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

No annotations provided, so description bears full burden. It discloses 'Free, no auth required,' which is helpful, but does not mention read-only nature, pagination, or side effects. Adequate but not comprehensive.

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

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

Three concise, front-loaded sentences. Each sentence adds value: purpose, value proposition, and key features (filtering, free, no auth). 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?

Given simple functionality (search with optional params, no output schema), the description is mostly complete. It covers purpose, filtration, free/auth. Lacks explicit mention of return format but is adequate for agent decision-making.

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% for all three parameters, so baseline is 3. Description adds minimal extra meaning beyond the schema, stating parameters are used for filtering but no additional 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?

Description clearly states the tool browses the Build Hub for tools, APIs, and services, with filtering by category and query. The verb 'Browse' and resource 'Build Hub' are specific, and it distinguishes from siblings like marketplace_categories and marketplace_get_listing.

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

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

Description implies usage for searching or browsing listings but does not explicitly state when to use alternatives like marketplace_categories or marketplace_get_listing. It provides clear context but lacks exclusion 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 full burden. It mentions filtering and bidding but lacks details on post-posting behavior, cancellation, or what happens after submitting. The phrase 'Your agent knows the what — hire the how' is vague and does not contribute meaningful behavioral transparency.

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

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

The description is two sentences long with clear phrasing. The second sentence includes a slightly non-essential phrase ('Your agent knows the what — hire the how'), but overall it is efficient and front-loaded with the core purpose.

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

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

With 5 parameters (4 required), no output schema, and a complex bidding process, the description lacks details on return values, bidding mechanics, and post-posting workflow. It is insufficient for an agent to fully understand the tool's expected behavior.

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

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

Schema description coverage is 100%, so parameters are documented in schema. The description adds context about trust score filtering (mapping to 'minTrustScore' parameter) but does not elaborate on other parameters beyond 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 clearly states 'Post a job and let qualified agents bid,' specifying the verb and resource. It provides context about filtering by capability, trust score, and availability. However, it does not explicitly differentiate from sibling tools like 'marketplace_post_listing' or 'broadcast_intent', so sibling differentiation is missing.

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 hiring agents with bidding and mentions compatibility with both internal and bridge agents. It does not provide explicit when-not-to-use guidance or name alternative tools, leaving usage context implied rather than explicit.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure. It explains that the tool performs analysis and predicts success probability without locking funds. However, it does not specify whether the tool is read-only, latency expectations, or authentication needs.

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, front-loaded with the imperative 'Run a credit check', and every sentence contributes meaningful information. 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?

The description covers the core functionality well, but lacks details on the output format (e.g., probability score, scale) and edge cases. Given no output schema, a slightly richer description of return values would improve completeness.

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

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

Schema coverage is 100% with both parameters described adequately as DIDs. The description adds context that both agents' completion rates are analyzed, but does not significantly enhance meaning 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 clearly states the tool's purpose: 'Run a credit check before committing money' and 'Predicts the success probability of an escrow before you create it'. It distinguishes from sibling tools like create_escrow by emphasizing the predictive pre-funding nature.

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 guides when to use: 'before committing money' and 'before you create it'. It implies alternatives by mentioning skipping bad deals, but does not explicitly name alternatives like agent_rank_lookup or compare_agents.

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

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

With no annotations, the description discloses key behavioral traits: funds stay locked until resolved, and neither party can drain the escrow without platform backing. It also mentions the 3-tier resolution process. This adds value beyond the schema, though it omits potential side effects or authorization 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 exceptionally concise, consisting of just two sentences that front-load the purpose and key behavioral information. Every sentence adds value without unnecessary 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 four required parameters and no output schema, the description explains the outcome (funds locked, resolution process) but does not mention what the tool returns or confirmation of success. It is mostly complete but could be slightly improved.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description does not add additional meaning to individual parameters (e.g., what constitutes a valid 'reason') beyond what the schema provides. 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 purpose: 'Raise a dispute when an escrow goes wrong.' It distinguishes from sibling tools like 'get_dispute' (querying a dispute) and 'release_escrow' (releasing funds) by focusing on initiating the dispute process.

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 specifies the condition for use ('when an escrow goes wrong'), providing clear context. However, it does not directly state when not to use or name alternatives, though the context implicitly differentiates from related tools.

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

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

No annotations are provided, so the description bears the full burden. It discloses that skipping means no search results and that registration is required before certain actions. However, it does not explain potential idempotency (e.g., what happens if already registered) or any side effects, such as whether it creates a new record or updates an existing one.

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 exceptionally concise: three short sentences with no filler. It front-loads the core benefit ('Make your agent discoverable') and efficiently conveys prerequisites and consequences.

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

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

The tool has no output schema, so the description should ideally mention the return value or confirmation of registration. It only implies success by stating the result of skipping, but does not describe what the agent receives after registration. For a simple registration tool, this is adequate but leaves a gap.

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

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

Schema coverage is 100%, and the schema already provides adequate descriptions for all three parameters (displayName, description, capabilities). The main description adds no extra parameter-specific guidance beyond the schema, so it meets 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 uses a specific verb ('make discoverable') and resource ('agent'), and clearly distinguishes from siblings by emphasizing search visibility and prerequisite nature for listing services. It effectively differentiates the tool's purpose from other marketplace 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 states when to use this tool: 'before listing services or earning passive income from incoming hire requests.' It also explains the consequence of skipping (agents never appear in search). However, it does not mention when not to use or provide direct 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 should fully disclose behavioral traits. It mentions immediate return and no KYC, but fails to address persistence, revocation, rate limits, or side effects, leaving significant 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 front-loaded with a compelling hook and efficiently conveys the key points in a few sentences. Minor verbosity is acceptable given the clarity gained.

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 registration tool with 2 parameters and no output schema, the description provides adequate context but omits details like key lifecycle, reuse, or integration with sibling tools.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context about no signup/KYC, slightly enriching ownerDid's meaning, but does not exceed baseline expectations.

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

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

The description clearly states the tool returns an API key to enable agent activities like posting jobs and earning income. It distinguishes from siblings like register_agent by focusing on key registration, though explicit differentiation is absent.

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 a prerequisite for many operations (post jobs, list services), but gives no explicit when-not-to-use or alternatives. Usage context is suggested but not exhaustive.

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, and the description lacks disclosure of behavioral traits such as authorization needs, reversibility, or limitations. The marketing tone ('forever', 'most leveraged') does not convey technical 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 relatively short (3 sentences) and front-loaded with a benefit statement. However, the final sentence ('The most leveraged tool in this toolkit.') is somewhat unnecessary and verbose.

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 registration tool with one parameter and no output schema, the description covers the purpose and earning model adequately. Missing details about response or verification, but acceptable for this complexity.

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

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

Schema coverage is 100% and the parameter's schema description clearly explains the DID field. The tool description adds no additional meaning beyond the schema, resulting in a baseline score 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 clearly states the tool registers a referrer to earn passive income. It uses a specific verb ('register') and resource ('referrer'), and distinguishes itself from sibling tools like get_referral_earnings.

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 earning passive income by referring agents but does not explicitly state when to use or not use this tool, nor mention alternatives. Guidance is implied rather than explicit.

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

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

Discloses multiple behavioral insights: triggers automatic payout across three channels, records on-chain across four chains, updates reputation scores. No annotations provided, so description carries full burden and does 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?

Two sentences with no wasted words. First sentence provides core action and condition. Second sentence adds motivational context but remains 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?

Adequately covers the tool's behavior despite lack of output schema and annotations. Could mention prerequisites like escrow state, but not critical.

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 escrowId described as 'Escrow ID'. Description adds no further meaning about the parameter, so 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?

Clearly states the action 'Release escrow funds to the seller' with a specific condition 'after reviewing proof'. Distinguishes from siblings like create_escrow, fund_escrow, and raise_dispute.

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?

Implies use after reviewing proof but lacks explicit when-not-to-use or alternatives. For example, does not mention raise_dispute or submit_proof as alternatives if proof is insufficient.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that it returns multiple data categories in one call and works across agent domains, but does not detail error handling, authentication needs, or potential side effects. The behavioral claims are clear but 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?

The description is two sentences, front-loading the core functionality. While the first sentence is somewhat lengthy listing many items, it remains readable and avoids unnecessary words. Minor improvements could include breaking into bullet points 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?

For a single-parameter tool with no output schema, the description provides a good overview of the returned data (profile, trust scores, listings, etc.) and the scope (both internal and external agents). It lacks details on pagination, limits, or error responses, but is adequate for the tool's purpose.

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 well-described 'did' parameter including pattern and length constraints. The description adds no additional semantic value beyond what the schema provides (e.g., it does not elaborate on the DID format or provide domain-specific usage hints). 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 ('resolve') and resource ('agent'), clearly stating it returns a comprehensive set of agent information including profile, trust scores, listings, etc. It distinguishes itself from siblings by emphasizing it provides a unified view for both internal and external agents.

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

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

The description implies usage when a complete agent overview is needed ('the bridge to a unified view'), but does not explicitly state when to use alternatives or specify situations where this tool should not be used. Sibling tools like agent_rank_lookup or get_identity are not mentioned, leaving the agent to infer the distinction.

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?

Discloses 'Free, no auth required', which is useful since annotations are absent. However, it does not mention read-only nature, pagination, rate limits, or what the response contains, leaving 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?

The description is short with the core purpose upfront, but the third sentence ('Your agent knows...') is marketing and could be omitted without loss.

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

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

Given no output schema, the description fails to explain what the tool returns (e.g., list of agent profiles). This is a significant omission for an agent to use the results effectively.

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

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

Schema coverage is 100%, so baseline is 3. The description paraphrases the parameter meanings (minimum trust score, capability, online status) but adds no new semantic 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 clearly states the tool finds agents and specifies the filters (capability, trust score, online status). It implicitly distinguishes from siblings like marketplace_search by focusing on agent capabilities, and the marketing line contrasts 'what' vs 'how'.

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 suggests using when your agent lacks capability ('can't'), but does not explicitly state when not to use or name alternatives among the many sibling tools like agent_rank_lookup or compare_agents.

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, so description must disclose behavior. It explains semantic matching mechanics and cross-vocabulary capability, but lacks info on side effects, auth needs, or result structure. Adequate but not thorough.

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, well-structured sentences. The core concept is front-loaded with a clear example. No extraneous information.

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

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

No output schema provided and the description omits what the tool returns (e.g., list of agents, relevance scores). This gap makes the tool harder to use correctly without prior knowledge.

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 already covers both parameters with descriptions. The tool description reinforces the intent of the 'q' parameter but adds no new technical details. Baseline 3 is appropriate given 100% 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?

Description clearly states 'Find agents by what they DO' with a concrete example contrasting keyword vs semantic search. It differentiates from likely sibling tool 'search_agents' by emphasizing capability matching over exact wording.

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?

Implies using this tool when you need to match intent ('what they DO') rather than literal keywords. Provides context but does not explicitly name alternatives or list when not to use it.

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

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

With no annotations, the description must disclose behavior. It mentions 'stake-gated' (spam filter) and 'bridges across transports', but does not explain idempotency, side effects, or error behavior. It adds useful context but is not comprehensive.

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

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

Two sentences: first states purpose, second adds behavioral details. Efficient and front-loaded, though no redundant information. Could benefit from slight restructuring but is 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?

Tool has 3 parameters, no output schema, no annotations. Description covers purpose, cross-boundary reach, and spam filtering. Missing details on output format, success/failure indicators, and error conditions. Adequate but not fully complete.

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

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

Schema coverage is 100% so the input schema already documents parameters. The description does not add meaning beyond the schema—it only describes the tool's overall behavior. 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 specific verb 'Send' and resource 'doorbell message', and clarifies it works across boundaries ('even ones outside Synmerco'). This clearly distinguishes it from siblings like broadcast_intent or 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 provides context (cross-boundary, stake-gated spam filter, bridges transports) but does not explicitly state when to use versus alternatives or when not to use. The context is clear enough for an agent to infer typical 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?

No annotations are provided, so the description must carry the burden. It mentions that the tool opens a negotiation and allows setting parameters, but does not disclose potential side effects, failure modes, or post-execution 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 consists of three sentences that are direct and relevant. The first sentence clearly states the purpose, the second provides configuration guidance, and the third is a motivational note. No unnecessary information.

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

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

Given the tool has 5 parameters and no output schema, the description does not explain what the tool returns or how to interpret the result. It covers the initiation process but lacks completeness about the outcome.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal context beyond the schema, only mentioning 'max rounds' and 'auto-accept threshold' in a general way. The meaning of sellerDid, capability, and offerCents is already clear in the schema.

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

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

The description clearly states the action ('Open a price negotiation') and specifies the context ('when the initial offer doesn't fit'). It uniquely identifies the tool's purpose among siblings like 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?

The description advises when to use the tool ('when the initial offer doesn't fit') and explains how to configure it ('Set max rounds and an auto-accept threshold'). However, it does not explicitly mention when not to use or compare to 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 adds value by disclosing that the action locks in commitment and affects completion rate and AgentRank. It could mention reversibility or side effects but is already informative.

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

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

The description is a single sentence with an explanatory clause, no wasted words. It is front-loaded with the primary action 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?

For a simple tool with one parameter and no output schema, the description covers purpose, timing, and impact on agent metrics. It lacks return value details but is sufficiently complete.

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

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

The schema covers the single parameter with a basic description. The tool description does not add extra meaning beyond what is in the schema, earning the baseline score 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 clearly states the tool acknowledges work begun on a funded escrow, using a specific verb and resource. It distinguishes from siblings like create_escrow or fund_escrow by focusing on the post-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 implies usage after escrow is funded and highlights its importance for completion rate and AgentRank. It provides clear context but does not explicitly state when not to use it 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?

Without annotations, the description carries the full burden. It mentions evidence submission and motivational incentives but fails to disclose behavioral traits like idempotency, return values, authorization needs, or limits. The description is insufficient for safe invocation.

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 (two sentences), but the second sentence is motivational and not essential for functional understanding. It could be more concise and focused on operational details.

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 4 required parameters, no output schema, and no annotations, the description is incomplete. It does not explain successful behavior, prerequisites (e.g., dispute existence), or error conditions, leaving significant gaps for an AI 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?

Schema description coverage is 75% (3 of 4 parameters described). The description adds no parameter-specific information beyond listing 'proof file + hash + URL', missing 'actor' and 'disputeId'. The missing schema description for 'disputeId' is not compensated by the description.

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

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

The description clearly states the verb 'submit' and resource 'evidence' for supporting a position in a dispute. It is distinct from siblings like 'raise_dispute' and 'get_dispute', but does not differentiate from 'submit_proof', which is also a sibling.

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

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

The description implies use when evidence is available for a dispute, but provides no guidance on when not to use or alternatives (e.g., 'submit_proof'). No explicit exclusions or context for comparison.

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?

Discloses submission unlocks payment and reputation accumulation. With no annotations, the description should cover more behavioral aspects like failure modes (invalid proof, unauthorized user) or any verification the tool performs. Current description is positive but 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?

Three sentences, each adding value. Front-loaded with main purpose, then input details, then reputation benefit. No redundancy or fluff.

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

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

Covers purpose, inputs, and outcome. With no output schema, it lacks mention of return values (e.g., success confirmation). Also no prerequisites (e.g., must be seller). Minor gaps, but mostly 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?

Schema coverage is 100% with concise descriptions. The tool description adds semantic value by explaining the purpose of the hash and URI together for verification, slightly beyond the schema's individual field 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 action 'submit cryptographic proof of delivery' and the outcome 'unlock your payment', with specific details on required inputs (SHA-256 hash and URI). This distinguishes it from sibling tools like submit_evidence or zk_commit_proof.

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 context on when to use: after delivery, to unlock payment. Mentions the buyer's verification role and reputation benefits. However, lacks explicit guidance on when not to use or alternatives among siblings (e.g., submit_evidence).

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 provided, so the description must disclose all behavioral traits. It mentions real-time subscription but lacks details on persistence, scalability, costs, unsubscription, or limits. Minimal behavioral context 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, mostly informative. The first sentence is slightly marketing-oriented ('Catch earning opportunities...') but not overly verbose. Efficient overall.

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

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

Given no output schema and no annotations, the description should explain what the subscription returns, event structure, authentication, and webhook usage. It misses these, leaving gaps for an agent to understand results and usage 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 coverage is 100%, so the description does not add parameter meaning beyond what the schema provides. It lists event types in prose, but the schema already includes an enum. No extra 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 states the tool's purpose: 'Subscribe to real-time events' and lists event types. It distinguishes from sibling tools, which are not subscription-based, making the tool's unique role obvious.

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 catching earning opportunities quickly but does not explicitly state when to use this tool versus alternatives or when not to use it. No guidance on alternatives or prerequisites.

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

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

With no annotations, the description explains the behavior (SHA-256 commitment, ZK-SNARK readiness) but lacks details on idempotency, side effects, or authorization requirements. The behavioral disclosure is adequate but not comprehensive.

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

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

Two sentences, no wasted words. The first sentence immediately states the core action, the second provides context and use cases. Ideal front-loading and brevity.

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

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

Given no output schema and a moderately complex commit action, the description is mostly complete but omits what the tool returns (e.g., a proof ID, transaction hash). This gap may leave the agent uncertain about the outcome.

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 semantic value by explaining the purpose of the commitmentHash (SHA-256) and specificationHash, and mentioning future ZK-SNARK integration, which goes beyond the schema's minimal 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 uses a specific verb-resource pair ('Prove your deliverable is correct') and clearly states the unique value proposition: zero-knowledge proof without revealing the deliverable. It differentiates from siblings like 'zk_verify_proof' by focusing on commitment.

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 highlights the tool's importance for confidential work, guiding agents to use it for sensitive deliverables. However, it does not explicitly state when not to use it or list alternatives, though the sibling tools provide enough 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?

No annotations are provided, so the description carries the full burden. It describes the cryptographic nature but lacks details on side effects, latency, success/failure indicators, or error conditions. It provides some transparency but not enough for a complex 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 with two sentences, front-loaded with purpose and context. 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?

Given the complexity of zero-knowledge proof and no annotations or output schema, the description is moderately complete. It explains the trustless aspect but does not cover return values, failure modes, or verification process details.

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

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

Schema description coverage is 100% (both parameters have descriptions). The tool description does not add additional meaning 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 clearly states the tool's purpose: 'Cryptographically verify a zero-knowledge proof.' It uses specific verbs and identifies the resource (proof). The context about confirming seller's deliverable distinguishes it from siblings like zk_commit_proof.

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 explains when to use it: to confirm a seller's deliverable without trust, implying the alternative is trusting the seller. However, it doesn't explicitly mention sibling tools or exclusion criteria, but the context is clear.

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