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

With no annotations, the description fully carries the behavioral burden: it discloses cost ('PAID (~$0.02)'), null/unresolvable behavior ('returns null and is NOT charged'), return shape ('resolved(bool), resolution(yes|no|null), resolved_at, outcome_verified'), and optional side effects. Nothing is hidden.

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 cost and purpose, then flows into behaviors, return fields, and optional parameter effect. Every sentence carries unique information; 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?

Given no output schema and only two params, the description covers all essential context: cost, input, output fields, optional enhancement, null/uncharged path, and use case. It is self-contained.

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 names both parameters ('Params: condition_id, side') and fully explains side's effect (adds queried_side and correct), but only implicitly defines condition_id as the market identifier via 'for one Polymarket market.' With 0% schema coverage, more explicit semantics for condition_id would help.

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 specifies a concrete verb+resource: 'Resolved-outcome ATTESTATION for one Polymarket market' and details the exact fields returned, distinguishing it from sibling attest tools (sports, kalshi, wallet) by the 'Polymarket market' scope and 'no modeled estimate anywhere' purity claim.

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

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

It gives an explicit use case: 'use it to VERIFY whether a past signal, call, or advertised win-rate was actually right.' It also clarifies unsupported cases ('Unknown/unresolvable market returns null'), but doesn't name alternative tools (e.g., predge_sports_attest) for exclusion.

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 transparency burden. It explicitly discloses that the tool is paid (~$0.005), which is important behavioral context. It also discloses the output scope and content (top-20, market/side/size/price/wallet/score) and the configurable window, though it does not discuss rate limits, permissions, or sort direction.

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: one sentence plus a parenthetical annotation. It front-loads the critical cost warning and packs the output scope, fields, and parameter details into a tight, readable format. There is no wasted prose.

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 single-parameter tool with no output schema, the description is complete enough. It covers cost, result limit, temporal window, market scope, and expected output fields. A caller can decide whether to invoke the tool and predict what it returns without additional lookup.

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 only defines 'window' with enum values, but the description adds the default value (24h) and explains the parameter as selecting the time window. This meaningfully supplements the schema, especially since schema coverage is 0%.

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 returning the top-20 largest single trades across all Polymarket markets, with the specific fields included (market, side, size, price, wallet + score). This is distinct from sibling tools like predge_whales_latest or predge_whale_market by focusing on single-trade size globally rather than whale activity or per-market trends.

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 you want the largest individual Polymarket trades within a 24h/7d window. It does not explicitly name alternatives or exclusions, but the scope is precise enough to guide tool selection without the need for detailed qualification.

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 burden, and it does well: it discloses the PAID nature, the signing mechanism, offline verification, and the attribution to the market's own result. However, it could have been more explicit about potential failures (e.g., network errors) and the format of the signature, though the mention of 'resolved(bool)' and 'resolution(yes|no|null)' adds clarity beyond what the schema implies.

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

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

The description is dense but front-loaded with critical information (PAID, signed, resolved). It packs a lot into a few sentences, but it is somewhat run-on and could be broken into clearer points. Still, every sentence contributes value, notably the verification instructions and edge-case behavior.

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

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

Despite no output schema and no annotations, the description provides a complete picture: it explains what is returned (resolved, resolution, resolved_at), how to verify, when to use, and edge cases. For a tool with only 2 params and no output schema, this is exceptionally complete, leaving little ambiguity 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 0%, so the description must compensate. It does: it explains the 'ticker' as a Kalshi market ticker and 'side' as optional with values yes|no, adding that it adds 'queried_side' and 'correct'. While the schema already includes enum values, the description clarifies their purpose and impact on the output, which is valuable.

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 this tool attests a settled Kalshi market with a signed resolution, distinguishing it from siblings like predge_attest and predge_sports_attest by specifying 'Kalshi' and 'settled market resolution'. It uses specific verbs like 'attests' and 'VERIFIES OFFLINE' and explicitly contrasts with trader data, making the purpose unmistakable.

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

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

The description explicitly explains when to use this tool: for settled market resolutions from Kalshi, and when not (e.g., for trader data, as it states it does NOT attest trader data). It also provides conditions like unsettled markets returning resolved:false and unknown tickers returning null without charge, guiding the agent on expected outcomes for edge 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?

