predictionguard

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

With no annotations, the description carries the full burden. It reveals a key behavioral trait: delegation to AMLOracle, and implies results include sources to cite. However, it does not disclose whether the operation is read-only, potential data sensitivity, rate limits, or any side effects. This is a moderate level of transparency but not comprehensive.

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

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

The description is three sentences, front-loaded with the primary purpose. Each sentence earns its place: what it scans, how it works (AMLOracle), and usage guidance. 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 description covers purpose, delegation, and user guidance, which is solid for a tool with three simple parameters. However, it does not describe the output format or result presentation, and with no output schema, that would be helpful. Overall, it is mostly complete but not exhaustive.

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

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

Schema description coverage is 100% (name, lang, limit all have descriptions). The tool description itself does not add semantics beyond the schema, simply framing the operation as a 'scan' by name. With full schema coverage, a 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 identifies the tool as an adverse media scan for negative news on specific crime types (fraud, money laundering, corruption, sanctions), which distinguishes it from siblings focused on PEP checks or sanctions screening. However, it does not explicitly compare itself to those adjacent tools, so it misses the full sibling differentiation.

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

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

The description states it is a 'core building block for evidence chains' linking a wallet or trader to publicly reported concerns, giving a clear when-to-use context. It also provides a usage rule ('always cite the source, never attribute'). It does not explicitly say when not to use it or name alternatives, but the context is sufficient for an agent to infer 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It states that the tool is a scan that returns flagged markets, severity levels, matched categories/keywords, and volume, which implies a read-only, non-destructive operation. It does not mention rate limits, authentication, or pagination, but for a read-only scanner with a clear output contract, the disclosure is adequate.

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

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

The description is two sentences: the first states the purpose and mechanism, the second specifies return values and a suggested follow-up action. Every sentence contributes new information; there is no filler 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?

The tool is simple with two optional params, no output schema, and no annotations. The description covers the output contract (severity, matched categories/keywords, volume) and the workflow context (daily compliance triage, pairing with a sibling tool), making it effectively complete for 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 input schema already covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds context that the scan operates on top markets by 24h volume and lists the exact keyword categories, which loosely maps to the category parameter. It does not add additional syntax or format details, but no compensation is needed given the full schema coverage.

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

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

The description opens with 'Daily compliance triage' and uses a specific verb phrase: 'scans top Polymarket markets by 24h volume and flags those whose question text matches curated sensitive-keyword categories.' This clearly distinguishes it from sibling market-scan tools by naming the source (Polymarket), the trigger (keyword categories), and the output (flagged markets with severity).

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 establishes a clear use case: daily compliance triage of high-volume Polymarket markets based on sensitive keywords. It also provides cross-tool guidance by instructing to pair HIGH-flagged results with pg_insider_signal_scan for active surveillance. It does not explicitly state when not to use this tool versus alternatives, but the context is strong 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?

With no annotations, the description bears the full burden. It discloses that the tool aggregates several data sources into one dossier, which is useful, but it does not mention read-only status, potential side effects, or any operational constraints like required permissions. The composition is described, but behavioral transparency is limited.

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 value and lists both components and use cases without unnecessary fluff.

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 bundle tool with no output schema, the description explains what the dossier contains and its intended applications. However, it omits details about the output structure, whether parameters are required, and what 'Trust Layer provenance trace' means, leaving some ambiguity.

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 (id, slug) are already fully described in the schema, so schema coverage is 100%. The description adds no extra parameter semantics beyond 'single Polymarket market', so the baseline of 3 applies.

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

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

The description clearly identifies the tool as a 'Complete forensic dossier' for a single Polymarket market, listing the constituent parts (integrity scan, volume anomaly profile, provenance trace) and distinguishing it from narrower sibling tools like pg_market_details or pg_market_integrity_scan. Though it lacks an explicit action verb, 'aggregated' conveys the bundling behavior.

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

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

It states the dossier is 'ready for manual review, press inquiry, or as input to a SAR report', giving concrete use cases. It does not explicitly contrast with individual component tools or state when not to use, but the 'complete' and 'aggregated' language implies it replaces multiple separate queries.

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 of behavioral disclosure. It transparently explains the weighted aggregation, the return payload (letter grade, composite score, component scores, interpretation guide), and prominently warns 'Statistical signal only — not a legal determination.' This adds meaningful context about what the tool does and its limitations.

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

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

The description is three sentences long, with each sentence serving a distinct purpose: stating the core function, detailing the aggregation formula, and clarifying the output and interpretative caveat. There is no filler or redundancy, making it highly 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 composite scoring tool with no output schema and no annotations, the description covers the essential elements: purpose, component weights, output structure, and a disclaimer. However, it does not explicitly address whether both id and slug are optional or how the market is identified when only wallet is provided, leaving a minor ambiguity.

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 descriptions for id, slug, and wallet. The tool description does not add parameter-level semantics beyond what the schema already provides, and it leaves the optionality of id/slug unclear (since only wallet is required, but the description references a 'specific market'). Baseline 3 is appropriate given the high schema coverage.

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

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

The description begins with a specific verb phrase 'Composite A-F rating for whether a wallet appears to have had non-public information on a specific market' and clearly distinguishes itself from sibling tools by naming the component tools (pg_position_timing_anomaly, pg_insider_signal_scan) and the bonus criteria. This makes its purpose unambiguous and unique among the listed siblings.

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

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

The description implies usage when a composite market-integrity score is needed, but it does not explicitly state when to prefer this tool over the individual component tools or provide exclusion criteria. The inclusion of component names suggests a relationship but stops short of direct guidance.

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

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

With no annotations, the description carries the burden and discloses important behaviors: cryptographic signing, on-chain anchoring on Polygon, and external verifiability via JWKS. It does not mention operational side effects like transaction costs, required wallet keys, or irreversibility, which would be valuable for a mutation tool.

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

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

The description is two focused sentences, front-loading the primary action and supporting with verification details. No redundant or filler content.

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 complex (on-chain signed alert), yet there is no output schema and the description does not specify what the tool returns (e.g., transaction hash, signed payload). It hints at external verification but leaves the agent uncertain about response format and prerequisites, making it incomplete for a production 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 descriptions for all five parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides, only referencing the underlying trust layer functions without connecting them to the fields.

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 'Issue a cryptographically signed, on-chain anchored integrity alert for a Polymarket market,' which is a specific verb+resource+outcome. It distinguishes itself from sibling tools like pg_verify_alert (which verifies) by emphasizing issuance of a signed alert.

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 a workflow by mentioning alerts 'are externally verifiable via pg_verify_alert', suggesting usage for creating alerts that will later be verified. However, it does not explicitly state when to use this tool vs alternatives like pg_insider_signal_scan or provide exclusion conditions, so it only gives clear context without full guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the default window (72h), the output structure (score, triggered signals, top 5 positioners, methodology), and the aggregated nature of the scan. It implicitly conveys a read-only operation via 'returns', but it does not explicitly state side-effect freedom or auth requirements.

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?

