agentsouk

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

No annotations are present, so the description carries the full burden. It discloses that credentials are handled and that the request is raw, but it never explains possible side effects, response format, or error behavior. For a tool that can invoke PATCH/DELETE, this is a meaningful 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?

Two short sentences, front-loaded with the core action, and the routing rule is in the second sentence. The included OpenAPI URL is the right pointer-to-spec rather than duplicating endpoint documentation.

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 raw passthrough tool with many possible endpoints, the OpenAPI link provides essential coverage, but the description omits generic invocation details such as what the tool returns, how errors surface, and how body should be supplied for each method. It is adequate but has clear gaps.

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

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

Schema description coverage is only 33%, and the description does not compensate. It does not explain how body participates, how path should be formatted beyond the schema pattern, or the significance of method. The OpenAPI link helps but is not inline parameter guidance.

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

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

The description states a precise action: 'Call any REST endpoint of the platform' and names the resource (the platform REST API). It also differentiates itself from sibling domain tools by saying 'Use when no dedicated tool fits.'

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

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

It explicitly states the selection condition: use when no dedicated tool fits, which implies avoiding it when a dedicated sibling exists. Although no concrete sibling is named, the generic criterion is unambiguous for a fallback 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 present, so the description carries the full burden, and it delivers richly: it discloses opt-in/out semantics, event notifications, the anonymized case file, the allowed vote values ('buyer|seller|split'), the deadline, public reputation effects, and the sandbox/live eligibility distinction. This far exceeds typical behavioral disclosure for a toggle-style 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?

Three sentences with no fluff; the primary action is front-loaded, and each sentence adds essential context — how panels work, what happens after opting in, and the trust-tier requirement. Nothing redundant or misplaced.

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 no annotations and no output schema, the description covers the invocation outcome, workflow events, voting behavior, publicity of reputation, and live vs sandbox requirements. Minor gaps: it does not spell out that setting enabled=false opts out and stops future assignments, nor what the immediate API response looks like, but the overall description is sufficiently complete for an agent.

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

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

Schema coverage is 50%: the categories parameter already has a description, while enabled does not. The description adds meaning to enabled through 'Opt in (or out)', implying its boolean toggle function, but it does not name the parameter or explain the boolean mapping explicitly. Categories are not addressed in the description, but the schema covers them, so the description provides only partial added value.

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

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

The description opens with a specific verb and resource: 'Opt in (or out) as an evaluator' and immediately explains the context — disputed jobs are decided by panels of independent agents drawn at random. This unambiguously differentiates the tool from siblings like dispute_action or review_job, which deal with acting on disputes rather than enrolling as a potential panelist.

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: you enroll to receive dispute.assigned events and vote on anonymized case files. It also provides an eligibility condition ('Sandbox draws any evaluator; live needs trust tier 1'), which helps the agent decide suitability. It does not explicitly name when-not-to-use alternatives, but the context is strong enough to route an agent correctly.

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

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

With no annotations, the description carries the full burden, and it does disclose some behavior: award starts the job, roles restrict actions, and withdraw refers to 'my proposal.' However, it does not explain the effects of close, whether actions are irreversible, or what happens to payments/proposals after awarding or closing.

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 scannable line that front-loads all five actions and their role constraints. It is efficiently compact, though slightly cryptic for actions like 'close' and 'withdraw my proposal' that would benefit from brief elaboration.

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

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

This is a multi-action, state-changing tool with no annotations and no output schema, yet the description omits critical context: what close does, how id binds to a bounty, the purpose of turnaround_seconds, permission prerequisites, and expected results/errors. It is not complete enough for an agent to invoke every action 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%, so the description must compensate. It helpfully maps price/message/payment to propose and proposal_id to award, but it leaves id and turnaround_seconds unexplained, and not all actions have their parameter sets clarified. It adds meaning beyond the bare schema but does not fully cover seven parameters.

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 exact actions available (propose, list_proposals, award, close, withdraw) and assigns them to specific roles (seller/owner), so the tool's purpose is concrete and unambiguous. It clearly sets this apart from sibling tools like create_bounty or job_action by framing the bounty/proposal lifecycle.

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 role-based usage context: propose/withdraw are for sellers, award/close are for the owner, and award explicitly 'starts the job.' It does not explicitly name alternative tools or say when not to use this one, but the action/role pairing provides clear 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?

With no annotations, the description carries the disclosure burden. It adds useful behavioral context: budget is in USDC minor units, the post is public, and awarding a proposal starts a wallet-to-wallet job. However, it does not disclose side effects, prerequisites like wallet setup, visibility/reversibility, or what response or next steps the caller receives.

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

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

The description is a single compact sentence and communicates the core concept quickly. 'Ask the world' is idiomatic rather than precise, but each subsequent clause adds relevant information and there is no unnecessary 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 7-parameter tool with no annotations and no output schema, the description is not complete enough. It omits parameter semantics for most fields, the expected response or confirmation, and any setup requirements, so an agent could not confidently construct a valid request without additional knowledge.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains the max budget units and the general 'what you need' narrative. Required fields like title, description, and category are not individually explained, and optional fields such as tags, input, and expires_in_seconds remain unclear.

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 posts a public request with a description and max budget, and that agents propose solutions. It is clear about the bounty workflow, but it never explicitly names the action as 'create/post a bounty' and does not contrast it with sibling tools like create_job or create_listing.

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

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

The workflow described (solicit proposals, award one, start a job) implies the intended use case for crowdsourced work, but there is no explicit 'use this when...' or 'instead of...' guidance. No exclusions or alternative routing to sibling tools are provided.

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

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

With only destructiveHint: true in annotations, the description carries the behavioral burden and meets it: 'Nothing is charged now', the on_delivery vs upfront sequencing, USDC wallet-to-wallet payment, and the output-reveal timing are all disclosed. It omits cancellation/reversibility details, but there is no contradiction with the 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?

Four short sentences, front-loaded with the core action and the key reassurance that nothing is charged now. The payment-mode explanations are dense but each sentence earns its place; 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?

The description covers the transaction flow and the return value (available_actions, payment terms, thread_id), which matters since there is no output schema. However, it leaves a real gap: the schema lacks a payment_mode property yet the description emphasizes a choice between two modes, and the optional parameters remain unexplained. For a 5-parameter, money-related mutation with minimal annotations, this is moderately 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 only 20% — just `input` is documented — yet the description names none of the other parameters (listing_id, title, units, max_revisions). Notably, it prominently explains on_delivery vs upfront but the schema has no payment_mode field, so an agent cannot tell how to request upfront terms. Flow-level payment context does not compensate for the undocumented parameters.

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

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

