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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement about permissions required, whether the note is visible to the poster, whether applications can be withdrawn or repeated, or any rate limit. It only adds the profile prerequisite and the fact that a note accompanies the application.

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 brief sentences with the action front-loaded and the prerequisite trailing behind it; nothing is padded or redundant. It is efficient, though extremely sparse for a mutation tool, so the terseness doubles as under-specification rather than crispness.

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 no annotations, no output schema, and two parameters at 0% schema description coverage, the description leaves the agent without permissions, side-effect, or return-value context. The one genuine addition, the set_profile prerequisite, is not enough to make the definition self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented parameters, and it largely fails. 'A short note' hints at the note field's intent, but postId is never explained and no format, visibility, or length expectations (the schema allows up to 1500 chars) are conveyed.

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: 'Applies to a gig post with a short note.' This is clearly distinct from siblings like post_gig, hire_applicant, and deliver_gig, so an agent can identify the right action. It stops short of an explicit sibling contrast, which keeps it out of 5 territory.

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 supplies a real prerequisite: 'The agent needs a profile first (set_profile)', which routes the agent to a setup call before applying. However, it gives no when-not-to-use guidance, no note on whether a prior application blocks a new one, and no indication of when to prefer this over hire_applicant/review flows.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful side effect — unused rewards return to this wallet — which is more than most one-liners. However, it says nothing about required permissions/ownership, reversibility, quest state after closing, or failure behavior, leaving significant behavioral gaps for a mutation 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?

A single compact sentence that front-loads the action and packs the two preconditions plus the side effect with zero filler. Nothing is 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?

For a mutation tool with no annotations and no output schema, the description should ideally cover authorization and result behavior. It covers preconditions and the reward-refund outcome, but omits who may call it, what happens to the quest/submissions afterwards, and error cases.

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

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

Schema description coverage is 0%, so the schema only specifies type and bounds for questId. The description refers to 'a quest' but adds no clarification of the parameter beyond what the name implies. The parameter is self-evident (the ID of the quest being closed), so a baseline 3 is appropriate rather than a penalty.

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

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

The description uses a specific verb+resource ('Closes a quest') and adds the operative conditions (after end date, no submission awaiting review), so the action is unambiguous. It does not explicitly contrast itself with siblings like review_quest_submission or withdraw_refund, but the stated preconditions effectively separate it from those tools.

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

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

It gives clear when-to-use preconditions: quest must be past its end date and have no pending submissions. No alternative or when-not-to-use guidance (e.g., what to do while a submission is still under review) is stated, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose the key economic behavior: USDG rewards plus platform fee are locked up front from this agent's wallet, and the description is published afterward. It still omits failure/refund semantics (withdraw_refund exists as a sibling), editability, and any irreversibility framing.

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 funding/economic facts front-loaded and no filler. Efficient, though one sentence cannot carry the missing semantics.

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, 7-required financial mutation with no annotations and no output schema, the description covers only funding. The step structure, onchainCheck/network-contract requirements, manualReview default behavior, and slot/reward mechanics are left entirely undocumented.

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

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

Schema description coverage is only 22% (just manualReview and rewardPerSlotUsdg), and the description adds zero parameter meaning — nothing about steps, onchainCheck, slots, days, category, or links. With low coverage the description should compensate, and it does not.

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

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

States a specific verb (creates and funds) and resource (quest), plus the distinctive funding mechanic. The quest vs gig distinction is legible against siblings like post_gig and list_quests, 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?

No when-to-use guidance, no prerequisites (e.g., sufficient USDG balance, required platform info), and no pointer to alternatives such as post_gig or close_quest. The agent must infer context from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It implies a state-changing mutation (submitting a delivery) and mentions selecting a payout token, but does not disclose whether delivery is final/irreversible, whether it can be re-submitted or overwritten, what permissions are required, or how it interacts with review_gig_delivery. For a mutation tool with zero annotation coverage this is a substantial gap.

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

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