Although no annotations are provided, the description discloses key behavioral traits: it is 'Free' and 'Returns...' data, indicating it is a read-only operation. It also states what is included (API description, network, payTo, endpoints with prices and returned content), which is sufficient for this simple listing tool. It doesn't mention side effects or auth, but given the nature, it is 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 description is extremely concise, using two sentences (and a single-word 'Free.') to convey the key points: cost, output content, and usage timing. It front-loads the most critical fact 'Free' and avoids any fluff, making it easy to parse quickly.

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 has no parameters, no output schema, and is simple in nature, the description covers the main aspects: what it does, its free nature, and when to call it. It could potentially detail the exact structure of the response, but for a discovery tool, the high-level overview is sufficient. The description is complete enough to guide the 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?

The tool has zero parameters and the schema coverage is 100% (empty properties). The description still adds meaning by stating what the tool returns, but since there are no parameters, the baseline for 0 params is 4. The description appropriately requires no parameter explanation.

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+resource: 'Returns the Predge API description, network, payTo, and every endpoint with its price and what it returns.' It clearly identifies the tool's function as listing endpoints and prices, and differentiates it from siblings by positioning it as the first step to discover available endpoints before paying for others.

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 instructs when to use the tool: 'Call this first to see what's available before paying.' This provides clear usage guidance and implies alternatives (other paid endpoints) are to be used after, making the distinction between this discovery tool and the others.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is PAID (~$0.01), which is critical behavioral information. It also mentions the data granularity (daily buckets) and normalization (YES side), which adds transparency about the output. However, it does not describe rate limits, auth requirements, or what 'recent prints' means exactly, but the paid note is a significant disclosure.

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 packs essential information: cost, data type, granularity, normalization, and parameters. It is front-loaded with the PAID warning, which is critical for decision-making. No wasted words; every element 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 the tool's moderate complexity (2 params, no output schema), the description is fairly complete. It covers the purpose, cost, data format, and parameters. It could mention what 'recent prints' means or the output structure, but since there is no output schema, a bit more detail on the return format would be helpful. However, the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains the window parameter with its enum values (7d|30d|all, default 30d) and the condition_id parameter (identifies the market). This adds meaning beyond the raw schema, which only lists the parameters without context. The description effectively documents both 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 tool provides price/volume history for one Polymarket market in daily buckets, normalized to the YES side, plus recent prints. It specifies the resource (one market) and the verb (get history), and distinguishes it from sibling tools like predge_whale_market or predge_markets_movers by focusing on a single market's price/volume history.

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 for retrieving historical market data for a specific condition_id, with a window parameter. It does not explicitly state when to use this vs alternatives, but the focus on a single market's daily price/volume history is clear enough to differentiate from siblings. No exclusions or alternatives are mentioned, but the context is clear.

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

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

With no annotations, the description carries the full disclosure burden. It does reveal the cost (~$0.005) and data source (trade prints), which are useful behavioral traits. However, it omits rate limits, result size, pagination, or any side effects, leaving some uncertainty.

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, tightly packed sentence: cost warning, core function, and parameter details are front-loaded. Every word contributes, and there is no redundancy 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 tool has one optional parameter and no output schema, so the description should clarify return shape, but it only states what the result is conceptually. It lacks details on the list format, number of entries, or sorting criteria. Adequate for a simple query but still incomplete.

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, but the enum itself provides limited meaning. The description adds the default value (6h) and compacts the options, yet it doesn't explain how the window impacts the returned movers. This partially compensates for the schema gap but not fully.

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 explicitly states the tool returns largest YES-price moves across active markets from trade prints, which is a specific action and resource. It clearly differentiates from sibling tools focused on whales, signals, or history.

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 does not provide any when-to-use guidance or compare against alternative tools like predge_market_history or predge_signals_market. The only hint is the paid nature, but no explicit scenarios or exclusions are given.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses that the tool is paid (~$0.03 premium), filters to active markets with whale activity in 24h, uses a smart-money score threshold of >70, and returns net flow, YES/NO volume, and a direction verdict. It does not mention rate limits, auth, or pagination, but for a zero-parameter read tool this is 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 description is a single compact sentence that front-loads the most important constraint ('PAID') and then lists the scope and outputs efficiently. Every phrase earns its place with no filler or redundant 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?

