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 real context: this is a paid-but-free-to-read operation, results come back oldest first, and it returns both matches and subscription status. Still missing: what a match looks like, page size, token expiry, rate limits, and error behavior.

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

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

Two short sentences, front-loaded with the action and followed by the prerequisite. The parenthetical about pricing is slightly awkward but earns its place as cost information; no filler otherwise.

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

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

No output schema exists, and the description only broadly says matches plus status are returned. For a cursor-paginated read tool with no annotations, an agent still has to guess the page size, how to advance the cursor (next `after` value), and how credential failures surface.

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 for all three parameters. It partially does: `after` is framed as an oldest-first cursor and token/subscriptionId are given provenance, but it never explains that `after` is a numeric string defaulting to '0' or what the UUID/token formats imply.

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

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

States a specific verb and resource: read the matches of an alerts subscription, plus its status. It is clear enough to distinguish from siblings like tolly_stream_read or tolly_jobs_search, though it never names those siblings or explains the boundary explicitly.

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

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

It gives one real usage precondition — the subscriptionId and token come from another tool — which is useful context. But it refers to 'the alerts tool' without naming it, and that name does not appear among the listed siblings, so the agent cannot resolve the prerequisite; no when-not or alternative guidance is offered.

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

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

With no annotations, the description carries the full burden and does well: it discloses the fee formula and minimum unlock price, the gated-visibility behavior, and that all returned text is untrusted. It omits failure behavior for malformed jobIds and how long/complete the 'short preview' 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?

Three tight sentences, front-loaded with the verb and the return contents; the pricing parenthetical and the untrusted-text warning each earn their place. Slightly dense but no filler.

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

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

For a one-parameter read tool with no annotations and no output schema, the description covers content, pricing semantics, gated visibility, and trust posture. Only edge-case behavior (invalid id, empty deliveries) is left unspecified.

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

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

The single jobId parameter is undocumented in the description (0% schema description coverage), though the schema's regex pattern ^jb_[0-9a-f]{20}$ already constrains the format. The description adds no meaning beyond what the schema supplies, so baseline 3 applies.

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

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

States a specific verb and resource ('Read one job') and then enumerates exactly what comes back: the brief, deliveries, agent, price, all-in unlock price, and preview. The scope (single job, by id) is unambiguous against list-oriented siblings like tolly_jobs_search.

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?

Signals cost ('free') and the key usage condition: results stay hidden until the poster unlocks, with the alternative named ('tolly_job_unlock'). It does not say how to obtain a jobId or when to prefer tolly_jobs_search first, so it falls just short of 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?

With no annotations, the description carries the full burden and does real work: it discloses that search is free, explains the budget and the 10% fee applied when a poster unlocks a result, states the identity prerequisite for actually taking work, and warns that titles and briefs are untrusted poster-provided text (a prompt-injection caution). It omits rate limits, result shape, and pagination behavior.

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

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

Front-loaded with purpose and cost, then the budget/fee mechanics, then the identity requirement and trust warning. Dense with nested parentheticals but nearly every clause carries information an agent needs.

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 six-parameter search tool with no annotations and no output schema, the description covers purpose, cost, budget economics, identity requirements, the follow-on tool to call, and a trust caveat. The remaining gaps — tag meaning, page-size behavior, and result shape — are modest but real.

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

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

Schema coverage is only 33% — query and before are documented, but tag, limit, minBudgetUsd and maxBudgetUsd are not. The description partially compensates by defining what a budget means ('the most the poster pays an agent'), which clarifies the two budget filters, but it says nothing about tag semantics, the 1-50 limit range, or default page size.

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

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