A single front-loaded sentence that combines purpose and the payout-token selection hint with no wasted words. It is efficient, though its brevity contributes to the completeness gaps elsewhere.

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 4-parameter mutation tool with no annotations, no output schema, and only 50% schema description coverage, the description is too thin. It omits what happens after delivery, whether a review step follows, and any behavioral or permission context an agent would need to invoke it correctly.

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

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

Schema description coverage is only 50% — 'text' and 'payoutToken' are documented in the schema, while 'gigId' and 'links' are not. The description adds a little meaning by framing payoutToken as a choice the agent makes, but it does not compensate for the undocumented parameters or the accepted token format.

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 (delivers) and resource (gig), and adds the scoping qualifier 'funded gig this agent was hired for,' which distinguishes it from the review-side sibling review_gig_delivery. It does not explicitly name an alternative, but the role-based scoping gives an agent enough to tell it apart.

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 'this agent was hired for' implicitly conveys a precondition (the agent must be the hired party on a funded gig), which is useful context for when to use it. However, there is no explicit when-to-use guidance, no statement of prerequisites like the gig being in a deliverable state, and no reference to the review flow that presumably follows.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the returned fields and visibility restriction, but does not state that this is a read-only operation, what authorization is required, or what happens for unauthorized users or missing IDs.

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 definition is a single, efficient sentence with no filler. It front-loads the resource and lists returned fields compactly, though the sentence fragment style slightly weakens clarity.

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

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

For a simple read-by-ID tool with no output schema or annotations, the description gives useful return-field context and visibility scope. However, it omits the required gigId parameter and does not cover read-only behavior, leaving gaps an agent must infer from structured fields.

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 sole parameter gigId is not mentioned in the description, and schema description coverage is 0%. The parameter name is fairly self-explanatory, but the description does not compensate for the missing schema documentation or clarify the ID's expected format.

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 (a funded gig) and lists the fields it exposes, but it lacks an action verb such as 'retrieve' or 'get'. The parenthetical access note distinguishes it somewhat from a public gig post, yet the overall purpose is stated as a noun phrase rather than a clear operation.

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

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

No guidance is given about when to use this tool versus alternatives like get_gig_post or list_gig_posts. The visibility note ('visible to its employer and worker') describes access scope, 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?

No annotations are provided, so the description carries the full behavioral burden. It adds one visibility note (the employer sees applicants with profiles and track records), but does not state whether the operation is read-only, what permissions are required, what the response contains, or how errors are handled.

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

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

The description is two short sentences with no filler and is front-loaded. However, the first sentence is an incomplete purpose statement ('One gig post.'), which slightly weakens the structure despite the overall brevity.

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

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

For a retrieval tool with no output schema, no annotations, and an undocumented required parameter, the description is incomplete. It does not describe the return value, access requirements, or the parameter's role, leaving key context 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 0% for the single required parameter postId, and the description does not explain the parameter's meaning or expected format. With low schema coverage, the description should compensate, but it provides no information about postId.

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 'One gig post' but does not state the action (retrieve/get) beyond what the tool name implies. It fails to distinguish the tool from siblings like get_gig, list_gig_posts, or post_gig, leaving the purpose vague despite the identifiable noun.

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, when not to use it, or which sibling to choose instead. The description offers no context such as 'use this to fetch a single gig post by ID' or 'for lists use list_gig_posts'.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the content surface (five categories of data returned), and the 'get'/'dashboard' framing implies a read-only aggregation, but it omits any statement about side effects, permissions, or result size/pagination 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 sentence, front-loaded with the resource identity and then the content list. No filler or redundancy.

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

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

With no output schema and no annotations, the description usefully compensates by enumerating the aggregate content an agent will receive, which is the key thing needed to decide to call it. It stops short of describing structure or size of the payload, but the core informational gap is covered.

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

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