Given that the tool has no parameters and no output schema, the description adequately covers the return content: per-market net flow, YES/NO volume, and direction verdict. It could be slightly richer by saying what 'direction verdict' looks like or clarifying market counts, but for this simple tool it is sufficiently complete.

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

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

The tool has zero parameters and the schema is empty, so the baseline of 4 applies. The description does not need to explain parameters, but it does add meaningful context about the dataset and output fields that would otherwise be entirely missing.

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 a smart-money consensus signal for active markets with whale activity in the last 24h, listing specific outputs: net flow, YES/NO volume, and direction verdict. It does not use an explicit verb like 'get' or 'list', but the intent is evident and distinguishes this from sibling tools by emphasizing 'consensus' and 'premium'.

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 useful context about when this tool applies: active markets with whale activity in 24h. However, it does not explicitly state when to prefer this tool over alternatives like predge_signals_daily or predge_signals_market, nor does it mention exclusions or use 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?

With no annotations, the description carries full behavioral disclosure responsibility. It does well by surfacing the paid cost, claiming edge verification, and describing the 404/not-charged behavior plus known_categories in the error response. It avoids discussing auth, rate limits, or output shape, but those are less critical for this simple read-like 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 only three sentences and front-loads the most decision-relevant detail: the ~$0.02 cost. Every sentence adds value: cost, data scope, and error handling.

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 paid tool with no output schema, the description covers the most important operational details: cost, scope, unknown input behavior, and the kind of data returned. It could be more complete by describing the success response structure or valid category source, but the current level is fairly strong.

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

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

There is only one parameter and the description says 'category' and that unknown categories cause a 404 with known_categories, which adds some meaning. However, the schema itself has no parameter description, enum, or examples, and the description doesn't define what counts as a valid category or where to find the known category list ahead of time.

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 providing edge-verified smart-money consensus scoped to one category, with net flow and direction. It is distinguishable from related signal tools by its category scoping, although it lacks an explicit retrieval verb.

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 behavior is clearly scoped to one category, which implies when it should be used, and the cost/non-charge on unknown categories gives practical guidance. However, it does not explicitly mention when to use the sibling non-category consensus tool instead, or other 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?

No annotations are provided, but the description discloses the key behavioral trait: 'PAID (~$0.02).' It also conveys a read-only digest operation through '24h digest' and lists the data contents. It does not mention output format or failure behavior, but for a zero-parameter data retrieval tool this is a reasonable level of disclosure.

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 segments with no wasted words. It front-loads the critical cost warning ('PAID') and then gives a tight, informative list of digest contents.

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 zero-parameter schema, no annotations, and no output schema, the description covers the essential context: cost, time window, and content categories. It is slightly light on exact definitions like what 'totals' means or how results are structured, but it is complete enough for such a simple 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?

There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since the input schema is empty and schema coverage is effectively complete.

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

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

The description says '24h digest: top markets by whale volume, net flow, largest single bets, totals' with a verb-plus-resource structure that clearly defines what the tool returns. It is easily distinguished from siblings like predge_whales_latest and predge_signals_daily_category by the '24h digest' framing.

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 '24h digest' phrase establishes a clear context for when to use this tool: getting a daily summary of whale activity. It does not explicitly name alternatives or exclusions, but the strong temporal scope and content list provide sufficient guidance for typical selection.

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

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

With no annotations, the description carries the burden and does well: it discloses the cost (~$0.01), the 404 error behavior for unknown categories, and that the response includes the known_categories list. It also implies the tool is read-only. However, it does not describe response format or rate limits, but for a simple lookup it is 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 description is concise and front-loaded with the cost, followed by the core purpose and error handling. The final 'Param: category' is redundant with the schema but harmless. It's a compact, efficient description with almost no fluff, though the redundant parameter sentence prevents a perfect score.

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 purpose, cost, error behavior, and parameter examples, which is solid for a one-parameter tool. However, there is no output schema, and the description does not explain the structure or contents of the 'digest' response. The agent would not know what fields to expect, which is a notable 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 schema only defines category as a string with min/max length (0% coverage). The description compensates by giving concrete examples (politics, economics, sports) and explaining that unknown categories result in a 404 with the list of valid categories. This adds meaningful guidance beyond the raw schema, though it doesn't provide the full valid category list.

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 tool's function: 'The 24h whale digest scoped to one market category' with examples (politics, economics, sports). It distinguishes from siblings like predge_signals_daily (which likely covers all categories) by emphasizing the category scope. The verb 'digest' and resource 'category' are explicit.

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 context: use this when you need a 24-hour digest for a specific market category. It does not explicitly mention when not to use it or name alternative tools, but the sibling context implies predge_signals_daily for overall digest. The category scoping is evident, and the error behavior (unknown category -> 404 with known_categories list) guides the agent on 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?

