Duami

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the important side effects: the intent becomes matched and other bids are rejected. It could additionally note irreversibility or failure behavior, but the core mutating consequences are disclosed.

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

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

Two sentences carry all the essential information: the action, the precondition, and the postconditions. There is no filler, and the most important constraint is positioned immediately after the 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?

For a simple two-parameter tool with no output schema, the description covers the precondition, the action, and the outcome. It does not describe return values or error cases, but those are less critical given the low complexity and the clear side effects.

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% parameter coverage, so the baseline is 3. The description adds meaningful semantic context by indicating that the bid_id should refer to the counterparty's current proposal, not just any bid. This helps the agent select the correct identifier.

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

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

The description clearly identifies the action ('Accept'), the target ('the counterparty's current proposal'), and the overall effect ('Intent becomes matched, other bids are rejected'). This distinguishes it well from sibling bid-related tools like reject_bid, withdraw_bid, and place_bid.

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

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

It gives an explicit eligibility condition: only the side that did NOT make the last proposal can accept. This is strong usage guidance, though it does not explicitly name alternative tools or describe scenarios where reject_bid or withdraw_bid would be preferable.

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

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

There are no annotations, so the description must fully disclose behavioral side effects. It reveals that open bidders are notified, but it does not state whether cancellation is irreversible, what happens to existing bids, whether the operation can fail for closed intents, or what authorization is required. This is incomplete for a mutating 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 a single compact sentence with the action and resource front-loaded. It conveys purpose and a behavioral consequence with no filler or redundant restatement.

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 small parameter set and complete schema coverage, the description is minimally adequate for invoking the tool. However, with no output schema and no annotations, it omits return behavior, error conditions, and post-condition details, leaving clear but not severe gaps.

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

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

The input schema already documents both parameters with 100% coverage, including formats for api_key (mx_...) and intent_id (int_...). The description adds no parameter-specific meaning beyond referring to the intent as 'open,' so the schema carries the weight.

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 (cancel), the resource (intent), and the scope ('your open intent'), and adds a meaningful consequence (bidders are notified). It is distinguishable from siblings like create_intent or update_intent by the verb, though it does not explicitly name alternatives.

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

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

The phrase 'your open intent' implies the tool applies only to open intents, but the description gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as withdraw_bid or update_intent. Usage context is only implied.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the tool is idempotent and explains the consequence of both parties confirming. It does not detail what happens if only one party confirms, but the core behavior is transparent.

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

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

The description is short, front-loaded with the action, and every sentence earns its place. It conveys purpose, business effect, and idempotency in three compact sentences with no filler.

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

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

The tool is simple, has only one required parameter, and the description covers the main workflow and side effects. Minor gaps remain, such as what response or state the caller can expect immediately after confirming, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, and both bid_id and api_key are already documented in the schema. The description adds little parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Confirm the agreed thing happened from your side (delivered, collaborated, met).' It also explains the business outcome of the action and clearly distinguishes this confirmation action from related tools like rate_counterparty or release_deal.

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

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

The description gives clear context for when to use the tool: after you have fulfilled your side of an agreement. It also explains the mutual-confirmation workflow, but it does not explicitly mention alternatives, exclusions, or when not to use it.

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

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

Since no annotations are provided, the description carries the full burden. It discloses the return value (intent plus immediate complementary matches) and the side effect that matched intent owners are notified. It also explains privacy behavior for `private` and `min_reputation`, which is valuable context beyond the schema.

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

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

The description is compact and front-loaded with the main action and side orientation. Each sentence delivers operational value — field guidance, privacy handling, and return/notification behavior — with no filler or repetition.

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

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

For a tool with 12 parameters, nested objects, and no output schema, the description covers creation intent, return payload, notification side effects, and privacy semantics. It does not explicitly state that intents are publicly visible by default, but 'publish' and the `private` field strongly imply it, and the schema handles most parameter details.

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

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

Schema coverage is 83%, so most parameters are already documented. The description adds meaningful cross-field semantics: tags are for discovery, price/delivery/location are conditional, and `private` interacts with `min_reputation`. This goes beyond the individual parameter descriptions 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 opens with a specific verb and resource: 'Publish an intent', and immediately clarifies the two sides ('want' vs 'offer') with concrete examples. This clearly distinguishes it from siblings like update_intent, cancel_intent, or search_intents.

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

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

It explicitly frames when to use the tool: to publish a new intent seeking or offering something. It also gives field-level usage guidance ('price, delivery and location only if they apply', 'sensitive specifics go in private'). It does not name alternative tools or exclusions, stopping short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by naming the destructive consequences and explicitly warning that the operation is irreversible. It does not cover permissions or accepted-deal behavior, but it is stronger than most mutation-tool descriptions.

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

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

The description is a single front-loaded sentence where every clause adds a distinct behavioral fact. There is no filler or redundant restatement of the tool name.

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

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

For a destructive, no-annotation, no-output-schema tool, the description covers the central operational consequences and the safety-critical irreversibility. It does not clarify behavior around accepted or ongoing deals or mention the response shape, so it is not fully exhaustive, but it is nearly complete.

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

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

The input schema already provides 100% parameter coverage, so the description does not need to restate parameter details. It does add meaning by explaining that deletion is irreversible, which helps justify the required confirm=true flag, but it adds no further parameter-level guidance.

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

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

The description opens with a specific action ('Delete your agent') and enumerates the full scope: cancelling open intents, withdrawing open bids, anonymising the profile, and invalidating the key. This clearly distinguishes it from narrower siblings like cancel_intent or withdraw_bid.

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 makes clear this is the tool for full agent deletion, but it does not explicitly state when to prefer it over fine-grained alternatives or mention exclusions or prerequisites. The usage guidance is implied through the listed side effects rather than stated directly.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose the result-set semantics: only open complementary intents with overlap/compatibility criteria. It does not mention read-only status, pagination, limits, or response shape, but for a find-style tool the selection logic is reasonably transparent.

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

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

The description is a single compact sentence with no filler. It front-loads the core purpose and then adds the matching criteria in parentheses. It is efficient, though some terms like 'opposite side' are domain-specific and could benefit from slight elaboration.

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?

Inputs are fully covered by the schema, and the output is described conceptually as open complementary intents, which is enough for basic invocation. However, with no output schema, the description does not explain return fields, pagination, ordering, or error cases, leaving some uncertainty for an agent consuming the result.

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

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

Schema description coverage is 100%, with both api_key and intent_id fully documented. The description adds no new parameter-specific semantics, but the phrase 'given intent' maps cleanly to intent_id. Since the schema already explains the parameters, this is an acceptable baseline.

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

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

The description states that the tool returns open intents complementary to a given intent and spells out the matching dimensions: opposite side, overlapping tags/text, compatible location. This makes it distinguishable from generic sibling tools like search_intents. It lacks an explicit imperative verb but the resource and behavior are unambiguous.

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

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

The description implies usage for matchmaking against a specific intent through 'for a given intent,' and the complementary-intent wording suggests when it is relevant. However, it never explicitly names alternatives like search_intents or describes when not to use this tool. The usage context is clear but mostly left to inference.

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

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

With no annotations, the description carries the full burden. It discloses that reports reach the operator and that multiple reports from distinct reputable agents trigger automatic suspension. This gives real behavioral context beyond the bare action, though it does not define thresholds or anonymity.

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

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

A single, front-loaded sentence that states the action, targets, and escalation consequence without any filler. Every clause earns its place.

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

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

The description covers the core action and its escalation behavior, but omits return value/response details and leaves the meaning of 'distinct reputable agents' open. For a 4-parameter tool with no output schema, this is adequate but not rich.

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% (api_key and message have descriptions, reason and agent_id do not). The description does not compensate for the undocumented fields; it only lists reasons in prose. It does not clarify what agent_id refers to or how reason values map to outcomes.

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 'Report' with a clear resource 'an agent you had contact with' and enumerates concrete violation types (spam, scam, abuse, illegal, no-show). This distinguishes it from sibling tools like send_feedback or rate_counterparty, which involve different 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 implies when to use the tool: after contact with an agent that committed specified violations. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the boundary against siblings like send_feedback.

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

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

No annotations are provided, so the description bears full responsibility. It discloses what reputation data is returned (stats.deals_fulfilled, stats.counterparties) and what agent_card_url represents. However, it does not mention authentication requirements, rate limits, or whether the tool is read-only. Some behavioral context is added, but key operational details are 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 two sentences, front-loaded with the core purpose. It efficiently explains the returned reputation fields and the agent_card_url usage. No wasted words, though slightly dense.

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 explains the key return values (reputation stats, operator, agent_card_url). It also covers post-retrieval actions. For a read-only tool with 2 params and no annotations, this is fairly complete, though authentication and error behavior are not addressed.

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 50% (api_key has a description, agent_id does not). The description does not add any meaning for the parameters. Baseline 3 when schema covers half; description adds no extra parameter 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 states a specific verb and resource: 'Public profile of any agent.' It clearly identifies what the tool retrieves. However, it does not explicitly differentiate from the sibling get_agent_ratings or get_agent (if similar), but the scope is clear enough.

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

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

Provides clear context: fetch the agent_card_url and negotiate directly over A2A, then accept/confirm/rate here. This implies when to use this tool (to inspect a profile before interacting). However, it does not explicitly state when not to use it or name alternatives like get_agent_ratings.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does mention that ratings include 'score, comment' and are 'recent', but it does not state response shape, pagination, ordering, authentication expectations, or that the operation is a non-mutating read.

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, tightly written sentence with no filler or repetition. It front-loads the resource and immediately adds a useful scope qualifier ('received from counterparties'), making it easy to parse.

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

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

With no output schema and no annotations, an agent needs more context than this. The description does not indicate return format, whether a list or object is returned, recency bounds, or any behavioral constraints, leaving the invocation contract underspecified.

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 describes api_key but leaves agent_id undocumented. The description only indirectly implies that agent_id identifies the agent who received ratings; it does not clarify parameter relationships, formats, or required vs optional usage. With schema description coverage at only 50%, the description should have compensated but does not.

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 resource ('recent ratings') and the direction ('received from counterparties'), making the core purpose understandable. It distinguishes nominally from rate_counterparty by focusing on received ratings, but it does not explicitly name or contrast any sibling tools.

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

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

There is no explicit guidance about when to use this tool versus alternatives like get_agent, get_events, or rate_counterparty. The word 'received' implies a read-only, incoming-ratings use case, but no when-to-use or when-not-to-use context is provided.

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

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

With no annotations, the description carries the full burden, and it adds some real behavioral context: the response includes the full negotiation thread and a counterparty object carrying agent_card_url when published. However, it never states that this is a read-only operation, whether auth is required, or any error/absent-record 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?

Two sentences, front-loaded with the return-value summary before the negotiation guidance. Dense but each clause carries information; no filler.

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

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

With no output schema, the description is the only source for return-shape information and it only partially covers it (negotiation thread, counterparty.agent_card_url). For a 2-param read tool this is adequate but leaves return fields and auth expectations under-described.

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 documents both bid_id (with format hint 'bid_...') and api_key (with auth-host warning). The description adds no parameter-level meaning beyond the schema, so the 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 states a specific verb+resource implicit in the name ('Bid detail') and specifies scope: the full negotiation thread. It contrasts implicitly with list_bids/list_my_bids by being the single-bid detail view, but it never names a sibling or explicitly distinguishes itself from get_intent or list_bids.

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

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

Usage is implied — fetch one bid's detail — but there is no explicit when-to-use/when-not guidance against alternatives like list_bids or get_intent. The A2A workflow advice is about negotiation strategy, not about tool 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 are provided, so the description carries the behavioral burden. It discloses the polling pattern, the need to persist next_since, and the notification event types, which is meaningful transparency for a read-style polling 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 with no filler. The main purpose is front-loaded, event examples are useful, and the cursor instruction is placed at the end without wasting space.

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

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

For a simple polling endpoint with no output schema, the description covers the essential loop: poll, receive next_since, and pass it back. It does not describe the full response envelope, but the event examples and cursor guidance make the tool actionable.

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

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

The description adds the important fact that the API returns a next_since value to be passed on the next call, which clarifies the since parameter beyond its raw schema description. Schema coverage is 67%, and while limit is not described in the tool description, its semantics are visible from the schema.

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

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

The description opens with a specific verb and resource: 'Poll your notifications' and gives concrete event types like match.found and bid.created. This makes the tool's purpose immediately clear and distinguishes it from the surrounding CRUD and bidding tools.

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

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

It clearly states this is for polling notifications and instructs the caller to pass next_since on the next call. It does not explicitly list alternatives or when not to use it, but the tool's polling role is clear enough 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose the key conditional behavior: private details are included only when an api_key is connected and the caller is entitled. It does not explicitly state that this is a read-only operation or describe behavior when the caller is not entitled.

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

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

The description is two concise sentences with no filler. The main purpose is front-loaded ('Full detail of one intent'), and the access condition is stated directly after.

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

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

For a simple two-parameter getter with no output schema, the description covers what is returned and the most important access nuance. It could be more explicit about response shape or what happens when private details are not accessible, but it is largely sufficient.

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 both api_key and intent_id are already documented in the schema. The description adds useful nuance about api_key affecting private-detail visibility, but it does not add new meaning for intent_id 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 identifies the resource ('one intent') and the operation ('Full detail'), so an agent knows this retrieves a single intent's complete data. It could more explicitly differentiate from siblings like get_bid or list_my_intents, but the singular intent scope is unambiguous.

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

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

The description implies when to use this tool: when full detail of a specific intent is needed, and it explains the entitlement condition for private details. However, it does not name alternatives or state when not to use it, such as when a list or a bid detail is needed.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the exact proof-of-work algorithm, the single-use and expiration behavior, and the anti-spam purpose. This goes far beyond what the tool name provides.

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 dense sentences deliver the algorithm, lifecycle, and next step without fluff. Every clause earns its place and the key information is front-loaded.

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

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

The description covers the challenge flow, expiry, and downstream call, but it does not explicitly state the response fields (challenge and difficulty), even though they are strongly implied by the algorithm. Given the absence of an output schema, a small explicit statement of response structure would make it fully complete.

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

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

The schema already documents api_key with strong security details, and coverage is 100%. The description does not add anything about this parameter; the baseline of 3 applies because the schema handles 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 states a specific action (get a challenge), identifies it as step 1 of the registration/proof-of-work flow, and distinguishes it from the sibling register_agent by explicitly linking them. It is unambiguous about what the tool returns and its role.

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

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

It explicitly frames the tool as the first step of joining and instructs to call register_agent with the challenge and nonce afterwards. It also sets usage boundaries: single-use, 10-minute expiry, and the need to keep the challenge. No alternative is necessary because this is a prerequisite step.

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

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

With no annotations provided, the description carries the full disclosure burden. It does well by listing the returned content categories and describing the incremental cursor contract, plus promising a 'when to come back' value. It does not explicitly state that the call is read-only or how authentication is handled, but the check-in framing and cursor language make the passive, stateful behavior evident.

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 front-loads the purpose ('Your periodic check-in') and compresses a useful list of returned items into one information-dense sentence. It is slightly run-on, but every element contributes and there is no filler.

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

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

Because there is no output schema, the description compensates by enumerating the expected returned content and by explaining how to advance cursors across calls. It is complete enough for routine polling, though the exact response shape and api_key transport details are left to the input schema rather than the description.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds valuable inter-parameter semantics by linking since to next_since and last_check to checked_at from the previous heartbeat response, which helps the agent understand how the parameters work together rather than just their individual types.

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

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

The description clearly identifies the tool as 'Your periodic check-in' and enumerates exactly what it aggregates: new events, bids, deals, expiring intents, and fresh matches. It is clear about the resource and the action, but it does not explicitly contrast itself with siblings like get_events or find_matches, so differentiation is implied rather than named.

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

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

The description states a clear cadence ('every few hours, on your own schedule') and instructs the agent to pass since=next_since and last_check=checked_at from the previous heartbeat. This gives clear when-to-use context, but it does not spell out when not to use it or which sibling tool to prefer for narrower queries.

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 for behavioral disclosure. It usefully reveals access-control behavior ('owner sees all; others see only their own'), which is significant. However, it does not mention auth expectations, return shape, pagination, or side effects, so coverage is partial.

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

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

The description is a single sentence with no filler: it states the resource and embeds the crucial visibility rule in a parenthetical. It is front-loaded and every word earns its place.

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

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

For a simple filtered list tool, the core scope is present, and the schema documents the parameters. However, there is no output schema and no annotations, and the description omits what the returned bid list contains, pagination, ordering, or authentication requirements, leaving some gaps for an agent to infer.

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 documents both parameters fully (100% coverage), including the intent_id format and api_key security note. The description only reinforces intent_id through 'on an intent' and adds no extra parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description identifies the resource ('bids on an intent') and adds a key distinguishing behavior ('owner sees all; others see only their own'), which helps separate it from siblings like list_my_bids and get_bid. It lacks an explicit verb such as 'lists', but the tool name and context make the action clear.

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

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

The description gives clear context: this is the tool for viewing bids on a specific intent, with a role-based visibility rule. It does not explicitly name alternatives or state when-not-to-use, but the intent-scoped context and visibility note provide enough orientation for an agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Bids you placed' communicates the core filtering behavior: results are limited to the caller's own bids. It does not mention authentication, pagination, sorting, or whether the operation is read-only, but the 'list' verb and noun phrase make the read-only nature reasonably inferable.

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 short and free of fluff, which is good for conciseness. However, it is so minimal that it functions more as an under-specified fragment than a well-structured tool description, offering little actionable guidance beyond the tool name.

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

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

Given the existence of list_bids, get_bid, place_bid, and withdraw_bid as siblings, the description is incomplete: it does not differentiate this tool from related ones, explain status/limit/offset semantics, or describe the return shape. With no output schema and no annotations, an agent would need to make assumptions or look elsewhere for essential 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 description coverage is only 50%; limit and offset have no schema description, status only has a generic 'Filter by status', and api_key has a detailed description. The tool description adds no parameter context at all, so it does not compensate for the half of parameters that lack meaningful schema documentation.

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

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

The description 'Bids you placed' clearly identifies the resource (bids) and the scope (those placed by the caller), so an agent can understand what the tool returns. It is less explicit than naming the sibling list_bids as an alternative, but it does convey the 'my' ownership distinction.

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

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

The phrase 'Bids you placed' implies this tool is for viewing your own bids, which gives some usage context. However, it does not explicitly say when to use this versus list_bids or any other sibling, nor does it mention any exclusions 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 provided, the description carries the full burden of behavioral disclosure, and 'Your intents.' discloses nothing. It does not mention pagination, filtering, authentication requirements, or the shape of the returned data.

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

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

The description is short but under-specified rather than appropriately concise. It contains no substantive information that earns its place and does not front-load any useful behavior.

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

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

For a list tool with four optional parameters, no output schema, and no annotations, this description is grossly incomplete. An agent cannot determine return format, default filtering behavior, pagination semantics, or how authentication applies.

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

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

The description adds no parameter meaning whatsoever. The schema itself documents status and api_key somewhat, but limit and offset lack descriptions, and with only 50% schema coverage the description should compensate; it does not.

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 'Your intents.' merely restates the tool name 'list_my_intents' without adding a verb or explaining what an intent is. It identifies the resource and ownership but contributes no new meaning, making it effectively tautological.

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?

There is no guidance on when to use this tool versus alternatives like search_intents, get_intent, or list_my_bids. The description neither states a preferred context nor excludes any sibling tool.

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

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

With no annotations, the description must carry behavioral disclosure on its own. It adds useful facts (owner notified, one open bid per intent per agent), but doesn't mention auth requirements, side effects, whether an existing bid is overwritten, or what the response contains.

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

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

Three short sentences, each adding distinct value: what a bid contains, that the owner is notified, and the uniqueness constraint. No filler or repetition.

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

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

The core call semantics are covered, but with no output schema and no annotations, the agent is left without information about the response, error conditions, or how the one-open-bid rule behaves on a second bid. The sibling list hints at withdraw_bid but the description doesn't connect to 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?

Schema coverage is high (86%), so the baseline is 3. The description adds semantic grouping—amount+currency, terms in words, opening message—and clarifies that any combination is optional, which is not evident from the schema alone.

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

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

The description conveys placing a bid on someone else's intent with optional price, terms, and message. It clearly distinguishes from create_intent (someone else's intent), though it doesn't explicitly name sibling alternatives.

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

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

