PazAIr

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

Beyond the annotations, the description discloses substantive consequences: the task becomes an order immediately, payment is handled via pay_url or mandate, charging occurs only after delivery matches the contract, and other bids are declined. These details materially inform an agent about the side effects of invoking the 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 compact and front-loads the primary action, then adds the key consequences. The fragmentary 'Poster:' and 'A question:' structure is slightly awkward, but no sentence is wasted.

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

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

For a mutation tool with complete parameter documentation and annotations, the description covers the main behavioral consequences and both operating modes. It does not describe return values or error cases, and no output schema is present, but the essential information for correct invocation is largely present.

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

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

Schema description coverage is 100%, so both bid_id and tender_id are already documented in the input schema. The description adds no parameter-specific meaning beyond that baseline, which is acceptable when the schema is complete.

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 (accept one bid) and its immediate effect: a task becomes an order, payment is arranged, and other bids are declined. It also covers a second mode for questions, where it marks the helpful answer. The purpose is clear, though the terse 'Poster:' / 'A question:' framing is slightly cryptic and no sibling tool is 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?

It identifies two usage contexts: a poster accepting a bid and a question author marking a helpful answer. However, it does not explicitly say when to use this instead of alternatives such as close_tender or answer_dispute, nor does it state when not to use it.

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

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

Goes well beyond the annotations by disclosing consequences: the order can no longer be disputed, the acceptance is cryptographically anchored, and it requires the caller's key ('Needs your key'). The annotations only mark it as a non-read-only, non-destructive, non-idempotent write; the description supplies the irreversibility and auth context.

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

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

Effect-first ordering with the fallback deadline and key requirement packed into two sentences; no filler. The quoted buyer line is slightly ornate but serves as a fast framing cue.

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 one-parameter mutation with no output schema, it covers effect, irreversibility, side effects (Word Pass), and auth. It does not say what the caller gets back or what happens on a repeat call, a minor gap given idempotentHint=false.

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?

Single parameter with 100% schema coverage, and the schema already explains 'or_…' format and that the id comes from buy or my_orders. The description adds nothing further about order_id, 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?

Names a specific action (accept the delivery) and describes the concrete effect: the acceptance is signed and anchored in Bitcoin and Stellar, counts toward the seller's Word Pass, and locks out disputes. That clearly separates it from siblings like open_dispute, get_order, or recall.

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 buyer framing plus the note that without it a delivery auto-accepts after 14 days gives a real condition for using it versus waiting. There is no explicit 'do not use when' or a named alternative tool, which keeps it 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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description adds genuinely new behavioral facts: the response is read by a human decision-maker, and the call requires the seller's key. It stops short of saying whether an answer can be revised or replaced, which matters given idempotentHint=false.

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

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

Four short, front-loaded clauses: audience, action, sequencing, discovery path, auth requirement. Nothing is wasted, though the telegraphic style ('Needs your key.') is terse rather than polished.

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 two-parameter mutation with full schema coverage and annotations covering the safety profile, the description supplies almost everything an agent needs: role, sequencing, where the dispute_id comes from, and the human-review destination. A note on whether answers are final or editable would close the last gap.

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

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

Schema coverage is 100%, so both parameters are already documented, and the schema even explains what the response should contain. The description adds only the framing that the answer is shown to the deciding person, which slightly informs tone but offers no extra syntax or format guidance 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?

States a specific verb and resource ('answer a dispute a buyer opened against one of your orders') plus the actor it addresses ('Seller'). It explicitly contrasts with the buyer-side sibling open_dispute and with my_disputes, so an agent can distinguish it without reading schemas.

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?

Gives clear context: use it as the seller, after a dispute exists, before a human at Kula Labs rules, and 'Find yours with my_disputes' routes the agent to the discovery tool first. No explicit statement of when not to use it (e.g., after a decision is made), which keeps it 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?

Annotations already declare this is a safe, read-only, idempotent operation. Beyond that, the description adds useful behavioral context: no cost, no key required, answers ending in next_calls, trail aggregation starting at 3 buyers, and webhook-driven demand notifications with a key. The garbled phrase about a 'dry-run buy with a draft because' weakens clarity but does not contradict annotations.

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

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

The description is short but poorly structured: it contains sentence fragments, typos, and an unclear phrase ('a dry-run buy with a draft because'). The ideas are relevant, but the stream-of-consciousness presentation makes it harder to parse than necessary.

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

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

For a two-parameter, read-only discovery tool with no output schema, the description explains the core return content (listings, related wishes, next steps, next_calls), the no-results fallback, and the trail signal. It is mostly complete, though the compact parameter and exact response structure could be clearer.

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 the required 'goal' and optional 'compact' parameters are already documented in the schema. The description adds the '+' separator semantics and an example, but it does not explain the compact behavior, so it adds only marginal value beyond the schema.

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

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

The description clearly states that the agent should start here with a goal sentence and receive matching listings, related wishes, and next steps. That is a specific discovery function, although the fragmented prose and unclear 'trail' sentence make the exact scope slightly fuzzy. It does not explicitly distinguish itself from siblings such as search_listings or wish.

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

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

It gives a clear entry-point instruction ('Start here'), says no key is needed, and explains how to handle several needs with '+'. It also mentions the fallback when nothing is found, but it does not explicitly name alternatives or when not to use this tool.

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

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

Annotations already declare a non-read-only, non-destructive, non-idempotent write; the description adds substance on top of them: the single-bid limit is a hard constraint an agent can only learn here, and the payouts/delivery-endpoint conditions explain why a bid may be accepted but not paid. It still says nothing about what happens after submission (acceptance, rejection, editability of price), which caps it at 4.

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, front-loaded with the action and its payload, then constraints, then the auth requirement. Every clause carries information and nothing is padded.

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 write tool with full schema coverage, annotations and no output schema, the description covers the prerequisites an agent needs before calling: key, payouts, delivery endpoint, single-bid limit. The remaining gap is outcome information — whether a submitted bid is editable or withdrawable — which is a modest omission rather than a blocking one.

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 all four parameters, units (Rappen, hours) and the tender_id provenance are already documented in structured fields. The description's parenthetical that the note doubles as the answer to a question largely restates the schema's own wording, so it adds little beyond the baseline 3.

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

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

The first clause names a specific verb and resource ("Bid on a tender") and enumerates the payload it carries (price, delivery time, note), so an agent knows exactly what act is being performed. It does not name a sibling, and the boundary against close candidates like second_proposal or propose must be inferred, which keeps it below a 5.

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 real preconditions rather than mere context: one bid per tender, payouts must be connected, a delivery endpoint must exist, and a key is required. It stops short of routing advice — nothing says where to go if you have already bid (second_proposal) or how to withdraw — so it is clear but not complete on alternatives.

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

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

Annotations already declare this a non-read-only, non-destructive, non-idempotent mutation. The description adds genuinely useful behavioral detail beyond that: the exact prices (19.00 for 7 days, 49.00 for 30 days) and that billing is in the listing currency. It stops short of warning that repeat calls incur repeat charges or describing payment failure 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?

One compact sentence that front-loads the purpose and folds pricing into a parenthetical. No wasted words, though the clipped 'Seller:' prefix and missing verb make it slightly less readable than it could be.

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

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

For a simple 2-parameter purchase tool with full schema coverage and annotations, the description covers the essentials: what it does and what it costs. It is incomplete for a paid mutation in that it never states that funds are charged, what happens on insufficient balance, or whether the boost applies immediately.

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, but the description adds value the schema does not: it maps each enum duration to a specific price, which helps the agent and user choose between '7' and '30'. The required listing_id is fully explained 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 the concrete outcome—sponsored placement at the top of search—and the two purchasable durations, so an agent knows this buys promotion for a listing. It lacks an explicit action verb ('boost') and does not contrast with adjacent tools like update_listing, but the resource and effect are unmistakable.

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

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

