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

Annotations provide readOnlyHint and openWorldHint. The description adds context about the ranking methodology and returned fields (rank, composite score, identity, P&L, win-rate, volume), which is consistent with a read-only 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 two concise sentences plus a list of returned fields. Every sentence provides essential information without redundancy.

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

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

The description covers the tool's purpose, usage, returned fields, and ranking criteria. It is complete given the absence of an output schema and the simplicity of the tool.

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

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

Schema coverage is 100% with parameter descriptions. The description adds value by explaining the ranking algorithm behind the default preset, which complements the schema's preset description.

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

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

The description clearly states the tool ranks top Polymarket traders by genuine skill metrics (calibration, alpha, risk-adjusted return) and explicitly distinguishes from vanity metrics. It differentiates from sibling tools like polyrank_get_trader_calibration and polyrank_get_smart_money_report.

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 includes a clear use case ('find traders worth copying or studying') but does not mention when not to use or specify alternative tools, though context from siblings is available.

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 adds moderate context beyond the annotations (e.g., 'differentiated signal', specific data fields). However, annotations already declare readOnlyHint and openWorldHint, so the behavioral burden is partially lifted. No contradictions.

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, well-structured sentence that front-loads the core purpose and then lists additional data. Every word adds value, with no redundancy.

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

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

For a single-parameter tool with clear annotations, the description sufficiently covers what the tool does, what data it returns, and how to invoke it. The output is adequately described without needing an output schema.

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

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

The sole parameter 'market' is fully described in the schema (100% coverage). The description echoes the schema explanation but adds no new semantic depth, so 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 clearly states the tool provides 'Smart-money consensus on a Polymarket market vs the market mid' along with volume, fills, positioner counts, and top holders. It distinctly differentiates from siblings like polyrank_get_movers and polyrank_get_smart_money_report, which focus on different aspects.

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

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

It explicitly explains how to use the tool (via conditionId or market slug) and lists the specific data returned. While it does not explicitly exclude alternative tools, the purpose is clear enough to guide selection among siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds limited behavioral detail beyond confirming it returns top movers. No contradictions.

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 concise sentences covering purpose and core parameters without extraneous detail. Efficient and easy to parse.

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

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

For a read-only tool with full schema coverage and no output schema, the description adequately explains return format (top climbers and fallers) and constraints (preset, lookback). Minor omission: does not specify that limit controls rows per direction, but schema covers that.

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 parameters are well-documented. The description mentions 'ranking preset' and 'lookback window' but adds no additional meaning beyond the schema definitions.

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 traders whose skill rank moved (climbers and fallers), specifying 'leaderboard momentum' and differentiating from sibling tools that show static ranks or specific trader skills.

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 momentum analysis ('climbed or fell the most recently') but does not explicitly mention when not to use or list alternatives. The context of sibling tools helps narrow 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 provide readOnlyHint=true and openWorldHint=true. The description adds 'Live' context and lists returned fields but does not disclose additional behaviors like rate limits, auth requirements, or data freshness guarantees beyond what annotations cover.

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 sentences with zero waste. First sentence efficiently enumerates returned data, second provides usage directive. Every word 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 zero-parameter tool with no output schema and simple purpose, the description completely covers what the tool does and when to use it. No gaps given the tool's low complexity.

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 no parameters (zero params, 100% schema coverage). Description adds no parameter info which is appropriate since none exist. Baseline 4 is justified per guidelines.

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 'Live Polyrank coverage and the canonical skill-metric count', listing specific data points like wallets ranked, trades indexed, markets covered, skill metrics count, and earliest year. This distinguishes it from sibling tools which focus on leaderboards, traders, or market-specific metrics.

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 advises 'Use this instead of hardcoding "N wallets / N metrics"', providing clear when-to-use guidance. It does not explicitly mention when not to use, but the sibling context implies alternatives exist for other purposes.

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 adds context beyond annotations: it discloses that the tool returns live data on 'big wins just banked (realized profit), sharp-money moves, the biggest recent trades, trending markets by volume, and markets where Polyrank consensus diverges'. This aligns with readOnlyHint and openWorldHint. No contradiction.

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

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

The description is a single concise paragraph with no wasted words. Key information is front-loaded, and every sentence adds value. It efficiently conveys the tool's purpose and output.

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 lacking an output schema, the description enumerates the types of data returned (big wins, sharp-money moves, etc.), providing sufficient context for an agent to understand what the tool provides. For a zero-parameter snapshot tool, this is 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 schema description coverage is 100%. The description does not need to add any parameter semantics; it appropriately describes the output content.

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 live Polymarket activity including big wins, sharp-money moves, largest trades, trending markets, and consensus divergence. The phrase 'what is smart money doing right now' succinctly captures its purpose and distinguishes it from sibling tools like leaderboard or trader-specific reports.

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 recommends the tool for the query 'what is smart money doing right now', providing a clear use case. However, there is no explicit guidance on when not to use it or mention of alternative tools, but the context signals and sibling names imply appropriate 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 indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds some transparency about the report content (sections) but does not disclose any behavioral traits like response size or performance. Since annotations provide the core behavioral context, a 3 is appropriate.

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 sentences with zero wasted words: the first lists the tool's output components, the second tells how to acquire the required input. Perfectly front-loaded and efficient.

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

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

For a simple get-report tool with one parameter and no output schema, the description is complete. It details what the report contains and where to get the identifier. No additional context is needed for correct invocation.

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

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

The schema already documents the 'week' parameter with description and example format. The description reinforces this by stating 'Report/week id from the archive' and gives an example '2026-w26'. This adds clarity beyond the schema, earning a 4 rather than a 3.

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 full weekly Smart-Money Report with specific sections (big wins, skill-rank movers, etc.), and distinguishes it from the sibling tool polyrank_get_smart_money_reports by instructing to pass the week/report id from that list.

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

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