Single cohesive paragraph that front-loads the core purpose and lists the 5 signals efficiently. It is dense but all information is relevant, no redundancy, and it covers inputs, outputs, and defaults without excessive length.

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

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

No output schema exists, so the description must explain return values – it does thoroughly (score, CLEAN/CRITICAL categories, evidence, top 5, methodology). For a complex tool with 4 parameters and 5 signal types, it covers all essential behavioral and output aspects with no obvious critical gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the window is 'before market end' and that min_position_usd is the threshold for flagging large positions, enriching the schema's basic descriptions for these parameters.

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

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

States 'Real-time insider-trading signal scan for a single Polymarket market' – a specific verb (scan) and resource (Polymarket market). It enumerates 5 distinct signal types, clearly differentiating it from sibling tools that focus on individual signals like pg_position_timing_anomaly or pg_pre_event_flow_analysis.

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

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

No explicit when-to-use or alternative recommendations. It implies usage for single-market insider signal scanning, but does not contrast with sibling tools such as pg_market_integrity_scan or pg_information_advantage_score, leaving the agent to infer placement.

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 full responsibility for behavioral disclosure. It clearly states the output format (ALLOW/MONITOR/WARN/BLOCK + 0-100 score + reference cases), a key limitation (cannot identify trader identity due to API anonymization), and the pattern-matching methodology against disciplinary cases. This is exemplary transparency for a tool with zero 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 three sentences, front-loaded with the core purpose, and each sentence contributes: regulatory basis, input/function, output, and limitation. No wasted words; it is concise yet information-dense.

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

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

The description explains the return values and limitations well, which is essential since there is no output schema. However, it doesn't clarify that all three parameters are optional and that at least one identifier (ticker or event_ticker) is likely needed to specify a market. This ambiguity is a minor gap given the tool's moderate 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it mentions 'market metadata' and 'candidate_name' only indirectly. The schema already explains ticker, event_ticker, and candidate_name, so the description doesn't need to compensate.

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

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

The description opens with a specific regulatory reference (CFTC Rule 5.17(z)) and states the exact purpose: analyzing Kalshi market metadata to detect insider-trading liability for decision-makers. It clearly distinguishes the tool from siblings like pg_market_integrity_scan or pg_insider_alert_signed by focusing on conflict-of-interest pre-trade checks.

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 frames the tool as a 'pre-trade check' and explicitly notes it cannot identify actual trader identity, advising to 'pair with internal surveillance for full enforcement.' This gives clear context for when to use it, though it does not name specific alternative tools or state explicit 'when not to use' scenarios beyond the internal-surveillance caveat.

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 responsibility for behavioral disclosure. It lists the output fields, indicates multi-outcome behavior for event_ticker, and highlights the inclusion of settlement criteria. It implies a read-only operation but does not explicitly state safety traits like readOnlyHint or rate limits, though the content is highly informative about what the tool returns.

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

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

The description is three sentences, front-loaded with the main purpose. Each sentence adds distinct value: an overview, parameter usage modes, and critical context about rules_primary for resolution risk. 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 absence of an output schema, the description explicitly lists return fields and distinguishes between market and event queries. It also emphasizes the importance of rules_primary. It omits edge cases like what happens if both parameters are omitted (since none are required), but it is sufficiently complete for typical usage scenarios.

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

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

Schema coverage is 100% with descriptive parameter definitions. The description adds decision guidance: 'Pass ticker for a single market' and 'event_ticker for all markets in an event (multi-outcome)', and specifies the type of data returned (yes/no bids+asks, etc.). This enriches parameter semantics beyond the schema by clarifying the distinction and expected outputs.

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 what the tool does: 'Detailed Kalshi market or event info.' It specifies two modes via 'ticker' for a single market and 'event_ticker' for an event, listing concrete return fields (bids/asks, last price, volume, OI, spread, hours until close). This distinguishes it from sibling tools like search or orderbook analysis, providing a specific verb+resource+scope.

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 on when to use each parameter: 'Pass ticker for a single market... or event_ticker for all markets in an event.' It also explains that rules_primary text is critical for understanding resolution risk, giving a concrete use case. However, it does not explicitly compare to alternative tools or state when not to use this tool, so it lacks exclusionary guidance.

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

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

With no annotations, the description carries the full burden. It discloses the bid-only nature of Kalshi data and the reciprocity calculation, plus the return structure. It does not mention permissions, rate limits, or side effects, but given the read-only analysis context, 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?

The description is well-structured with a clear purpose statement, numbered pattern list, and return summary. Every sentence provides valuable information without unnecessary verbosity.

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 explains the return values (0-100 score, severity, level-by-level data) and a key data behavior (bid-only). It does not cover error handling or invalid tickers, but for a single-parameter tool this is nearly complete.

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

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

Schema coverage is 100% with one parameter (ticker) described as 'Kalshi market ticker'. The description adds no additional parameter details beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states 'Forensic orderbook analysis for one Kalshi market' and enumerates specific manipulation-vulnerable patterns, distinguishing it from sibling tools like thin market alerts or market details. It defines exactly what the tool does and what it returns.

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 deep-dive orderbook analysis on a single market, but does not explicitly address when to prefer this over alternatives (e.g., pg_kalshi_thin_market_alert). It provides clear context but no explicit exclusions or comparisons.

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 key behaviors: bucketing by time windows, flagging CFTC-sensitive categories, and the look-ahead window. This goes beyond typical descriptions, though it omits output format details and any limitations.

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 four short, impactful sentences. It front-loads the purpose, then provides bucketing, flagging, and usage context. Every sentence earns its place with 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 3 optional params, no output schema, and no annotations, the description provides strong context: what it does, how results are organized, special flags, and when to use it. It lacks explicit return-structure details, but is sufficient for a read-only calendar 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 schema has 100% coverage for all three parameters, so baseline is 3. The description adds minor context by tying hours_ahead to the listed buckets and mentioning Elections/Politics as relevant categories, but it does not substantially extend 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 lists Kalshi markets resolving in the next N hours, with specific bucketing (6h, 24h, 48h, 1 week) and a special flag for CFTC-sensitive categories. This distinguishes it from sibling tools like pg_kalshi_market_details or pg_kalshi_search, 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?

The description explicitly recommends use for 'daily surveillance prep' and explains the risk window rationale. It does not explicitly mention alternatives or when not to use, but the context is clear and actionable.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It explicitly states 'Public data, no auth needed' and describes the ranking behavior and event/market structure, providing useful safety and context. However, it does not disclose output format or rate limits, leaving some gaps.

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 four concise sentences, front-loaded with the core action. The category list and child-market explanation add useful context without redundancy. Every sentence contributes, so a 5 is warranted.

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 context: what is returned (events ranked by volume), auth requirements, and the event-market relationship. Without an output schema, it partially explains return values but omits details like pagination or field structure, leaving minor gaps for a tool with 4 optional parameters.

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

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