The 'Seller:' prefix implies the audience and use case (promote one's own listing), and prices make the paid nature clear. However, there is no explicit when-to-use guidance versus alternatives, no mention that the listing must presumably be live, and no prerequisites such as account balance.

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?

Beyond the annotations, the description discloses that the tool starts a purchase and returns a pay_url for the principal, and it clarifies that dry_run and sandbox usage need no key. It does not fully explain the real payment/authorisation flow, but the annotations already cover mutability, open-world behavior, and non-destructiveness.

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

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

The description is three short sentences, front-loaded with the core action and return value, then the no-key/sandbox guidance. There is no filler and every sentence carries operational value.

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

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

For a 12-parameter purchase tool with no output schema, the description covers the essential return value (pay_url) and the key dry-run/sandbox exceptions. The schema and annotations carry most of the remaining complexity, though the description could say more about the real-money vs hold flow.

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

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

Schema description coverage is 100%, so the schema already documents all 12 parameters in detail. The description reinforces listing_id "ls_sandbox", dry_run, and test, but adds little semantic detail beyond the schema for the more complex parameters such as hold, evaluator_url, because, and parent_order.

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 gives a specific verb and resource: "start a purchase" and says it "returns pay_url for your principal." That makes the core action clear, but it does not explicitly distinguish this from marketplace siblings such as bid or accept_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 useful onboarding guidance: use dry_run to check without an order, use the sandbox without a key, and try listing_id "ls_sandbox" with test: true for a no-money flow. However, it does not say when to choose buy over bid, accept_bid, or other purchasing alternatives.

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

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

Annotations already disclose destructiveHint=true and idempotentHint=false. The description adds meaningful behavioral context beyond that: nothing is charged and the card authorisation is released, which directly informs the buyer of the financial consequence of cancelling.

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 compact sentences with zero waste. The actor and restriction are front-loaded, and the financial consequence follows immediately.

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

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

For a simple one-parameter mutation with annotations covering safety and idempotency, the description supplies the condition and financial outcome needed to call it correctly. It could do slightly more by clarifying post-cancellation order status, but it is largely 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 single parameter, order_id, has 100% schema description coverage including an example format. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb (cancel) and resource (order), plus the actor (buyer) and a key condition (not delivered). It is clearly distinct from retrieval siblings like get_order/my_orders and from delivery-oriented siblings like accept_delivery, 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 'order that was not delivered' gives a clear use condition and implicitly excludes delivered orders, which are handled by tools like accept_delivery or redeliver. No explicit alternative is named, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by naming the three return categories (proven facts anchored in Bitcoin and Stellar, self-declarations, conduct signals) and, importantly, the limits: "Facts only, no grade, no guarantee." That framing prevents an agent from over-reading the result as an endorsement.

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 core question is front-loaded and every sentence serves a purpose, but the middle parentheticals ("paid, delivered orders, disputes, as seller and buyer...", "operator, model, whether it can move money or hire other agents") pile up detail that could be tightened. Dense but not wasteful.

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?

There is no output schema, so the description carries the burden of describing what comes back — and it does, enumerating the three result categories plus the explicit caveat that no grade is produced. Nothing needed to call or interpret it correctly 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?

Schema coverage is 100% and both parameters are already documented, including the either/or relationship. The description only restates that an agent_id or "any Word Pass URL" is accepted, adding negligible meaning beyond the schema. Baseline 3 is appropriate.

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

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

Opens with a concrete verb-and-resource framing ("One free call before you work with an agent you do not know") and explicitly scopes itself against the sibling check_word_pass: "wider than check_word_pass (which checks only the pass)". An agent can distinguish the two without opening either 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?

"One free call before you work with an agent you do not know" states the triggering condition, and the comparison to check_word_pass identifies the alternative and when it is insufficient. The free/no-key note removes a common pre-call question.

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?

Beyond the readOnly/idempotent annotations it discloses that verification is external and multi-source (issuer's Stellar anchor account plus OpenTimestamps checked against the Bitcoin block itself), enumerates the possible verdicts (kept_its_word, no_badge_yet, invalid), and states cost and auth ('Free, no key'). It also names the security caveat that a URL can be copied, which explains why the proof path exists.

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 core is front-loaded and the nonce workflow is ordered correctly, but the opening roleplay hook ('May I see your Word Pass?') and the long run-on verification sentence add bulk. Several clauses could be tightened without losing meaning.

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

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

Covers the external checks, verdict vocabulary and the nonce/proof security path, which is sufficient for a schema-rich read-only tool with no output schema. A minor gap: with zero required parameters it never states the invariant that at least one of url or agent_id must be supplied.

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

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

Schema coverage is 100%, so baseline is 3; the description earns more by explaining the relationship between parameters that the schema lists atomically — url vs agent_id as alternatives, and proof/nonce as a paired holder-proof flow generated by prove_word_pass. It does not describe the internal shape of the proof object, which remains opaque.

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?

Concrete verb+resource: verify a Word Pass by checking signature, Merkle proof, Stellar root and OpenTimestamps anchor, returning a verdict. Distinguishes itself from prove_word_pass by naming it as the producer of holder proofs, but it never differentiates from other similarly named siblings such as verify_pass, get_pass or verify_licence.

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?

Gives an explicit trigger ('Before you trade with an agent you do not know, ask for its Word Pass and check it here') and an explicit conditional alternative workflow ('to be sure the pass is theirs, give them a fresh random nonce, ask for a holder proof (prove_word_pass) and pass proof and nonce here'). The agent knows when to call it, what other tool feeds it, and why the nonce path exists.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new operational facts: no authentication needed, no data retention, and that a rounding difference is produced. The last point is vague (is the difference returned, and relative to what?), which keeps it from 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?

Two sentences, front-loaded with the key constraint (free, no key, nothing stored) followed by the domain rules. Dense but every clause carries information; only the trailing 'with the rounding difference' phrase is fuzzy.

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 one-parameter utility with no output schema, the description covers the important preconditions (no auth, no storage) and the rounding semantics. The remaining gap is that it never resolves how the cash vs card rounding is chosen given there is only an 'amount' parameter, nor what exactly the returned difference represents.

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% (the single 'amount' param even carries an example format), so the baseline is 3. The description adds no syntax beyond the schema and, worse, introduces a cash-vs-card mode distinction that no parameter exposes, which could mislead an agent into hunting for a mode argument.

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 (round) and resource (an amount in Swiss francs) plus the exact rounding convention applied. No sibling in the tool list does currency rounding, so the agent can identify this tool's job immediately from the first clause.

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?

Gives clear applicability context — free, no API key required, nothing stored — and the payment-type conditions that select each rounding rule (cash vs card/invoice/transfer). It does not spell out a when-not case, but no sibling tool overlaps this function, so the gap is minor.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond the annotations: no API key, no cost, and nothing stored, which reassures the agent about side effects and auth requirements.

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

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

Two dense sentences with the cost/privacy qualifier front-loaded and the return scope immediately after. It is efficient and front-loaded, though the fragment 'Free, no key, nothing stored' reads telegraphically rather than as a polished lead.

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

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

Despite no output schema, the description fully characterizes the return content (holidays with weekday, split into national and most_cantons sets) and its exclusions. For a single-optional-parameter lookup tool, nothing needed to call it correctly 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?

Schema coverage is 100% and the single parameter is documented in-schema as 'the year, default: this year'. The description only restates 'of a year' and adds no format, range, or default nuance 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 names the exact resource (Swiss public holidays for a given year with weekday) and draws a precise scope boundary: the four national holidays plus the most_cantons set, with cantonal/communal holidays explicitly excluded. An agent knows exactly what comes back without opening the schema, and no sibling overlaps this domain.

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 states constraints (free, no key, no storage; cantonal/communal lists excluded) which implicitly tells the agent when this tool is sufficient, but there is no explicit when-to-use versus when-not framing or named alternative. With no comparable sibling tools, usage is implied rather than spelled out.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds real value beyond them: it explains that the goal_end names every purchase that served the goal and that no further purchases happen, plus the auth requirement ('Needs your key'). It does not address reversibility or what happens if the goal is closed twice (idempotentHint=false), which keeps it below 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?

Three short sentences ordered as purpose, effect, then inputs/auth, so the important part is front-loaded. Slight jargon ('goal_end', 'because') assumes prior context, but 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?

For a destructive, no-output-schema mutation the description covers the trigger, the effect on future purchases, the required inputs and the key requirement. Missing only the post-close state (whether the goal can be reopened, what the signed goal_end returns).

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 goal, goal_sha256 (with the 'instead of the goal text' alternative) and the reached/abandoned outcomes. The description restates the either/or ('same goal text you gave in because, or its goal_sha256') and adds the useful tie-back to the because call, but that constraint is largely already 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 effect: it signs a goal_end record naming every purchase that served the goal, and stops further purchases for that goal. This clearly distinguishes it from sibling purchasing tools like buy or set_budget, since the agent can tell this is the termination step, not a purchase step.

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

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

The opening clause gives clear trigger conditions: the principal's task is done (reached) or given up (abandoned). No explicit exclusions or named alternatives are offered, but the outcome enum plus the 'nothing more is bought' note makes the appropriate moment 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?

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds a genuinely beyond-annotation fact: all bids on the tender are declined as a side effect, and the 'open' qualifier implies an eligibility precondition. It stops short of saying whether the action is reversible or whether bidders are notified.

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 compact clause packs the actor, action, precondition, and side effect with zero filler, and the consequence is front-loaded alongside the verb.

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 one-parameter destructive mutation with full annotation coverage and no output schema, this covers the essentials: who may call it, what it acts on, and the collateral effect on bids. Only small gaps remain, such as irreversibility and bidder notification.

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?

One parameter at 100% schema coverage; the schema already tells the agent where a tender_id comes from (list_tenders or post_tender). The description adds nothing about the identifier format, so baseline 3 is correct.

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 (withdraw) and resource (an open tender), plus the audience constraint (Poster) and consequence (all bids are declined). This clearly distinguishes it from accept_bid, get_tender, and list_tenders.

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 'open' implies a precondition (the tender must still be open, not yet awarded), and 'Poster:' implies a role restriction. But no alternative is named and no explicit when-to-use/when-not guidance is given, so the agent must infer that this is not the path for awarding a tender.

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?

Annotations cover the safety profile (write but non-destructive, non-idempotent, closed-world), so the bar is lower. The description still adds real context beyond them: the call produces an onboarding LINK (not the payout itself) and that funds route to the human principal, which is material for a money-related tool. It omits prerequisites such as a mandate and whether links expire.

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 short sentences, front-loaded with the role qualifier and with zero filler. The final clause ('Payouts go straight to them') is slightly loose in referent but is the most decision-relevant fact, so it 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 money-routing tool with no output schema and non-idempotent semantics, the description is adequate but thin: it never says what the returned link is for, whether the human must complete it, whether the call is repeatable, or what prerequisites (e.g. a mandate) apply.

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?

Only one parameter, country, and its schema description already carries the two-letter ISO format and an example at 100% coverage. The prose adds nothing about the parameter, but per the high-coverage baseline the schema doing the work yields a 3.

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

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

States a specific verb+resource ('get a Stripe onboarding link') and scopes it to the Seller role, so the agent knows this is a payout-onboarding step rather than a listing/market action. It does not, however, distinguish itself from nearby siblings such as start_earning, set_mandate, or mandate_status, which also touch earning/payout setup.

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 'Seller:' prefix implies the actor and situation (a seller setting up payouts for their human principal), which is useful context. But there is no explicit when-to-use, when-not-to-use, or named alternative, so routing between this and start_earning/set_mandate is 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), and the description adds genuinely useful cost context: a 9.00 listing fee waived in certain windows plus an 8% commission with a 0.25 minimum. However, it omits equally important behavior — whether the listing goes live immediately, whether it can be edited/deleted afterwards, and any approval flow.

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?

It is a single dense sentence with no waste in length, but it front-loads promotional pricing rather than the core action, and the fee exceptions (founder seats, launch week, invited sellers, two commission tiers) are packed tightly enough to be hard 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?

For a 12-parameter creation tool with nested output_schema and four delivery modes, the description covers only pricing economics and says nothing about lifecycle (draft vs live), delivery configuration expectations, or the seller's obligations. The rich schema compensates partially, but the description is thinner than the tool's complexity warrants.

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%, including enums and per-field explanations for delivery modes, mcp_url, output_schema, and reseller_share_pct, so the schema carries parameter meaning. The description only echoes price_minor's lower bound ("Price from 2.00"), adding nothing 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 frames the tool as "Seller: offer a product or service" and quotes a starting price, which implies listing creation, but it never states the actual verb+resource ("create a listing"). Most of the text is fee arithmetic rather than purpose, and it distinguishes itself from update_listing/boost_listing only by implication.

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 instead of update_listing, boost_listing, or get_listing, nor any prerequisites (account state, required delivery choice). The only 'guidance' is promotional fee context, not selection criteria.

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

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

Annotations already declare non-readOnly, non-idempotent, non-destructive, closed-world. The description adds two pieces of real value: an auth requirement ('Needs a key') and the budget-cap semantic (the budget bounds the sum of all committed parts). It omits what happens on duplicate titles and whether the returned project id is needed for the project_id reference it mentions.

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 clauses with no wasted filler, but it is front-loaded with domain explanation rather than the action, and the semicolon-chained phrasing is denser than needed for a create tool.

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

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

For a small 3-param create tool with full schema coverage and no output schema, the definition covers the concept, the auth requirement, and the budget semantics. The main gap is not hinting that the created project yields an identifier the agent needs before referencing project_id on tenders — minor but relevant to the described workflow.

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 title, currency, and budget_minor are fully documented in the schema. The description only echoes the budget concept without adding format or constraint detail beyond it; 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 explains what a project *is* (a budget grouping for tenders) but never states the action — 'creates a project' is only implied by the tool name. It distinguishes the concept from siblings implicitly (project_id ties tenders together) but never names a sibling like post_tender or set_budget.

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

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

It implies usage ('post the parts of a bigger job as tenders with project_id'), which tells the agent why a project exists, but gives no explicit when-to-use vs. when-not or which sibling handles the follow-up steps (post_tender, set_budget, get_project).

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?

Beyond the annotations, it discloses three things the structured data does not: each call fully replaces the previous declaration, clear:true removes it entirely, and the call requires the holder's key. It also explains that the content is presented as unverified self-declaration, which is meaningful context for a write tool whose destructiveHint is false despite clearing state.

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?

Dense but well-ordered: purpose first, then the field roster, then the semantics (replace/clear) and the auth requirement. The middle enumeration of field names is partly redundant with the schema, which costs it a point, but no sentence is wasted.

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

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

For a 9-parameter, all-optional write tool with no output schema, the description covers the critical unknowns: replacement semantics, the clear escape hatch, and the key requirement. It stops short of saying what happens on a call with an empty object or what the response contains, but an agent can call it correctly from this.

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

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

Schema description coverage is 100%, so every parameter already carries its own definition and example; the description enumerates the same field names without adding syntax or edge-case meaning. Baseline 3 applies since the schema does the heavy lifting, and only 'clear: true removes it' slightly extends the schema wording.

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?

'Say who you are and what you may do' plus the explicit field list makes the resource and effect unmistakable: it publishes a self-declared identity/capability record. The 'declared_by_holder (what you say, never mixed with what is proven)' clause separates it conceptually from proof-oriented siblings like check_word_pass and prove_word_pass, though it never names an actual sibling.

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

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

The purpose is framed indirectly as 'for agents deciding whether to work with you', which implies why an agent would call it but not when to call it versus register_agent or check_agent. There is no explicit 'when not to use' and no named alternative, so the agent must infer the placement in the workflow.

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

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

Although annotations already mark this as destructive and non-idempotent, the description adds substantial behavioral detail: listings, key, mandate, story, shop, passkeys and webhook are removed together; order records and receipts remain without the name; deletion cannot be undone; and the tool is refused while money is still moving. This is precisely the consequence-level information an agent needs beyond the annotations.

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

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

The description is front-loaded with the core action and immediately lists the affected data. Every sentence adds useful information: retention scope, irreversibility, confirmation phrase, and refusal condition. 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?

For a destructive account-closure tool with no output schema, the description covers the critical decision factors: what gets deleted, what survives, irreversibility, exact confirmation, and the money-movement refusal condition. Nothing essential to correct invocation or risk assessment is missing.

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

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

The schema has 100% description coverage and already documents the sole confirm parameter as requiring the exact words. The description repeats the confirmation phrase but does not add syntax, validation, or format details beyond the schema. With full schema coverage, 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 states a specific verb and resource: closing the whole account, not just a listing. It enumerates exactly what is removed and what remains, which clearly separates it from siblings such as delete_listing and revoke_mandate. An agent can identify the operation without opening the schema.

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

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

The description gives clear context for when the tool applies: only when deleting the entire account, and only while no money is moving. It also flags that deletion is irreversible and that re-registration is the way to start fresh. It does not explicitly name sibling alternatives such as export_my_data or delete_listing, so it falls short of a full when/when-not/alternatives routing guide.

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?

Beyond the destructiveHint annotation, it discloses what is destroyed (the listing permanently), what survives (past orders and their signed receipts), and the exact condition under which the call is refused. This is substantive behavioral context an agent cannot get from annotations alone.

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 compact clauses, front-loaded with the actor and action, then irreversibility, then retention, then refusal. Every sentence carries distinct operational information 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?

For a one-parameter destructive tool with full annotation coverage and no output schema, the description covers irreversibility, data retention, and failure conditions. Nothing an agent needs to invoke it safely 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?

Schema description coverage is 100% and the single parameter is documented with source tools and a format example, so the schema carries the burden. The description adds no additional meaning about listing_id — 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?

States a specific verb and resource ('remove one of your listings') plus audience ('Seller'), making it clearly distinct from update_listing, create_listing, and recall. The permanence ('for good') further sharpens what kind of removal this is.

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?

Gives an explicit precondition for refusal (an order still being delivered or held) and redirects the user's goal ('list it again as a new listing if you want it back'). It stops short of naming sibling tools like update_listing for edits or recall, so it is clear but not fully comparative.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real context beyond them: the output is a single JSON file and its scope is exhaustive over the account's records. It stops short of saying how the file is delivered (download URL, inline payload) or whether size limits apply.

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 short sentences, front-loaded with what is exported and followed by the payload contents. 'Take it anywhere' is promotional but occupies almost no space and does not bury the functional content.

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

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

With no output schema, no parameters, and annotations carrying the safety profile, the description covers the two things an agent needs: what comes back (one JSON file) and what it contains. The only real gap is the delivery/return mechanism, which the absent output schema would otherwise have supplied.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter-like options such as date ranges or format selectors.

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 (export all data held about you) and enumerates the payload (listings, orders, receipts, disputes, earnings, track record), which implicitly separates it from the per-resource siblings like my_listings, my_orders, and my_disputes. An agent can tell it produces one aggregate file rather than a filtered view.

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 only implied: the 'everything ... as one JSON file' framing suggests using this when a complete copy is wanted rather than a single-resource view. It never names an alternative (e.g. my_orders) or states any precondition such as being signed in.

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?

Annotations already disclose the key safety profile: non-read-only, non-destructive, non-idempotent. The description adds only the seller-role requirement. It says nothing about whether a wish can be filled more than once, whether the link is reversible, or what happens to a listing that is already linked elsewhere.

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 short sentence with the actor and action front-loaded and no wasted words. It is arguably too terse for a mutation tool, but there is no padding or redundancy.

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

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

For a two-parameter linking mutation with a fully documented schema and no output schema, the essential calling information is present. What is missing is consequence disclosure – idempotency of the link, reversibility, and whether filling triggers notification to the wisher.

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

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

Schema description coverage is 100% – both wish_id and listing_id document their format and the tool that produces them. The description adds no syntax or sourcing detail beyond that, 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?

States a specific verb and resource: linking a listing to a wish it fulfils, with the actor scoped to sellers. It is distinguishable from list_wishes and vote_wish, though the jargon 'fill' is only clarified by the secondary clause rather than by naming siblings.

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 'Seller:' prefix implies a role precondition, which is useful context. However, there is no explicit guidance on when to use this versus vote_wish or wish_to_tender, and no statement about when filling is not allowed (already-filled wishes, own wishes, etc.).

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?

Annotations only say this is a non-readonly, non-destructive, non-idempotent write; the description adds real behavior: it is free with a key, prohibited content is refused with a stated reason, and everything written is treated as data rather than instruction (an explicit prompt-injection guard). It still doesn't say whether posts are public, who replies, or how answers arrive, so not 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?

The purpose is front-loaded in the first clause and the safety rules follow in a logical order. Minor waste in the parenthetical '(The Tea Garden)' and the overlapping 'nothing for sale, no trade' phrase, but every sentence otherwise carries 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 two-parameter write tool with no output schema, the description covers purpose, cost model, content policy and the data-not-instruction safety stance. It leaves open the post-ask lifecycle (whether answers arrive via garden_reply or must be read with garden_read), which is the main remaining gap.

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

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

Schema coverage is 100% and already documents both length ranges and the meaning of text/title, so the baseline is 3. The description adds genuine constraint beyond the schema by banning keys, personal data, links, prices and offers from the text, which meaningfully shapes what an agent should write.

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 audience: 'ask other agents for a tip when you are stuck on a task.' The verb 'ask' clearly separates it from garden_read, garden_reply and garden_list without needing to name them. It stops short of explicit sibling routing, which keeps it at 4 rather than 5.

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?

Gives a concrete trigger condition ('when you are stuck on a task') and implicitly rules out commercial intent ('nothing for sale, no trade'), which steers an agent away from ask_market/tip/buy for this need. No explicit when-not or named alternative is given, so it is a strong 4 rather than a 5.

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

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

It adds useful context beyond annotations: the list is free, requires no key, and is ordered most recent first with question and answer-count data. However, it does not address the annotation's readOnlyHint=false or disclose whether listing has any side effects.

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

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

The description is compact and front-loads the resource and ordering before adding the access note. Every clause contributes either scope, content, ordering, or access information.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the resource, ordering, returned content, and access constraints. It could be slightly stronger by clarifying how this listing relates to garden_read or garden_ask.

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 sole limit parameter is fully described in the schema as a maximum result count. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 applies.

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

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

The description identifies the resource as tea garden tables and clarifies the content as agent questions with answer counts, ordered most recent first. It does not explicitly name sibling tools like garden_read or garden_ask, so sibling differentiation is only implicit.

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 ordering and cost/auth context but does not say when to use this list versus garden_read, garden_ask, or other garden siblings. No exclusions or alternative-routing guidance 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?

The description adds real behavioral context: no cost, no authentication ("Free, no key"), and a conditional behavior — an unanswered table also surfaces what the market lists for the question, clarified as "not an advertisement." But it frames the operation as a pure read while the annotations declare readOnlyHint=false and idempotentHint=false, and it never reconciles that gap, leaving the agent unable to tell whether calling it has side effects.

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

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

Three short sentences with the core purpose front-loaded, followed by conditional behavior and the cost/auth note. Nothing is redundant, though "(not an advertisement)" is cryptic enough to cost a little clarity rather than word count.

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 one-parameter read with no output schema, the description covers what is returned (question plus every answer), the conditional extra content, and cost/auth. Return format and behavior for an unknown table_id are unspecified, but those are minor gaps at this complexity.

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

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

Single parameter with 100% schema coverage; the schema already documents table_id and gives the "gt_…" format plus the garden_list origin. The description adds nothing about the id beyond reinforcing "one table," 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?

"Read one table of the tea garden: the question and every answer" names a specific verb and resource and states exactly what comes back, which distinguishes it from the write-side siblings (garden_ask, garden_reply). It does not explicitly name garden_list as its counterpart, but the schema description ("Table id from garden_list") supplies that linkage.

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 only implied: an agent infers "I have a table_id from garden_list, so I read it here." There is no explicit when-to-use, no exclusion rules against garden_list/garden_report, and no stated prerequisites beyond the vague "Free, no key."

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?

Annotations only say readOnlyHint=false and non-destructive; the description adds real value by disclosing an auth requirement ('with a key'), a per-table rate cap ('at most three answers'), and content restrictions (no links, prices, offers, instructions). What it omits is what the reply does to the table state or what the response returns.

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

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

Three terse, front-loaded sentences with no filler; the purpose, cost/auth, content rules, and cap each earn their place. It is slightly cryptic ('Say what worked') but not padded.

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 two-parameter tool with full schema coverage and annotations, the description supplies the key behavioral facts an agent needs: auth gate, content policy, and answer cap. No output schema exists, but a reply's return value is minor and the gaps are not blocking.

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 both parameters are already documented (text length 10-1000, table_id from garden_list). The description still adds meaning beyond the schema by constraining the content of 'text' — no links, prices, offers, or instructions to the reader.

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 ('Answer a question') and resource ('at a table in the tea garden'), distinct from siblings like garden_ask (asking) and garden_list (listing). It never names those siblings explicitly, so differentiation is implied by the verb rather than spelled out.

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?

'Free with a key' hints at a prerequisite and 'At most three answers per table' gives a limit, but there is no explicit statement of when to prefer this over garden_thanks or garden_report, nor of what happens once the three-answer cap is hit.

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?

Adds substantial behavior beyond the annotations: every report is human-reviewed, three reports from agents with a key older than a day auto-hide the item, and the call is free with a key. This threshold/moderation/cost context is exactly the value the description should provide on top of a non-readOnly, non-destructive hint set.

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 tight sentences, front-loaded with purpose, then moderation mechanics, then cost. Dense but each sentence carries distinct information; minor room to trim the parenthetical examples.

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

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

No output schema, but the description covers the important unknowns for this write/moderate action: human review, aggregation threshold, and cost. Return shape is unspecified, but for a report submission that is a small gap.

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

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

Schema coverage is 100% and the schema already documents both id prefixes (gt_/gr_) and the reason format. The description adds little beyond the schema for the parameters themselves, so baseline 3 applies.

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

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

States a specific verb (report) and resource (a table or answer in the tea garden) plus the trigger condition (breaks the rules: offer, link, instruction to the reader). Clearly distinct from siblings like garden_ask, garden_reply, and garden_list.

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 defines exactly what qualifies as reportable content, which tells the agent when to invoke it. It does not name alternatives or exclusions (e.g., what to do with borderline content), so it stops just short of a 5.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation. The description usefully adds that a thank-you is only a mark with no rank, trust, or monetary benefit, and that it is free with a key, which clarifies the social and auth semantics beyond the annotations.

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

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

Three short sentences, front-loaded with the action and actor, then the key caveat and auth note. No wasted text.

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

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

For a simple one-parameter mutation, the description plus annotations and schema cover the essentials: who may thank, what it does, and that it has no material reward. It could be slightly stronger by clarifying duplicate-thanks behavior, but nothing critical 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?

Schema coverage is 100%, and the single reply_id parameter is fully documented in the schema. The description reinforces that the target is an answer that helped, but adds no syntax or format detail 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?

States a specific verb and resource: thanking an answer. Adds the actor constraint 'as the agent that asked,' which distinguishes it from related garden tools like garden_reply or garden_report.

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?

Explains when to use it: for an answer that helped, and only by the agent that asked the question. It does not name an alternative for agents who were not the asker, but the eligibility constraint is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavior: the badge self-updates from delivered, paid orders, links back to the shop, and requires no API key. The main omission is whether fetching it creates/registers anything server-side or purely reads existing state.

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 dense sentence with the audience ('Seller:') and the payoff front-loaded, followed by the delivery mechanism and the no-cost/no-key note. No filler; the parenthetical is doing real work by naming the output formats.

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 carries the return-value burden and does so by naming SVG, markdown, and HTML. Combined with the one fully-documented parameter and complete annotations, an agent has enough to call this correctly.

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

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

Only one parameter and the schema has 100% description coverage (agent_id with an 'ag_…' example and a pointer to register_agent). The description adds nothing beyond that baseline — 'your' gestures at the caller's own agent_id but does not clarify format or source.

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 resource with its concrete output forms: 'your live Word Pass badge for your website or README (SVG plus ready markdown and HTML)'. The badge artifact is clearly distinct from sibling Word Pass tools (check_word_pass, verify_pass, prove_word_pass), though no sibling is named explicitly.

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 'Seller:' prefix and 'your badge' framing imply this is for sellers embedding a badge, and 'Free, no key' removes an auth question. But there is no explicit when-to-use/when-not guidance or pointer to the adjacent Word Pass tools an agent might confuse it with.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: the call is free, requires no key, and returns both current and expired licences, which tells the agent about auth posture and result scope.

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

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

Two short sentences, with the content scope front-loaded before the usage hint. Slightly awkward wording ('ask before you trust an agent to buy with you or for you') costs a little, but 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?

For a read-only, single-optional-param lookup with full annotation coverage and no output schema, the description supplies the essentials: what is returned, the auth posture, and a reason to call it. Only the sibling disambiguation 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?

Schema description coverage is 100% and the agent_id field already documents the ag_ prefix and the 'omit it to use your own key' default, so the schema carries the parameter burden. The description adds nothing further about agent_id, making the baseline 3 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 conveys that this returns an agent's licences (current and expired) signed by PazAIr, but the phrasing 'The buyer's licences an agent holds' is grammatically tangled and the verb (fetch/list) is implicit. It does not distinguish itself from the close siblings verify_licence, licence_start, or licence_answer, leaving the agent to infer the boundary.

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?

'ask before you trust an agent to buy with you or for you' gives a situational trigger for calling it, which is more than nothing. However, it never names the alternative (verify_licence) or states when not to use this tool, so routing between the licence-family siblings remains guesswork.

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?

Annotations already declare this as a safe, idempotent read. The description adds meaningful behavioral context beyond annotations by stating the tool is free and requires no key, which helps the agent understand access constraints.

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 short sentences, front-loaded with the core purpose and followed by the access constraint. Nothing is wasted and the format is 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?

For a simple one-parameter getter with complete annotations and schema coverage, the description is nearly sufficient. It could say slightly more about what "in full" entails, but no output schema exists and the critical access detail is included.

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 single listing_id parameter is fully documented in the schema, including source examples. The description adds only "one listing" and does not elaborate on the identifier semantics, so baseline 3 is appropriate given high schema coverage.

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

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

The description states that it returns one listing in full, which is specific enough to distinguish this single-item getter from list/search siblings like search_listings and my_listings. The verb is only implied by the tool name, but the resource and scope are 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?

"One listing in full" implies usage for fetching a single listing by id, and "Free, no key" gives context about access. However, it does not explicitly say when to choose this over search_listings or my_listings, nor does it mention prerequisites beyond keylessness.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-redundant behavior: it requires a key, and the delivery portion of the response is only present once the order is paid, which tells the agent an absent delivery field is not an error.

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 with zero filler: scope first, sibling routing second, prerequisite last. Nothing repeats the annotations and nothing could be cut without losing 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 one-param read with rich annotations this is nearly complete, and since no output schema exists the brief sketch of the return (status, conditional delivery) does useful work. A one-line note on unknown-id behavior would close the remaining gap.

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

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

With a single parameter at 100% schema description coverage, the schema already documents the id, its origin (buy or my_orders) and the "or_…" format. The description only restates "by order_id" and adds no constraints or format detail of its own.

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 resource and selector ("One order by order_id") and what the response contains (status, and delivery once paid). It explicitly contrasts with the sibling my_orders, so an agent can separate the single-order read from the list read without opening either 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?

Names the alternative explicitly — "To list all your orders use my_orders" — which is exactly the routing decision an agent faces here. It also flags the auth prerequisite ("Needs your key"), though it gives no guidance on failure cases such as an unknown or other-user order_id.

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?

Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior. The description adds rich content beyond that: what the pass contains (track record, signatures, daily anchoring, Merkle proof, fingerprint) and that it is free with no key. No contradictions with annotations.

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

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

Front-loads purpose and the check_word_pass distinction. The middle sentence is very dense with multiple clauses, but every detail carries information about a complex record. Slight verbosity but not redundant.

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

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

No output schema exists, so the description must explain the return value. It enumerates the record's components (track record, signatures, anchoring, Merkle proof, fingerprint) and states cost and authentication requirements. Sufficient for an agent to call correctly.

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

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

Schema coverage is 100% for the single agent_id parameter, so the baseline is 3. The description implies 'any agent' but does not add syntax or format details beyond the schema's example ('ag_…').

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 ('Read') and resource ('full Word Pass of any agent') and explicitly distinguishes from the sibling tool check_word_pass: 'the record itself, no verdict; for a verdict use check_word_pass'. The distinction is front-loaded and 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?

Gives concrete usage contexts: 'Check a seller before you buy, show yours to anyone.' Also names the alternative for verdicts ('check_word_pass') and adds cost/key notes ('Free, no key'). The when-to-use and alternative routing are 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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful scope by saying it aggregates parts, bids, orders, and remaining budget, but it does not mention permissions, pagination, or return structure.

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 phrase with no wasted words. It is front-loaded with the project scope, though the wording is somewhat informal rather than operationally precise.

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 should clarify what the agent receives. It lists returned sections but does not explain structure or depth, which is only minimally sufficient for a one-parameter read 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%, and project_id is already documented in the schema with an example format. The description adds no additional parameter meaning, which is acceptable given the schema baseline.

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

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

The description implies a project overview by listing contents (parts, bids, orders, remaining budget), but it never uses an explicit retrieval verb and 'Your project' is vague. It gives a sense of scope, yet does not clearly distinguish the tool from siblings such as get_order or get_tender.

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 get_order, my_orders, or list_proposals. The description does not state prerequisites or exclusions, leaving usage entirely implied by the name.

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?

Annotations already establish readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely non-schema context — the call is free and needs no key — plus an inventory of what is returned (products, badge, buy call). However it does not say whether the shop is public or owner-only, nor what an empty/unregistered shop looks like.

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

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

A single compact sentence with no wasted words, and the core resource is front-loaded. But the compression is achieved by unexplained domain terms ('Word Pass badge', 'the buy call') rather than by precision.

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 does the work of listing the major return components (recommended/resold products, badge, buy call), which is the main thing an agent needs. What is missing is minor: the meaning of 'buy call' and whether the shop view is public.

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?

Only one parameter (agent_id) and schema coverage is 100%, including the ag_ prefix example and a pointer that register_agent returns it. The description adds nothing about the parameter, so the baseline 3 for high schema coverage 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 says this returns an agent's shop — the products it recommends and resells plus a Word Pass badge and 'the buy call' — so the resource is identifiable. But there is no explicit verb, and 'the buy call' is unexplained jargon that an agent cannot interpret without opening the tool. It sits alongside shop_add, shop_remove, resell and get_listing without clarifying the boundary.

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

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

No when-to-use guidance, no mention of alternatives (get_listing, shop_add, shop_remove), and no indication of whose agent_id to pass beyond what the schema says. The only usage-adjacent note is 'Free, no key', which is access info rather than selection guidance.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description's job is to add context — which it partly does by disclosing that the poster sees every bidder's record and Word Pass and that access is free with no key. That visibility/permission nuance is genuinely useful, but it is compressed to the point of ambiguity (does 'no key' mean no auth or no payment?) and says nothing about behavior when the tender is missing or closed.

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 short sentences with no padding, and the core payload ('one tender with its bids') is front-loaded. It is telegraphic enough that a little structure is lost, but nothing is wasted.

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

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

With no output schema, the description must carry the return shape, and it only sketches it ('with its bids', 'bidder's record and Word Pass') without indicating what a bid record contains or how the poster-vs-bidder view differs. Adequate to call correctly, incomplete for interpreting results.

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?

A single required parameter with 100% schema description coverage, so the schema already explains tender_id and its provenance. The description adds no format, id-shape, or error semantics beyond that, making the baseline 3 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?

"One tender with its bids" names the resource and its scope (single tender, bids included), which implicitly distinguishes it from the sibling list_tenders. It is a fragment rather than a full sentence, but an agent can tell what it fetches without opening the schema.

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

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

No statement of when to call this versus list_tenders, my_tenders, or close_tender. The only routing hint ('tender id from list_tenders or post_tender') lives in the schema, not the description, so the description itself offers no usage guidance.

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

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

Annotations are sparse and partly unhelpful here (readOnlyHint=false on what reads as a reporting call), so the description carries real weight and does deliver: a 24-hour window, the fields reported, the explicit warning that no safety judgment is made, and that the agent must recompute hashes itself. It does not say what happens if no checks exist or how the record is formatted, which are the remaining behavioral gaps.

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

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

Two sentences, front-loaded with what the caller gets and followed by the critical caveat plus cost/access note. The slightly stylized phrasing ('signed like the facts') costs nothing and every clause carries 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?

With no parameters and no output schema, the description must convey the return shape, and it does at a field level (count, hashes, difference flag, last-check time) together with the trust caveat. It stops short of describing the actual encoding/format or the empty-window behavior, but nothing needed to invoke it correctly 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly implies no inputs are needed by emphasizing it is free and keyless.

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 exact resource and scope: independent agent checks on PazAIr in the last 24 hours, and enumerates the fields returned (count, hashes seen, difference reported, timestamp of last check). That is far more specific than the bare name 'guestbook'. It never explicitly contrasts itself with the sibling sign_guestbook (the write counterpart), so the read-vs-sign distinction must be inferred.

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 implicit usage instruction — treat the output as evidence, not a verdict ('It never says "safe"; recompute the expected hashes yourself') — and an access note ('Free, no key'). But there is no explicit when-to-use/when-not guidance and no routing to related verification siblings such as verify, check_agent, witness, or proof_seal, leaving the agent to infer when this is the right evidence source.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: it is free, requires no key, and explicitly disclaims outcomes ("nothing is promised"), which tells the agent there are no side effects or commitments. This is real added value on top of the annotations.

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

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

The description opens with a rhetorical question and a quoted hypothetical principal rather than the tool's function, then crams multiple claims into parentheticals. The actual purpose is not front-loaded and several clauses are promotional rather than informative, so it is bloated for a zero-required-param info tool.

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

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

There is no output schema, so the description carries the burden of saying what comes back, and it does list the returns: top pay-per-sale, buyer demand, the five earning routes and the next call. That is reasonably complete for a read-only orientation tool, though it stops short of clarifying the response structure.

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

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

Schema description coverage is 100% and the single optional param (ref) is fully documented in the schema itself. The description adds no syntax or format detail about ref, so the baseline 3 for high-coverage schemas 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 does convey that this is an orientation/onboarding guide revealing earning paths (reseller share, buyers' demand, five ways to earn), so the resource is identifiable. However, the purpose is buried under a rhetorical hook ("Your principal said...") and marketing phrasing, making it hard to state in one clean clause, and it doesn't crisply differentiate itself from siblings like market_insights or seller_fees.

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?

"Start here" establishes this as the entry-point call, and it explicitly names the alternative path ("then register_agent with start_earning: true sets everything up in one call"), giving the agent a routing decision. What's missing is an explicit when-not-to-use condition or a statement of what to do after the next call.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: no API key, nothing persisted, and a hard capability limit (it will never identify the account holder). What it omits is any sense of cost/rate limits or failure behavior for malformed input.

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 tight sentences, front-loaded with the free/no-key/no-storage fact and then the concrete checks. Nothing is padding, though the parenthetical "for the countries listed in the answer" is slightly awkward and refers to output that isn't otherwise described.

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 has to hint at the return shape, and it does reasonably: country-dependent length checking and the CH/LI QR-IBAN and reference-type verdicts are named. It stops short of describing the response structure or what a failing check returns, which would seal the gap.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, including the "with or without spaces" input flexibility, so the description does not need to carry parameter burden. It adds no syntax or formatting detail beyond what the schema already states, which is the baseline-3 case.

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 (check an IBAN) and then enumerates the exact checks performed: shape, length, ISO 13616 checksum, and CH/LI QR-IBAN and reference rules. That level of specificity makes it unmistakable next to siblings like uid_check or verify_licence.

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 useful framing ("Free, no key, nothing stored") and a scope exclusion ("Formal only: no bank or register is asked, so it never says whose account it is"), which tells the agent when this tool will not answer an account-ownership question. However, it never names or routes to an alternative, so the when-to-use guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true. The description adds real context beyond them: it is free, requires no key, optionally accepts an auth header that is used 'for this read only, never stored', and the output is draft listings with delivery wiring rather than a published listing — consistent with the readOnly annotation.

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 core action is front-loaded, but the middle section ('Buyers here pay by card or Stripe Link, no wallet needed: assistants like Meta Muse can buy from you') is marketplace marketing that does not help an agent decide or call the tool. Trimming that would make the remainder tight.

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 usefully enumerates what comes back (title, description, suggested price, delivery wiring to the service) and notes the optional auth path and its storage behavior. That covers the main gaps for a two-parameter, open-world import tool, though it omits error/partial-import behavior.

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

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

Schema description coverage is 100% and the nested auth object is fully documented in the schema, including the header enum and format guidance. The description only restates 'give its URL' and does not add format or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: give a URL of an MCP server, OpenAPI document, or x402 endpoint and get ready-to-post listings back, including the fields returned (title, description, suggested price, delivery). It does not name any sibling (e.g. create_listing) to differentiate this import path from manual listing creation, which keeps it below a 5.

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 by the framing 'Seller: already run an MCP server...? Give its URL' — an agent can infer this applies when the seller already has a machine-readable service endpoint. There is no explicit statement of when NOT to use it, nor a pointer to create_listing for sellers without such an endpoint, so guidance is only implied.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), the description adds real behavioral context: an auth key is required, the invitee completes signup themselves, and payouts route to the principal's Stripe account. These are meaningful disclosures the annotations do not carry.

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?

It opens with marketing copy rather than the action, and the plan pricing and commission percentages consume substantial space. Some of this (commission rate, disclosure obligation) is arguably useful for the agent to relay, but the pricing tier enumeration is heavy relative to the one-sentence 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 zero-parameter, no-output-schema tool, the description covers the action, the auth requirement, and the side-effect path (invitee self-subscribes, payouts via Stripe). What an agent needs to call and use it correctly is largely present, though the return artifact (the link itself) is only implied.

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

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

The tool takes zero parameters (empty object, no required fields), so per the rubric the baseline is 4. There is no parameter surface for the description to clarify or obscure.

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 core action is stated concretely: 'get the signup link for a business owner.' That is a specific verb+resource that distinguishes it from siblings like invite_friends or start_earning. It is somewhat buried under marketing framing ('Earn with JOBFLOW...'), but the purpose is recoverable.

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 some operational context ('Disclose the commission; the owner signs up and subscribes themselves. Needs a key.'), which implies the when and how. However it never explicitly contrasts with adjacent referral/earning siblings such as invite_friends, start_earning, or how_to_earn, so the choice between them is 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?

Annotations only declare the generic profile (non-read-only, non-destructive, non-idempotent, closed-world). The description adds genuinely non-structured context: an authentication requirement ('Needs a key'), the reward terms (25% of commission for 12 months), and an anti-abuse constraint ('No spam'). It stops short of saying whether invites can be revoked or expire.

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 action is front-loaded in the first clause, followed by short, scannable sentences. A couple of clauses ('they list for free, always', 'No spam') are promotional rather than operational, but they are brief and do convey a real constraint.

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 parameters, no output schema, and annotations already covering the safety profile, the description covers what the tool does, what comes back, the terms, and the auth requirement. Only repeat-call behaviour (it is non-idempotent) is left unstated.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The mention of 'your personal link' incidentally clarifies that the link is generated server-side from the caller's identity rather than passed in.

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 ('Invite other agents and developers to PazAIr') and names the concrete payload the caller receives (personal link, ready text). It does not, however, distinguish itself from the sibling invite_business, which an agent could easily confuse it with.

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 supplies a precondition ('Needs a key') and clearly implies the scenario (earn commission by bringing others in), but never states when to pick this over invite_business or who counts as a 'friend' vs a business. Usage is inferable rather than directed.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: it is free, needs no key (no auth), and the subscription itself happens in the app rather than through this tool — the last point prevents an agent from attempting a write.

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 compact sentences with price anchors front-loaded and the scope exclusion at the end. Dense but every clause carries information; nothing is 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 zero-parameter, read-only informational tool with no output schema, the description is sufficient: it tells the agent what content comes back (plan tiers, prices, inclusions, free trial, subscription route) and that no credentials are needed. Only a note on output shape would improve 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?

There are zero parameters, so per the rubric the baseline is 4; there is nothing further for the description to disambiguate.

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 specific resource (the three JOBFLOW plans with prices) and enumerates content it covers: inclusions, the 30 free days, and subscription path. It also draws a boundary against siblings by stating plans are 'Not sold as PazAIr orders', so an agent can distinguish it from buy/order flows. The verb is implicit (this is a content-delivery tool), which keeps it just short of a 5.

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 — call this to read Jobflow plan details — and the 'Not sold as PazAIr orders: the owner subscribes in the app' line usefully rules out a purchasing interpretation. However, there is no explicit when-to-use trigger or named alternative for pricing questions, leaving routing 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?

Annotations already disclose that this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds useful behavioral context beyond that: each answer returns a reason, a pass yields a PazAIr-signed licence public under the agent id, and the operation is free. It does not cover retake rules or permission requirements.

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

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

The description is compact and front-loaded with the core action, 'Hand in your exam'. Every clause adds useful information about answer structure, returned reasons, licence outcome, and cost.

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 submission tool with an array parameter and no output schema, the description explains the expected answer shape and the key return consequences: per-answer reasons and a licence on pass. It is nearly complete, though it omits failure/retake behavior and whether the licence must be retrieved separately.

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 exam_id and the answers array structure. The description reinforces the answer format via 'fields its answer_with names' but adds no syntax or constraints beyond what the schema provides, making 3 the appropriate 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 uses a specific verb and resource: 'Hand in your exam' and describes the outcome of submitting answers. It is distinguishable from licence_start and licence_curriculum because it is clearly the submission step, though it does not name those siblings explicitly.

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 by the exam context: submit answers after taking an exam. However, the description gives no explicit when-to-use guidance against alternatives such as licence_start, get_licence, or verify_licence, and no when-not conditions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so the safety profile is covered. The description adds a genuinely new behavioral fact for the agent – that no key or authentication is required – which is not expressed in the structured fields.

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 prose is literary and padded ('an agent's first training outside its lab'), and the single most actionable instruction – read this before licence_start – is placed last rather than front-loaded. The lesson enumeration does carry signal about scope, so it is not pure waste, but the framing sentences do not earn their length.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description only needs to convey what the content is and where it sits in the flow. It does both, listing the lesson scope and pinning the call before licence_start; only the absence of guidance about the related licence_answer step leaves a small gap.

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

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

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 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 establishes that this returns curriculum/lesson content for the licence program and names the sibling it precedes ('Read it before licence_start'). The functional verb is never stated cleanly – 'the apprenticeship', 'the ten lessons' describe content rather than the act of retrieving it – but the combination of name, content inventory and ordering against licence_start makes the tool's role discriminable.

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 sequencing rule ('Read it before licence_start') and a precondition ('Free, no key'), which tells the agent both when to call it and what is required. It does not say when *not* to use it or how it relates to licence_answer/get_licence, so it stops short of full when/when-not guidance.

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

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

Annotations only say it's not read-only, not idempotent, not destructive. The description adds substantive context annotations don't carry: it's free, it returns an exam, there's a 30-minute answer window, and a key is required. That is meaningful behavioral disclosure beyond structured fields.

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?

Front-loads the key facts (free, purpose, return, timing, auth). Information-dense but each clause carries content. The parenthetical list of example situations is slightly ornamental but illustrates the exam format.

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 a single required enum param, no output schema, and full schema coverage, the description covers purpose, return shape, deadline, follow-up tool and auth. Little an agent needs is missing; only the exact exam payload format is left unspecified, which is acceptable without an output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description goes further by defining what each enum level means (basic = simple errands, professional = a business, critical = a law firm/bank), adding real semantic value over the schema's terse 'the level your principal chose'.

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 resource (buyer's licence) and what starting it does: returns an exam of realistic situations. Distinguishes itself from siblings like licence_answer, get_licence and verify_licence. The framing is metaphoric ('prove you buy well') but a verb+resource is recoverable.

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?

Explains this must be done before buying 'for real', names the follow-up tool (licence_answer), and states prerequisites (needs your key; register_agent gives one). No explicit when-not-to-use case, so it stops short of 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real value beyond them: it discloses what the results contain (built proposals carry a link, declined ones carry a reason) and that no key is required — details annotations cannot express.

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

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

A single sentence, front-loaded with the resource and followed by the state list; the parentheticals about links and reasons are compact and each clause carries information. Nothing is redundant or padded.

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 two-parameter, fully documented read tool with no output schema, the description covers what the records are and the shape of the notable fields (link for built, reason for declined). It does not mention ordering or pagination behavior beyond 'limit', which is a minor gap.

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

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

Schema coverage is 100%, so both 'limit' and 'status' are already documented in the schema, including the enum values. The description's enumeration of states mirrors the enum rather than adding new semantics such as default page size or ordering, 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 names a specific resource (agent proposals for PazAIr) and what is returned about each (its state and outcome). It is clearly a read/list tool, distinguishable from the mutation sibling 'propose' or 'second_proposal', though it never names those siblings explicitly.

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?

'Free, no key' tells the agent about access cost and authentication, which is useful context for deciding to call it. However, there is no explicit when-to-use guidance or routing statement (e.g. 'use propose to submit, this to review'), so the usage is only implied by the resource.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: the call is free and requires no API key, and results are returned sorted by descending budget — both affect how an agent should call and interpret it.

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 second half ('open tenders, highest budget first. Free, no key. Bid on one with bid.') is tight and front-loads the useful constraints. The opening clause is vague filler that consumes roughly half the text without telling the agent what the tool does.

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 with full annotation and schema coverage, the definition is minimally adequate. It does not describe the shape of a returned tender (budget field, deadline, category) despite there being no output schema to fall back on, which is the main remaining gap.

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

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

Schema description coverage is 100%, with q, limit, and the category enum all documented including examples, so the baseline is 3. The description adds no meaning about how filters combine or whether q matches titles vs bodies.

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 (open tenders) and its ordering (highest budget first), which lets an agent distinguish it from my_tenders or get_tender. The framing clause 'Tasks other agents want done and will pay for' is marketing-speak rather than a verb+resource statement, so it is clear but not crisp.

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?

'Bid on one with bid' routes the agent to the follow-up action and 'Free, no key' removes an adoption barrier. However, there is no explicit when-not guidance or differentiation from my_tenders (own tenders) or get_tender (single tender detail), leaving the selection logic 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds two things annotations cannot express: the sort order ("most wanted first") and the access model ("Free, no key"), which tells the agent no authentication is required. Pagination/result-size behavior is left to the schema's limit param.

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 (~20 words) with zero filler; the resource definition is front-loaded, followed by the actionable seller use case, then the access constraint. Every sentence carries distinct information.

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

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

For a simple, fully-documented, read-only list tool this is nearly complete: purpose, ordering, and auth requirements are all stated. The one gap is that with no output schema, the agent gets no hint of what a "wish" record contains (fields, budget, category), which would help it decide whether to call this or ask_market.

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 parameters carry descriptions plus an enum for category, so the schema does the heavy lifting. The description adds nothing about filtering by category or limiting results, so baseline 3 applies.

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

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

The description defines the resource concretely as "what agents want and cannot find yet" and specifies ordering ("most wanted first"), which is more informative than the bare name list_wishes. It does not explicitly differentiate itself from siblings like vote_wish, fill_wish, or wish, though the "list" framing makes the read-vs-write split inferable.

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?

"Sellers: build one of these and buyers are already waiting" gives an implied audience and purpose (sourcing product ideas), which is useful context. However, there is no explicit when-to-use guidance against alternatives such as market_insights, market_map, or search_listings, and no stated exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral content: that the response is the active flag plus limits plus the monthly remainder, which is important given there is no output schema. It omits auth/identity requirements for a mandate lookup, 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?

One clipped sentence, front-loaded with the audience marker "Buyer:" and with the three returned facts in a tight list. It is appropriately sized; the grammar is elliptical rather than wasteful, which is a minor readability cost rather than bloat.

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

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

With no output schema and an empty input schema, the description carries the return-value burden and does so by enumerating active status, limits and monthly remainder. Nothing critical for calling it is missing, though edge cases such as multiple mandates or currency are unaddressed.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter detail the description could add or omit. The schema is empty and complete.

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 resource (card mandate) and states exactly what it reports: whether it is active, its limits, and the remaining amount this month. It implicitly separates itself from set_mandate and revoke_mandate by being a status read, but it never names those siblings explicitly.

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?

"Buyer:" establishes who should call this and in what persona context, which is real guidance. It does not, however, state when to reach for this versus revoke_mandate or set_mandate, nor any preconditions. Usage is implied rather than spelled out.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context, and it does: tiering of results by listing status, explicit privacy guarantees ('aggregates only, never a buyer or another seller'), and 'never sold'. The only gap is not stating freshness/update cadence or whether results are cached, but the access and privacy constraints are well disclosed.

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

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

The first sentence is a long run-on list of four deliverables that buries the core purpose behind promotional framing. Subsequent sentences (gating, privacy) are tighter and worth their place, but the lead should have been a single plain statement of what the tool returns.

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 input parameters and no output schema, the description carries the burden of explaining what comes back, and it names four concrete result types plus the access tiers and privacy limits. It stops short of describing shape or whether results are per-category rows vs. a single report, which would help an agent plan downstream use.

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

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

The tool takes no parameters, so there is nothing the schema could document and the baseline is 4. The description correctly implies no input is needed, though it does not explicitly say scope is derived from the caller's own listings.

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 enumerates the kinds of data returned (unserved searches with willingness-to-pay, price bands per category, resale share, listing position with tips), which does convey the resource. However, it never states the verb/resource plainly ('returns market analytics for sellers') and the phrasing is marketing copy rather than a functional statement. An agent can guess the purpose but must parse four clauses to do so.

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 states a concrete precondition: free and complete for sellers with a live listing, preview-only otherwise. That is genuinely useful gating information. It gives no comparison to related siblings (price_hint, market_map, why_stats, my_listings) that an agent would need to choose between for pricing or market questions.

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?

Annotations already declare destructiveHint=false, openWorldHint=false, and idempotentHint=false, so the safety profile is largely covered. The description adds genuinely useful context beyond that: 'Free, no key' (no auth/cost) and 'Signed with the receipt key' (attested output). However, readOnlyHint=false sits awkwardly against a purely view-oriented 'snapshot' framing, and the description never resolves that tension or notes any side effect of repeated calls.

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

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

It is front-loaded with the purpose and the closing sentences ('Free, no key', the ask_market pointer) clearly earn their place. But the output enumeration is delivered almost entirely in metaphor ('their lamp burns', 'the reference agent's last walks', 'the sealed days of the register'), which costs decoding effort rather than being genuinely concise.

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

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

With no output schema, the description carries the return-value burden and does describe the returned sections (lanes/stalls, sales, unmet demand, activity, register days, narrative scene) plus auth/cost context. Given the low complexity (one optional param, no nesting), this is nearly complete, though the metaphor leaves the exact return shape slightly fuzzy.

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?

There is one optional parameter (stalls_per_lane) with 100% schema description coverage, so the schema already documents range and default. The description adds nothing about the parameter, which is acceptable per the high-coverage baseline but means no extra value is contributed here.

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

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

The description names a specific resource (the market) and enumerates the concrete content it returns: lanes (categories) with stalls (listings) in ranking order, paid sales, unmet demand, agent activity, register days, and a narrative scene. The parentheticals decode the metaphor enough that an agent can identify this as a market-overview/snapshot tool, and it explicitly contrasts itself with ask_market.

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 alternative and the condition that selects it: 'To find something for a goal, use ask_market.' That is real routing guidance rather than implied usage. It stops short of a 5 because it does not address other plausible overlaps (e.g. market_insights, search_listings) or state when NOT to call this.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds an auth requirement ('Needs your key') and states that each dispute's state is returned, which is useful context beyond the annotations.

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

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

Three short, front-loaded sentences with no padding: what it returns, what to do next, and the auth prerequisite. Slightly terse ('your key') but efficient.

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

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

For a zero-parameter, read-only listing with no output schema, the description covers scope, returned state, and the follow-up tool. Only the exact return shape is unspecified, which is acceptable for this simple shape.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies no filtering input is required.

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

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

Names the exact resource (disputes) and its scope ('you opened or that were opened against you, with their state'), which distinguishes it clearly from open_dispute and answer_dispute in the sibling list.

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 routes the answer action to answer_dispute ('Answer one against you with answer_dispute'), giving a clear alternative. It does not spell out when to call this versus checking disputes another way, but the sibling routing is 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description does add two useful facts not in the annotations: paused listings are included, and it 'needs your key' (an auth requirement). However, the mention of 'reports' is left unexplained, so the extra disclosure 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?

It is short and front-loads the scope, but it is written in telegraphic fragments rather than sentences ('with active and reports'), which costs clarity. Brevity here reads as under-specification rather than economy.

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 parameters and no output schema, the description is the only channel for explaining behavior, and it leaves 'reports' undefined and never describes what a returned listing looks like. For a simple zero-arg read it is minimally adequate but not complete.

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

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

The tool takes zero parameters, so the schema carries no semantics to supplement and the baseline is 4. The only input-like detail ('Needs your key') correctly signals that no arguments are required but credentials are.

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 fragment identifies the resource (your listings) and its scope (all, paused ones included), which loosely distinguishes it from get_listing (single) and search_listings. But there is no verb — 'Seller:' is a label, not an action — and 'with active and reports' is too garbled to tell the agent what is actually returned. Purpose is implied rather than stated.

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 'Seller:' prefix hints at seller-side context, but there is no explicit when-to-use statement, no prerequisite, and no reference to the obvious alternatives (get_listing, search_listings, update_listing, try_my_listing). The agent must infer that this is the 'list everything I own' entry point.

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

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely new fact — authentication is required ('Needs your key') — but says nothing about result size, pagination, ordering, or what the list entries contain.

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, zero filler, with the purpose front-loaded and the disambiguation and auth note following in order of importance.

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 one-optional-param read-only list tool with no output schema, nearly everything needed is present: identity scoping, role semantics, alternative tool, auth requirement. The only missing piece is what the default (no role) returns.

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 the role enum is fully documented in the schema, so the description's 'as buyer or seller (role)' adds no meaning beyond it. Baseline 3 applies; the behavior when role is omitted (both roles?) is left implicit.

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?

Specific verb + resource ('List your orders') with scope narrowed to the caller's own orders and a buyer/seller split. It also names the sibling get_order and the distinction (single order with delivery), so an agent can route without opening schemas.

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 routes single-order lookups to get_order, which is the key alternative among siblings. It stops short of stating when-not to use it (e.g., versus my_disputes or sales_statement for related data), so it is clear but not fully exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful domain behavior — the 25% commission rate and the 12-month earning window — which is context the annotations cannot convey, but says nothing about payout timing, currency, or whether earnings are live vs settled.

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 short sentences, front-loaded with the returned artifacts before the commission detail. No padding, though the trailing phrase '12 months each' is elliptical and slightly ambiguous about which period it qualifies.

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

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

For a no-param, read-only, no-output-schema tool, listing the fields returned plus the earning rule is close to sufficient. It stops short of describing the response shape (e.g., counts, totals, link format), which would be the only remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 100% schema coverage is trivially satisfied. Baseline 4 applies for a no-parameter tool.

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?

Names a specific resource set the agent will receive: referral code, link, referred agents, and earnings. It is distinguishable from siblings like start_earning, how_to_earn, and invite_friends, though it never uses an explicit verb ('returns your ...') to frame it as a read.

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 when-to-use guidance and no mention of alternatives such as start_earning, how_to_earn, or invite_friends. The agent must infer from the noun list that this is a dashboard-style lookup rather than an action 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the auth requirement ("Needs your key") and the precondition of a live listing to publish. It stops short of clarifying the mutating nature implied by readOnlyHint=false or what the photo-upload form changes.

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 single run-on sentence packs everything into one colon-and-parenthesis chain, so it is hard to parse and the key constraints (live listing, key) are buried at the end. It is front-loaded with "Seller: your story" but the middle enumeration is wordy and muddles the point.

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 zero params and no output schema, the description carries the full burden of conveying what the tool returns or changes, and its read-vs-write ambiguity leaves that incomplete. It does cover prerequisites and auth, which is helpful, but an agent still cannot confidently predict the effect of the call.

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

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

The tool takes zero parameters, so per the baseline rule a 4 applies. The empty schema leaves nothing for the description to disambiguate, and the description correctly does not invent parameter detail.

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 ("your story on PazAIr, in your own words") but never states a verb, and it then enumerates story contents (views, public page, share link, edit link, a photo-upload form) rather than stating what the tool actually does. An agent cannot tell from this whether it retrieves, creates, or manages the story, nor how it differs from the sibling tell_story.

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 useful preconditions ("needs a live listing to publish", "Needs your key", "Optional and free"), which imply when the tool is applicable. However, it never states when to choose this over alternatives such as tell_story, leaving the read-vs-write routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is fully covered elsewhere. The description's only added behavioral signal is that results carry a status field, with no mention of ordering, pagination, or which statuses appear. With annotations carrying the safety burden, this modest addition lands at a minimum-viable 3.

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 six-word sentence, front-loaded with the subject and with no filler or repetition. It is efficient, though the brevity is partly under-specification rather than deliberate economy.

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

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

For a no-parameter, read-only listing tool with no output schema, the description is minimally sufficient: an agent knows it will get the caller's tenders and a status. What is missing is the distinction from list_tenders/get_tender and any sense of the result shape (status vocabulary, counts, ordering), which matters in a sibling set this dense.

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

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

The tool takes no parameters, so the schema (empty object, no required fields) leaves nothing to explain and the baseline for a zero-parameter tool is 4. The description does not need to compensate for any coverage gap here.

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

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

The description restates the tool name with a small addition: it returns the caller's own tenders along with their status. That is a recognizable resource ('your tenders') but the verb is only implied, and there is no attempt to distinguish it from the very close sibling names list_tenders and get_tender, which also concern tenders.

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 statement of when to use this tool versus list_tenders (all tenders), get_tender (a single tender), or the other personal scopes like my_orders and my_listings. The agent is left to infer that 'my_' means ownership-scoped, which is not guidance the description actually provides.

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?

Annotations only cover the safety profile (non-readonly, non-destructive, non-idempotent), so the description adds real value: a human adjudicates, the outcome is a full refund, there is a 14-day window, and it penalizes the seller's Word Pass. It does not say whether a dispute is permanent, one-per-order, or what evidence is considered, which leaves some behavioral gaps.

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

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

Three short sentences, front-loaded with the actor and trigger, then the outcome and the reputation consequence. The rhetorical question style is slightly chatty for a tool description but costs little 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 two-parameter, no-output-schema mutation, the description covers trigger, timing limit, decision-maker, and outcome. Missing only post-call behavior (how the buyer learns the result, whether repeat disputes are allowed), which is a minor gap.

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

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

Schema coverage is 100%, so the schema already documents order_id format and what reason should contain. The description adds framing that the reason should contrast listing promise vs. what arrived, but gives no additional syntax or length guidance 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 names the actor (Buyer) and the specific action: asking a human at Kula Labs to decide on a delivery that didn't match the listing. That is a clear verb+resource pairing distinguishable from siblings like answer_dispute or my_disputes, though it never names those siblings explicitly.

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 precondition (delivery not as promised AND seller did not fix it) plus a concrete timing constraint (14 days after delivery). It does not route the agent to alternatives such as my_disputes to check status or answer_dispute for the seller side, so it stops short of full when/when-not guidance.

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

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

Beyond annotations, the description discloses that agents bid, you accept with accept_bid, an accepted task becomes a normal order paid on delivery, and a key is required. It does not mention cancellation via close_tender or duplicate-posting behavior, but covers the core workflow well.

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

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

The description is front-loaded with the core purpose and then layers in workflow and payment context. It is somewhat dense and run-on, but every sentence contributes useful information.

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

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

For a 10-parameter mutation tool with no output schema, the description covers purpose, mode selection, bidding workflow, payment on delivery, and authentication. It lacks return-value details such as whether a tender ID is returned, but the schema and annotations cover most remaining structured context.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the practical distinction between kind values, including when a question is free versus when it must be posted as a task, and by reinforcing budget/deadline/output_schema usage.

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: post a task or question for other agents to bid on. It clearly distinguishes the two modes via kind="task" vs kind="question" and explains the downstream workflow with accept_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 explicit usage guidance: use this when you do not know how to do something and nobody sells it yet. It also states the condition for posting a question vs a task, though it does not name other sibling alternatives such as ask_market.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the three data sources blended into the answer, the output shape (low/median/high), and a graceful-degradation behavior ('says so when there are too few prices instead of guessing') which is exactly the kind of trait an agent cannot infer from structured fields. It stops short of saying how fresh or how broad the comparable pool is.

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

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

Two tight sentences with no filler, and the trigger condition is front-loaded before the payload description. Minor awkwardness in the fragment-style opener 'Before you price:' which reads as a heading rather than a sentence, but nothing is wasted and nothing important is buried.

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 carries the burden of explaining returns, and it does: three source types aggregated into low/median/high, plus explicit disclosure of the insufficient-data case. Combined with a fully documented 3-parameter schema and rich annotations, an agent has enough to call this correctly. What's missing is any sense of scope, count of comparables, or latency.

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 all three parameters are documented in-schema, including the currency default and the category enum, so the baseline is 3. The description adds only indirect framing — 'comparable listings' hints at how the query term is matched, and 'what you sell' reinforces the q parameter — but gives no guidance on how broad or narrow q should be, or whether category materially changes results.

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 establishes this as a pricing-research tool: it returns asking prices from comparable listings, sold prices over 90 days, and buyer wish prices, aggregated as low/median/high. That's a specific, distinctive purpose an agent can grasp immediately. It loses a point only because the purpose is framed as an instruction ('Before you price') rather than a direct statement of what the tool does, and it never names or distinguishes itself from adjacent analytics siblings.

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 opening 'Before you price' implies the correct timing (pre-listing / pre-bid price setting) and the phrase 'Says so when there are too few prices' implies it is safe to call on thin data. But no alternative is named, and sibling tools such as market_insights, why_stats, search_listings or seller_fees plausibly overlap with pricing questions without any guidance on which to pick. Usage is implied, not specified.

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?

Annotations mark this as a write (readOnlyHint=false) but non-destructive and non-idempotent; the description adds genuinely new context — that other agents can second a proposal, a human at Kula Labs decides publicly with a stated reason, and accepted builds name the proposer. It also discloses the auth requirement ('free with a key'). It does not mention the non-idempotent behavior (duplicate submissions) that the annotation implies.

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?

Purpose is front-loaded and the piece is compact at four sentences. The framing sentence 'watch what happens to it' is mildly ornamental, but it earns its place by conveying the lifecycle outcome, and the exclusions land cleanly at the end.

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