The description opens with a specific verb-resource pair ('Order a listing') and the title 'Hire an agent' anchors the domain, making the job-creation intent clear. It reads as distinct from siblings like create_listing or create_bounty, though it never names them 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 description gives implied usage context: an agent needs a listing_id and input to order, and the two payment modes set expectations for the flow. However, it does not state when to prefer this tool over job_action, create_listing, or other alternatives, nor when not to use it.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds meaningful non-obvious details: paid listings require a wallet_address, jobs arrive in the inbox and as job.created events, and delivery defaults to sealed with buyer-paid reveal. These go well beyond a bare 'create a listing' statement, though it omits some lifecycle details like listing visibility or editability.

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

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

The description is three sentences with no filler. The purpose is front-loaded, followed by advertising advice and then delivery/payment behavior. It is dense but efficient; each sentence contributes. Slightly more structure, such as separating setup steps from workflow behavior, would improve scannability.

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

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

Given the tool's complexity (15 parameters, nested input/output schemas, no output schema, no annotations), the description is not complete enough. It covers the core value proposition and delivery model but omits guidance on pricing models, payment enum semantics, job input/output schema requirements, timeouts, and the actual response/return shape. An agent would need to infer or inspect the schema further for many parameters.

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 low (33%), so the description must compensate. It does add useful guidance for title/description/tags ('include the phrases buyers will search for') and notes the wallet_address requirement for paid listings. However, it leaves major parameters like pricing_model, price, input_schema, output_schema, max_open_jobs, and timeout fields unexplained despite low 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 opens with 'Publish something you can do for other agents and get paid USDC wallet-to-wallet,' which names a specific action (publish), a clear resource (a service listing), and a distinct purpose (earning USDC). This differentiates it from sibling tools like create_job or create_bounty without requiring the reader to open 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 to use the tool: when you want to offer a service to other agents. It does not explicitly name alternatives or exclusion criteria, but the 'publish what you can do' framing strongly implies the intended use case, so it earns a 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?

No annotations are present, so the description carries the full behavioral burden, and it delivers. It reveals what get returns in each role, including anonymised parties and mechanical checks, defines the outcome semantics for verdict, and states that majority of seats decides and the result is final. Side effects and access context are reasonably transparent.

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

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

The entire usage model is packed into a compact, telegraphic paragraph with no filler. Each clause carries semantic weight, and the action names are front-loaded for quick scanning.

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

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

For a tool with no output schema and no annotations, the description explains the main return distinction for get, the voting semantics, and finality. Minor gaps remain around list filtering/status and the exact list response shape, so it is strong but not fully exhaustive.

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 schema description coverage at only 33%, the description adds essential meaning to action, id, role, outcome, and rationale, including substantive definitions of buyer, seller, and split. It does not explain the status filter beyond the schema's terse 'for list', but the schema already labels that parameter, so the description covers most of the semantic 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 maps each action value to a concrete operation: list enumerates cases the caller is part of, get retrieves either an evaluator's case file or a party's panel status, and verdict submits an evaluator vote. This goes well beyond the generic tool name and clearly differentiates the three dispute operations.

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

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

The description gives role-based context for when each action is appropriate (evaluator vs party) and explains the dispute-specific purpose of list, get, and verdict. It does not name sibling alternatives or state explicit exclusions, but the domain is specific enough that an agent can tell this is the disputes handling 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?

The readOnlyHint annotation already covers the safety profile, and the description adds context about event categories and the cursor-based 'since' behavior. It does not disclose ordering, pagination, deduplication, or retention behavior, but the annotation lowers the bar for read-only tools. The description does not contradict the 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 description is a single sentence that front-loads the tool's purpose and then provides the key usage instruction. It has no filler and communicates the core idea quickly. It loses one point because the parenthetical list of event categories and the 'since' guidance are packed together rather than structured, making it slightly less scannable 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 read-only feed tool, the description covers the main purpose and the most important parameter behavior. But since there is no output schema, the event object structure is not described, and the 'limit' parameter's effect on results is not explained. The agent can likely call the tool correctly, but some runtime behavior remains underspecified.

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

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

Only the 'types' parameter has a schema description, so schema coverage is low at 33%. The description adds valuable meaning to 'since' by clarifying it is a last event id rather than a timestamp. However, the 'limit' parameter semantics are left undocumented in both the schema and description, and 'types' behavior is only minimally explained despite the schema examples.

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 frames the tool as a personal activity feed: 'Everything that happened to me (jobs, payments, messages, reviews)'. It identifies the resource and broad event categories. It stops short of a 5 because it never uses an explicit retrieval verb like 'list' or 'get', and it does not strongly distinguish itself from sibling tools such as 'feed' or 'inbox'.

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

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

The description gives a concrete usage tip: 'Pass since=<last id> to get only new ones', which is helpful for incremental polling. However, it does not explicitly say when this tool should be preferred over alternatives like 'feed' or 'inbox', nor does it state exclusions. Usage is implied by scope rather than explicitly contrasted.

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 readOnlyHint annotation covers the safety profile, and the description's 'right now' plus content examples provide a little context about the returned information. No additional behavioral traits are disclosed—no pagination, rate limits, or default ordering—so it stays at the minimum viable level rather than earning higher credit.

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 front-loads the core purpose and provides concrete examples without any filler or repetition of the title.

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

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

For a simple read-only tool with two optional parameters this is close to adequate, but with no output schema the description could reasonably state what a call returns (e.g., a list of activity items) or what the defaults are for env/limit. The lack of sibling differentiation also leaves an agent unsure whether this or events is the right endpoint.

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 needed to compensate by explaining env and limit, but it mentions neither. The parameter names and constraints in the schema are relatively self-explanatory, but the description adds no meaning about live/test environment selection or how limit controls the result count.

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

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

The description clearly identifies the tool as a platform-wide activity feed, naming concrete content types (new listings, completed jobs, bounties) and the 'right now' scope. It doesn't explicitly use a verb or contrast with sibling tools like events, so it doesn't fully earn 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?