Schema description coverage is 75%, so the baseline is 3. The description mentions categories and child markets but does not add substantive meaning for individual parameters like limit, query, or status. The 25% gap (status enum lacking text description) is not compensated.

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 searches Kalshi prediction markets and specifies the unique output (events ranked by aggregate 24h volume), which distinguishes it from sibling tools like pg_kalshi_market_details or pg_kalshi_trending. However, it does not explicitly name alternative tools, 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?

The description implies usage for searching Kalshi events by query or category, but it does not explicitly state when to prefer this tool over sibling search tools like pg_market_search or pg_kalshi_trending. No alternatives or exclusions are mentioned, so it only earns a 3.

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

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

With no annotations, the description carries the full burden. It discloses the specific vulnerability factors, the output ranking by risk_score, and the ≥30 threshold. It does not mention auth, rate limits, or data freshness, but as a read-only scanning tool these are less critical; the disclosure is substantive.

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

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

The description is three sentences long, front-loaded with the core purpose and criteria, and contains no redundant or filler content. Every sentence contributes meaning, 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 no output schema, the description clarifies that results are ranked by risk_score and filtered by threshold, which is essential output context. It also lists the key vulnerability dimensions, making the tool self-explanatory for a scan. Minor gaps include not specifying the exact output fields or any data-source caveats, but the description is adequate for selecting and invoking the tool.

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

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

The input schema already provides descriptions for both parameters (category filter and max_results, including default and max). The description adds no additional parameter-level context, so the baseline 3 applies for full schema coverage.

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

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

The description uses a specific verb ('Scan') and resource ('all open Kalshi markets'), and clearly states the tool's function: flag manipulation-vulnerable markets based on concrete criteria (closing soon, low open interest, low liquidity, wide spread, low volume). It distinguishes itself from sibling tools by naming the risk_score threshold and its triage role.

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 'Daily triage tool' provides clear timing/context for use. It also suggests a complementary tool ('pg_kalshi_resolution_calendar') for a broader compliance briefing, which helps orient the agent. However, it does not explicitly state when not to use this tool or list alternative scans to prefer.

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 discloses ranking methodology (aggregate 24h volume), the inclusion of the highest-volume sub-market per event, and categorical filtering. It does not detail output format or pagination, but the core behavioral traits are well explained.

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

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

The description is three sentences long, front-loaded with the main purpose, and every sentence contributes useful information without redundancy or filler. It is tightly structured and easy to scan.

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 low complexity, no output schema, and two well-documented parameters, the description provides sufficient context: it explains what is returned (trending events with top sub-market), how ranking works, and filtering options. It could mention the output format explicitly, but it is not a significant gap for this use case.

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

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

Schema coverage is 100%, so the baseline is 3. The description only reiterates that the tool is filterable by category and does not add meaningful detail about the limit parameter beyond what the schema already provides.

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's function: ranking top trending Kalshi events by aggregate 24h volume across child markets. It distinguishes itself from siblings like pg_trending_markets by specifying Kalshi events and the sub-market inclusion behavior.

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 for when to use the tool (for a top-trending Kalshi events overview, filterable by category, suitable for daily briefings). It does not explicitly mention alternatives or when-not scenarios, but the context is strong enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context by stating 'Summaries only — no accusations against named parties,' which discloses output limitations and ethical boundaries. The term 'Registry' also implies a read-only operation, though it does not explicitly state read-only or describe side effects.

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

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

The description is a compact two sentences that front-load the core purpose and follow with filtering and caveat. Every clause adds relevant information without waste, and the examples and constraints are efficiently embedded.

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 with 2 optional parameters and no output schema. The description covers purpose, filtering, and a critical caveat about summaries/no accusations. It does not detail return fields, but given the simplicity and explicit examples, it is reasonably complete for agent selection and invocation.

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

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

Schema description coverage is 100% (both category and min_aml_relevance have descriptions). The description only restates the filter options and enum values, adding minimal meaning beyond the schema. The baseline of 3 is appropriate since the schema already provides complete parameter documentation.

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

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

The description clearly identifies the tool as a registry of publicly reported prediction-market integrity cases, listing concrete examples (Théo, Hyperliquid whale, etc.). It distinguishes itself from sibling tools like pg_wallet_lookup or pg_market_integrity_scan by focusing on known cases rather than scans or entity lookups, and the filtering verbs add operational clarity.

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 known integrity cases and mentions filtering by category or AML relevance, giving clear context. However, it does not explicitly name alternative tools or provide when-not-to-use exclusions, so it falls just short of full guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes what the tool does and mentions delegation to AMLOracle, but it does not state whether it is a read-only operation, the nature of side effects, rate limits, or failure behavior. This is insufficient for a tool with no annotation backup.

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, with two sentences that front-load the purpose. The second sentence about delegation is of limited value to an agent but does not add significant clutter. Overall, it is efficiently written.

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

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

This is a complex composite tool with no output schema, yet the description does not explain what the response contains, how results are aggregated, or any operational caveats. Given the lack of annotations and output schema, more context is needed for safe and correct invocation.

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

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

Schema description coverage is 67%, with country and entity_type having descriptions. The description adds that the tool is for a 'named entity' and includes 'country risk', which hints at the name and country parameters. However, it does not clarify the expected format or constraints for the name parameter beyond being an entity identifier.

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 performs a full KYC bundle (sanctions, PEP, adverse media, country risk) for a named entity in a single call. This distinguishes it from sibling tools that offer individual checks, such as pg_sanctions_screen_entity and pg_pep_check_entity.

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 'Full KYC bundle' and 'in a single call' implies use when comprehensive screening is desired, but it does not explicitly mention when to use individual sibling tools instead. There are no named alternatives or exclusions, so guidance is only implied.

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

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

With no annotations, the description carries the full burden. It lists what data will be returned, indicating a read operation, but does not explicitly state that it is read-only, nor does it disclose potential edge cases (e.g., what happens if neither slug nor id is provided, or if both are given).

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 sentence that packs in the returned data fields and the required input format. Every word adds value, with no redundancy or fluff.

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 two optional parameters and no output schema, the description covers the essential return values and invocation requirement. It lacks context about which market platform or data source this applies to, but that is not critical given the tool's narrow scope.

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 provides descriptions for both parameters (id and slug), achieving 100% coverage. The description adds the important semantic that slug and id are alternatives ('Provide slug or id'), clarifying the expected usage 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 indicates the tool returns full market information, enumerating specific data fields like outcomes, volume, and spread. It distinguishes itself from search tools by requiring a slug or id, though it doesn't explicitly differentiate from the sibling tool pg_kalshi_market_details.

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 precondition ('Provide slug or id') and implies this tool is for fetching details by identifier rather than searching. However, it does not explicitly state when to prefer this over alternatives like pg_market_trades or pg_kalshi_market_details.

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 must convey whether this is a safe read operation. The word 'scan' implies read-only, and the description details the output structure, which is useful. However, it does not disclose any side effects, limitations, or required permissions, leaving some ambiguity for a tool with no annotation coverage.

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, no fluff. The first sentence front-loads the key concept ('Multi-signal integrity scan') and enumerates components; the second succinctly lists the output fields. 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?