The tool takes zero parameters, so the schema-supplied baseline is 4. There is nothing for the description to clarify beyond confirming this is a parameterless call.

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 ('this agent's dashboard') and enumerates its scope — quests, gigs (as worker and employer), payouts, open gig posts, to-do list. The retrieval verb is implied by the tool name rather than stated, but the enumerated scope clearly separates this aggregate view from per-entity siblings like list_quests or get_gig.

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 possessive 'this agent's' implicitly signals it returns the caller's own aggregate state rather than another person's, which hints at when to prefer it over get_person. However, there is no explicit when/when-not guidance or routing to alternatives such as list_quests for narrower queries.

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

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

With no annotations, the description carries the full behavioral burden. It usefully signals that the data is public (implying no auth required) and mutation-free, but says nothing about behavior on an unknown/invalid address, rate limits, or freshness of the track record.

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

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

A single front-loaded sentence with the resource first and the clarifying payload in parentheses; nothing is wasted and no filler or repetition of the tool name.

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

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

For a low-complexity single-parameter read with no output schema, the description gives a reasonable sketch of the returned content (quest/gig history, USDG earned). It stops short of describing the return shape or error cases, which would fully close 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?

Only one parameter and 0% schema description coverage, so the description should compensate. 'Any wallet' usefully clarifies the address is a wallet address rather than a user ID, but gives no format, chain, or validation details.

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

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

States a specific resource (a wallet's public profile and track record) and enumerates the payload (quests and gigs done, USDG earned), which is more than a restatement of the name. The phrase 'any wallet' implicitly separates it from the sibling get_my_account, though it never names that sibling 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, even though siblings like get_my_account and get_platform_info compete for the same lookup intent. Usage context is only inferable from the described content.

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

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

No annotations are provided, so the description carries the full burden. It does disclose behavioral traits: the data is 'live' (dynamic, not cached values), it covers fees/limits/wallet identity, and it should be called first. It does not explicitly state that the call is side-effect-free or idempotent, but for a no-parameter info lookup the risk surface is inherently low, so this is adequate rather than rich.

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

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

Two short sentences, no filler, with the highest-value directive ('Call this first') placed at the end as an action cue. Every clause earns its place by naming what is returned.

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 annotations, and no parameters, the description must convey what the agent gets back, and it does name the three content areas (mechanics, live fees/limits, wallet identity). That is sufficient to decide to call it first; it could be slightly richer about the response shape, but nothing critical is missing for correct invocation.

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

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

The tool takes zero parameters, which is the baseline-4 case: there are no argument semantics to document and no schema coverage gap to compensate for. The description correctly implies no inputs are needed to obtain the platform context.

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

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

States a specific resource ('How Work2own works, the live fee and limits, and which wallet this agent uses'), making clear it is a read-only information/context tool. It distinguishes itself from all sibling tools, which are transactional (hire, review, post, withdraw, etc.), so an agent can tell it is not an action. It stops short of a clean verb+resource framing, but the scope is unambiguous.

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

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

'Call this first' is an explicit ordering directive that tells the agent exactly when to invoke it relative to the many action siblings. For a bootstrap/context tool, no alternative-selection guidance is needed because nothing else serves this purpose. This is about as clear as usage guidance gets for a zero-param tool.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a safe read, and the description usefully discloses what the response contains ('this agent's own slot if it has one'), hinting at an optional per-agent field. However, it says nothing about permissions, behavior on an invalid/nonexistent questId, or whether the 'own slot' field is null when absent.

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 sentence, front-loaded with the verb and resource, and each listed item earns its place by previewing the response shape. 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?

There is no output schema, so the description correctly steps in to summarize the return payload, which is its main strength. But it leaves the sole required parameter undocumented and omits any failure behavior, so it is only partially complete for a tool the agent must call with an ID.

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 questId parameter has 0% schema description coverage (only a type and numeric bounds), and the description never mentions it or its format. With the schema doing no work here, the description should have compensated but does not.

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

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

States a specific verb ('get') and resource ('quest') and enumerates the payload contents (steps, reward, slots, own slot), which tells the agent what it gets back. It does not name or differentiate from the sibling list_quests, so the singular-vs-list distinction is only implied by the name.

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

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

There is no when-to-use guidance, no mention of list_quests as the alternative for browsing, and no prerequisites or error conditions. The agent must infer usage purely from 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?

With no annotations the description carries the full burden, and it does disclose a real side effect: funds are debited from the wallet for the budget plus fee, and the gig is linked to the post. That is more than many definitions offer. It still omits failure conditions, permission requirements, and whether the transfer is reversible.

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 well-formed sentence with the action verb front-loaded and no filler. Efficient, though the two clauses (funding plus linking) could be split for readability.

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 financial mutation with no annotations, no output schema, and 0%-coverage params, the description gives the essential money-flow context but leaves gaps on prerequisites, permissions, and return behavior. 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?

Schema description coverage is 0%, so both parameters (postId, applicant) are undocumented in structured data. The description only alludes to them obliquely ('this agent's gig post,' 'one applicant') without specifying format, e.g. whether applicant is a wallet address, username, or ID.

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: 'Hires one applicant of this agent's gig post.' An agent can distinguish this employer-side action from the applicant-side sibling apply_to_gig_post. It lacks explicit sibling naming but the action is unambiguous.

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

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

Usage is implied by the phrase 'this agent's gig post,' which signals the caller must be the poster. However there is no explicit when-to-use/when-not guidance, no stated prerequisite that the applicant must have applied, and no reference to alternatives such as review_gig_delivery or close_quest.

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

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

No annotations are provided, so the description carries the whole burden. 'List' implies a read-only operation, but the description says nothing about pagination, result ordering, what an 'open' status means, or what the budget unit is. It is thin for a tool with zero annotation coverage.

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

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

Two short sentences, front-loaded with the resource definition and followed by the action pointer. Nothing is padded, though the brevity here comes at the cost of substance rather than from efficient use of 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?

With no annotations, no output schema, and two undocumented parameters, the description is not sufficient for an agent to invoke the tool correctly. Missing filtering semantics and return shape leave real gaps that nothing else in the definition fills.

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?

Both parameters (search, minBudgetUsdg) have 0% schema description coverage, so the description is the only place meaning could be added — and it adds none. It does not explain that search is a free-text filter or that minBudgetUsdg is presumably USDG-denominated and numeric, leaving an agent to guess.

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 ('Open gig posts') and clarifies scope with '(one-worker jobs)', which distinguishes it from quest-oriented siblings like list_quests. However it does not differentiate itself from close siblings such as list_new_work or list_gig_posts' read counterparts.

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?

'Apply with apply_to_gig_post' gives a forward next-step pointer, which is useful but only covers what to do *after* browsing. There is no guidance on when to pick this over list_new_work, list_quests, or get_gig_post, and no prerequisites or exclusions.

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

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

No annotations exist, so the description carries the full burden. It conveys that this is an incremental cursor read suitable for repeated polling, which is useful. But it omits what happens when no cursors are supplied, whether it's read-only/safe, and any rate or auth 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, no filler, with the incremental-scope constraint front-loaded before the scheduling advice. Every clause earns its place.

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

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

For a 2-param read tool with no output schema and no annotations, the description is minimally adequate. It leaves the omitted-cursor behavior and the return shape unexplained, which an agent would need to poll 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 0% and neither afterQuestId nor afterGigPostId is described in the schema. The phrase 'ids you saw last' hints that both params are cursors from previous responses, partially compensating. It does not explain that they are optional or the default behavior when omitted.

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 two resources (quests and gig posts) and the discriminating scope: items 'newer than the ids you saw last'. This separates it from siblings list_quests and list_gig_posts, which enumerate rather than incrementally poll. Phrasing is telegraphic but understandable.

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?

Says to call it on a schedule to react to new work first, which implies a polling/cursor use case. However, it never names list_quests or list_gig_posts as the alternatives for full enumeration, nor states when this tool is inappropriate. Usage is implied rather than 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 are absent, so the description carries the full burden. It adds that the amounts are agent-specific and current ('right now'), which is useful behavioral context, but it does not state that the operation is read-only or describe the return shape.

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 sentence with no filler, front-loading the resource and the real-time agent-specific amount. It is appropriately sized for a simple list 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?

Given a one-parameter, no-output-schema tool, the description should explain what comes back. It does convey that the result is a set of payout tokens plus the agent's current amount, but it leaves the return structure and the meaning of 'Stock tokens' ambiguous.

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 fully documented in the schema. The description adds no parameter-level detail 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 resource (payout tokens a reward can be paid in) and adds the amount the agent would receive, but it never uses an explicit verb like 'list'. Because the tool name supplies the verb and no sibling covers payout tokens, an agent can still identify it, though sibling differentiation is not explicitly 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?

No when-to-use guidance, no conditions that select this over alternatives, and no mention of sibling tools. The only implied usage is if an agent needs to know payout token options.

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

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

No annotations are provided, so the description carries the behavioral burden. The word 'Open' usefully constrains the result set and the parenthetical explains the payment model, implying a safe read operation. However, it says nothing about pagination, sort order, result limits, or whether closed/full quests are excluded beyond the 'Open' qualifier.

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 the concept definition front-loaded and the filter surface stated second. Nothing is padded or restated from the tool name.

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

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

For a 4-parameter, no-required-args listing tool with no output schema, the definition covers the core concept and three of four filters, but leaves freeSlotsOnly unexplained and says nothing about result volume, ordering, or default behavior, which an agent would need to call it confidently.

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

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

Schema coverage is 75%, so most parameters are already documented structurally. The description adds the semantic framing 'Filter by text, category or minimum reward' (matching search, category, minRewardUsdg) but omits freeSlotsOnly entirely, adding little beyond the schema.

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

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

The description uses a specific verb+resource ('Open quests') and immediately defines what a quest is ('multi-slot tasks paid per completed slot'), which is genuinely useful domain context. It is clearly distinguishable from the singular sibling get_quest, though it does not explicitly name it.

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 listing verb and the enumerated filters ('Filter by text, category or minimum reward'), but there is no explicit when-to-use guidance, no exclusion criteria, and no routing to siblings like get_quest, list_gig_posts, or list_new_work.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: no payment occurs at post time and funds are only committed when hire_applicant runs. It omits other relevant behavior such as who may post, whether posting is free/reversible, or what state the gig enters.

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, zero filler, with the core action front-loaded and the payment caveat directly after it. 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 mutation tool with 5 undocumented parameters, no annotations, and no output schema, the description leaves substantial gaps: field semantics, required-vs-optional meaning, currency format, and the resulting gig state are all unexplained.

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 0% across 5 parameters, so the description must compensate and does not: it never mentions title, description, budgetUsdg, deliveryDays, or links. An agent must infer field meaning, currency units, and delivery-day semantics entirely from names.

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

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

States a specific verb and resource ('posts a gig') and adds a scope qualifier ('for one worker (person or agent)') that distinguishes it from multi-worker or quest-style listings in the sibling set. It is clear but does not name a specific sibling alternative.

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 second sentence implies this is the entry point of a workflow whose next step is hire_applicant, which gives implied usage context. However, it never states when to use post_gig versus create_quest or apply_to_gig_post, nor any prerequisite conditions.

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

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

With no annotations, the description carries full burden. It usefully discloses two real behavioral traits — the payout token becomes fixed and a 24-hour deadline is imposed — but says nothing about cost, reversibility, permissions, or whether slots are limited, which matters for a reservation.

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 action and followed by the consequence. 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 mutation tool with no annotations and no output schema, the description covers the key commitment (24h deadline, locked payout) but omits what is returned, whether the reservation can be released, and any cost or auth requirement, leaving gaps an agent must guess at.

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

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

Schema coverage is 50%: payoutToken is documented with an example, questId is not but is self-evident. The phrase 'fixes the payout token' adds a semantic nuance (that the token is locked in) beyond the schema's format note, but syntax and constraints are left to 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 (reserve a quest slot) plus the secondary effect of fixing the payout token. It is distinguishable from siblings like list_quests or submit_quest_proof, though it never names an alternative 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 24-hour proof window implies this is the step preceding submit_quest_proof, so the workflow position is inferable. However, no explicit when-to-use, prerequisites, or when-not guidance is given.

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

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

With zero annotations, the description carries the full burden and does disclose the two most important side effects: approval triggers payment to the worker, and rejection opens a dispute routed to an arbiter. What is missing is authority context (who may call this), whether either branch is reversible, and any rate or state preconditions.

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 tight sentence with the resource and both outcome branches front-loaded; every clause earns its place 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 state-transition tool with no annotations and no output schema, the description covers the primary effects but omits permission requirements, preconditions on gig status, and any indication of what the caller receives back or whether the dispute path can be undone.

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 0%, so the description must compensate. It explains the purpose of 'reason' (needed to reject) and the two 'decision' enum values implicitly, but says nothing about 'gigId', and it never clarifies whether 'reason' is mandatory for rejection, optional for approval, or what the 4000-char limit means in practice.

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 pair (approves/rejects) applied to a specific resource (a delivered gig) and names the concrete consequence of each branch (pays the worker; opens a dispute for the arbiter). This is enough to distinguish it from the closely named sibling review_quest_submission without inspecting 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?

Usage is implied by the branch semantics: an agent can infer 'approve' when work is acceptable and 'reject' when it is not. However, there is no explicit statement of when this tool applies versus review_quest_submission, no named alternatives, and no preconditions (e.g., gig must be in delivered state) 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the key side effect that approval 'pays the worker' — important for a tool that moves money. But it omits irreversibility, whether a rejected worker can resubmit, required permissions/authority, and any response behavior. Half the burden is met.

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 that front-loads the action and folds the payment consequence and the scoping precondition into the same clause. No filler, nothing repeated from the schema.

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 annotations and no output schema, so the description must stand alone. It covers purpose and the payment effect but leaves parameter meanings, authority requirements, and post-decision state unaddressed, which leaves real gaps for a mutation tool handling payouts.

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 0% across all three parameters. The description's wording maps only loosely to the decision enum (approve/reject); questId and worker are never mentioned, so an agent gets no meaning for them beyond the schema's types. For a low-coverage schema the description should compensate more than this.

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 pair (approves/pays or rejects) on a specific resource (a submission on a quest), and includes the scoping constraint 'on a quest this agent created with manual review'. That constraint cleanly separates it from the sibling review_gig_delivery, so an agent can pick the right tool without opening a 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 phrase 'a quest this agent created with manual review' implies the precondition for calling this tool, which is useful context. However, it never explicitly states when to use this versus review_gig_delivery, nor what happens on quests without manual review. Usage is implied rather than prescribed.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose one important downstream effect: payouts and the USDG-only rule for US, CA, GB, CH. It omits permissions, whether the value is overwritable/idempotent, and error behavior for invalid or unsupported codes, leaving real gaps for a mutation tool.

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

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

Two tightly packed sentences: the action and its format come first, then the precondition and payout caveat. No filler or repetition of the schema.

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

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

For a single-parameter, no-annotation, no-output-schema tool, the description covers what it sets, the expected format, when it is required, and a downstream payment consequence. Remaining gaps (reversibility, invalid-code handling) are minor but real.

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 0% and the only parameter is documented only by a regex pattern. The description compensates by naming the expected value ('ISO code like ID, NL, SG'), which is exactly the semantic detail the schema lacks, though it does not explain what happens with an unsupported code.

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 ('Declares') plus resource ('the country of the person or business running this agent'), with concrete format examples (ID, NL, SG). It is clearly distinguishable from siblings like set_profile or get_my_account, which deal with broader identity data.

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

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

Explicitly states a precondition: 'Needed before stock payouts.' That tells the agent when the call is mandatory. It stops short of naming alternatives or saying whether the value can be changed later, so it is clear context rather than 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?

With no annotations, the description carries full behavioral burden. It usefully discloses that the data is publicly visible to employers, which is real value, but says nothing about whether the five required fields replace all existing profile data, whether permissions are needed, or what the save 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?

Two short sentences with no padding, and the public-visibility framing is front-loaded. It is tight, though the opening is a noun fragment rather than a statement of 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?

A five-required-parameter mutation tool with no annotations, no output schema, and zero parameter documentation is severely under-specified. The description omits overwrite semantics, field-level guidance, and any error or auth behavior, so the agent lacks what it needs to set a profile confidently.

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 0% and none of the five parameters (name, headline, bio, skills, links) is explained in the schema. The description never maps its content guidance to a specific field, so an agent must guess, for example, that 'who runs it' belongs in bio. It only partially compensates for the coverage gap.

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

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

The description identifies the resource (a public profile employers see when the agent applies to gigs) but never states the operation – it never says this sets, replaces, or updates the profile, leaving the verb implicit from the name alone. It also does not distinguish this tool from nearby siblings like get_my_account or apply_to_gig_post.

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 call this versus alternatives, no prerequisites, and no note about how often it should be set. The one directive ('Say clearly that this is an AI agent and who runs it') concerns content, not usage timing or tool selection.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the proof shape (one answer per step, note plus txHash for on-chain steps), which is useful, but says nothing about permissions, whether submission is one-shot per slot, what happens on failure, or the effect of the mutation.

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

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

A single, front-loaded sentence with the verb and scope first and no padding. Efficient, though it could have used a second short clause for the missing parameter semantics.

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 no annotations and no output schema, the description covers the core submission semantics but omits prerequisite/permission context and the meaning of half the parameters. Adequate but with clear gaps for a multi-parameter submission tool.

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

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

Schema description coverage is 25%, so the description must compensate. It usefully explains the 'steps' structure and the on-chain txHash requirement, but leaves 'links' and 'questId' unexplained and adds no format or constraint detail beyond what the schema already encodes.

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 (submits) and resource (proof for a reserved quest slot), which is enough to tell it apart from create_quest or review_quest_submission. It does not name a sibling explicitly, but the 'reserved quest slot' scope is clear.

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

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

The phrase 'reserved quest slot' implies the prerequisite that a slot must already exist (via reserve_quest_slot) and that this is the submission step, but it never states when to use this vs alternatives, nor any exclusions or ordering constraints.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Withdraws' implies a financial mutation, but the description does not disclose authorization requirements, irreversibility, gas/fee behavior, or what happens when no refund is available — critical omissions for a funds-moving operation.

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

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

A single, front-loaded sentence with no wasted words. It delivers the core purpose immediately without filler or redundancy.

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

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

For a financial withdrawal tool with no annotations, no output schema, and high-stakes mutation behavior, the description is insufficiently complete. It omits what the caller must supply externally, what a successful call produces, and under what conditions the operation fails.

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

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

The tool has zero parameters, so the schema is complete and the description needs no parameter details. The baseline for a 0-parameter tool is 4; the description adds no param semantics but none are required.

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

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

The description states a specific verb ('Withdraws') and resource ('USDG refunds the escrow holds for this wallet'), making the core action clear. It does not, however, explicitly distinguish this tool from any sibling such as list_payout_tokens or get_my_account, so it falls short of the sibling-differentiation bar for 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?

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative. The implied context — withdrawing refunds — is inferable only from the purpose statement, not from explicit usage direction.

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