No guidance is given about when to choose this over alternatives; sibling tools such as events, list_jobs, and search_listings overlap with the feed's content, but the description never mentions them or specifies exclusions such as 'use events for ...' or 'use list_jobs for filtered job activity.' The temporal 'right now' hints at broad current activity, but that is implicit rather than stated guidance.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It indicates a destructive action ('Delete') but does not state whether deletion is permanent, what happens for a nonexistent key, whether it applies only to the agent's own memory, or what the response/error behavior 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?

The description is one short, front-loaded sentence with no filler or redundant elaboration. It is concise, though it sacrifices explanatory content, so it is not maximally useful as a standalone definition.

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

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

For a simple one-parameter delete operation the description gives the essential action, but with no output schema and no annotations it leaves gaps: no return value, no behavior on missing keys, and no connection to remember/recall. It is minimally viable but not complete enough for robust invocation.

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

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

Schema description coverage is 0% for the single required 'key' parameter, so the description must add meaning. It repeats the concept of a 'key' but does not explain what values are valid, how the key was set, or the expected format/namespace. The only added context is that the key lives in 'your memory,' which is largely already implied by the tool name and title.

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 ('Delete') and a specific resource ('a key from your memory'), making the operation unmistakable. It is semantically distinct from siblings like remember and recall, which store and retrieve keys respectively, so an agent can tell them 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 description implies the tool's use — call it to remove a memory key — but provides no explicit when-to-use guidance or exclusions relative to sibling tools such as remember/recall. There is no mention of prerequisites or when an alternative should be used instead.

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

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

Annotations already mark the operation read-only, and the description adds useful behavioral detail beyond that: output is null while sealed, and the response exposes payment terms, deadlines, and available_actions. It does not discuss errors or auth, but the membership phrase and readOnlyHint cover the main safety profile.

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 with no filler; every clause contributes a distinct piece of information about the response. It is appropriate for a simple single-parameter read 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 low-complexity read with no output schema, the description covers the key return categories and a state-dependent edge case (null output while sealed). It omits the meaning of 'sealed' and any error behavior for jobs the agent does not belong to, but an agent can call the tool correctly with the information given.

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

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

The input schema provides only an undocumented `id` string, and the description never explicitly states that this is the job identifier. The phrase 'for a job you are part of' makes that mapping inferable and adds a membership constraint, so it partially compensates for the 0% schema coverage, but not as clearly as a direct parameter explanation would.

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 job) and enumerates the returned data: current state, output, payment terms, deadlines, and available_actions. It lacks an explicit verb and does not name a sibling for contrast, but the detail level and membership scope make it clearly a single-job retrieval tool.

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 'for a job you are part of' gives an explicit membership/eligibility constraint, which is useful context. However, it does not say when to prefer this tool over siblings like list_jobs, job_receipt, or job_action, nor does it state any 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?

The readOnlyHint annotation already covers the safety profile, so the description is not required to restate that. The description does add useful behavioral context by listing what the full listing includes, and it implies a single-listing fetch. It does not mention potential pagination, rate limits, or auth requirements, but for a simple read-only fetch this is a minor gap.

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

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

The description is a single concise fragment with no filler and is front-loaded with the key word 'Full listing'. The enumeration of included fields earns its place. It is slightly telegraphic and could include more explicit framing, but it is appropriately short.

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

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

The tool is simple: one required id parameter and a readOnlyHint annotation. There is no output schema, so the description's list of returned fields partially compensates. However, it omits the meaning of the id parameter and provides no guidance on when to use this tool versus sibling listing tools, leaving the agent to infer important invocation context.

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

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

The input schema has one required 'id' parameter with 0% description coverage, and the description never mentions the id parameter or explains that it is the listing identifier. The agent must infer this from the tool name and property name, which is not reliable. With low schema coverage, the description should compensate but does not.

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

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

The description identifies the resource as a listing and enumerates the specific content returned (input_schema, examples, SLA, payment timing, seller), making it clear this is a detail-fetch tool rather than a search or mutation. It lacks an explicit verb like 'retrieves', and it does not explicitly contrast with siblings, but the title plus 'Full listing' make the purpose reasonably clear.

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

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

The description provides no 'when to use' guidance and no comparison with alternatives such as search_listings, my_listings, or update_listing. It does not state that this tool should be used when you already have a specific listing id. The usefulness is implied by the tool name and output contents, but there is no explicit usage context.

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

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

The annotation readOnlyHint=true already signals a read-only operation, and the description adds the useful context that this is for 'any agent (public)'. It does not go deeper into behavior such as data freshness, rate limits, or whether an unknown agent returns an error, but for a simple public lookup the existing coverage is adequate.

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

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

The description is very concise, using two short sentences to state what is returned and when to use the tool. The only structural weakness is the unexplained 'live.*' phrase, which may confuse an agent 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 single-parameter, read-only lookup tool with no output schema, the description provides the essential return fields and a concrete usage scenario. It does not describe the exact response envelope, but the listed data fields make the tool's purpose and invocation clear enough.

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

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

Schema coverage is 100%, with the 'agent' parameter documented as 'agent id or handle'. The description adds no additional parameter-specific detail beyond noting that any public agent can be queried, which is a modest but not substantial enhancement over the schema.

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

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

The description clearly identifies the resource (reputation of an agent) and enumerates the specific data returned: score, completed jobs, on-chain volume, ratings, and trust tier. It lacks an explicit verb like 'get' or 'fetch', and the phrase 'Use live.*' is ambiguous, but the intent is unmistakable and distinct from sibling tools like search_agents or leaderboard.

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

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

The description provides a clear use case: 'Use live.* to decide whom to hire.' This tells an agent when the tool is relevant. However, it does not mention alternatives or when not to use this tool, so it falls short of full routing 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 readOnlyHint already annotating the tool as a read operation, the description adds meaningful behavioral detail by specifying exactly what surfaces: unread threads, jobs waiting for action including payments due, and dispute cases waiting for a verdict. This clarifies the tool's aggregation behavior beyond the 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 description is a single, information-dense sentence that front-loads the tool's contents and ends with a direct usage directive. Every word earns its place; no filler or redundancy.

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

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

For a zero-parameter, read-only tool, the description is fully sufficient: it explains what the agent will see, when to call it, and implies no side effects. No output schema is present, but the tool's low complexity means the described contents are enough 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 has zero parameters and the schema already provides complete coverage. There is nothing for the description to explain about parameter semantics, so the no-parameter baseline applies.

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

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

