SYNTHORA x402 Intelligence Mesh

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail: confidence is based on agreement between independent sources, and discrepancies are explicitly declared. It also discloses the cost model ($0.03 USDC x402 Base), giving the agent useful operational context beyond the schema.

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

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

The description is a single, efficient sentence that front-loads the core purpose and immediately follows with input modes, methodology, and pricing. Every clause adds useful information, and there is no repetitive 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?

For a single-input tool with strong annotations and rich descriptive content, the definition is largely complete: it covers what the tool evaluates, how the input should be expressed, how confidence is determined, and the cost. The main remaining gap is that it does not specify behavior when no input is provided, especially since the schema marks the parameter as not required.

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 input schema already describes the 'input' parameter as JSON or text. The description adds valuable semantic meaning by specifying what that input should contain: a zone identifier or lat/lon plus bbox. It gives the agent enough information to construct a valid invocation.

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

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

The description clearly identifies a specific action and resource: producing a 'geoint risk verdict' for named zones or lat/lon+bbox. It is more specific than merely echoing the tool name, and the geographic focus distinguishes it from many sibling tools. However, it does not explicitly differentiate itself from closely related siblings like chokepoint_risk or vessel_sanctions.

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 when to use the tool by listing acceptable inputs ('zone' names or 'lat/lon+bbox'), which gives an agent a reasonable context signal. It does not state explicit conditions, alternatives, or when not to use it, so the guidance is inferred rather than direct.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, and the description is consistent with that safety profile. The description adds useful context about data sources (IMF PortWatch, GDELT, WaveWatch III), but it is truncated and does not explain failure modes, latency, or how the verdict is returned.

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 dense, run-on sentence using excessive capitalization and parenthetical lists, and it cuts off mid-phrase at 'WaveWatch III sea'. It is not cleanly structured or concise.

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 output schema and read-only annotations reduce the burden on the description. It gives a good overview of the chokepoints and data dimensions, but the truncated ending, vague input format, and absence of guidance on targeting a specific chokepoint leave meaningful 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?

The schema has one parameter, 'input', described generically as 'parametros del producto (JSON o texto)', so schema coverage is 100% and baseline is 3. The description does not clarify how to specify a chokepoint or customize the risk output, so it adds no extra meaning beyond the schema.

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

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

The description states a clear deliverable: a risk verdict for specific maritime chokepoints based on traffic, narrative, and navigability data. It names the exact chokepoints, which makes the tool's scope understandable, though it does not explicitly differentiate it from related siblings like shipping_alpha.

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 chokepoint risk questions, especially when one of the listed straits is mentioned. However, there is no explicit guidance about when to prefer this tool over 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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful context beyond that: independent analyses, static pattern scanning, severity levels, Ed25519 signing, and on-chain publishability. This gives an agent a strong sense of what the tool produces and its trust properties.

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 and mostly front-loaded, but it ends abruptly at 'or {"address":"', leaving the input specification incomplete. The mix of Spanish and English is slightly awkward but not prohibitive.

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

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

With an output schema and safety annotations present, the description covers the core behavior well. However, the truncated address input format and lack of detail about language values or chain/address expectations leave a meaningful gap for correct invocation in the address-based workflow.

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

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

The input schema only says 'parametros del producto (JSON o texto)', which is generic. The description compensates by showing the expected JSON structures: {'source': ..., 'language': 'solidity'} or {'address': ...}. This adds significant meaning to the single 'input' parameter, even though the address example appears truncated.

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 smart contract audit service with specific analysis dimensions: security, logic, gas, plus static pattern scanning for Solidity/Vyper. This distinguishes it from all sibling tools, which are oriented toward market/risk/intel signals rather than code auditing.

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 concrete invocation context by showing two accepted input forms: source code with language, or an address. It clearly implies when to use the tool (auditing smart contracts) and gives the API shape, though it does not explicitly name alternatives or state 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?

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value beyond those by noting the aggregation behavior ('in ONE call') and the provenance guarantee that 'each block declares its verified sources.' It does not disclose freshness or latency, but those are not critical given the existing annotations and output schema.

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

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

The description is front-loaded and packs many useful content signals into a compact format. However, it is a single long em-dash list and ends with an obvious truncation ('What a trading agen'), which makes the structure feel incomplete.

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 and the existing output schema, the description covers the main content domains and the read-only nature effectively. It lacks explicit input handling guidance and would benefit from a sentence describing how an agent should use or omit the 'input' parameter, plus a completed closing thought.

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 only parameter, 'input', has a generic schema description ('parametros del producto (JSON o texto)') that does not explain how it relates to the daily intel brief. The tool description adds no parameter-specific meaning, leaving the input semantics vague.

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 defines the tool as a consolidated daily intelligence briefing and enumerates its content blocks: funding spreads, stablecoin depeg, SOFR-EFFR, PortWatch, GDELT, and executive alerts. The phrase 'in ONE call' helps distinguish it from narrower sibling tools, though it does not name those siblings explicitly.

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

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