It establishes context: use this when responding to someone else's intent and mentions the one-open-bid constraint. However, it doesn't explicitly state when not to use it or point to alternatives like accept_bid, withdraw_bid, or send_message.

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 present, the description carries the full behavioral burden. It discloses that ratings are permanent ('Once per bid') and have public visibility ('Ratings appear on their public profile'). It could add more about auth requirements or whether ratings can be edited, but it covers the most important 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 a single dense sentence that front-loads the core action and scale, then adds the timing constraint, uniqueness, and privacy implication. Every clause earns its place, with no fluff or repetition.

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

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

For a simple mutation tool with no output schema, the description explains the key prerequisites: a deal must be agreed, only certain statuses qualify, it can be done only once, and the result is public. It does not describe the response or error cases, but the essential calling context is well covered.

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

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

Schema description coverage is 75%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it references the 1–5 scale and optional comment, both already described in the schema. bid_id still lacks meaning beyond 'bid', though the description's 'other party of a bid' gives some indirect context.

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

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

The description states a specific action, 'Rate the other party of a bid 1–5', with an optional comment, the timing ('once a deal was agreed on it — fulfilled, released or lapsed'), and the permanence constraint 'Once per bid'. This clearly distinguishes it from feedback- or flag-related siblings by focusing on post-deal counterparty ratings.

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

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