The description covers the output well (score, level, signals, recommendation) despite no output schema, but it omits parameter semantics and usage context. Given the tool's complexity and lack of annotations, the description is adequate but has clear gaps in how to target the scan and when to prefer it.

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

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

Schema description coverage is 0% and the description never mentions the id or slug parameters. It fails to explain that these likely identify the market to be scanned, leaving the agent to guess how to invoke the tool. With two parameters and zero explanation, this is a significant gap.

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

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

The description clearly states a multi-signal integrity scan, listing specific signal components (thin-book flag, spread, low liquidity, etc.) and the exact return format (score 0-100, level, triggered signals, operational recommendation). This fully identifies the tool's purpose and differentiates it from simpler sibling tools like pg_kalshi_thin_market_alert.

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

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

No guidance about when to use this tool versus alternatives such as pg_prediction_market_integrity_gate or pg_resolution_risk_score. The description only explains what the tool does, not the context in which it should be selected over other integrity-related 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 behavioral disclosure. It lists output fields (question, slug, 24h volume, liquidity, end date) but does not mention default filtering like active_only or limit behavior, which are present in the schema. It sufficiently describes the core read-only search behavior.

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

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

The description is two concise sentences, front-loaded with the primary verb and resource, and includes only essential information: examples of keywords and return fields. No 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 low complexity (3 parameters, 100% schema coverage) and no output schema, the description sufficiently covers the tool's behavior and output. It could be slightly improved by noting the default active_only behavior, but the schema makes this visible to 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 input schema has 100% coverage for all three parameters with clear descriptions. The tool description adds no additional parameter context, so the baseline score of 3 applies; it does not need to compensate for missing schema information.

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: 'Search Polymarket markets by keyword' with concrete examples. It differentiates from siblings like pg_kalshi_search by specifying the platform (Polymarket) and from pg_market_details/trending markets by focusing on keyword search.

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

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

The description provides examples of keywords, implying usage for searching by topic. However, it does not explicitly state when to use this tool versus alternatives like pg_trending_markets or pg_market_details, nor are any exclusions mentioned.

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 of behavioral transparency. It discloses pagination behavior (max 25 pages × 1000 trades), the nature of filters (client-side), and the exact return fields (wallet, side, price, notional, etc.). This exceeds the minimum but could be enhanced by noting any rate limits or authentication requirements.

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 four sentences with high information density and zero fluff. It front-loads the core purpose, then lists filters, pagination, and return format in a logical order. Every sentence contributes substantive information.

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

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

Given 9 parameters, no output schema, and no annotations, the description covers the essential aspects: what data is returned, how filtering works, and how pagination behaves. It lacks explicit guidance on whether id or slug is required, but the schema covers parameter semantics. Overall, it is sufficiently complete for an AI 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 coverage is 100%, so the baseline is 3. The description adds value by grouping filters into time range, side, size, and wallet, and by explaining pagination semantics (pages of 1000, max pages) that are not fully captured in the schema. This gives the agent a clearer mental model of how the parameters interact.

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 'Raw trade access for a Polymarket market via the Polymarket Data API', identifying a specific verb ('access') and resource ('trade data for a market'). This differentiates it from sibling tools focused on market details, wallet risk, or integrity scans.

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 use for raw trade retrieval by listing supported filters and pagination details. While it does not explicitly name alternatives or exclusionary conditions, the specification of 'client-side filters' and 'server-side pagination' gives clear context for when to use this tool versus a more curated market data tool.

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

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

No annotations are provided, so the description must carry the full burden. It discloses the heuristic logic (comparing volumes, z-like ratio) and the flagging condition. However, it does not explicitly state whether the tool is read-only, what it returns, or any potential side effects. This is a moderate level of transparency.

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

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

The description is a single, concise sentence that packs in the purpose and heuristic details without wasted words. It is front-loaded with the tool's primary function and structured clearly with a colon and conjunction.

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 two optional parameters and no output schema. The description explains the core algorithm but does not explain how parameters are used or what the output looks like. It also lacks context about the meaning of 'on-book liquidity' or the expected result format, making it incomplete for an agent to use effectively.

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 defines 'id' and 'slug', but the description does not mention either parameter. With schema description coverage at 0%, the description should compensate by explaining how parameters identify the market or affect the heuristic, but it is completely silent. This leaves the agent with no guidance on what to provide.

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 what the tool does: it compares 24h volume to average daily volume since market start and flags thin-book situations. It uses specific verbs ('compares', 'flags') and identifies the resource (market volume) and the heuristic approach (z-like ratio), which distinguishes it from sibling tools like pg_kalshi_thin_market_alert.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any use case, prerequisites, or contrast with sibling tools. It only describes the tool's behavior without any context for 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 full burden. It does disclose key behavior by listing the tool's checks, including external dependencies (Polymarket Gamma API ping, Polygon RPC ping via Ankr) and a known-case count. However, it does not explicitly state read-only behavior, error handling, data freshness, or potential side effects, though for an overview tool these are likely minimal.

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

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

The description is a single, front-loaded sentence that begins with the tool's purpose ('PredictionGuard platform overview') and then compactly enumerates the included items. Every word earns its place; there is no filler 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?

For a zero-parameter overview tool with no output schema, the description provides enough information about the major result categories to set agent expectations. It could be slightly more explicit about whether this is a health/status check, timestamps, or error behavior, but the core content is covered and clearly distinguishes it from the more specialized sibling tools.

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

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

The input schema has zero parameters and 100% schema description coverage, so there are no parameter meanings for the description to clarify. Baseline 4 applies for a no-parameter tool, and the description appropriately requires no parameter details.

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

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

The description clearly identifies the tool as a platform overview and lists its contents (covered platforms, tool inventory, pings, known-case count), which distinguishes it from the more targeted sibling tools. However, it lacks an explicit verb like 'get' or 'retrieve,' so it reads more as a summary than a direct instruction.

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 is provided on when to use this tool versus sibling tools. The description implies a high-level snapshot, but it does not mention that specific details should be obtained from dedicated tools (e.g., pg_market_details, pg_wallet_lookup) or exclude any 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 provided, the description carries the full burden. It reveals that the tool delegates to AMLOracle and uses Wikidata, but it does not state whether the operation is read-only, what errors may occur, or what the response looks like. This is a notable gap for a tool with no annotation support.

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, focused sentence that conveys the purpose, data source, and relevant context without any filler words. 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?