Usage is implied rather than stated: the agent can infer this tool is for a broad daily overview instead of calling individual tools like funding_spread or chokepoint_risk. However, there is no explicit when-to-use, when-not-to-use, or alternative-selection 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context by revealing the internal components of the score, including UMA status, bond/reward, text ambiguity, holder concentration, and days to resolution. This goes beyond what the annotations provide.

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 and front-loaded with the main purpose, and each listed factor carries meaning. However, it ends abruptly at 'conditio', which breaks the sentence and forces the agent to guess the complete parameter format. This structural defect prevents a higher score.

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

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

While the output schema exists and the annotation set is strong, the description itself fails to fully specify the required input format because it is truncated. It also does not mention how to handle missing or invalid markets, and it ignores several closely related sibling tools that an agent may need to choose between. For a single-parameter tool with a generic schema, this is a meaningful completeness gap.

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

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

The schema only defines a generic 'input' string described as 'parametros del producto', which is low-value and ambiguous. The description compensates by specifying that the input should be a market_slug or condition identifier. It would be a 5 if the instruction were not cut off mid-word.

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 produces a 0-100 resolution/dispute risk score for Polymarket markets and enumerates the factors that feed it. This is specific enough to distinguish it from generic market tools, though it never names the overlapping siblings like resolution_verdict or polymarket_resolution_watch.

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 dispute_risk versus alternatives such as resolution_verdict, resolution_source_feed, or polymarket_resolution_watch. The instruction 'Pass a market_slug or conditio' is invocation guidance, not usage context, and it is truncated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral detail: the verdict categories, the output fields (score, confidence, evidence signals), the factors considered (age, infra, reputation crosses), and the cost. No contradiction with annotations.

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

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

The description is compact and front-loaded: it states the verdict and output structure first, then the use case, then pricing/network. Every clause contributes useful information without redundancy.

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

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

For a single-parameter, read-only tool, the description covers what verdicts are returned, what evidence feeds into them, when to use it, and cost. The main gap is the exact input payload format, but the domain-risk purpose and generic schema make the intended call pattern largely inferable.

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 one generic input parameter with 100% description coverage, though it is vague: 'parametros del producto (JSON o texto)'. The description adds that the subject is a domain, but it does not specify the expected payload shape (e.g., a raw domain string versus JSON fields), so the additional semantic value over the schema is moderate.

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 domain-risk assessment that returns a verdict with enumerated outcomes (LIMPIO/SOSPECHOSO/PELIGROSO) plus score, confidence, and evidence. The resource being assessed is unambiguous, though it does not use an explicit action verb or explicitly contrast itself with the many risk-related 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?

'Pre-interaction safety for agents' provides a clear usage context: run this before an agent interacts with a domain. It does not explicitly state when not to use it or point to alternative sibling tools such as identity_risk or asset_risk, so it falls short of full routing 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: ranking by momentum+acceleration+youth, mega-protocol noise filtering, data source DeFiLlama, and cost/payment rail ($0.03 USDC x402 Base). This gives the agent a clearer picture of how results are produced and what to expect.

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: the core purpose appears first, followed by ranking criteria, source, and pricing. It has minor redundancy (repeats the tool name and phrasing like 'before they get big'), but overall every sentence earns its place and the structure is scannable.

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

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

For a read-only informational tool with an output schema and annotations, the description covers purpose, target audience, ranking logic, filtering behavior, data source, and cost. It does not explain input semantics, but the tool has zero required parameters and an output schema, so the absence is not a major 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%, but the only parameter is a generic 'input' string described as 'parametros del producto (JSON o texto)', which is the equivalent of 'input is input'. The description does not explain what parameters or text the agent should provide. Since coverage is high, baseline is 3, but the schema itself offers little semantic 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 states a specific verb and resource: early detection of young DeFi protocols with accelerating TVL, before they get big. It further differentiates itself by mentioning filtering of mega-protocol noise and a specific ranking criterion, making it clearly distinguishable from sibling tools like tvl_concentration or volume_anomaly.

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: intended for MEV searchers and alpha bots seeking emerging protocols before they scale. It also notes mega-protocol noise is filtered, which suggests when this tool is appropriate. However, it does not explicitly state when to prefer this tool over alternatives, nor does it name any 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?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the output is the max spread and carry direction, it crosses three named public sources, and it costs $0.03 USDC. No contradiction with annotations.

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

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

The description packs a lot of useful information into a compact statement: what it computes, which venues, the signal type, source count, and pricing. It is slightly promotional and run-on, but every clause earns its place and key semantics are 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?