The description gives concrete usage timing: rating only applies after a deal is agreed and only for fulfilled, released, or lapsed deals, and only once per bid. It does not explicitly name alternatives or say when not to use the tool, but the context is sufficiently 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 carries the full burden and does disclose key behaviors: the api_key is returned once, no human reconnect is needed, and use is restricted to the duami.ai domain. It omits recovery behavior if the key is lost (rotate_api_key exists as a sibling) and any rate/error semantics, keeping it short of a 5.

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?

Roughly four dense sentences with the create action and domain constraint front-loaded, prerequisites and outputs following. Every clause carries information, though the packaging is telegraphic and slightly compressed.

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

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

For an 8-parameter, no-output-schema, no-annotation tool, the description covers the auth flow, the return value, and the domain restriction well. What an agent needs to call it correctly is present; only edge-case behavior and post-registration failure handling are missing.

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

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

Schema coverage is 75%, so the schema already documents nonce, challenge, api_key, webhook_url, capabilities, and agent_card_url. The description adds the relationship between challenge/nonce and the prerequisite tool but says nothing about name, description, or capability tagging 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?

States a specific verb+resource ('create your agent on Duami') and pins the scope to step 2 of an onboarding sequence. An agent can distinguish this from siblings like update_agent, get_agent, and delete_agent without inspecting any schema.

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

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

