PMWallets

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered and no contradiction arises. The description contributes only the return content (plan, allowances used, balance), with no detail on permissions, scope, or freshness.

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 filler. It is sparse rather than padded, though it reads more like a field caption than a tool description.

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

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

With no output schema, the description is the only source of return-shape information, and it gives only a high-level listing (plan, allowances used, balance) without structure or units. For a zero-parameter getter this is minimally adequate but leaves the agent guessing at the payload.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.

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

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

The description names the resource (account) and what it surfaces (plan allowances used, balance), which is more than a tautology. But it is a noun phrase with no verb, and it does nothing to distinguish this tool from ambiguous siblings like 'entity' or 'subscriptions'.

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

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

There is no indication of when to call this tool, no prerequisites, and no mention of alternatives among the many siblings (entity, subscriptions, fills). The agent must infer that this is the account-summary getter.

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

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

Goes well beyond the annotations (readOnly=false, destructive=true): it discloses that funds are actually spent, that a stale price is refused with 409 price_changed and nothing is charged, that re-buying the same traders/days returns the earlier order without a second charge, and that 402 means insufficient balance/no paid plan while 409 plan_exhausted means the allowance is gone. Note the no-double-charge rule is effectively idempotent behavior even though idempotentHint=false, but the description is the more informative of the two, not a misleading claim.

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 the core action ('Buy an export...'), and every sentence carries operational weight (spend source, price ceiling, consent, idempotency, error codes). It is a dense single block rather than scannable bullets, but it is not padded.

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

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

For a money-spending mutation with no output schema, the description covers prerequisites, consent, failure codes and repeat-call behavior thoroughly; the only real gap is the shape of a successful order response, which the agent must infer.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: maxPriceCents is defined as the export_quote price the user agreed to and acts as a hard ceiling, and viaPlan is described as removing the from/to/maxPriceCents requirement that the schema leaves purely optional. That conditional-requirement relationship is not derivable from the schema alone.

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

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

States a specific verb+resource with its exact semantics: 'Buy an export: a permanent grant over these traders' daily files, usable at once.' The bounded scope (entityIds, day range, 25-trader cap) and the contrast with export_quote (which supplies the price) separate it cleanly from siblings like export_files, export_options and export_quote.

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 names the two mutually exclusive funding paths and their conditions ('from the balance... from, to and maxPriceCents required' vs 'with viaPlan... no from/to/maxPriceCents'), gates invocation on the user's explicit yes, and points to export_quote as the source of maxPriceCents. That is explicit when/when-not guidance an agent can act on without opening the schema.

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 supply destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description reinforces the destructive nature by stating it stops payment and updates the 'subscriptions' collection, adding useful context beyond the annotations. It stops short of explaining reversibility beyond the idempotent hint.

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 tight sentence with no waste, front-loading the action and immediately qualifying its financial 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 one-parameter destructive tool with annotations and no output schema, this is nearly complete. The only minor gap is not stating whether cancellation is immediate or at period end, which an agent might need.

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

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

Schema coverage is 100% and the single parameter is documented in the schema. The description adds value by clarifying that the id comes from the `subscriptions` list, which helps the agent locate the correct identifier – something the schema does not state.

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 ('Stop following... a subscription') and adds a financial consequence ('stop paying for'). It is clearly distinguishable from the sibling 'subscribe' as its counterpart.

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?

Implied that this is used to end an existing subscription, but no explicit when/when-not or alternative routing is given. Adequate for a simple, single-purpose tool but not a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral nuance — that the full address is only returned once unlocked — but says nothing about rate limits, access tiers, or whether statistics differ by period.

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 filler; the core purpose comes first and the qualifier trails it. The parenthetical phrasing ('the full address only once unlocked') is slightly compressed and ambiguous about who unlocks what, costing a point.

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

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