The description gives enough context for when to use the tool and mentions the external delegation, but because there is no output schema, it should ideally describe the return format or output. It also lacks usage exclusions. The low complexity and clear purpose keep it from being lower.

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 straightforward descriptions ('Person name' and 'Optional ISO country code'). The tool description itself adds no further parameter details, so the baseline score of 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 performs a PEP check via Wikidata and delegates to AMLOracle. This specific verb+resource combination distinguishes it from sibling compliance tools like sanctions screening or adverse media checks.

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 provides clear context by stating the tool is 'Relevant for prediction markets where reported traders overlap with political figures.' However, it stops at context and does not explicitly mention alternatives or when not to use the 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?

With no annotations provided, the description carries the full burden and fully discloses the exact scoring rubric, the three analysis dimensions, and the returned fields (0-100 score, first-trade timestamp, total notional, methodology). This gives an agent an accurate behavioral model of the tool's computation and output.

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 dense sentences, front-loaded with purpose followed by a numbered breakdown of the scoring logic and return values. Every sentence contributes necessary information, and the detail about point thresholds is essential for understanding the tool's 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?

Given the absence of an output schema, the description compensates by explicitly listing return fields and methodology, making the tool actionable. It does not explain how to choose between the optional id and slug parameters or how malformed wallet addresses are handled, but these are minor gaps given the schema and dense functional description.

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 documents all three parameters with 100% coverage, so the schema carries the burden. The description adds only general context ('single wallet', 'specific market') and does not provide new parameter-level meaning beyond what the schema already states, meriting the baseline score.

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

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

The description opens with a specific function: 'Statistical timing analysis of a single wallet's position on a specific market' and enumerates three concrete checks with scoring values. It also mentions pairing with pg_information_advantage_score, which distinguishes this tool's analytic niche from sibling tools.

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

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

The description clearly scopes usage to a single wallet's position on a specific market and explicitly recommends pairing with pg_information_advantage_score for a full assessment, giving practical usage context. It does not provide explicit exclusions or a full list of alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the output format (decision, risk level, signed receipt), the aggregated data sources (orderbook, resolution-window, conflict-of-interest, insider scan), platform support, and the x402 paywall interaction. It does not explicitly state whether the operation is read-only or if any data is persisted, but 'pre-trade integrity gate' strongly implies a non-executing check. The description adds significant behavioral context beyond basic read/write status.

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 every sentence contributes new information. It front-loads the core purpose and output, then details aggregation, platform support, optional inputs, and the paywall design. There is no redundancy or filler, making it 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 complex aggregator with 5 parameters and no output schema, the description is fairly complete. It explains the decision output, risk scale, signed receipt, and the role of each optional input. It does not specify exact thresholds for ALLOW/WARN/BLOCK or verify the receipt format, but those are edge details that might be covered by the API or documentation. Overall, it gives an agent sufficient context to 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?

All 5 parameters are documented in the schema, but the description enriches their semantics by explaining optional inputs: wallet for Polymarket-side checks, candidate name for Kalshi Rule 5.17(z) name matching, and amount_usd to amplify risk on thin markets. This provides rationale for when and why to pass these parameters, adding value beyond the schema's basic 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 the tool's function: a pre-trade integrity gate that returns an ALLOW/WARN/BLOCK decision, risk level, and signed receipt. It distinguishes itself from sibling tools by explicitly aggregating orderbook analysis, resolution-window risk, CFTC conflict-of-interest checks, and insider signal scans, making it a comprehensive gate rather than a single check.

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

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

The description provides clear usage context: 'Designed for x402 paywall pre-trade calls — agent pays once, gets binary go/no-go.' This implies when to use it (before trade execution) and hints at the alternative of using individual sibling tools, though it does not explicitly say 'use this instead of those.' No exclusions or when-not-to-use guidance is given, but the context is strong enough for an agent to decide.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It is remarkably transparent about what the tool does: it aggregates trades, classifies wallets, detects specific signals (volume concentration, timing clusters with a precise threshold, volume spikes vs historical average), and returns a risk score with thresholds. It does not mention side effects, data freshness, or computational costs, but the algorithmic details go well beyond a generic 'analyze' and provide strong behavioral context.

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

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

The description is three sentences, front-loaded with the primary purpose, and packs a substantial amount of detail without redundancy. Each clause adds value: the analysis methods, the specific signals, and the output format. There is zero waste, and the structure flows logically from purpose to methodology to results.

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

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

Given the tool's complexity (multiple analyses, risk scoring, top lists) and the absence of an output schema, the description does a good job of explaining the return value (risk score with categories, triggered signals, top positioners/new wallets) and key parameter context. It does not explain interpretation of the risk score categories or limitations, but for a complex analytical tool, this is reasonably complete. The lack of explicit id/slug semantics is a minor gap.

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

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

Schema coverage is 50% (only max_pages and days_before_end have descriptions). The description adds the default window (7 days) and contextualizes days_before_end as the pre-event window, but it adds no explicit semantics for id or slug beyond the obvious 'market' context. It does not fully compensate for the missing schema descriptions, but the self-evident nature of id/slug and the context of 'Polymarket market' provide some support.

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

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

The description opens with a specific verb and resource: 'Analyze pre-resolution positioning on a Polymarket market.' It then enumerates distinct analyses (wallet aggregation, new wallet classification, volume concentration, timing clusters, volume spikes) and concrete outputs (risk score, top positioners). This clearly differentiates it from siblings like pg_position_timing_anomaly and pg_market_trades, which focus on narrower or 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?

The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The context implies it is for pre-resolution positioning analysis, but there is no 'use this when...' or 'for X use sibling' guidance. For a tool among many related siblings, this is a clear gap, though the specialized scope provides some implicit guidance.

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

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

With no annotations, the description carries the full burden. It discloses the computation logic, the output (score plus triggered signals), and the auditability mechanism (point deductions). It does not explicitly state read-only status, but the 'returns' phrasing and nature of a scoring tool strongly imply a non-mutating query.

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

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

The description is compact and front-loaded, with the core purpose in the first phrase. Each clause adds a distinct signal type or output feature, with no wasted words. The structure is easy to scan and digest.

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 complexity of the tool and lack of output schema, the description adequately covers the score range, categories, and the return of triggered signals with point deductions. It could be more explicit about parameter requirements, but overall it provides sufficient context for an agent to understand the tool's function.

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 tool description does not elaborate on the 'id' and 'slug' parameters. It only says 'for a Polymarket market,' leaving unclear whether both are required, what formats are expected, or how they map to market identification.

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 computes a multi-signal resolution-risk score for a Polymarket market, with a specific 0–100 scale and CLEAN/LOW/MEDIUM/HIGH/CRITICAL categories. It distinguishes itself from siblings by detailing unique signal components such as category priors, resolution-phase proximity, and UMA dispute ratio.

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 use—assessing resolution risk for a Polymarket market—and implies this tool is for detailed risk analysis. However, it does not explicitly name alternatives or state when-not-to-use conditions, though the rich signal list implies a specialized role 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?