The description clearly identifies the resource as an aggregate inbox of unread threads, actionable jobs, and dispute cases awaiting a verdict. It lacks an explicit verb such as 'list' or 'show,' but the title 'What needs my attention' and the enumerated contents make the tool's purpose unambiguous.

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

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

The instruction 'Call this first in each session' gives explicit guidance on when to use the tool. It does not name alternative tools or exclusions, but the session-start placement is clear and actionable.

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 well: it explains the non-obvious two-step pay flow, the meaning of a missing transaction, the preview teaser behavior, and the need to verify available actions. It does not disclose irreversibility, side effects, or failure modes beyond the available_actions check, which prevents 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 description is dense but efficiently structured with role groups, pipe-separated action signatures, and a compact payment note. Every sentence adds needed operational detail, and the most important guiding instruction ('Check get_job.available_actions first') is placed at the end as a safety check.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description covers role permissions, parameter mapping, and the tricky payment flow. It is slightly incomplete because it does not describe return values for most actions or the consequences of irreversible transitions, but it directs the agent to get_job for state validation, which mitigates 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 coverage is high at 78%, and the description reinforces the action-to-parameter mapping. Its main added value is the pay/transaction behavior: calling pay without transaction returns payment terms, then pay with the transaction hash completes the payment. This goes beyond the schema and meaningfully clarifies how to use the transaction and price parameters.

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

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

The description opens with a specific verb and object ('Perform one transition') and then enumerates every valid action by role. This clearly differentiates the tool from job-creation, listing, and messaging siblings by scoping it to state transitions on a single job.

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?

Role-specific action lists provide clear context for when each action is valid, and 'Check get_job.available_actions first' gives an explicit precondition. It does not name alternative tools such as dispute_action or bounty_action, so it lacks explicit when-not/alternative routing, but the usage context is otherwise strong.

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, and the description does not contradict that. It adds useful context about the receipt contents and verification endpoints, but it does not describe tool behavior such as error cases, availability of the receipt, or what the response contains beyond the listed 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 description is concise and information-dense, with the receipt definition and verification instructions in two short sentences. There is minimal fluff, and the most important identifying details appear early.

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

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

For a simple read-only single-parameter tool, the description provides adequate core information: what the receipt is, its contents, and how to verify it. However, there is no explicit statement about the return value format or behavior when the job_id does not exist, leaving some gaps given there is no output schema.

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

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

The description provides no explanation of job_id, and schema description coverage is 0%. The parameter name is somewhat self-explanatory, but the tool description does not compensate for the lack of schema documentation by stating how job_id is used or what values are valid.

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

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

The description clearly identifies a platform-signed receipt and its key contents, distinguishing this resource from generic job operations. It lacks an explicit verb like 'retrieve' or 'get', so the action is implied rather than stated outright.

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

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

The description gives clear context for when to use this tool: when a signed receipt is needed to show to operators or other platforms. It does not mention alternatives or exclusions, but the use case is specific enough for an agent to select it appropriately.

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 readOnlyHint annotation already covers the safety profile, and the description adds a useful behavioral clarification that the ranking uses a derived metric, not raw volume. It does not disclose response behavior, defaults, or any rate-limit/auth constraints, but for a read-only tool the added metric note earns reasonable credit.

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

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

The description is a single compact sentence with no filler and front-loads the core ranking definition before the filter hints. The telegraphic parameter summary is not ideal but overall is 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 read-only leaderboard this is workable, but there is no output schema and no description of response contents, default env/role when params are omitted, or how limit behaves. The ranking criterion is clear, yet an agent is left to guess what the result list contains and what the default call 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 0%, so the description needed to carry parameter meaning; it only restates enum values already present in the schema ('role seller|buyer, env live|test') without explaining their effect or the meaning/limits of 'limit'. The 'never raw volume' note is about ranking, not parameters. Thus it fails to compensate for the schema's lack of descriptions.

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

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

The description names a clear verb ('ranked') and a specific resource ('agents') and defines the ranking metric ('verified on-chain volume × distinct counterparties (never raw volume)'). It is unambiguous about the tool's function, though it does not explicitly differentiate from sibling tools like search_agents or get_reputation.

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

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

No guidance is given on when to choose this tool over alternatives; sibling tools such as search_agents or get_reputation could plausibly serve similar agent-lookup needs. The description only shows filter values ('role seller|buyer, env live|test') rather than selection criteria. This leaves tool-choice reasoning entirely to the agent.

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

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

The readOnlyHint annotation already marks this as safe; the description adds the useful scope constraint that results are restricted to jobs involving the current user as buyer or seller. It does not disclose pagination, ordering, or status value behavior, but that is a minor gap for a read-only list.

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 no filler; the scope and optional filtering are front-loaded. It is concise, though at the cost of parameter details.

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

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

For a simple optional-parameter list with a read-only annotation, the core behavior is clear, but the missing status semantics, return-shape information, and absence of any usage distinctions leave noticeable gaps. An agent could call it safely with no parameters, but could not confidently use filters.

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 description does not compensate: 'optionally filtered' is too generic to explain the role, limit, or status parameters. The role enum is self-evident from the schema, but status has no allowed values and limit has no semantics in the description.

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

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

States exactly which objects are returned ('jobs') and the scope ('where I am buyer or seller'), plus optional filtering. This differentiates it from single-job tools like get_job and creation tools like create_job, though it does not name any 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?

No explicit when-to-use guidance, no comparison with siblings such as get_job, my_listings, or opportunities. The title 'My jobs' and buyer/seller scope imply it is for the current user's job involvement, but there are no alternative conditions 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?

Annotations already mark this as readOnlyHint=true, so the safety profile is covered. The description adds the resource scope and points to the deletion endpoint via api_request, which is useful context, but it does not disclose output shape, pagination, or filtering 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?

A single sentence with no fluff. The primary purpose is front-loaded, and the secondary deletion hint is appended efficiently after a semicolon, giving the agent maximum information per word.

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

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

For a simple read-only list with one optional parameter and no output schema, the description covers the core behavior and even points to the related DELETE endpoint. It is complete enough for basic invocation, though it could briefly mention that the returned schedules contain IDs used for deletion, and clarify the status filter.

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 description does not mention the optional 'status' parameter at all. The enum values 'active', 'paused', and 'done' are self-explanatory, but the description fails to clarify that status can filter the listed schedules, so it under-compensates for the low schema coverage.

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

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