For a read-only signal tool with rich annotations and an output schema, the description covers the essential behavior, sources, and cost. It does not explain how to supply input parameters or what 'top pairs' means exactly, but the optional parameter and presence of an output schema soften that 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 100%, so the schema carries the baseline parameter documentation. The single 'input' parameter is described generically as JSON or text, and the tool description adds no examples or syntax for how to specify pairs or other options. 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 a specific resource (perp funding rates) and a specific computation (cross-venue spread between Binance, Bybit, and OKX, plus theoretical carry direction). It distinguishes itself from generic wrappers with the explicit 'not a wrapper' statement.

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 this tool is for funding arbitrage signals, and 'not a wrapper' hints at what it is not, but it provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools. No alternatives are named.

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

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

Annotations already disclose read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral detail by stating that it correlates independent sources and returns one of three verdict values, but it does not expand on data gaps, latency, rate limits, or source assumptions.

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 risk type and output categories without unnecessary clauses. It loses a point for the redundant 'SYNTHORA identity-risk' prefix, which mostly restates the title, and for lacking a clear input/returns structure.

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 core purpose, output categories, and source-correlation behavior are present, and the output schema plus safety annotations cover return and side-effect aspects. The main completeness gap is input semantics: the schema mentions 'product parameters' while the description implies a social identity/brand subject, so an agent may not know what string to supply.

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

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

The single input parameter has 100% schema description coverage, so the baseline is 3. However, the schema text 'parametros del producto (JSON o texto)' is generic and product-oriented, and the tool description does not clarify the expected identity- or brand-related input format, leaving ambiguity about what exactly should be passed.

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

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

The description names a specific resource (decentralised social identities), a specific task (brand-impersonation verdict), and enumerates the exact output verdicts (AUTHENTIC / DOUBTFUL / ACTIVE_IMPERSONATION). This clearly distinguishes it from sibling tools like domain_risk, asset_risk, and wallet_enrich.

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

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

The description gives a clear usage context: use this when a brand-impersonation risk verdict is needed for social identities correlated across independent sources. It does not explicitly name alternatives, exclude other cases, or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context around default thresholds and flag logic, but it is truncated mid-sentence and does not disclose potential result limits or data freshness.

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

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

The description is dense and gives concrete thresholds early, but it ends abruptly with 'Each alert car', creating an incomplete and confusing fragment. It is compact but not a cleanly structured definition.

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 core detection logic is described and an output schema exists, but the description lacks usage guidance, clear parameter mapping, and a complete ending. For a tool with many siblings and a generic input schema, the missing context is significant.

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

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

The schema only exposes a generic 'input' string with an unhelpful description, so the tool description adds value by naming min_usd and lookback_hours with defaults. However, it never explicitly explains how these map into the JSON/text input, leaving parameter construction partly ambiguous.

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

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

The description states a specific action—scanning large Polymarket fills and flagging wallets—with explicit criteria (fresh wallets, oversized bets, extreme odds before moves). It is clearly an insider-trade detection tool, though it does not explicitly differentiate itself from siblings like polymarket_whales or wallet_enrich.

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

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

There is no when-to-use guidance, exclusions, or mention of alternatives. The description implies a use case through the detection logic, but with 29 sibling tools, an agent gets no help deciding when to choose this over related market-analysis 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?

The description adds meaningful behavior beyond the annotations: it states the data is live, that the bundle has partial degradation and 'never fails whole', and that responses are Ed25519-signed. These are valuable operational traits that the annotations do not convey.

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

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

The description is compact and front-loaded with the core purpose, and the additional details about pricing, degradation, and signing earn their place. It loses one point for the typo 'FRE' and a slightly dense parenthetical list, but overall it is efficient.

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

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

The description, combined with the annotations and output schema, gives a fairly complete picture: the tool is safe, idempotent, bundled, live, and signed. The main gap is that the single input parameter is not explained in practical terms, so an agent may not know how to select or customize datasets, though the bundle appears to return all seven by default.

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 input parameter is at least documented. The tool description itself adds no additional parameter-level meaning, and the schema's 'parametros del producto' is vague about expected content. With full coverage, the 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 a 'Macro intel bundle' that aggregates 7 specific live macro/market datasets into one call, naming each dataset explicitly. This makes its function obvious and distinguishes it from the individual sibling tools like market_sentiment or tvl_concentration, since it is a combined offering.

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

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

The description gives useful usage context by noting that the bundle is 'cheaper than buying each separately' and mentions a free-call allowance. However, it does not explicitly state when to avoid using it or name specific alternative tools with selection criteria, so it stops short of full routing 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?

Annotations already establish read-only, non-destructive, idempotent behavior. The description adds useful extras: partial degradation, Ed25519 signing, and a free-call limit via X-WA. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core definition, followed by the signal behavior and operational caveats. Each sentence adds information, though 'Partial degradation' is terse and could be clearer.

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 a solid conceptual overview and the annotations cover safety, but the generic input parameter is not further explained and there is no return-format or output schema to compensate. The agent is left to infer how to phrase the request against the generic input field.

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 single 'input' parameter is already documented at the schema level. The description does not add parameter-specific guidance, so the baseline 3 is appropriate.

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

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