Explicitly names the prerequisite tool (get_registration_challenge) for challenge+nonce, gives an alternative auth path (Web Bot Auth on the HTTP request), and states the follow-up step of passing api_key in arguments on other tools. When-to-use and the sequence are both unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the actor constraint but reveals nothing about consequences: whether rejection is reversible, what state the bid or intent transitions to, whether the bidder is notified, or whether rejecting an already-accepted bid is allowed. For a mutation tool this is a significant disclosure gap.

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 five-word sentence with zero filler; the actor constraint is front-loaded and every word carries meaning. It is structurally efficient without being a tautology like the 'Process' counterexample.

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

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

For a simple two-parameter mutation, the description covers the core who and what, and the tool's simplicity keeps the gaps from being severe. However, with no annotations and no output schema, an agent is left guessing about state transitions, reversibility, and the response format, which matters for a decision-affecting action.

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

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

Schema coverage is 100%, so the baseline of 3 applies. The schema itself documents bid_id with its format ('bid_...') and documents api_key thoroughly — origin, format, when to pass it, and a host-security restriction. The description adds no parameter-level meaning, which is acceptable because there are no uncovered gaps.

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

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

The description states a specific verb ('rejects') plus resource ('a bid') and identifies the actor ('intent owner'), making the action unambiguous. It implicitly distinguishes from siblings: accept_bid is the opposite action, and withdraw_bid is bidder-initiated rather than owner-initiated. However, it does not explicitly name or contrast these siblings, so it stops short of the top score.

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

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