With no annotations, the description carries the transparency burden. It mentions the delegation to AMLOracle, which is useful, but it does not disclose whether this is a read-only operation, potential rate limits, external dependency behavior, or what happens when no match is found. Some behavioral context is present 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 two sentences long, front-loaded with the primary purpose and followed by a usage hint. There is no filler, and every sentence contributes useful information.

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

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

The tool has no output schema, so the description should ideally hint at return values or match behavior. It does not mention what the tool returns (e.g., match list, risk score, Boolean). The usage context is strong, but the absence of output/error semantics leaves 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?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description does not add any additional meaning beyond the schema, which is acceptable per the baseline but provides no extra value.

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

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

The description uses a specific verb ('Screen') and clearly specifies the resource ('named entity against global sanctions lists') with concrete list names (OFAC SDN, EU FSF, UN SC, Interpol). This distinctly separates it from sibling tools like pg_pep_check_entity or pg_adverse_media_entity.

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 on when to use the tool: 'Use after resolving a wallet/trader to a real name via public reporting or known-case registry.' It does not explicitly mention alternatives or exclusions, but the timing and prerequisite are well-defined.

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 output is marked 'draft_for_review' and that 'PredictionGuard does not submit SARs directly,' which is key behavioral context. It does not mention permissions, side effects, or failure modes, but the draft/non-submission caveat is significant.

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

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

The description is three sentences with no padding. It front-loads the core purpose, then covers supported formats, inputs, behavior, and output status efficiently. Every sentence contributes useful information.

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

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

Given the tool's complexity (8 parameters, nested objects, no output schema), the description covers the main workflow, jurisdiction options, and output format. It does not describe the exact structure of the generated markdown report or edge-case behavior, but the high schema coverage compensates for most omissions.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the filing_jurisdiction enum values ('FATF-aligned STR', 'Form 111 structure', 'German FIU draft') and by grouping the key inputs (subject, market, activity window, signals, evidence), which helps the agent understand how to populate parameters 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 'Generates a draft Suspicious Activity Report (SAR/STR) from structured inputs' and names the supported jurisdictions (EU_GENERIC, US_FINCEN, DE_goAML). This specific verb+resource, combined with the output type, distinguishes it from the sibling scan/analysis tools.

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

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

The description implies downstream usage by referencing 'integrity signals' and 'evidence references' from prior tools, and it clarifies the report is a draft for review. However, it does not explicitly state when not to use this tool or name alternative tools, so it lacks full exclusionary 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 must convey that this is a read-only query. The phrasing 'Top Polymarket markets by 24h volume' implies a read operation but does not explicitly state safety characteristics, nor does it describe output format or data freshness. It adds the news-catalyst context, but that's more about usage than behavior.

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

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

Two sentences, front-loaded with the core function, followed by a brief utility. No redundant wording or unnecessary detail.

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 covers the essential function and value. It lacks explicit details about the returned fields or market status, but that information is not critical for selection and invocation at this level.

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

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

The only parameter 'limit' is fully described in the schema (default 10, max 25), and schema coverage is 100%, so the description does not need to elaborate. The description adds no additional parameter semantics; 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 identifies the tool's function: returning top Polymarket markets ranked by 24-hour trading volume. This distinguishes it from the Kalshi trending sibling (pg_kalshi_trending) by explicitly naming Polymarket.

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 concrete use case ('daily compliance triage, catching news catalysts') and implies it is for trending markets on Polymarket. It does not explicitly list alternatives or exclusions, but the sibling naming convention makes the alternative 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 provided, the description carries the full transparency burden. It discloses the entire operational flow: fetching from Gamma, extracting the resolutionSource address, verifying deployment on Polygon, and classifying the phase. This gives a clear expectation of behavior, though it does not address potential side effects, rate limits, or failure modes, so a 4 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?

The description is compact and front-loaded with the core purpose, then efficiently lists the step-by-step process and the possible phase values. Every clause contributes meaningful information with no redundancy, making it an excellent model of concise, structured description.

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

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

Given there is no output schema, the description explains the main outputs (resolution source and phase) and lists all phase categories, which is essential for understanding what to expect. It could go further by describing the exact return format or error handling, but for a tool with only two documented parameters, 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?

Schema description coverage is 100% with both 'id' and 'slug' documented. The tool description does not add any additional parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description clearly states the tool's purpose: returning resolution source and phase for a specific Polymarket market. It includes a detailed step-by-step breakdown (fetching metadata, extracting resolutionSource, verifying contract, classifying phase) and enumerates the exact phase categories, which fully distinguishes it from sibling tools like pg_market_details or pg_resolution_risk_score.

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

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

The description makes the usage context evident: for a specific Polymarket market when you need resolution source and phase. However, it does not explicitly mention when NOT to use this tool or compare it to alternatives such as pg_uma_status or pg_resolution_risk_score, so it falls short of a 5.

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

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

With no annotations provided, the description carries the transparency burden. It explains the internal computation logic (event tallying, rate, ratio) but does not explicitly state whether this is a read-only operation, potential performance implications of 'blocks_back', or any authentication/rate-limit requirements. It adds useful behavioral detail but omits some safety and performance aspects.

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, with two sentences. The first sentence states the purpose, the second details the operation. Every clause adds value; no filler or redundancy.

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

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

The description explains the tool's inputs and computational outputs well, and since there is no output schema, it adequately conveys what the tool returns (tallies, rate, ratio). However, it does not mention error conditions, units for 'blocks_back' beyond the schema default, or how the output is structured beyond these metrics.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the parameters by mentioning 'configurable window' (blocks_back) and 'optionally OOv1' (include_v1), but adds no new meaning beyond what the schema already provides.

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 scans UMA Optimistic Oracle event logs on Polygon to compute health metrics. It specifies the resource (OOv2/OOv1 on Polygon) and the specific computations (event tallies, hourly rate, dispute/propose ratio), distinguishing it from sibling tools like pg_uma_market_resolution which focuses on market resolution.

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

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

The description implies the tool is for monitoring oracle health but does not explicitly state when to use it versus alternatives, nor provide exclusions or prerequisites. It gives context that it is a health indicator but lacks direct guidance on 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?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses that the tool delegates to Trust Layer verify_signature, returns validity, signer, and timestamp, and provides the JWKS URL. This goes beyond a simple 'verify' statement and gives the agent useful context about the underlying mechanism and output. It does not, however, mention potential failure modes, rate limits, or that exactly one of jws/content_hash is required, which keeps it from a perfect score.

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 long. The first sentence front-loads the core purpose, and the second efficiently adds key behavioral details (delegation, return values, JWKS location). Every word adds value, with no fluff 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?