The description gives a clear usage pattern: obtain the id from polyrank_get_smart_money_reports and then pass it here. It does not explicitly state when not to use this tool or mention alternative sibling tools, but the purpose is well-defined enough for an agent to infer the appropriate context.

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

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

Annotations (readOnlyHint: true, openWorldHint: true) already indicate read-only and dynamic data. The description adds that the output is a list of report ids/weeks with summaries, which provides behavioral context about the return format. It does not disclose other traits like pagination or latency, but with annotations covering safety, this is adequate.

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

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

Two sentences with no wasted words. The purpose is front-loaded and the instruction for fetching a full report is efficiently included. Every sentence serves a purpose.

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 listing tool with one optional parameter and no output schema, the description provides enough context: it explains what the output contains (list of report ids/weeks with summaries) and how to get more details. Annotations cover read-only and dynamism. No gaps remain.

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 documents the only parameter 'limit' with description, min, max, and default (100% coverage). The tool description adds no additional explanation for the parameter, so it relies on the schema, making a baseline score of 3 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?

Description clearly states the tool lists Polyrank weekly Smart-Money Reports with ids/weeks and summaries, and directly differentiates itself from the sibling tool polyrank_get_smart_money_report for fetching a full report. The verb 'list' and resource 'archive of reports' are specific.

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?

Provides clear context for when to use this tool (to get a list of reports) and explicitly mentions the alternative polyrank_get_smart_money_report for fetching a full report. However, it does not state any preconditions or when not to use this tool.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. The description adds context that only resolved, won positions are included, with a real cost floor, and identities are masked. This provides useful behavioral detail beyond what annotations offer, with no contradiction.

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

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

The description is two sentences, front-loaded with the core purpose and key details. Every sentence adds value without unnecessary 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 5 parameters, 2 enums, and no output schema, the description covers the core concept and one optional filter but omits return format details, explanation of sort keys, and limit behavior. It is adequate but not fully comprehensive.

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 baseline is 3. The description mentions the category filter but does not add extra meaning for parameters like sort, dir, limit, or since_days. It provides minimal additional value over the schema.

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

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

The description clearly states the tool returns the biggest return-on-cost resolved Polymarket bets (won positions with a real cost floor), acting as a hall-of-fame of single trades by ROI multiple. This specific verb+resource combination distinguishes it from siblings like leaderboard or pulse.

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 optional category filtering and identity masking but does not explicitly state when to use this tool versus alternatives like polyrank_get_leaderboard or polyrank_get_trader_skill. Usage context is implied but not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds context about returning a masked skill teaser and the limitation of not providing full identity without signing in. It does not cover error cases or behavior for invalid tids, but is consistent with annotations.

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

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

The description is extremely concise with three sentences covering purpose, source of tid, return type, and limitation. Every sentence adds value, and the most important information is front-loaded. No unnecessary words or repetition.

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

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

Given the tool's simplicity (one parameter, no output schema) and the presence of related sibling tools, the description provides adequate context: what it does, input source, return type, and a key limitation. It could mention error handling or tid validity but overall is sufficient for an agent to use it correctly.

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

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

The schema already describes the 'tid' parameter as an opaque trader id from a masked row (100% coverage). The description adds value by specifying where the tid originates (leaderboard, pulse, movers, top-ROI rows), which helps agents understand the context of the parameter 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 looks up a trader by an opaque masked id (tid), specifying the source surfaces (leaderboard, pulse, movers, top-ROI rows). It explicitly distinguishes from wallet lookup and mentions the return type (masked skill teaser), making the purpose clear and specific.

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 explains when to use the tool (when you have a tid from masked rows) and when not (full identity resolution requires signing in). However, it does not explicitly name alternative tools like get_trader_calibration or get_trader_skill for other use cases, leaving some ambiguity.

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 and openWorldHint. Description adds meaningful behavioral context: explains calibration as skill signal and specifies return data (bins + total resolved count). No contradictions.

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?

Extremely concise: two sentences, no filler. Front-loaded with the core function and immediately clarifies the concept of calibration.

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?

Sufficient for a simple tool with one parameter and no output schema. Explains what is returned and the underlying concept. Could elaborate on bin format or interpretation, but not strictly necessary.

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

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

Schema coverage is 100% with one parameter well-described. Description adds no additional parameter semantics beyond the schema's definition of address 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?

Clearly states it returns a 10-bin reliability diagram for a wallet's calibration, distinguishing it from siblings like polyrank_get_trader_skill which likely provides a single skill score. Verb 'get trader calibration' and resource are specific.

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

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

No explicit guidance on when to use this tool versus alternatives like polyrank_get_trader_skill. Usage is implied by context (calibration vs. overall skill), but no when-not or alternative mentions.

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 declare readOnlyHint=true and openWorldHint=true. The description adds that some fields are gated behind a paid tier, which is useful behavioral context. However, it lacks details on error handling, authentication, or rate limits.

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

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

Two sentences, front-loaded with the main purpose, and no redundant information. 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?

The description lists many output metrics but does not specify the response structure (e.g., JSON fields) or how gated fields behave for free vs paid users. Without an output schema, more detail would improve completeness.

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 the 'address' parameter with its format. The description does not add additional meaning or examples 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 it returns a single wallet's skill profile, listing specific metrics (composite rank, P&L, win-rate, etc.), and distinguishes from sibling tools that focus on leaderboards or market consensus.

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

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

No explicit guidance on when to use this tool versus alternatives like get_trader_calibration or get_leaderboard. The description does not provide decision context or when not to use it.

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