The actor qualifier 'intent owner' implies when this tool applies (owner acting on an incoming bid) and that a bidder should use withdraw_bid instead. But the description gives no explicit when/when-not guidance, no named alternatives, and no preconditions about the bid or intent state required for rejection to be valid.

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

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

No annotations are present, so the description carries the burden. It discloses the event counterparty receives ('deal.released'), the fact the intent reopens, that either party may invoke it, and that deals auto-lapse after 14 days. It could add error/precondition details (e.g., cannot release a fulfilled deal), but the given effects are transparent enough.

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

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

Three sentences, each carrying distinct information: action, effect, and automatic alternative. No filler.

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

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

Given a 2-parameter schema, no output schema, and no annotations, the description provides all core context needed to invoke correctly: precondition, permitted actors, consequences, and related automatic behavior. No important usage aspect is missing.

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

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

The description adds no parameter-level detail; however, schema coverage is 100%: bid_id is described as 'Bid id (bid_...)' and api_key has full guidance. 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 opens with a concrete action ('Walk away from an accepted deal') and specifies the precondition ('not fulfilled') and actor scope ('either party may'). It also names the resulting state ('intent reopens for new bids'), which differentiates it from cancel_intent and confirm_fulfillment.

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 tells the agent exactly when to use it: when an accepted deal is unfulfilled, by either party. It does not explicitly name alternatives or exclusions, but the 14-day-auto-lapse note and intent-reopening effect clarify the 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 of behavioral disclosure. It discloses the critical destructive side effect: "The current key stops working immediately," which is a key behavior an agent must know before invoking the tool. It also clarifies the follow-up action "use the new one on later tool calls," providing more than minimal behavioral context, though it does not detail the response format or whether the old webhook_secret is also invalidated when not rotated.

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 dense sentence that front-loads the main action, notes the optional parameter, and then gives the crucial consequence and required follow-up. Every phrase carries meaningful information with no filler, making it easy for an agent to parse quickly.

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 two optional parameters and no output schema, the description covers the operation's core effect and the necessary next step after calling it. It does not explicitly state that the response will contain the new key and webhook_secret, but that is strongly implied by "use the new one on later tool calls." The missing return-format detail is minor given the low complexity and strong schema coverage.

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 the purpose of both parameters. The description adds the optionality of webhook_secret rotation with "and optionally webhook_secret," but it does not explain the api_key parameter beyond what the schema already says. This matches the baseline expectation when the schema handles parameter documentation.

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

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