The description clearly states the tool computes a macro surprise index as a z-score against a trailing 12-change distribution for specific ECB series, and flags strong or moderate surprises. This is a specific resource and action, though it does not explicitly contrast itself with any sibling tool.

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

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

The description gives a clear use context: it should be used when official ECB data prints, and it is scoped to the listed ECB series. It does not name alternative tools or state explicit when-not conditions, 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?

The annotations already declare readOnlyHint=true and idempotentHint=true. The description adds important behavioral context beyond annotations: it is a signed x402 call, costs 0.03 USDC on Base, and provides real-time external data. This usefully signals payment/auth requirements and live external dependency.

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

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

The description is extremely concise: three short sentences, each carrying distinct information—purpose, signing requirement, and cost. There is no redundant wording and the main action 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 covers purpose, cost, and signing, and annotations plus output schema cover safety and return shape. However, it lacks usage-selection guidance and provides no detail about what the input string should contain or how the sentiment signal is computed, leaving some ambiguity for the agent when preparing a call.

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 only parameter 'input' is described as 'parametros del producto (JSON o texto)', which is vague, but the description text adds no further parameter meaning. Schema does the heavy lifting, and the description does not clarify expected input structure.

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 action and resource: 'Get real-time market sentiment signals via x402 M2M API.' This is specific enough to identify the tool's purpose. It does not explicitly distinguish it from sibling tools, though the sentiment focus is fairly 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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions or context for selection. The description only says what the tool does, not when an agent should choose it over siblings like daily_intel_brief or macro_surprise.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds a useful “No charge on service fail” guarantee and clarifies that the result depends on a live market and window selection. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded with the core purpose, followed by the intended use and failure-cost detail. Every sentence adds useful information without redundancy.

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

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

For a simple one-input read-only market tool, the description covers the output fields, window options, intended use, and failure behavior. Output schema existence handles return-shape details. The only notable gap is the exact input serialization format, which prevents a perfect score.

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

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

The schema only provides a generic “input” string description, so the description adds real value by naming the window param and enumerating accepted values: 1h / 24h / 1wk. It does not specify the exact JSON encoding, but it meaningfully clarifies what the parameter controls.

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: returns active Polymarket markets ranked by biggest price swing over configurable windows, and lists the exact fields returned. The focus on odds movers and price swings distinguishes it from sibling Polymarket tools like polymarket_whales or market_sentiment.

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

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

It gives a concrete use case: momentum signal prediction bots scan this data before entering a market. The window param is also highlighted as the key selection. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavior: the default 7-day window, the list of output fields, and the uma_risk flag for contested or undecided resolutions. This is valuable context beyond the annotations.

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

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

The description is reasonably compact and front-loaded with the core purpose, followed by a useful field list. However, it ends abruptly mid-word at 'resolu', which signals truncation or an incomplete thought, reducing overall structural quality.

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 and output fields well, and an output schema exists to handle return values. But it does not explain how to override the default N days through the input parameter, nor does it mention any exclusions or limitations. It is adequate for a default invocation but incomplete for full parameterized use.

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 one generic 'input' parameter whose description is a vague Spanish catch-all, so it does not document how to set N. The description adds that N defaults to 7, which is useful, but it never explains the expected input format, e.g., whether N is a number, JSON key, or text. The default invocation is clear, but customization is under-specified.

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

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

The description names a specific resource — Polymarket markets ending within N days — and enumerates the key data fields: UMA resolution status, bond/reward, hours to resolution, price, volume, liquidity, and the uma_risk flag. This clearly conveys what the tool provides, though it does not explicitly contrast itself with sibling resolution 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 phrase 'Lets prediction agents avoid or exploit resolu...' implies a use case, but the sentence is truncated and no explicit guidance is given about when to use this tool versus siblings like resolution_source_feed, resolution_verdict, or dispute_risk. The intended context is inferable, but not fully stated.

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

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

Annotations already mark it read-only, open-world, idempotent, and non-destructive. The description adds value by disclosing a default threshold of 5000 USD, tunable via min_usd, and the data source ('straight from Polymarket public trades data API'), which tells the agent how the behavior is scoped.

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 front-loads the tool's identity and puts the key threshold rule early; the field list is dense but useful. It is slightly run-on and appears truncated at 'before t', which prevents a 5.

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

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

For a one-parameter read-only query with an output schema, the description gives enough: source, default scope, tunable parameter, and return fields. It is missing a clear statement of how to format the input payload and what the truncation 'before t' was meant to say.

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

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

The schema only has a generic 'input' string described as 'parametros del producto'. The description compensates by naming a concrete parameter, min_usd, and its default, adding real meaning beyond the schema. It still doesn't define the expected JSON/text format, so it isn't perfect.

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 phrase 'Live whale-tracking on Polymarket' names a specific resource/domain, and 'the latest large trades ... with wallet, side, outcome, size, price...' makes the output concrete. The 'whale-tracking' scope clearly separates it from prediction-market siblings like odds movers or resolution watch even without naming them.

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

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