With no annotations provided, the description bears the full burden. It discloses the cost (~$0.01) and hints at the output (edge-verified smart flow, direction, confidence). Yet it does not state whether the operation is read-only, any side effects, or error behavior, leaving significant behavioral traits undisclosed.

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 concise with no filler words. It front-loads the cost and scope, then explains the verdict and ends with the parameter. Every word contributes value, making it efficient and well-structured.

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 tool with no output schema or annotations, the description covers cost and output essence but omits critical framing for the sole parameter (condition_id) and any boundary conditions like error cases or data freshness. This leaves an agent uncertain about how to procure and correctly use the required input.

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 only mentions 'Param: condition_id' without explaining what a condition_id represents or how to obtain one. Since schema description coverage is 0%, this lack of semantic context forces the agent to guess the parameter's meaning, failing to compensate for the schema's silence.

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's function: providing a smart-money verdict for a single market, using terms like 'VERDICT' and 'decision for one market'. It distinguishes itself from sibling tools like 'signals_daily' and 'signals_consensus' via the 'single-market' scope, though it lacks an explicit verb like 'retrieve' or 'generate'.

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 through 'single-market' and notes the PAID cost, which is a usage consideration. However, it does not explicitly state when to choose this tool over alternatives or provide any exclusion criteria. Context is present but not fully elaborated.

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 burden. It discloses the payment cost (~$0.02), offline verifiability, signing key location, and the null/not-charged behavior for unknown events. This goes beyond basic transparency, though it could mention rate limits or response format details.

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 paragraph but front-loads key facts (PAID, SIGNED, OFFLINE). Every sentence contributes meaningful details; however, it could be more structured with bullets for readability.

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

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

Given no output schema, the description covers return behavior (null for unknown/unfinished), the winner parameter's effect (queried_winner and correct), and the data fields returned. It does not specify the exact response structure (JSON shape or signature format), but it provides sufficient context for basic usage.

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 define each parameter. It explains league (with enum list), event_id (provider event id, pattern hints), and winner (team abbreviation, optional, adds queried_winner and correct). It also explains that unknown league/event yields null, which adds semantic value beyond the schema.

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

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

The description clearly states the tool's purpose: it provides a signed settled game outcome for one finished match, including winner, final score, completed flag, teams, and scheduled time. It specifies the source (ESPN) and the signing (Ed25519), and it distinguishes itself from siblings by emphasizing offline verification and sports-specific attestation.

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 concrete use cases: settle bets, prove track record, ground a wager. It also notes the boundary that unknown/finished events return null and are not charged. However, it does not explicitly contrast with sibling attest tools (e.g., kalshi_attest, wallet_attest), but the sports-specific focus makes it clear enough.

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 explicitly discloses that it is paid (~$0.02), uses Ed25519 signing, verifies offline against a public key, and returns 404 without charging if no resolved trades exist. This provides excellent transparency about costs, verification method, and error behavior, exceeding typical descriptions.

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 redundant and repetitive. It states the signing and verification twice, and lists parameters twice in slightly different order. Phrases like 'PayPal... PAYMENT' and the duplicated mention of 'signed' and 'verifies offline' could be condensed without losing meaning.

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

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

The description provides key information about payment, verification, and error handling, but lacks details about the response structure (e.g., the format of the signed attestation). With no output schema, this omission leaves the agent uncertain about the return value's shape, though it may suffice for basic 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?