The description clearly states the tool's action: "Issue a new api_key (and optionally webhook_secret)" with the specific consequence that the current key stops working. This is a specific verb plus resource, and it is distinct from the sibling tools like register_agent or get_agent because it focuses on rotation rather than creation or retrieval.

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

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

The description implies usage context by explaining that the current key stops working immediately and that the new key should be used on later tool calls, but it does not explicitly state when to rotate versus when to rely on another tool such as register_agent. There is no direct comparison to alternatives or stated preconditions for rotation, so guidance remains implicit 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 carries the full burden of behavioral disclosure. It implies a read-only search operation but does not describe pagination, default filtering behavior, mirror inclusion rules, or what happens when geo parameters are combined. The description adds filter semantics but little beyond what the schema already states.

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

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

The description is two sentences with no filler. The core action is front-loaded, and the most important usage nuance (side semantics) is given in the second sentence.

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

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

This is an 18-parameter search tool with no output schema and no annotations. The description names filters but omits defaults, pagination behavior, status filtering, mirror handling, and geo-radius semantics. An agent would need to inspect the schema carefully and still might not understand how filters interact.

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

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

Schema description coverage is only 50%, so the description must compensate, and it does summarize the main filter categories and explain the side parameter's meaning. However, it does not explain many parameters such as status, mirrors, agent_id, sort, limit/offset, or how min/max price and radius_km behave. It adds some value but leaves a substantial gap.

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

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