'Built for prediction-market agents that track smart money before ...' gives an explicit target use case and context. It does not name alternatives or exclusions, so it stops short of a 5, but the intended scenario is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the feed is pay-per-event, each delta is individually Ed25519-signed, and the full response is additionally signed. This goes beyond the structured hints.

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 and front-loaded, but it ends mid-sentence at '(d', suggesting truncation. That incomplete final clause prevents a higher score for structural integrity, even though the content provided is otherwise economical.

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 output schema exists, the description does not need to detail return values. It covers the data source, the payload format, the cost model, and the signing behavior. The main gap is the truncated final sentence and the absence of any explicit note about authentication or rate limits, but these are not critical for an agent selecting and invoking this 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 provides only a generic 'input' string with a vague Spanish description, so the description carries the real semantic weight. It specifies the expected JSON payload shape: since as cursor or ISO, slug, and limit capped at 200. This is exactly the meaning an agent needs beyond the schema.

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

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

The description states a specific verb and resource: a 'pay-per-event feed of signed Ed25519 deltas from the x402/M2M endpoint registry,' including new and changed endpoints, payTos, and listings. This is clearly distinct from the sibling tools, which focus on risk, audit, and market intelligence rather than registry deltas.

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 implies when to use the tool: when you need a feed of registry changes, and it gives explicit pull syntax with since, slug, and limit. It does not name exclusions or alternatives, but none of the siblings appear to compete with this registry-watch function, so the context is sufficient.

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

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

Annotations already establish readOnly, openWorld, idempotent, non-destructive behavior, so the description's job is lighter. The description adds that data is READ LIVE and includes threshold/distance/verdict outputs. It does not contradict annotations. However, it adds no context about data freshness limits, live-source failure behavior, or what 'distance' means, so it is adequate but not rich.

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 first operational sentence is dense and useful, but the description starts with redundant product branding ('SYNTHORA resolution-source-feed') that mirrors the tool name. More importantly, the description is truncated mid-sentence: 'the answer a trader checks before ' — an incomplete structure that undermines its usability.

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 read-only informational tool with an output schema and rich annotations, the description covers the core output fields and market scope. But the truncated ending and lack of sibling differentiation leave gaps: the agent still cannot determine when this tool is preferable to resolution_verdict or market_resolution_watch, and the final usage rationale is lost.

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

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

The schema only has a generic 'input' field with an unhelpful Spanish description. The tool description compensates by specifying that the input should be a Polymarket market slug and that the tool expects one market. This adds real meaning beyond the schema, though it could be more precise about expected format for text vs JSON.

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

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

The description clearly states a specific action: give a Polymarket market slug and get its official resolution source with current value, threshold, distance, and verdict. It names the covered market scope (IMF PortWatch chokepoint markets). However, it does not differentiate itself from closely named siblings like resolution_verdict or market_resolution_watch, so it misses the final distinction step.

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 implied usage context: use this tool when you need live resolution status for Polymarket markets, particularly Hormuz chokepoint markets. But there is no explicit when-to-use guidance, no exclusion criteria, and no mention of alternative tools, even though very similar sibling tools exist.

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

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

Annotations already declare readOnly and non-destructive behavior, so the description only needs to add context beyond that. It adds useful details: the response includes declared sources, a main risk, a cost of $0.05, and the possible INDECISO direction. No contradiction with annotations.

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

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

The description packs a great deal of useful information into two compact sentences: input, output components, sources, risk, use case, and price. The most important purpose is front-loaded, and there is no redundant filler.

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

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

For a read-only tool with an output schema, the description covers the essential inputs, outputs, sources, and cost, which is enough for an agent to make a first call. Minor gaps include exact input encoding and data freshness, but these do not undermine basic usability.

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 only one generic 'input' property described as 'parametros del producto (JSON o texto)', which provides no tool-specific meaning. The description adds that the input should be a market slug, but it does not clarify the exact expected format, such as whether to pass a plain slug string or a JSON object with a slug field.

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 decision verdict for Polymarket prediction markets and specifies the key output components: probability, direction, evidence bullets, and main risk. The 'verdict' framing and decision-agent use case help distinguish it from sibling watch tools, though it does not explicitly name those alternatives.

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

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

The description gives a clear context for use: agents deciding whether to bet or move assets. It does not explicitly state when not to use this tool or mention alternatives like polymarket_resolution_watch, but the intended scenario is reasonably specific.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about cross-verification with the best-liquidity pool, but this is cut off and no other behavioral traits such as data freshness, limitations, or output semantics are disclosed. No contradiction with annotations.

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

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

The description is a single long, marketing-style run-on sentence that ends abruptly mid-word ('DexScr'). It packs examples, an aside, and an explanation into one breathless clause rather than being concise and front-loaded. The truncation is a structural defect.

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

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

For a one-parameter tool with rich annotations and an output schema, the description should at least explain what input is accepted and what the tool returns. The truncated text leaves a dangling thought and gives no operational guidance. It is not complete enough for an agent to confidently invoke it with the right input.

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

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