For a read-only, two-parameter tool with fully documented schema and safety annotations, the essentials are present. However, with no output schema the description could reasonably say what statistics are returned or how 'period' affects them, and it never clarifies the relationship to the sibling 'account' 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 100%, so both parameters ('id' as 12-char handle or 0x address, 'period' as "30d"/"7d") are already documented. The description echoes the handle-or-address distinction but adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource (one trader's statistics) and the two accepted identifier forms (handle or address), which is more than the vague name 'entity' conveys. It stops short of distinguishing this from the sibling 'account' tool, which an agent could plausibly confuse it with.

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

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

There is no guidance on when to use this versus 'account' or 'leaderboard', nor any prerequisite statement. The parenthetical hints that a condition (unlocking) gates full-address lookups, but this is stated as a fact about output rather than as usage instruction.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description adds substantial extra behavior: oldest-first ordering, paging, a 50,000-fill ceiling, decimal-vs-1e-6 unit conversion, per-fill market naming, a 5-minute download link, and 404 meaning. This is rich disclosure beyond the annotations.

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

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

Front-loaded with purpose and packed with only substantive detail across two sentences. Slightly dense clause-chaining (semicolons) but nothing is 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 carries the return-value burden and does so: it describes the fill records, amount units, market naming, and the downloadable CSV link with its expiry. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real context for limit/offset by stating paging is 'a page at a time, up to its first 50,000 fills', which bounds what offset can reach beyond the schema's max 500 note.

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

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

The description names a specific verb and resource: reading one purchased daily file of a wallet's fills for one UTC day. It scopes the operation ('one purchased daily file') in a way that clearly separates it from sibling list tools like export_files, fills, and exports.

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

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

The word 'purchased' implies a prerequisite (buy_export/subscribe) and the 404 note gives useful failure semantics, but no alternative tool is named and no explicit when-not-to-use guidance is given. Usage is implied rather than spelled out.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for adding genuine domain behavior instead: the result is sorted by wallet then day, and a wallet with no fill on a given day produces no file. Those gap/sort semantics are non-obvious and materially affect how an agent interprets results.

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

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

A single dense sentence front-loads the returned shape before the sort order and the edge case, with no filler. It is appropriately sized, though the semicolon-joined clauses make it slightly harder to parse at a glance.

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

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

With no output schema, the description usefully characterizes the returned items (wallet, day, rows) plus ordering and the empty-day edge case. Pagination and the required export-order id are left to the schema, which is acceptable, but a note on default result size would round it out.

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

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

Schema description coverage is 100%, so all four parameters (id, limit, offset, wallet) are already documented in the schema, making 3 the baseline. The description mentions 'wallet' as both a row field and implicitly a filter dimension but adds no syntax or format detail beyond the schema.

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

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

The description states the resource returned (the daily files an export order grants) with its tuple shape (wallet, day, rows), so an agent can identify this as the listing tool for an export order's files. It implicitly contrasts with export_file ('Read one with export_file'), though it never uses an explicit verb like 'list' to name the operation.

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

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

It routes the agent to export_file for reading a single file's content, which implies this tool is for enumerating them. However, it gives no guidance on when to prefer this over exports or export_options, and no prerequisites (e.g. that an export order must already exist) are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds two traits annotations cannot express: that the catalog is free (no purchase required) and the export granularity (one file per wallet per UTC day). It stops short of saying what the returned structure looks like or how the listed days/ranges are meant to be consumed.

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

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

It is a single sentence with no wasted preamble and the resource is front-loaded. The parenthetical and the trailing fragment 'quick ranges priced for one trader in US cents' are dense and ambiguous, making the enumeration harder to parse than the length alone would suggest.

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

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

With no parameters and no output schema, the description carries the full burden of telling the agent what comes back. It lists the three returned elements but leaves 'minimum length' undefined and gives no sense of the response shape, so an agent knows the topic but not the form of the payload.

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 and the baseline is 4. The prose correctly adds no parameter information because none exists.

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?

It names the resource (trade-history export options) and enumerates its contents — available days, minimum length, quick ranges, pricing in US cents — which is more specific than a tautology. However, it never supplies an explicit verb (list/get/show), so the action is inferred rather than stated. A reader can roughly place it against export_quote and buy_export, but differentiation is left to implication.

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

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

There is no when-to-use statement, no prerequisite, and no named alternative among the siblings (exports, export_quote, buy_export). The trailing 'Free.' implies a cost advantage but does not say when to pick this tool over the other export tools. An agent must guess the intended workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by confirming 'Charges nothing' (a cost behavior annotations cannot express) and by naming the return field orderPriceCents, which matters because no output schema exists.

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

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

Two tightly packed sentences with zero filler; the scope and the cost/return facts are front-loaded where an agent will read them first.

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 three-param, no-output-schema read tool, it covers scope, validation constraints, cost, and the key return field. Only the full shape of the quote response is left unstated, which is a minor gap given the key field is disclosed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds semantics the schema omits: the range is inclusive UTC days, must meet a minimum length, and must fall inside the days on sale. Those are real calling constraints, not restatements.

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 ('Price') and resource ('an export of these traders') with the exact scope [from, to]. It also names the sibling it relates to (buy_export), so an agent can distinguish a free quote from the actual purchase without opening either schema.

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

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

The line 'Charges nothing. orderPriceCents is what buy_export would charge from the balance.' clearly frames this as the pre-purchase pricing step versus the paid buy_export. It stops short of an explicit 'call this before buy_export' instruction, but the cost contrast makes the intended usage unambiguous.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the ordering behavior ('newest first') and the returned fields, which is useful, but says nothing about result limits, volume, or history scope.

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

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

A single compact sentence with the resource and the ordering front-loaded and no filler. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the returned fields and ordering, which covers the main gap. Minor omission: no mention of result limits or how many exports are returned for a list-style 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 takes zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. The parenthetical field list is extra value aimed at the return shape rather than 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?

States the specific resource (this account's export orders) and the ordering (newest first), plus the fields returned. It implicitly distinguishes itself from siblings like export_files and export_quote, though it does not name an alternative explicitly.

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

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

Usage is implied – retrieve the current account's export orders – but there is no explicit when-to-use or when-not-to-use guidance relative to siblings such as export_files, export_quote, or export_options. Appropriate but leaves routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds the parts annotations cannot express: cursor exclusivity ('strictly after'), ordering, the implicit one-hour lookback window, and the next/more pagination contract. It does not describe rate limits or the shape of a fill record, keeping it out of 5 territory.

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

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

Three short sentences, front-loaded with the resource/scope, then default window, then pagination. Every sentence carries information an agent needs; phrasing is slightly telegraphic but not padded.

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

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

With no output schema, the description does the necessary work of naming the returned `next` and `more` fields and the loop that consumes them, and annotations carry the safety profile. It leaves unspecified what fields an individual fill contains, which is a minor gap for a read-only list tool.

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

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

Schema coverage is 100% and the schema already documents limit defaults/max, so the baseline is 3. The description goes beyond it by clarifying that sinceBlock is an exclusive cursor, that sinceLogIndex pairs with it, and that omitting sinceBlock yields a default recent window — meaningful additions over the terse schema text.

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

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

The description names the specific resource (fills), the scope (of followed traders only), and the ordering (oldest first), which is enough for an agent to distinguish this from siblings like leaderboard, account, or market. It never explicitly contrasts itself with a sibling, but the resource scope is precise enough that no confusion is likely.

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

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

It states the default behavior when sinceBlock is omitted ('from about one hour ago') and gives explicit pagination procedure ('pass the returned `next` back', 'call again at once while `more` is true'), which is real operational guidance. It does not name an alternative tool or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only the statistical window concept and the entity-per-row grain; it says nothing about the anonymous-vs-signed-in allowance asymmetry already present in the schema, so it clears the lowered bar without excelling.

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

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

Two compact sentences, zero filler, with the core operation (ranking) front-loaded and the grain clarification trailing. Nothing can be cut without losing information.

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

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

For an 18-parameter, no-required-args tool with no output schema, the description covers the core semantics but says little about the return shape beyond row grain or about default behavior (default sort, anonymous sample size, offset restrictions). The schema carries most of that, but a ranking tool with this many knobs warrants a bit more orientation.

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 83%, so the schema already documents the meaningful parameters (sort default, limit cap, minRoi scale, period values, bands). The description adds no param-level meaning beyond the generic 'with filters', which is the correct baseline when the schema does the heavy lifting.

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: ranking Polymarket traders by realized PnL and other stats over a configurable window with filters. It also clarifies the row grain ('one trader, possibly several wallets'), which implicitly separates it from the single-entity `entity` sibling. It stops short of naming an alternative tool the way a 5 would.

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

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

There is no guidance on when to reach for leaderboard versus entity, account, or fills, and no mention of prerequisites such as sign-in level. 'With filters' is an implied usage, but nothing routes the agent between competing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by naming what comes back (question, condition id, slug), which matters because there is no output schema, but it says nothing about behavior when the token id is unknown or not a market outcome token.

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 tight sentence with the resource and the identifying input front-loaded and the returned fields parenthetically grouped. Nothing is padded, though the fragmentary phrasing is slightly less scannable than an explicit verb-first statement.

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 trivial one-parameter read with no output schema, the description covers what the tool resolves and what fields the caller should expect. The only real gap is failure/not-found behavior, which is minor at this complexity level.

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

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

Schema description coverage is 100% and the single parameter is documented as 'outcome token id (decimal)'. The description corroborates this by naming the same key, but adds no format, source, or validation detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific resource (the Polymarket market) and the lookup key (an outcome token id), making the reverse-resolution purpose clear. It is phrased as a noun fragment rather than a verb+resource, but an agent can still tell exactly what it does and none of the unrelated siblings (exports, subscriptions, fills) overlap.

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

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

There is no when-to-use or when-not-to-use guidance, no stated alternatives, and no prerequisites. For a simple single-purpose lookup this is tolerable, but the description offers nothing to help an agent decide between this and other calls.

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

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

Annotations already establish read-only, idempotent, non-destructive closed-world access. The description adds important behavior beyond them: Pro/Max entitlement with 403 plan_required otherwise, rounded amounts, and anonymized trader identity via handle and PnL band. It still omits freshness, ordering, and pagination, so not a 5.

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

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

Two compact sentences, front-loaded with scope and then access and output qualifications. Every clause adds useful information; no repetition or 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 access gating and some return-value characteristics, which matters because no output schema exists. However, it does not state the time window, ordering, pagination, or full result shape, and it gives no sibling routing, so an agent lacks some context needed to interpret 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 100%, including minUsd allowed values and smart flag semantics, so the schema carries parameter meaning. The description adds no parameter-specific guidance and only speaks to output-side rounding and anonymization. Baseline 3 is appropriate.

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

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

The description names the resource concretely: large taker fills across the whole market, not just "radar". It is clear what the tool returns, but it does not explicitly contrast with the sibling fills tool or explain when radar is preferable.

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

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

Usage is implied by "large taker fills across the whole market" and by plan gating, but there is no explicit when-to-use or when-not guidance versus fills or leaderboard. An agent can infer the large-fill use case, but must infer alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. Beyond that, the description adds real context the annotations cannot: plan gating with the specific 403 error code, plus output traits (amounts rounded, wallets identified by handle). It doesn't state result limits or pagination, which keeps it off a 5.

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

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

Two short sentences with no filler, and the core definition is front-loaded ahead of the plan-gating parenthetical. The output-format note is compact and 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 three-optional-parameter read tool with full schema coverage and no output schema, this covers what the tool returns, who can call it, and how values are presented. The remaining gap is that the filtering parameters are never mentioned, so an agent must read the schema to learn that results can be narrowed.

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

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

Schema description coverage is 100%, so q, source, and category are already documented at the field level, and the baseline of 3 applies. The description adds nothing about filtering semantics — notably it never clarifies the official-vs-mine distinction on source or how q matching works.

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

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

The description names a specific resource and predicate: markets where multiple smart-money wallets took the same side in a short window. That is concrete enough to distinguish it from siblings like leaderboard and radar, though it opens with a noun phrase rather than an explicit verb (list/return), leaving the read operation implicit.

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

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

It gives access guidance (Pro and Max plans required, 403 plan_required otherwise), which is useful before calling. It does not say when to prefer this over radar or leaderboard, nor what a caller should do if they only have a free plan.

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?

Without relying on the annotations, it discloses the key non-obvious behavior: the call BILLS THE ACCOUNT per hour unless the plan covers it, plus the 402 (insufficient balance) and 409 (inactive entity, with retry parameter) failure modes. It does not say how the subscription is terminated or that cancellation is a separate tool, and it does not explicitly frame the operation as destructive. These gaps keep it short of 5, but it goes well beyond what the annotations convey.

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 clauses, front-loaded with the core action and effect, then cost, then failure modes. No filler; every clause carries operational information.

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

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

With no output schema and only two parameters, the description covers effect (fills from now on), cost, and error handling. It omits how to stop the subscription and what exactly a successful response looks like, both of which matter for a billed, non-idempotent write.

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 50% — acceptInactive has no schema description — and the description supplies its semantics ('retry with acceptInactive' after a 409). It also reinforces entityId's accepted forms via the schema. It stops short of explaining what accepting an inactive entity implies.

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 concrete verb+resource ('Follow a trader: their fills start arriving from now on') and immediately scopes it in time, which separates it from the historical export tools named in the same sentence. An agent can distinguish this from 'subscriptions', 'fills', or 'export_files' without opening any schema.

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

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

Gives the when ('their fills start arriving from now on'), the when-not/alternative ('earlier fills: the export tools'), and low-level recovery guidance ('409 = no fill for 7 days (retry with acceptInactive)'). This is explicit routing rather than implied usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and a closed world, so the safety profile is covered. The description adds one useful piece of behavioral context – that both active AND paused subscriptions are returned – but says nothing about ordering, pagination, or 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?

A single front-loaded sentence with no filler. It is efficient, though it reads as a fragment rather than a full tool definition and could carry slightly more substance without becoming verbose.

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

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

For a zero-parameter, no-output-schema read tool the safety profile is covered by annotations, but the description never says what a subscription entry actually contains or how the list is returned. Adequate but leaving a modest gap.

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

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

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. The description adds nothing about parameters because there is nothing to describe.

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

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

The description names a specific resource ('the traders this account follows') and clarifies scope with 'active and paused subscriptions,' which clearly separates it from siblings like subscribe and cancel_subscription. The verb is implicit ('list/get') rather than stated, so it falls just short of a perfect score.

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

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

There is no explicit when-to-use guidance or naming of alternatives. An agent can infer this is the read-side counterpart to subscribe/cancel_subscription, but the description itself provides no routing context.

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