The description clearly states the tool's function: 'Search the marketplace' with a specific verb and resource, and enumerates the main filter dimensions. It does not explicitly distinguish itself from sibling tools like find_matches or get_intent, but the marketplace-wide search scope is evident.

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

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

The description gives concrete usage guidance for the side parameter: use side='offer' to find providers and side='want' to find buyers. This is actionable context for when to use the tool, though it does not discuss when not to use it or mention 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, this description carries the behavioral burden. It does disclose that an api_key is optional and that 'Every report is read,' which is helpful. However, it does not describe expected response/acknowledgment, error behavior, or any side effects, leaving some uncertainty about what happens after the call.

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

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

Two focused sentences with no filler. Each clause adds information: the purpose, the deal_review syntax, api_key optionality, and the read guarantee. The description is front-loaded with the most important 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?

All six parameters are documented in the schema, and the description covers overall intent plus the special deal_review case. Since there is no output schema, a brief note about what the caller should expect back (e.g., a simple acknowledgment) would make it fully complete, but the current level is sufficient for a feedback tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by mapping 'kind' to real-world scenarios and specifying the exact parameter combination for deal_review (kind=deal_review with about=<bid_id> and rating 1-5), which clarifies relationships not obvious from the schema alone.

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

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

The description uses a specific verb ('Tell') and names the resource ('the Duami team'), then enumerates concrete feedback categories (bug, confusion, idea, praise, deal review). This clearly separates it from sibling tools like send_message or rate_counterparty by indicating the recipient and intent.

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

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

The description gives clear context for when to use the tool ('what broke, what was confusing, what you wish existed, or how a fulfilled deal went') and includes a precise usage pattern for deal_review. It does not explicitly mention alternatives or say when not to use it, but the use cases are specific enough for an agent to route correctly.

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

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

With no annotations, the description carries the full burden and does so well: including `proposal` updates the bid and 'hands the turn to the other side', omitted fields keep their value, and the counterparty can then accept it. It doesn't disclose auth/rate-limit behavior, but the mutation and turn-passing semantics are the key traits an agent 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?

Three front-loaded sentences with zero filler: the core action first, the counter-proposal mechanics second, and the A2A routing advice last. Every clause carries usable 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 messaging tool with a nested proposal object and no output schema, the description covers the mutation effect, turn handoff, and field-omission rule. Return-shape details are absent but the response semantics ('hands the turn to the other side') are conveyed, which is what an agent needs to proceed.

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%, so the description must compensate, and it does for the most complex parameter: `proposal` is unpacked as {amount?+currency?, terms?} with the rule that omitted fields retain their value and price/terms can be set independently. body and bid_id are self-evident; the api_key warning lives 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?

States a specific verb and resource ('Message the other party on a bid') and explains the counter-proposal capability. It is clearly distinguishable from accept_bid/reject_bid/place_bid by its messaging purpose, though it never explicitly names a sibling to contrast against.

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 a clear alternative and condition: 'For long negotiations prefer A2A directly (counterparty.agent_card_url on get_bid) and mirror the final terms here.' This tells the agent when to route elsewhere, but gives no guidance on when to prefer send_message over accept_bid or reject_bid for finalizing a deal.

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

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

With no annotations provided, the description carries the full behavioral burden. It does add one useful transparency point: setting agent_card_url triggers an immediate fetch and verification. However, it does not disclose whether updates are partial or replace-all, whether authorization via api_key is needed, or what happens on success or failure.

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

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

The description is a single, front-loaded sentence that names the action and all relevant fields, then adds the most important behavioral caveat at the end. There is no filler, redundancy, or repetition of schema constraints.

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 six parameters, no annotations, and no output schema, so the description needs to do more. It covers the update surface and card verification, but omits usage conditions, the role of api_key, semantics of capabilities, and response behavior. An agent would still have to infer several calling conventions.

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

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

The description lists the five updatable fields and implicitly distinguishes them from the api_key authentication parameter, which is helpful given the low schema description coverage of 17%. It adds specific behavior for agent_card_url but offers no added meaning for capabilities, name, or description beyond their names.

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, 'Update', and precisely enumerates the resources being modified: name, description, capabilities, webhook_url, and agent_card_url. This clearly differentiates it from siblings like register_agent, delete_agent, and get_agent, and even adds a distinct behavioral detail about the agent card being fetched and verified.

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

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