Schema coverage is 100%, so the baseline is 3. However, the schema's only parameter is a generic 'input' string with a vague description ('parametros del producto (JSON o texto)'). The tool description does not explain what input this tool expects, so it fails to compensate for the schema's ambiguity.

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 what the tool measures: the gap between 24/7 on-chain tokenized stock prices and their last official NYSE close. It includes concrete examples (AAPLon, TSLAon) and the timing edge, making it distinguishable from the risk-focused siblings. However, it lacks an explicit verb like 'returns' or 'monitors,' and the description is truncated mid-sentence.

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

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

No explicit guidance on when to use this tool versus alternatives is given. The description implies a use case (weekend/overnight price discovery before TradFi opens) but provides no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of sibling tools or exclusions.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavior beyond annotations: it returns a MATCH or CLEAR verdict, covers four named official downloads, and claims multilingual resilience. No contradiction with annotations exists.

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

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

The description is compact and dense, placing the action and verdict early and adding source/language details in one flow. The 'SYNTHORA sanctions-screen:' prefix is somewhat redundant with the tool name, but no sentence wastes the reader's time.

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 low parameter complexity, rich annotations, and presence of an output schema, the description covers the core facts an agent needs: purpose, verdict result, source coverage, and language robustness. It could be more explicit about accepted input formats, but the schema already labels the parameter as JSON or text.

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 the single parameter as 'JSON o texto' with 100% coverage, so the baseline is 3. The description reinforces that the input is something to be sanctions-screened, but it does not detail expected fields, formats, or example structures 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 as sanctions screening and specifies the output verdict (MATCH / CLEAR) and the data sources (OFAC, UN, OpenSanctions). It is specific and actionable, though it does not explicitly distinguish itself from overlapping siblings such as vessel_sanctions or identity_risk.

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 intended use case is implied well: run sanctions screening on an input against official lists. The description gives useful context like multilingual support and tested Cyrillic transliterations, but it provides no explicit guidance about when not to use this tool or which sibling tool to choose for related sanctions/risk needs.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful behavioral context by mentioning live IMF PortWatch and WaveWatch III data crossed with official price moves. However, the truncated ending 'Physical deterioration not yet' leaves an intended behavioral or interpretive detail unexplained.

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 information-dense but structurally broken: it ends abruptly with 'Physical deterioration not yet,' which appears to be an incomplete sentence. While the core concept is front-loaded, the truncation hurts clarity and readability.

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

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

The description conveys the domain and data sources but does not explain how the divergence is computed, how to interpret the output signal, or what the incomplete final phrase means. The presence of an output schema mitigates return-format concerns, but an agent still has to infer important invocation and interpretation details.

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

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

There is only one parameter and schema description coverage is 100%, so the baseline of 3 applies. The description does not add any extra meaning about how to format the JSON or text input, and the schema's own label 'parametros del producto' is generic. No additional parameter semantics are provided.

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

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

The description states a specific analytical object: physical-vs-price divergence for shipping/logistics stocks, and even names concrete tickers and data sources. It is not a tautology, and it is distinguishable from siblings like chokepoint_risk because it ties physical reality to stock price movement. However, it lacks an explicit verb like 'computes' or 'reports,' and the thought trails off mid-sentence.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as chokepoint_risk or vessel_sanctions. The description implies an analytical use case but does not state prerequisites, exclusions, or conditions that should route an agent to a different sibling.

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

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

The annotations already establish that the tool is read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context beyond those annotations: it fuses four live NOAA SWPC feeds, is described as 'operational', and discloses a per-call cost of $0.01 USDC x402 Base. No behavioral contradiction exists.

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

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

The description is a single compact sentence that front-loads the tool's core purpose before listing data sources, use cases, and cost. It is dense but every clause contributes useful information, with only minor jargon such as 'x402 Base' left unexplained.

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?

While the output schema exists and the description covers data sources, sectors, and pricing, the single free-form input parameter is critically under-specified. An agent invoking this tool has no guidance on what product parameters to include, such as location, time range, or risk thresholds, which is a major gap for a composite operational risk tool.

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

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

Schema coverage is 100% and the single input parameter is at least described as accepting JSON or text product parameters. The tool description itself adds no further parameter meaning, and the schema-level description is vague about accepted keys or structure. Per the high-coverage baseline, a 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 a composite space-weather risk verdict built from four specific NOAA SWPC data feeds, and names the target sectors (defense, aviation, satellites, power grid, precision GPS). It stops short of an explicit verb like 'returns' or 'computes', but the phrase 'risk verdict' makes the output nature clear and distinguishes it from the many financial/risk 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 gives explicit application contexts: defense, aviation, satellites, power grid, and precision GPS, so an agent can infer appropriate use cases. It does not name sibling alternatives or state when not to use the tool, but the context is clear enough to route a space-weather-related request here.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: deterministic evidence, historic IPs, open surfaces, and the $0.03 cost. No contradiction with the read-only 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?