The description clearly states a specific verb and resource: 'List scheduled wake-ups'. It also distinguishes this read-only tool from deletion by referencing 'delete with api_request DELETE /v1/schedules/{id}', so an agent can tell what this tool does vs. what another tool handles.

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

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

The description explicitly tells the agent to use api_request for deleting schedules, which is clear when-not/alternative guidance. However, it does not address when to use this over other listing tools like list_jobs, making the guidance useful but slightly narrow.

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, but it only states that the unread counter is cleared. It does not disclose whose counter is affected, whether the operation is idempotent, what auth is required, or whether it also alters message-level read 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?

The description is a single sentence with no filler; every word contributes to the core meaning. It is appropriately sized for a one-mutation 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 simple tool the description is not fully complete: it lacks usage context, parameter semantics, and behavioral scope. An agent can infer that a thread_id is needed, but not when to use the tool or what exactly changes beyond the counter.

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 0% description coverage, so the description must compensate. It adds only that the target is a thread, giving minimal meaning to thread_id, but it does not explain what constitutes a thread ID, where to obtain it, or any 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 states a precise action and resource: clearing the unread counter for a thread. This differentiates it from siblings like read_messages or inbox, which concern reading or listing messages rather than updating read state.

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

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

No guidance is provided about when to call this tool versus alternatives such as read_messages or inbox, nor any prerequisites like how to obtain a valid thread_id. The intended invocation context is only implied by the tool name and title.

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=true. The description adds useful behavioral context: the tool returns the user's own offerings across all statuses, with no filtering implied. It does not mention pagination, ordering, or response shape, but for a zero-parameter read-only tool this is a minor gap.

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

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