For a simple tool with only two optional parameters and no output schema, the description covers the essential aspects: purpose, inputs, outputs, and the underlying trust layer. However, it does not explicitly state that jws and content_hash are mutually exclusive alternatives, nor that exactly one should be provided (the schema marks both as optional). This is a minor but relevant gap for an agent deciding how to invoke the tool.

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

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

The input schema already includes descriptions for both parameters: 'Full JWS string' and 'SHA-256 content hash (alternative to JWS)'. The description adds little beyond the schema, merely repeating 'JWS or content-hash'. With 100% schema coverage, the description does not meaningfully enhance parameter understanding, so it earns the baseline score of 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's function: 'Verify a previously issued signed alert (JWS or content-hash).' This uses a specific verb ('verify') and a specific resource ('previously issued signed alert'), and it distinguishes this tool from its siblings, which focus on market data, wallet lookups, and other alert-related tasks. No other sibling tool mentions verification of signed alerts.

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 its usage context: it is for verifying signed alerts, likely complementing pg_insider_alert_signed which presumably creates them. It mentions delegation to Trust Layer verify_signature, giving some context, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No alternative tools or exclusionary conditions are mentioned.

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 of behavioral disclosure. It reveals the output components (markets traded, top 20 cotraders, aggregate severity score) and explicitly states the scoring thresholds (≥3 = MEDIUM, ≥5 = HIGH). It does not state whether the operation is read-only or if there are side effects, but the 'Find' verb implies a read operation. The detailed threshold and output description provide substantial behavioral transparency.

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

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

The description is three sentences, each serving a purpose: the first states the core function, the second enumerates the returns, and the third provides the use case. It is front-loaded and avoids fluff. Every sentence earns its place, making it 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?

The description fully covers the tool's inputs, outputs, and scoring logic. Since there is no output schema, it compensates by detailing exactly what is returned. Given the tool's moderate complexity (2 parameters, no nested objects), this description is complete enough for an agent to select and invoke it correctly. The mention of market slugs and sensitivity also aligns with the predictive-market integrity context of sibling tools.

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 both parameters well (wallet address format and 2-10 market slugs), so the baseline is 3. The description reinforces the parameter constraints in prose but does not add significant new meaning beyond the schema. It ties the parameters to the output (e.g., 'which markets the target traded'), which is slight added value, but not enough to raise the score above baseline.

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

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

The description opens with a specific verb and resource: 'Find wallets that co-trade across multiple sensitive Polymarket markets with a target wallet.' It clearly differentiates from siblings like pg_wallet_lookup or pg_wallet_risk_profile by focusing on co-trading correlation across multiple markets. It also specifies the exact deliverable (top 20 cotraders, severity score), 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 states the input requirements ('Given a wallet and 2-10 market slugs') and a concrete use case: 'detect coordinated trading rings, shared-info syndicates, or wallet clusters that consistently bet on the same sensitive events.' This gives clear context for when to use the tool, though it does not mention alternatives 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.

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains the resolution process, the fallback to heuristics, and the specific return fields (entity name, type, category, AML relevance, confidence, source URL). This is transparent about both the method and the output, though it does not mention potential errors, rate limits, or additional side effects, which keeps it from a 5.

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

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

The description is two well-structured sentences. The first sentence front-loads the primary purpose and mechanism, and the second lists the return fields. Every word adds value, with no redundancy or filler. It is concise yet comprehensive, fitting the tool's complexity.

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 a single parameter and no output schema, so the description must explain both usage and return values. It does so thoroughly, outlining the registry sources, the fallback heuristic, and the output fields. This makes the tool's behavior fully understandable without additional documentation. The description is complete for the tool's simplicity.

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 description covers the single parameter 'address' with format details (0x + 40 hex chars), so the baseline is 3. The tool description adds context about the address being a Polygon address and the resolution process, but it does not add parameter-specific syntax or constraints beyond what the schema already provides. Thus, it neither improves nor degrades the schema's clarity.

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: 'Resolve a Polygon address to a known entity via PredictionGuard's Wallet Registry', with a specific fallback to on-chain heuristic classification for unknown addresses. It specifies the resource (Polygon address), the action (resolve), and the outcome (entity details), distinguishing it from sibling wallet tools like pg_wallet_lookup or pg_wallet_risk_profile.

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: when you have a Polygon address and need to identify a known entity or classify an unknown one, this is the tool. It provides context on the registry contents (Polymarket contracts, stablecoins, CEX hot wallets) and the fallback behavior, making the use case clear. However, it does not explicitly mention when not to use it or suggest alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It transparently mentions the data source (JSON-RPC), its fallback behavior ('Ankr-backed when RPC_POLYGON is set, public fallback otherwise'), and the exact return data. It does not explicitly state that the operation is read-only or discuss error handling, but the read-only nature is clearly implied and the network dependency is disclosed.

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

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

The description is a single, dense sentence that front-loads the tool's purpose and immediately provides key details. Every phrase adds value: data source, fallback behavior, and specific return fields. There is no redundancy or fluff.

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 simplicity of the tool (single parameter, no output schema, no annotations), the description is fully complete. It explains what the tool does, how it works (JSON-RPC with fallback), what it returns (balance, tx count, contract/EOA, risk heuristic), and its place in the tool ecosystem ('base profile'). No critical information is missing for an agent to decide when and how to invoke it.

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

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

Schema coverage is 100%, with the single 'address' parameter fully described as a 'Polygon address (0x + 40 hex chars)'. The tool description adds no additional semantic detail about the parameter beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: retrieving a 'Polygon wallet base profile via JSON-RPC'. It specifies the resource (Polygon wallet), the action (lookup/profile retrieval), and the key outputs (MATIC balance, outbound tx count, contract-vs-EOA detection, risk heuristic). This distinguishes it from sibling tools by emphasizing 'base profile' and 'lightweight risk heuristic', differentiating from more specialized tools like pg_wallet_risk_profile.

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

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

The description implies usage context (a base-level wallet lookup) but does not explicitly state when to use this tool versus alternatives like pg_wallet_risk_profile or pg_wallet_entity_resolve. The phrase 'base profile' and 'lightweight risk heuristic' hints at a quick first-pass check, but no explicit when-to-use or when-not-to-use guidance is provided. This is implied rather than clear direction.

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 bears the transparency burden and discloses the composite nature, the grading scale (A=clean, F=blocked), dependence on entity screening availability, and the auditability feature (triggered flags with points). It does not mention side effects, errors, or performance, but the read-only nature is implied through the 'risk profile' framing.

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 each clause adds meaningful detail without redundancy. It is a model of concise, information-dense writing.

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, data sources, grading scale, and output features (flags/points), giving a solid basis for selection. It falls short of detailing the exact output structure or edge-case behavior, but since no output schema exists, the level of detail is adequate for most decision-making.

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 documents the only parameter 'address' with full format details (0x + 40 hex chars), and the description adds no additional meaning beyond that. With 100% schema coverage, the baseline score of 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 an aggregated A–F risk profile for a Polygon wallet, enumerating the combined data sources (pg_wallet_lookup, pg_wallet_entity_resolve, and AMLOracle) and defining grade meanings. This distinguishes it from sibling wallet and screening tools which focus on individual 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?