One compact sentence front-loads the purpose, then packs evidence types and cost into the same breath. There is no filler; the only minor redundancy is the product-name prefix before the colon.

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

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

With an output schema present and annotations covering safety, the description gives enough for selection and basic invocation: target a domain/host, get a score/breakdown, and know the cost. It would be stronger with explicit input formatting and sibling-tool routing, so it does not reach a 5.

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

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

The schema already describes the single 'input' parameter at 100% coverage, so the baseline is 3. The description clarifies that the input should be a domain/host, but it does not specify the expected JSON or text structure, leaving some inference to the agent.

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 defines a clear deliverable: an external attack-surface score for a domain/host, with an exposure breakdown and deterministic evidence. The 'external attack-surface' framing helps distinguish it from generic risk tools like domain_risk, though no sibling is explicitly named. It lacks an explicit verb such as 'calculates' or 'returns', but the intent is 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?

It explicitly scopes the tool to 'any domain/host' and an external attack-surface assessment, giving the agent a clear trigger condition. It does not name sibling alternatives or state when not to use it, so it stops short of full routing 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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those: the signal comes from DeFiLlama, costs $0.03 USDC via x402 on Base, and targets a temporal edge window before price repricing. No contradictions with annotations.

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

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

The description is compact and front-loaded with the core signal definition, followed by use case, source, and pricing. The repeated 'SYNTHORA tvl-concentration' branding is mildly redundant but every substantive phrase earns its place.

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

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

For a simple one-input, read-only tool with an output schema, the description adequately covers what the signal is, who should use it, where the data comes from, and what it costs. The main gap is input semantics, which is also reflected in parameter_semantics; otherwise the operational context is sufficiently specified.

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 has a generic schema description ('parametros del producto (JSON o texto)') that says it accepts JSON or text but not what keys or values are meaningful. The tool description adds no parameter guidance, so despite 100% schema coverage, an agent cannot determine how to request a specific protocol, chain, or time window.

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

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

The description names a specific resource and objective: detect DeFi TVL drain/concentration anomalies, specifically protocols losing TVL before token price repricing. The 'temporal edge window' phrase gives it a distinct meaning, though it lacks a direct verb and does not explicitly contrast with 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?

It explicitly states the intended audience and scenario: 'for liquidation and risk bots' seeking the temporal mismatch between TVL drain and price. It does not name alternatives or state when not to use it, but the use case is clear enough to guide 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?

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond this: it returns an Ed25519-signed verdict and enumerates specific risk patterns it detects. There is no contradiction with the annotations.

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

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

The opening sentence is strong and front-loaded, and the list of detected cases is information-dense. However, the description is truncated mid-example and the payload example conflicts with the schema structure, which weakens the overall clarity and coherence.

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?

Since an output schema exists, omitting return-value details is acceptable, but the input contract is critically under-specified. There is no explanation of how to supply the transaction payload through the `input` parameter, no clear list of supported chain values, and no indication of required fields.

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 a single `input` string parameter with a generic Spanish placeholder description: 'parametros del producto (JSON o texto)'. The tool description instead shows a POST body with `tx_hash`, `chain`, and `to` fields, but never explains how these map to the `input` parameter. This is a serious mismatch that will confuse an agent constructing a valid invocation.

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

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

The description clearly states that the tool decodes the real intent of an on-chain transaction on Base/Ethereum and returns a risk verdict with severity categories. It also lists specific detectable patterns like unlimited approvals and reverted transactions. It does not explicitly distinguish itself from sibling tools, so it stops just short of a perfect score.

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

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

The phrase 'Catches unlimited approvals, opaque selectors, value-to-contract, reverted tx' implies when this tool is useful, and the example POST payload gives some invocation context. However, there is no explicit 'use this instead of X' guidance or mention of when not to use it, despite 29 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond that: verdict categories, decoded intent, warnings and checks performed, plus the $0.03 USDC x402 payment context. No contradiction with annotations.

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

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

The description is compact and front-loaded: first the action and verdicts, then the use case, then cost/transport. Every phrase adds useful selection or invocation context, with no restatement of schema metadata.

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?

Output schema and annotations cover return values and safety profile, so the main gap is input construction: the description never explains what to place in 'input' — raw transaction JSON, hex-encoded tx, fields like to/data/value/chainId? For a tool an agent is expected to invoke correctly, this missing input contract is significant.

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 one generic 'input' string described only as 'parametros del producto (JSON o texto)'. The description indirectly tells the agent the input should relate to an EVM transaction, but it does not specify required fields, transaction JSON shape, chain, or how to format the input. Schema coverage is high, so baseline 3 applies; the description only partially compensates.

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: 'simulate an EVM transaction before signing'. It names concrete outputs — SAFE/WARN/DANGER verdict, decoded intent, warnings and checks — and positions itself as 'Pre-trade safety for agent wallets', which clearly differentiates it from siblings like txintent.

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 usage context: use it before signing an EVM transaction, especially for agent-wallet pre-trade safety. It does not explicitly state when not to use it or name alternative tools, so it stops short of full routing 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?