Both parameters are described: 'address' with format (0x…) and 'window' with enum values (7d|30d) and default (30d). The description also explains the window's effect on resolved trades and the 404 condition. Minor gap: it doesn't explicitly define 'window' as a time period, but context implies it.

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 tool's purpose: providing a signed attestation of a wallet's track record over resolved Polymarket markets, with offline verification via a public key. It also specifies payment and the condition for no charge, making the 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 description implies usage for obtaining tamper-evident proof of a wallet's win/loss history, but does not explicitly state when to use this tool versus alternatives. It mentions the paid nature and the 404 condition, but lacks direct guidance on when not to use it or comparison with sibling 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?

With no annotations provided, the description carries the burden. It discloses the cost (~$0.02) and the nature of the PnL as 'modeled', which is important caveat. However, it does not explain the potential latency, failure modes, or that this is a paid API call might need user consent. The 'PAID' alert is helpful but incomplete.

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, one sentence with essential info front-loaded ('PAID' and purpose). It wastes no words. A small deduction for lack of line breaks, but overall very 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?

The tool is simple (2 parameters, no output schema), so the description covers the basics. However, it omits details about the output format (e.g., what the PnL curve looks like) and whether the win-rate is over the window. For a paid tool, an agent might need to know more about the return value to decide if it's worth calling.

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, and the description compensates by explaining both parameters: address (0x...) and window (30d|90d|all, default 30d). This adds clarity to the enum and pattern, making it easier for the agent to fill in values. Without this, the schema alone might be 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 clearly states the tool returns a wallet's trade history with a win-rate and modeled-PnL curve. It distinguishes from siblings by specifying 'one wallet' and the PnL curve, differentiating from predge_wallet_profile (likely profile info) and predge_wallet_attest (attestation).

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 mentions the 'PAID' cost, which is a key usage consideration for an AI agent, and lists the parameter options. However, it does not explicitly state when to use this vs alternatives, though the 'PAID' callout and specific output imply it's for in-depth wallet analysis. It lacks explicit when-not-to-use 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 burden of behavioral disclosure. It honestly discloses the monetary cost (~$0.01), the 15-minute delay for trade data, and that only the last 20 trades are included. This is notably transparent for what would otherwise be a paid, read-only data endpoint, though it does not cover edge behaviors like error conditions.

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 a bullet-like list provide cost, purpose, key outputs, and the parameter. Each piece of information is useful and none, is wasted. The most critical fact (paid) appears 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 single-parameter tool with no output schema, this description is mostly sufficient: it tells the agent what parameters will be needed, what the response will contain, cost, and freshness. It does not include any guidance about when to select this over other wallet-oriented siblings, but for simple invocation and a one-address query it covers all essentials.

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 already provides the exact argument: a required string `address` matching `^0x[0-9a-fA-F]{40}$`. The description only repeats 'Param: address (0x…)', adding no meaningful semantic content—no explanation that this is an Ethereum wallet address, no context for what data is keyed on. Because schema description coverage is 0%, the description should compensate, but it only restates the parameter name and a partial 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 clearly identifies the tool as returning 'one wallet's profile' and enumerates exact data items: Predge score, win rates (7d/30d), favorite categories, and last 20 trades. This specifies a concrete resource and distinguishes it from siblings like wallet_history (a record of activity) and wallets_compare (comparison between wallets).

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 context is implied: it is for inspecting a single wallet's profile rather than history, compare, or leaderboard. However, the description lacks explicit 'when to use' or 'when not to use' guidance, and it does not mention sibling alternatives unlike the examples or other 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?

With no annotations, the description carries the burden of disclosure. It reveals that the tool is paid (~$0.02) and describes exactly what results are returned (scores, win rates, modeled PnL, market overlap). It does not mention rate limits or failure modes, but the cost disclosure is a valuable behavioral detail beyond basic operation.

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

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

The description is brief and front-loaded with the most important operational detail (cost). It efficiently conveys purpose, parameter constraints, and expected output in two sentences with zero 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: cost, purpose, metrics, and parameter format. It lacks discussion of potential errors or edge cases, but for a comparison endpoint, this is reasonably complete.

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

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