The description explains that the tool aggregates on-chain behavior, entity resolution, and AML screening, implying it should be used when a comprehensive risk score is needed rather than calling the underlying lookup tools separately. However, it does not explicitly state exclusions or alternative scenarios, so it stops short of full guidance.

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

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

With no annotations, the description carries the full burden. It does disclose the side effect of taking a baseline snapshot, which is useful. However, it does not mention behavior for duplicate addresses, error conditions, or whether adding is reversible or updates existing watchlist entries.

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

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

The description is three sentences with no filler: the main action, the side-effect context, and parameter guidance. Every sentence earns its place and the most important information is front-loaded.

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 explains the core purpose and snapshot behavior, but with no output schema and no annotations, it omits return value details and edge cases like re-adding an existing wallet. It is adequate for a simple add operation but not thorough.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description adds minor value by explaining alert_threshold_matic as sensitivity tuning and noting tags are free-form, but these are largely redundant with the 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 'Add a Polygon wallet to the PredictionGuard watchlist,' using a specific verb and resource. It distinguishes itself from sibling tools like pg_whale_remove, pg_whale_scan, and pg_whale_list by clearly naming the add-to-watchlist action.

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

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

The description provides clear usage context by explaining that an initial baseline snapshot is taken for subsequent pg_whale_scan calls, implying this tool is the setup step before scanning. It does not explicitly name alternatives, but the sibling tool names make the differentiation 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 burden of disclosing behavior. It does mention the default limit of 50 and the cross-watchlist scope, which is useful. However, it does not disclose potential side effects, rate limits, or other edge cases, though the read-only nature is implied by 'retrieve'.

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 long, front-loaded with the core purpose, and includes all essential information without redundancy. Every clause adds value, from the resource type to the filter options and default 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?

For a simple retrieval tool with no required parameters and no output schema, the description provides sufficient context: the source (watchlist audit log), filtering options, and default limit. It does not detail the return structure, but given the simplicity, it is adequately 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 schema has descriptions for only half of the parameters (limit and since). The description adds meaning to the undocumented 'address' and 'severity' parameters by explaining they are filters, and explicitly lists severity values. It also clarifies that 'since' is an ISO timestamp, augmenting the schema information.

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 retrieves alerts from the watchlist audit log, using the specific verb 'Retrieve' and a defined resource. It also distinguishes itself from sibling tools like pg_whale_list by focusing on the audit log alerts rather than watchlist management.

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 that it can be filtered by address, severity, and since, and notes the default behavior of returning the 50 most recent alerts. However, it does not explicitly mention when to use this tool over alternatives or when not to use it, leaving some ambiguity regarding its place among 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?

No annotations are provided, so the description carries the full burden. It discloses the output fields and optional filtering, but it does not explain pagination behavior, ordering, or any side effects or limitations beyond the schema's max limit. The core behavior is clear, but deeper behavioral traits are absent.

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 sentence that front-loads the primary action and resource. Every word contributes to understanding, with no filler or redundancy.

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

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

Given the tool's simplicity (2 optional params, no output schema, no annotations), the description is mostly complete: it states the purpose, output fields, and optional filter. It could improve by noting pagination or result ordering, but overall it is sufficient for correct invocation.

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

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

Schema description coverage is 100% for both parameters (tag and limit), so the baseline is 3. The description reinforces the tag filter but adds no new meaning beyond the schema; it omits mention of the limit parameter entirely, leaving schema to fully define 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 action (List), the resource (all watched wallets), and the specific fields included (alias, threshold, tags, notes, last snapshot), plus an optional filter. This distinguishes it from sibling tools like pg_whale_add, pg_whale_alerts, and pg_whale_scan.

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 by stating what the tool does, but it provides no explicit when-to-use or when-not-to-use guidance relative to alternatives. The optional tag filter is mentioned, but there is no exclusion of sibling tools or mention of scenarios where another tool would be more appropriate.

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 of behavioral disclosure. It explains the default behavior (keeps historical snapshots and alerts) and the effect of setting keep_history=false (purge everything). This is transparent about the operation's scope and potential irreversibility, particularly the word 'purge'.

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 main action, and contains zero wasted words. It efficiently conveys the default behavior and the optional parameter adjustment in a clear, scannable format.

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 tool with no output schema, the description is complete. It covers the primary action, default behavior, and how to customize it. There are no significant missing details that would prevent an agent from understanding when and how to invoke the tool.

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

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

The description adds significant meaning beyond the schema. It clarifies that 'address' refers to the wallet to be removed, and it explains the purpose of keep_history ('for audit trail') and what the boolean controls ('purge everything'). This compensates for the schema's sparse coverage, especially for the address parameter.

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: 'Remove a wallet from the watchlist.' This uses a specific verb and resource, and it distinguishes the tool from sibling tools like pg_whale_add, pg_whale_list, and pg_whale_scan. The purpose is immediately evident and 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 through the context of the whale tool family, but it does not explicitly mention alternatives or when to use this tool versus others. However, it does provide clear guidance on the keep_history parameter, explaining the default behavior and when to set it to false, which is a form of usage instruction.

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

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

With no annotations provided, the description carries the full burden. It discloses side effects: 'writes a new snapshot, and emits an alert when the delta exceeds the wallet's configured threshold.' It also explains severity levels ('MEDIUM / HIGH / CRITICAL by delta size') and confirms it performs a comparison against a snapshot. It does not mention permissions or reversibility, but for a scanning tool these are less critical. It could say what happens if no alert is triggered, but it is fairly 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 four sentences, each contributing essential information: the action, the comparison/snapshot/alert mechanism, severity levels, and the parameter behavior plus scheduling context. It is front-loaded with the main action and contains no filler.

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

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

The tool is simple (one optional parameter, no output schema, no annotations). The description covers purpose, usage context, behavioral side effects, parameter semantics, and scheduling. Missing is an explicit statement of what the tool returns, but the emphasis is on alert emission. Given the complexity, it is nearly complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the optional behavior: 'Omit 'address' to scan the entire watchlist.' This clarifies the semantics of a single optional parameter, making the parameter more meaningful than the schema alone.

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

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

The description opens with 'Scan one or all watched wallets against Polygon RPC', which is a specific verb+resource+scope. It clearly distinguishes this from sibling tools like pg_whale_add, pg_whale_list, and pg_whale_alerts by focusing on the scanning and alerting behavior. It also clarifies the full watchlist vs. single address case.

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

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

The description gives clear context for when to use the tool: 'Designed to be called periodically via SchedulerOracle or a systemd timer.' It implies this is a monitoring/scheduled tool, but it does not explicitly name alternatives or state when not to use it. This is clear context without exclusions.

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