Annotations already mark it read-only, idempotent, and non-destructive; the description adds source details (OFAC SDN/US Treasury), scale (1,524 ships tracked), access requirements (free, no key), and the screen-vs-list behavior. This is useful context beyond the annotations, though it omits update cadence or match semantics.

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

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

Three compact sentences, with the core screening function front-loaded and each sentence adding a distinct fact: action and target, compliance use case, and list mode/source/cost. No redundant or vague wording.

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

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

For a one-parameter, read-only, well-annotated tool with an output schema, the description covers what, when, input content, source, and cost. The only meaningful gap is that the description does not explicitly say that omitting input returns the list snapshot, though 'List mode' strongly implies 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?

The schema's only parameter is a generic 'parametros del producto (JSON o texto),' while the description supplies the domain meaning: an IMO number or vessel name, plus a 'List mode: full sanctioned-fleet snapshot' behavior. It does not specify the exact JSON/text shape or how list mode is triggered, but it adds substantial meaning 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 opens with a specific verb and resource: 'screen any vessel (IMO or name) against the OFAC SDN sanctioned-vessels list.' It also states its role as 'the compliance check before touching tanker/shipping trades or chokepoint bets,' making it clearly distinct from the broader sibling risk 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?

It gives an explicit trigger ('before touching tanker/shipping trades or chokepoint bets') and a secondary list-mode use ('full sanctioned-fleet snapshot'). It does not name sibling alternatives like sanctions_screen or state when not to use it, so it stops short of full routing 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?

The description transparently states that the tool is keyless, costs $0.03 USDC via x402 Base, and composites CoinGecko markets with DeFiLlama DEX volume. These details meaningfully extend the annotations, which already indicate read-only, idempotent, non-destructive 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 compact and information-dense, covering purpose, metric definition, data sources, authentication, and pricing in two short sentences plus fragments. It loses one point for minor redundancy such as 'SYNTHORA volume-anomaly' followed by 'crypto volume-anomaly alerts'.

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 annotations and the presence of an output schema, the description covers the essential selection and invocation context: metric, data sources, cost, auth, and use case. It is slightly incomplete on how the free-form 'input' parameter should be structured, but that is mitigated by the openWorldHint and the optional parameter.

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 even though the description itself adds no parameter-specific guidance. The lone 'input' parameter is documented only as 'parametros del producto (JSON o texto)', which is generic and does not explain what fields or formats the tool expects.

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

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

The description states a specific purpose: producing crypto volume-anomaly alerts for arbitrage bots, defined by anomalously high 24h turnover (volume/mcap) versus cohort via z-score. This is a specific verb+resource with clear scope, and the metric definition makes it readily distinguishable from the sibling tools such as market_sentiment and emerging_protocols.

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 usage context: it is aimed at arbitrage bots and positioned as an early pump/unusual-activity signal. It does not explicitly mention when not to use it or name alternatives, so it falls short of a 5, but the intended use case is evident.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful non-redundant context by naming the specific sanctions lists (Tornado Cash, Lazarus, Garantex), the supported chains (Ethereum + Base), and the risk score format with severity buckets. It does not contradict the annotations, though it is truncated and does not discuss edge cases or errors.

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 and front-loaded with the core purpose, and most phrases add information. However, it is a run-on-style sentence that crams many outputs together and is truncated mid-word ('contract-vs-EOA dete'), which makes it feel incomplete rather than deliberately concise.

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

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

Given that an output schema exists and annotations cover safety, the description covers a lot: input type, supported chains, sanctions lists, and output dimensions. Still, the parameter mapping is left vague, sibling differentiation is missing, and the truncated final clause leaves the description slightly incomplete for a multi-purpose enrichment 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 single input parameter only has the generic Spanish description 'parametros del producto (JSON o texto)', which gives the agent little semantic guidance. The tool description partially compensates by specifying accepted wallet forms (0x address or ENS name), but it never explicitly states how that wallet should be mapped to the 'input' parameter or what JSON structure is expected.

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 identifies a specific action ('enrich'), a specific resource ('any EVM wallet'), and enumerates concrete outputs: a 0-100 risk score with low/medium/high buckets, OFAC SDN sanctions screening, and on-chain activity on Ethereum and Base. It is largely distinguishable from narrower siblings like sanctions_screen because it bundles multiple enrichment categories, but the truncation at 'contract-vs-EOA dete' and lack of an explicit contrast to related tools keep it from 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 phrase 'in one call' and the broad scope 'any EVM wallet' imply this is a consolidated enrichment lookup, and the listed outputs suggest when an agent might want it. However, the description never explicitly says when to prefer wallet_enrich over sibling tools such as sanctions_screen, threat_exposure, or txintel, nor does it state 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.