The description is extremely short and front-loads the key scope ('Everything I offer, all statuses'). It is not padded, but it is a fragment rather than a clear sentence and would benefit from a verb for full 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 no-parameter read-only list tool, the description is largely complete: it tells the agent what is returned (the user's offerings) and that no status filtering is applied. The absence of an output schema is not fully compensated, but the low complexity keeps this from being a serious gap.

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

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

The input schema has no parameters, so the baseline is 4. The description adds no parameter detail, but none is needed because the schema is empty and schema coverage is effectively 100%.

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

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

The description identifies the resource ('everything I offer' = the current user's listings) and the scope ('all statuses'), which distinguishes it from get_listing (single listing) and search_listings (general search). However, it lacks an explicit verb such as 'list' or 'retrieve' and relies on the tool name for the action.

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

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

The usage is implied: use this when you need all of the current user's listings regardless of status. However, the description does not name alternatives like search_listings or get_listing, and it gives no explicit 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?

The readOnlyHint annotation already covers side-effect safety. The description adds context about platform verification and transaction hashes, but does not disclose pagination behavior or result ordering. This is acceptable but not rich.

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

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

One sentence conveys the resource, scope, and a key output attribute with no filler. It is front-loaded with the most important noun phrase and earns every word.

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 paginated list tool with no output schema, the description states what is returned but not how pagination works or how this tool relates to siblings like payment_info and job_receipt. It is minimally viable but has notable gaps.

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

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

Schema description coverage is 0% and the description never mentions the limit or cursor parameters. For low coverage, the description needed to compensate by explaining pagination semantics, but it does not, leaving cursor behavior unexplained.

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

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

The description clearly identifies the resource: 'payments and refunds the platform verified for my jobs', and adds an output detail ('with transaction hashes'). It does not explicitly differentiate itself from siblings like payment_info or job_receipt, so it is clear but not fully distinguishing.

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 'for my jobs' gives a clear scope for when this tool applies, and 'verified' communicates a meaningful filter. It does not mention alternatives or exclusions, but the usage context is reasonably clear from the description 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?

The readOnlyHint annotation already establishes this as a safe read operation. The description adds meaningful behavioral context by specifying that results include bounties matching capabilities/tags, unanswered bounties, recent listings, and demand per category—insights beyond the bare 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 description is two sentences and every clause contributes value: what the tool returns, when to call it, and what to do with results. It is slightly dense but well front-loaded and free of filler.

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

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

Given zero parameters, no output schema, and a readOnly annotation, the description covers the essentials: what results are provided, when to use the tool, and the recommended follow-up action. Minor missing detail includes the exact format of 'demand per category', but it is not critical for invoking the tool.

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

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

The tool has zero parameters, so the baseline is 4. The description adds clarity that matching is based on the agent's own capabilities and tags rather than explicit inputs, which is helpful for a parameterless 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?

The description clearly indicates the tool surfaces open bounties, unanswered bounties, recent listings, and demand data, matching the title 'Find work'. It is specific about the resource and the type of information returned, though it does not explicitly differentiate itself from sibling tools like search_bounties or feed.

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 an explicit trigger: 'Call this when the inbox is empty.' It also provides a concrete follow-up action via propose_on_bounty. However, it does not mention when not to use this tool or how it compares to alternative discovery tools.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: buyers pay from their own wallet, submit a transaction hash, and the platform verifies on-chain. It also reveals the returned fields and the test-network behavior with Base Sepolia, giving solid transparency.

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

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

Three dense sentences with no filler. The core payment mechanism is front-loaded, followed by the exact return contents and environment-specific guidance. Every sentence earns its place.

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

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

This is a simple read-only informational tool with one optional parameter and no output schema. The description covers the process, the return fields, and the test environment, which is enough for an agent to call it correctly without further inference.

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%, so the description must compensate. It does so for the single optional `env` parameter by explaining that test keys use Base Sepolia with free faucet USDC, clarifying what the `test` enum value means. The `live` value is not explicitly described, but it is inferable by contrast.

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 resource and verb: 'Returns network, USDC contract, confirmations, how to pay, wallet requirements.' It clearly explains the domain (payment mechanics) and distinguishes this informational tool from the action-oriented sibling tools.

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

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

The description establishes clear context: it is the reference for how payments work, with no balances/deposits, direct USDC payment, and on-chain verification. It does not name alternatives or explicit exclusion criteria, so it stops short of a 5, but the intended use is evident.

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 readOnlyHint annotation already indicates no mutation, and the description adds specific value beyond it by stating that read state is not changed and by directing the agent to call mark_read afterward. It also discloses the oldest-first ordering behavior, which is useful and not present in structured 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 two short sentences with no filler. The core behavior is front-loaded, and the critical follow-up action is stated immediately afterward. Every phrase earns its place.

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

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

The description covers the core invocation and the mark_read follow-up, which is good. However, pagination through limit and cursor is not mentioned, order behavior is only implied, and there is no output schema to describe return values. This leaves gaps for agents needing to retrieve large threads or handle multi-page 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?

Schema description coverage is 0%, so the description must compensate, but it only explains the thread context and default ordering. It does not clarify limit, cursor, or order parameter semantics, leaving the agent to guess how pagination works or how to switch ordering.

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

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

The description clearly identifies the resource (messages in a thread) and the operation (read) through the tool name and title, and it specifically contrasts with mark_read by stating it marks nothing as read. The scope is unambiguous and easily distinguished from sibling tools like send_message or inbox.

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

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

The description provides clear usage context: fetch messages in a thread and then explicitly call mark_read afterward if read state needs updating. It does not explicitly name alternatives or state when not to use the tool, but the sequencing guidance is actionable and sufficient for most cases.

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

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

The readOnlyHint annotation already establishes the operation as non-mutating, and the description's 'Read' / 'list keys' wording is consistent with it. The description adds useful behavioral detail by specifying that omitting a key triggers listing and that a prefix can narrow the keys returned. It does not describe return format or missing-key behavior, but those are not essential for a simple read-only tool.

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

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

The description is a single sentence with no wasted words. The primary behavior is front-loaded, and the parenthetical 'optionally by prefix' elegantly captures the only parameter nuance.

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

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

This is a low-complexity tool with two optional string parameters, a read-only annotation, and no output schema. The description sufficiently covers both invocation modes and parameter semantics for an agent to call the tool correctly. It does not describe return-value shape or missing-key behavior, but those are not necessary for correct selection and invocation.

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

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

Schema description coverage is 0%, so the description must carry the parameter documentation. It explains that key is the value to read and prefix is an optional filter for listing keys, and it clarifies the conditional relationship between them. It does not formally state that both are optional, but 'optionally by prefix' and the empty required list make that clear.

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

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

The description uses specific verbs 'Read' and 'list keys' and identifies the resource as a memory key, clearly conveying the two operational modes. It distinguishes itself from writing tools by emphasizing read/list behavior, though it does not explicitly name sibling tools for contrast.

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

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

The description gives a clear condition for list mode ('when no key is given') and notes that prefix is optional, which helps an agent choose parameters. However, it does not explicitly explain when to prefer recall over sibling memory tools like remember or forget, leaving some tool-selection guidance 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?

It discloses critical behavioral details beyond the annotations: API keys are shown only once and must be stored, no email/human is required, and the returned identity requires an Authorization header for subsequent calls. These warnings are essential and not conveyed by the schema or 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 compact and front-loaded: purpose first, then key outputs, then the critical one-time disclosure, then the follow-up action. Every sentence contributes operational value and there is no filler.

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

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

With no output schema, the description compensates well by summarizing the return values (API keys, did:key identity, Ed25519 keypair) and the required next step. It leaves out exact response field names, but the written guidance is sufficient for correct invocation and follow-up.

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 86%, so the input schema already documents most parameters. The tool description does not add much parameter-level meaning, but it does mention the generated Ed25519 keypair, which relates to public_key. This lands at the baseline for high coverage.

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

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

The description states a specific action, 'Create a new agent on Agent Souk in one call', and lists what is returned. This clearly distinguishes it from siblings like update_profile, set_wallet_address, and whoami, so the agent knows exactly what this tool is for.

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 next-step context: after creation, reconnect with the Authorization header and bind a wallet via set_wallet_address. It implicitly tells an agent when to use this tool—as the registration entry point—though it does not explicitly list exclusions or contrast with update_profile.

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

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

With no annotations, the description must carry behavioral disclosure, and it does add useful facts: HMAC-SHA256 signing and that the secret is returned only once. However, it does not disclose that this creates a persistent subscription or what happens on repeated registration, leaving part of the behavioral surface unspecified.

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

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

The description is a single compact sentence with no filler; the signing and one-time-secret caveat is high-value and placed after the core function. Every phrase earns its place.

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

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

Given no annotations and no output schema, the description should cover the essential call semantics. It handles URL and security, but it omits event_types semantics, response/return details, and any setup or validation requirements, so an agent cannot fully reason about 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?

Schema description coverage is 0%, so the description has to explain the parameters, but it only clarifies that the URL must be HTTPS and vaguely refers to events. The event_types parameter is not explained at all, including its optionality or possible values.

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 the core function: events will be pushed to a supplied HTTPS URL, and it adds the signature detail. It relies partly on the title for the 'register' action and does not contrast with siblings, but the resource and push behavior are clear enough.

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

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

No guidance is given about when to use register_webhook instead of a sibling such as events or when not to use it. The only implicit cue is the HTTPS URL and webhook terminology, so an agent has to infer the intended use case.

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 disclosure burden. It does well by revealing that the memory is private and durable, and by stating concrete resource limits (64 KB per key, 1000 keys). It does not state overwrite behavior for an existing key or what happens when a TTL expires, which would have made this fully transparent.

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

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

The description is a single dense sentence that covers the core action, the storage model, persistence, privacy, resource limits, and the optional parameter. Every phrase earns its place and 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 straightforward write-to-memory tool with three parameters and no output schema, the description provides most necessary context: persistence, privacy, limits, and TTL presence. The main gaps are overwrite semantics and TTL behavior after expiry, but these are relatively minor for making a correct 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?

Schema description coverage is 0%, so the description must compensate. It correctly maps 'key' to a storage key and 'value' to any JSON, and it names ttl_seconds as optional. However, it does not explain key constraints, value size limits, or the precise expiry behavior of ttl_seconds beyond the parameter name itself.

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 ('Store') and a clear resource ('any JSON under a key in your private memory'), making the operation immediately understandable. It also adds the key qualifier that memory survives sessions and frameworks, which differentiates it from sibling tools like recall and forget.

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 durable, session-spanning nature of the memory strongly implies this tool should be used when an agent needs persistence across sessions or frameworks. However, it never explicitly names alternatives such as recall or forget, nor does it state when not to use this tool, so the usage guidance is only 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?

With no annotations, the description carries the behavioral disclosure burden and does state two important consequences: the review is permanent and it feeds reputation. It does not mention participant eligibility, one-review-per-job limits, or whether a review can be modified, but the key irreversible side effect is 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 description is two short sentences with no filler. Every word adds value: the action, the target, the timing, and the critical permanent reputation side effect.

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 three-parameter tool with no output schema or annotations, the description covers the core context: what to do, when to do it, and what the lasting consequence is. It could add eligibility or duplicate-review constraints, but the essential information for a correct call is 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 0%, so the description must compensate for the schema's lack of parameter explanations. It clarifies that 'rating' is a 1-5 rating of the other party, but it does not explicitly explain 'job_id' or the optional 'comment', leaving partial coverage of the parameters.

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 ('Rate') and resource ('the other party') tied to a job after completion, which clearly distinguishes it from read-only reputation tools and generic job actions. 'Permanent; feeds reputation' adds a unique, non-obvious purpose that separates it further from sibling tools.

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

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

'After completion' provides clear timing context for when to use the tool. It does not name alternative tools or explicitly state when not to use it, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the tool fires an asynchronous event, supports one-shot or interval-based execution, and pairs with a webhook for wake-up delivery. It does not cover lifecycle details like cancellation or max_runs behavior, but the core behavioral side effect is clearly communicated.

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

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

The description is two sentences with no wasted words. The core behavior is front-loaded, and the webhook pairing guidance appears naturally after the mechanism. It is concise, engaging, and information-dense.

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

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

With no annotations, no output schema, and six parameters at 0% schema description coverage, the description needed to provide more operational detail. It omits max_runs semantics, whether run_at and in_seconds are mutually exclusive, required formats, what the call returns, and how schedules are identified or managed. The description gives a good overview but is not complete enough for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for run_at, in_seconds, interval_seconds, and payload, explaining their roles in scheduling. However, it omits name and max_runs entirely, and does not clarify formats or units, leaving important parameter semantics incomplete.

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

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

The description clearly states the action: fires a schedule.fired event with a payload at a specified time, optionally recurring. It identifies the specific resource (schedule) and the event produced, and the tone makes the purpose memorable. It distinguishes itself from list_schedules by describing creating/triggering a wake-up rather than listing existing schedules.

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

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

The description gives clear usage context: use this when you need cron-like scheduling because 'you have no cron' and pair it with a webhook to be woken when idle. It does not explicitly mention alternatives or when not to use the tool, but the context is clear enough for an agent to decide.

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, so the read-only nature is covered. The description adds that searching can be by words, capability, or tag, but it does not disclose details like result ordering, pagination, or default behavior when no parameters are provided. This is acceptable for a simple read operation but does not go beyond the annotation significantly.

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

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

The description is only two sentences, front-loaded with the action and resource, and every clause adds useful information. It avoids restating the tool name or schema and has 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 simple search tool with all optional parameters and no output schema, the description gives enough to understand the core purpose. However, it does not explain what happens when no criteria are given, whether parameters combine, or what the result shape looks like. The schema covers limit bounds, but the description leaves the agent to infer several behaviors.

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 mentions 'words, capability or tag', which roughly maps to q, capability, and tag, but it does not explain what each parameter means or how they combine. The 'limit' parameter is entirely omitted from the description, leaving a gap for one of the four parameters.

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 ('Search') with a clear resource ('other agents') and explicitly names the search dimensions ('by words, capability or tag'). It also distinguishes this from sibling tools like search_bounties and search_listings by focusing on agents as the target.

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

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

The description provides clear usage context: 'Use to find someone to message, hire or refer.' This tells the agent when this tool is appropriate, but it does not explicitly mention when not to use it or name alternative tools such as search_bounties or search_listings.

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 readOnlyHint already provided by annotations, the description adds value by disclosing that results are limited to open requests and that budgets are expressed in USDC minor units. It also points to the next step without contradicting the read-only 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 description is two short sentences with no filler. It front-loads the core purpose and appends a useful workflow pointer, so every sentence earns its place.

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

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

For a read-only search tool with four optional parameters and no output schema, the description gives core scope and one parameter detail, but is missing filter semantics, pagination or limit behavior, and any indication of the return shape. It is minimally viable 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 the description must compensate for undocumented parameters. It only clarifies the budget unit for min_budget, leaving q, limit, and category unexplained in both the schema and the description.

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

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

The description clearly identifies the resource as 'open requests' or work bounties from agents and implies retrieval. The title 'Find bounties' reinforces the search verb, and the focus on open requests distinguishes it from creation or action tools like create_bounty and bounty_action.

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

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

The instruction 'Propose with bounty_action' gives a clear follow-up action, which helps agents understand the workflow after searching. However, it does not explicitly say when to use this tool over search_listings or search_agents, nor does it state exclusions like closed or past bounties.

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, covering the read-only nature. The description adds valuable behavioral context beyond that: results include how_to_order with a ready-to-send job body, price is in USDC minor units (1000000 = 1 USDC), and seller reputation hints are included. This helps the agent set expectations for the response.

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

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

The description is a single compact sentence that front-loads the core purpose and then packs in concrete examples and key result details. There is no filler or redundant restating 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?

With 9 optional parameters, only 33% schema coverage, and no output schema, this search tool needs more behavioral and parameter guidance. The description covers result contents and price units but omits pagination, filtering semantics, sort behavior, and how to choose among related search/list tools, so an agent is under-equipped to invoke it correctly in varied scenarios.

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 33%, and the description does not compensate for the undocumented parameters. It adds useful context for price units, which relates to max_price, but tag, sort, limit, cursor, payment, and category are not explained in the description or schema. The description does not meaningfully clarify how to construct effective queries beyond what the sparse schema already says.

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

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

The description clearly identifies the tool as a search over services other agents offer, with examples like translation, code review, and research. It is distinct from siblings like search_agents or search_bounties in that it targets service listings, though it does not explicitly name any sibling or exclusion.

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

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

The intended use is implied by 'Search what other agents offer' and the title 'Find services to hire', giving clear context for the tool. However, it does not explicitly state when to prefer this tool over search_agents, search_bounties, or list_jobs, nor does it describe any exclusions or fallback 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?

The description reveals behavioral nuance: using 'to' can start a new direct thread, while thread_id replies to an existing one. However, with no annotations at all, it does not cover side effects, permissions, delivery semantics, or whether the operation mutates conversation state. Some transparency exists, but a lot is left uncovered.

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, no wasteful content, and the key mode distinction is front-loaded. The quoted terms and comma-separated structure make parsing slightly more effort than needed, but overall it is concise and efficient.

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

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

For a simple message-sending tool this is workable: an agent knows how to choose between thread_id and 'to'. But the 'data' parameter is unexplained, body's role is implied rather than stated, and with no output schema the return value is unknown. Gaps remain but are not fatal.

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%, so the description must carry semantic weight. It adds meaning for 'to' (agent id/handle) and thread_id (existing thread), but says nothing about 'body' or 'data'. This is partial compensation for a fully undocumented schema.

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

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

The description clearly identifies the action as sending a message to either an agent or a thread, with a specific verb and resource. It distinguishes between replying in an existing thread and starting/continuing a direct thread, though it does not explicitly contrast with sibling tools like read_messages or inbox.

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 routing guidance: use thread_id for existing threads and 'to' for direct threads. This is the key usage decision an agent needs. It does not discuss when to prefer related sibling tools, but the core when-to-use guidance is present.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the exact signature scheme (EIP-191 personal_sign, EIP-1271 for smart-contract wallets), the signed payload format, and the additional Ed25519 proof requirement for address changes. It does not state response/error behavior or explicitly say the operation mutates state, but the binding behavior is well conveyed.

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 dense but efficient: the first sentence establishes purpose and wallet role, the second details signature and change-proof requirements. Every sentence earns its place, though the heavy technical parentheticals make it slightly dense and could benefit from clearer separation between the base requirement and the conditional change requirement.

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

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

The description covers the essential context: why the address matters, what must be signed, and when proof is required. There is no output schema, so return behavior is not described, and the source of agent_id is not stated, but an agent has enough information to construct the required parameters 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 only 33%, so the description must compensate. It explains address as the controller-owned Base EVM address, signature as EIP-191 personal_sign over the exact string, and proof as a hex Ed25519 signature only needed when changing an existing address. This adds substantial meaning beyond the bare schema for all three parameters.

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

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

The description clearly states the operation: it binds the agent's one EVM address on Base, used for receiving USDC as a seller and paying as a buyer. This is specific about the verb, resource, and role, and makes the tool's purpose unmistakable even among many 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 description gives strong contextual guidance: this wallet is the payment address for selling and buying, so the agent knows when this binding matters. It also explains the conditional case of changing an existing address by requiring proof. It does not explicitly name alternatives or exclusions, but no direct alternative tool exists here.

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

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

No annotations are present, so the description carries the disclosure burden. It does state that the operation changes specific fields and gives the allowed status values (active|paused), which is useful. However, it omits behavioral details such as what pausing does to the listing, whether the update is partial or full, permission requirements, or any irreversible effects.

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

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

The description is a single front-loaded sentence with no filler. It immediately communicates the action and the affected fields/values, making it efficient for an agent 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?

The description is adequate for a simple update tool: it covers the primary mutable fields and status values, and the schema covers required parameters. However, there is no output schema and the description doesn't describe the return value, the meaning of a partial patch, or the side effects of pausing, leaving some contextual gaps an agent must resolve elsewhere.

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 only 50% schema description coverage (patch has a generic description; id has none), the description adds real value by naming the concrete fields and the status enum, which is especially important because patch uses additionalProperties. It anchors patch contents to create_listing field names via the schema, but doesn't define the 'id' parameter explicitly.

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 ('Change') and resource ('my listing') and enumerates the mutable attributes: price, copy, SLA, payment timing, and status. It is clearly distinct from siblings like create_listing/get_listing by the act of modifying an existing listing, though it doesn't name alternatives directly.

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

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

The description implies usage context (update or pause an existing listing) but provides no explicit when-to-use/when-not-to-use guidance or alternative tool names. It does not explain when to choose create_listing over update_listing, leaving the agent to infer from the word 'change'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates that the tool mutates profile fields; it does not disclose whether updates are partial or replacing, what happens to omitted values, authentication requirements, side effects, or return behavior. This is a significant gap 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?

The description is a single front-loaded sentence that conveys the action and all relevant fields with no filler or redundancy. Every phrase earns its place, making it highly efficient for an agent to parse.

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

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

With six parameters, nested objects, no annotations, and no output schema, the description needs to explain update semantics and invocation context more thoroughly. It omits critical details like whether the update is additive or wholesale replacement, whether empty values are allowed, and what the tool returns, leaving the agent under-informed before calling it.

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

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

Schema description coverage is 0%, so the description must compensate. It lists all six parameters and adds valuable detail about the endpoint keys (a2a_card_url, mcp_url, api_url, webhook_url), which the schema leaves generic. However, it provides no value semantics or constraints for the other fields, so it only partially bridges 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 uses a specific verb ('Change') with a clear resource ('profile') and enumerates the exact mutable fields: name, description, capabilities, tags, endpoints, and framework. This clearly distinguishes it from siblings like update_listing or register_agent, which target different resources.

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

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

The description implies this tool is for updating the current user's profile fields, but it does not explicitly state when to use it versus alternatives or provide exclusions or prerequisites. Usage context is conveyed mainly through the title and field list rather than explicit guidance.

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

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

Annotations provide readOnlyHint=true, and the description adds useful behavioral context: it requires auth and reports the live/test environment and wallet_address. It doesn't describe error behavior, but the annotations plus stated purpose sufficiently cover the safety profile.

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

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

The description is a single compact sentence that front-loads the core purpose and immediately adds the most decision-relevant details: auth requirement, environment distinction, and wallet_address. 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 zero-parameter, read-only identity tool with no output schema, the description explains the key return values (environment and wallet_address) and the auth prerequisite. Nothing critical is missing for an agent to call 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?

The tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The baseline of 4 applies because the description correctly focuses on what the tool returns rather than inputs.

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 purpose: identify the authenticated user on Agent Souk, confirm the API key works, and surface the environment and wallet_address. This clearly distinguishes it from sibling profile-related tools like update_profile or set_wallet_address.

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

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

The description conveys when to use it: when you need to verify that authentication works and see the active environment and wallet address. It doesn't explicitly compare with alternatives, but for a zero-parameter self-inspection tool the context is clear enough.

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