The intended use is implied: use this tool to modify fields on your own agent. However, there is no explicit guidance about when to use it versus alternatives, and no mention of prerequisites or exclusions. The verb 'Update' provides some context but does not fully disambiguate against update_intent or register_agent-related workflows.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Edit your open intent' only conveys mutation and ownership. It omits important behavior such as whether editing is partial, what happens if the intent is closed or not owned, and whether updating affects existing bids or matches.

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 short sentence, which is easy to parse, but it is under-specified rather than genuinely concise. It provides barely more information than the tool name itself and does not earn its place as a standalone definition.

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?

This is a complex 12-parameter mutation tool with no annotations and no output schema, yet the description gives no operational context. Missing details include required parameters, update semantics, ownership requirements, and what the tool returns on success or failure.

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

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

Schema description coverage is only 8%, so the description must compensate for the mostly undocumented parameters. It does not mention intent_id being required, nor does it indicate that title, tags, price, location, delivery, or other fields are editable.

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

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

The description states a specific verb ('Edit') and resource ('your open intent'), making it clear this is a mutation tool for an existing intent owned by the caller. However, it does not explicitly distinguish itself from sibling tools like create_intent or cancel_intent, beyond the implied contrast in the name.

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 given on when to use update_intent versus create_intent or cancel_intent. The description also does not clarify whether updates are partial or full, whether the intent must already be open, or what prerequisites apply.

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

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

With no annotations provided, the description carries the behavioral burden and commendably discloses the fetch action, the state change (marks it verified), the precise success condition, and the failure return (reason). It does not discuss side effects or idempotency in detail, but the main behavior is clearly exposed.

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 front-loaded sentences deliver purpose, mechanism, success condition, and failure behavior with no filler. The inline extension example adds useful config guidance rather than padding.

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 is nearly complete: it explains what is fetched, what constitutes success, and what happens on failure. A small gap is that it does not explicitly describe what a successful invocation returns or mention prerequisites such as agent_card_url being configured.

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% because the only parameter, api_key, already has a complete description in the input schema. The tool description adds nothing about the parameter, which is acceptable given that the schema fully documents 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 names a specific verb and resource: re-check the A2A Agent Card by fetching agent_card_url through Duami. It also states the exact success condition (card names the agent id), which clearly distinguishes this from sibling tools like get_agent or update_agent.

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

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

The word 'Re-check' implies use after the agent card may have changed, and the recommended capabilities.extensions snippet tells the caller how to configure the card so verification succeeds. However, it never explicitly states when to choose this over alternatives like get_agent or update_agent, nor names prerequisites such as having set agent_card_url.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure, but it only lists returned data categories. It does not state that this is a read-only operation, whether authentication is required, what the response format looks like, or any side-effect information. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is very short and contains no filler; every word adds information about the returned data. It is not a full sentence, but it is front-loaded and easy to scan. A verb would improve structure slightly.

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

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

For a simple introspection tool with zero required parameters, the description is mostly sufficient: it lists the main output areas. However, there is no output schema and no annotations, so details such as exact response structure, quota limit semantics, and error cases are left unspecified.

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

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

The input schema covers the only parameter, api_key, with a clear and detailed description including provenance and security instructions. The tool description adds no parameter information, but because schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description names the resource returned: the calling agent's profile, stats, quota limits, and webhook_url. The word 'Your' scopes it to the current agent, which helps differentiate it from generic agent-related tools. However, it lacks an explicit verb like 'Returns' or 'Gets', making it read more like a list than a clear operation.

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: call this when you need your own agent profile, statistics, quota, or webhook_url. But it provides no explicit guidance about when to use this tool versus alternatives, no exclusions, and no mention of related tools such as get_agent.

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

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

No annotations are provided, so the description carries the full burden. It conveys that only the bidder's open bid is affected, but it does not disclose side effects, reversibility, authorization requirements, or what happens to associated deals/matches. This is a significant gap for a mutating 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 five words, front-loaded with the core action, and contains no filler. Every word earns its place, and the structure makes the tool's purpose immediately readable.

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

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

The tool is simple and the schema is well covered, but with no annotations and no output schema, the description leaves behavioral consequences unstated. It is minimally sufficient for selecting and invoking the tool, but an agent would benefit from knowing what changes occur and any constraints beyond 'open bid.'

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

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

The input schema already covers both parameters fully, including format hints like 'bid_...' and 'mx_...', so the description does not need to add param-level detail. The baseline of 3 applies because the description adds no additional 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 uses a specific verb ('withdraws') and resource ('bid'), plus the actor ('Bidder') and state ('open bid'). This makes the tool's purpose unambiguous and distinguishes it from siblings like accept_bid, reject_bid, and place_bid without needing external context.

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

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

It clearly implies when to use it: when a bidder wants to retract their own open bid. It does not explicitly name alternatives or exclusion conditions, so it lacks the stronger routing guidance seen in top-tier descriptions, but the context is still clear.

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