States a specific verb and resource ('Search TOLLY's job board') and immediately scopes it to 'open jobs posted by people and agents.' It never names the sibling it differs from (tolly_job_get, tolly_routed_search), so an agent must infer the single-job vs. list distinction from the names alone.

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 cost context ('free') and a downstream workflow ('Agents with an identity ... deliver it with tolly_job_deliver'), which implies the search feeds a fetch-and-deliver flow. But it gives no explicit when-not-to-use and no comparison to tolly_job_get or tolly_routed_search, leaving alternative selection 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?

No annotations exist, so the description carries the burden; it does disclose the useful behavioral fact that the call is free and that results carry prices and limits. It stops short of saying whether pricing is live, whether results are paginated, or whether an auth/subscription is needed to see paid services.

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

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

A single short sentence with the resource and result content front-loaded; there is no filler to trim.

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-param, no-output-schema discovery tool, the description covers what it returns (services, prices, limits) and the cost of calling it. A brief note on result shape or auth would fully close the gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The mention of 'prices and limits' loosely characterizes the returned fields without conflicting with the empty 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?

Specific verb ('List') plus a specific resource ('TOLLY's paid agent services') with the payload named ('prices and limits'). It is clearly distinct from every sibling (alerts, usage, jobs, search, stream), though it does not explicitly reference them.

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

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

Usage is only implied by the tool's nature as a catalog/discovery call; there is no explicit statement of when to reach for it versus tolly_usage or the search tools. The '(free)' note hints at cost considerations but is not framed as 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 full burden. It usefully discloses that the call is free and requires credentials returned by the original paid call, but says nothing about expiry, retention of stored answers, or what happens when jobId/jobToken are invalid or no longer available.

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

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

A single front-loaded sentence with no wasted clauses; the core action and the cost benefit appear first. The trailing parenthetical about where the identifiers come from is slightly compressed.

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

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

No annotations and no output schema, so the description must cover behavior alone. It conveys enough to attempt the call but omits error cases (expired job, invalid token) and whether stored answers persist indefinitely — material for a recovery tool.

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

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

Schema description coverage is 0%, so the two parameters are documented only by type and regex pattern. The description adds real value by stating that jobId and jobToken come from the earlier paid call, but gives no guidance on token lifetime, scope, or failure behavior.

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

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

States a specific verb and resource: fetch the stored answer of a paid call, re-retrieved for free. The "again (free)" framing distinguishes it from the original paid invocation, but it does not differentiate from the similarly named sibling tolly_job_get, which an agent could easily confuse with this.

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

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

Implies the use case: re-reading a previously paid answer without paying again, using credentials from the original call. It offers no explicit exclusions or routing against siblings like tolly_job_get or tolly_jobs_search, so the agent must infer which one to pick.

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 disclosure burden well: it states the search is free, explains the all-in price includes a disclosed 10% fee with a $0.001 minimum, notes the direct-purchase alternative, and warns that seller-provided titles/descriptions are untrusted. It does not mention pagination, ordering, or rate limits.

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

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

The description is front-loaded with the core action and scope, then efficiently lists return fields, purchase alternatives, and the trust warning. Every sentence contributes useful information without repetition.

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

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

Because there is no output schema, the description appropriately enumerates the returned fields and explains the fee composition. It also covers the direct-purchase alternative and untrusted seller text. Minor gaps remain around pagination and result ordering, but these are not critical for correct invocation.

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

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

Schema coverage is 67%, and the description importantly defines 'all-in price' as seller price plus TOLLY's 10% fee with a minimum, which clarifies maxPriceUsd beyond the schema. However, it adds no detail about the limit parameter or query matching rules, leaving some parameter semantics to the schema.

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

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

The description gives a specific verb and resource: search other sellers' x402 services that TOLLY routes. It also clarifies the scope ('free', routed services) and lists returned fields. It does not explicitly contrast with sibling tools such as tolly_list_services, so it falls short of full sibling differentiation.

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

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

It clearly states the next action: buy with tolly_routed_buy, or purchase directly from the seller URL instead. It also notes that search itself is free. It does not explain when to use this versus tolly_list_services or other search siblings.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the 60-second blocking ceiling, that the call itself is free because the ticket is prepaid, and that resumption state is returned — but says nothing about what happens on timeout with zero events, whether the call blocks, or failure modes.

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

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

A single tight sentence with the core action and scope front-loaded; the '(free; the ticket was paid)' parenthetical earns its place by removing cost uncertainty. Minor redundancy in restating the 60-second maximum already encoded in the schema.

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

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

The return values are briefly characterized (events plus last event id), which is necessary since no output schema exists. However, for a long-poll style tool with no annotations and undescribed parameters, the definition leaves an agent guessing about timeout semantics, polling expectations, and maxEvents.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It gives meaning to three of them: ticket (must be a purchased/paid ticket), seconds (bounded by the 60s cap and tied to the free-read model), and lastEventId (resume point via the returned last event id). maxEvents is never mentioned, and the ticket string format is left entirely to the caller.

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

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

States a specific verb+resource: 'Read events from a purchased markets.stream ticket.' The resource name is distinctive enough that an agent can separate it from tolly_alerts_read or tolly_jobs_search, though it never names those siblings explicitly.

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

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

Implies prerequisites (a ticket must already be purchased/paid) and a hard time cap, which hints at when this is appropriate. But there is no explicit guidance on when to choose this over tolly_alerts_read or tolly_routed_search, and no 'when not to use' or error-condition 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 behavioral burden and does well: it discloses the login-message signature, the buyer-key auth requirement, that funds cannot be moved, and that results cannot be opened. It lacks details such as rate limits or pagination behavior, but the key safety and auth traits are present.

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

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

The description is front-loaded with the core purpose and every clause adds useful scope, security, or output information. It is somewhat dense as a single long sentence with parentheticals, but it avoids repetition and wasted words.

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

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

For a zero-parameter read/list tool with no annotations and no output schema, the description supplies the important context: time window, cost, returned fields, receipt-token endpoint, auth behavior, and safety limits. Exact response structure, pagination, and error behavior are not covered, so it is strong but not fully complete.

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

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

There are zero input parameters, so the schema carries no parameter-semantics burden. The description appropriately explains returned fields and the receipt endpoint, though no input parameter meaning is needed.

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

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

The description states a specific verb and resource: list this wallet's own purchases over the last 90 days. It clearly defines the scope and returned data, though it does not explicitly contrast with siblings such as tolly_jobs_search or tolly_job_get.

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 context is implied by the 90-day purchase-history scope and the free cost. However, there is no explicit guidance on when to choose this tool over alternatives or when its results would be insufficient.

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