The input schema already fully defines the 'addresses' parameter with pattern, minItems, and maxItems. The description's 'Param: addresses (2-10 0x… addresses)' mostly repeats this structured information without adding deeper semantic meaning like ordering, duplicates, or edge cases. It is adequate but not additive.

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 action (side-by-side comparison) on a specific resource (wallets) with a defined scope (2-10 wallets) and lists the output metrics (scores, win rates, modeled PnL, market overlap). This distinguishes it from sibling tools like predge_wallet_profile, which focuses on a single wallet.

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 context that this tool is for multi-wallet comparison, which implies when to use it versus single-wallet tools. However, it does not explicitly exclude alternatives or state when not to use it, such as for single-wallet analysis.

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 burden of behavioral disclosure. It usefully adds the paid cost of about $0.01 and clarifies that only resolved markets are considered. However, it does not say what the response items contain, whether pagination exists, or how edge cases like tie-breakers are handled.

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

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

The description is three short, dense sentences: cost, purpose, and parameters. Every segment carries useful information and there is 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?

For a simple two-parameter leaderboard tool, the description covers cost, scope, time window, and limit, which is sufficient for an agent to select and invoke it. It could additionally describe the expected output structure, but that is not essential for this low-complexity 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 input schema provides types, enums, and ranges, while the description adds the missing defaults: window default to 30d and limit defaults to 50. It also clarifies that the 7d/30d are valid window choices and the limit is within 1-100, which compensates for the absence of schema 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 clearly states that the tool returns top wallets by realized win rate over resolved markets, which is a specific metric and scope. It is plainly differentiated from sibling tools such as wallet_profile or wallets_compare by its leaderboard focus.

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 usage context: a paid leaderboard query by realized win rate, with configurable window and limit. It does not explicitly name alternatives or provide when-not-to-use guidance, but the sibling list makes the distinctions reasonably apparent.

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 burden of behavioral disclosure. It explicitly discloses the paid nature ('PAID (~$0.01)'), the time window ('7-day'), and the included aggregate metrics. While it does not mention output shape or edge cases, the cost and time-scope are meaningful behavioral details beyond the schema.

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, efficient sentence that front-loads the cost, then lists the tool's data scope and required parameter. There is no redundancy, fluff, or architectural overhead, every token adds value.

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

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

For a simple tool with only one parameter and no output schema, the description covers the cost, market context, time range, and the exact aggregates included. The main missing piece is a fuller explanation of 'condition_id', but the overall tool is simple enough that this description provides a sufficient level of context.

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

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

Schema description coverage is 0%, and the description only names the parameter via 'Param: condition_id' without explaining what it means, how to obtain it, or the expected format beyond the regex in the schema. The surrounding phrase 'for one Polymarket market' provides a weak hint, but it does not compensate for the lack of semantic 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 clearly specifies what the tool does: it returns '7-day whale activity + aggregates' for 'one Polymarket market'. The list of aggregates (volume, YES/NO split, net flow, unique wallets) further makes the purpose concrete. It also distinguishes itself from siblings like predge_whales_latest by explicitly scoping to a single market.

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

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

The phrase 'for one Polymarket market' implies when to use the tool, and the required condition_id supports that context. However, it does not explicitly state alternatives or when not to use it, such as when needing cross-market or wallet-driven whale data. The usage guidance is present but only implicit.

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 transparency burden. It does well by disclosing the paid cost (~$0.005), the 15-minute delay, and the minimum notional threshold. It also lists the returned fields, which helps the agent understand the tool's behavior, though rate limits, ordering, and error behavior are not mentioned.

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 most important operational detail (paid), then lists the data fields and the parameter. Every word adds value, with no redundancy 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?

For a simple one-parameter list endpoint with no annotations and no output schema, the description is reasonably complete: cost, delay, threshold, output fields, and parameter range/default are all covered. Missing details like response format or ordering would raise it further, but they are not critical for basic usage.

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 only parameter is described as 'limit (1-100, default 50)', which adds the default value and repeats the schema's min/max range. However, it never explicitly states that limit controls the maximum number of trades returned. This is adequate for a single simple parameter but does not fully compensate for the schema's 0% description 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 identifies a listing/retrieval tool for the latest Polymarket whale trades, with specific criteria (≥$10k notional, 15-min delay) and output fields. It differentiates from siblings like predge_wallet_history and predge_bets_biggest, but lacks an explicit verb such as 'List' or 'Returns', so it stops short of a 5.

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

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

There is no explicit guidance about when to use this tool versus the many sibling tools. The use case is implied by the name and threshold details, but no alternatives, exclusions, or contextual prerequisites are provided, leaving the agent to infer applicability on its own.

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