f1ow

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

The readOnlyHint annotation already covers the safety profile, and the description adds the 7-day scope and filtering behavior. However, it does not disclose response shape, pagination, or whether some catalyst types are excluded, so the behavioral detail 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?

Two tight sentences carry the full meaning: primary action and time window first, optional filter second. No filler or redundancy.

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

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

For a simple read-only list tool with one optional parameter, the description is complete enough to invoke correctly. The readOnlyHint covers safety, the schema covers the parameter, and the description clearly defines what is returned and over what window.

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 fully documents the single 'coins' parameter with a comma-separated example and the omit-for-all-coins instruction. The description essentially repeats that example without adding validation, format, or default-behavior details 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 uses a specific verb ('Lists'), names the resource ('upcoming crypto catalyst events'), and adds a clear time horizon ('next 7 days'). The word 'crypto' helps distinguish it from the sibling catalysts_economic_calendar, so an agent can tell them apart.

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: list crypto catalyst events over the next 7 days, optionally filtered by coin IDs. It does not explicitly name alternatives or exclusion cases, 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 readOnlyHint=true, so thedescription does not need to establish the read-only nature. The description adds useful behavioral context: the time range, the type of content, and how min_importance changes the result set. It does not disclose return structure or pagination, but for this simple read-only tool the added behavior is sufficient.

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

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

Two short sentences cover the core purpose, time window, and optional filter behavior with no wasted words. The most important information appears first, and every clause contributes to an agent's ability to invoke the tool correctly.

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 one optional parameter and no output schema, the description provides the essential content, schedule scope, and filtering option. It could be more complete by describing the returned fields or contrasting it with catalysts_calendar, but those are minor gaps relative o the tool's simplicity.

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

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

There is only one parameter and the schema already documents it fully, including the 1-3 scale and default of 2. The description essentially restates the schema's meaning rather than adding new semantic or edge-case detail, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource as scheduled macroeconomic data releases with concrete examples (CPI, FOMC, jobs, GDP) and an explicit time window. It does not use a direct verb like 'list' or 'get,' and it does not explicitly differentiate itself from the sibling catalysts_calendar, so it falls just short of a 5.

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

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

The description gives clear context for when the tool is appropriate: macroeconomic releases within roughly the last 2 days to next 7 days. It also explains the optional min_importance filter. However, it does not state when to prefer an alternative tool like catalysts_calendar, so no exclusions are provided.

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?

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral traits: data is delayed, weekends are skipped, the latest row's age is reported, and the attached price is from that date rather than current spot. This gives the agent critical expectations about data freshness and 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 dense, well-ordered sentences: the core purpose and result shape come first, followed by essential caveats and the alias note. There is no filler or repetition of schema details that don't add value.

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

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

Even without an output schema, the description gives a sufficient picture of what the tool returns: total, per-fund breakdown, trend, date with age, and associated price. The parameters are fully covered, behavior is explained, and no critical calling information is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by enumerating accepted asset values (BTC, ETH, SOL, XRP), reinforcing the default, and explicitly documenting the 'symbol' alias. This goes beyond the schema's minimal descriptions.

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

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

The description precisely identifies the resource (spot-ETF net flows in USD), the supported assets (BTC, ETH, SOL, XRP with BTC default), and the output shape (latest day total, per-fund breakdown, trailing daily trend). This clearly distinguishes it from other flow-related siblings like flow_orderbook or flow_whale_context.

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 it: whenever ETF flow data for a supported asset is needed. It provides important context about timing (flows settle behind spot, skip weekends) and interpretation (positive means net inflows), but does not explicitly name alternatives or state when not to use this tool.

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

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

Annotations only provide readOnlyHint=true; the description adds substantial behavioral detail: cross-exchange aggregation, a single-venue fallback when the aggregate source is offline, series low/high context, and the ability to suppress the series. This is exactly the kind of beyond-annotation transparency the dimension asks for.

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 most important result summary is front-loaded, followed by interpretation, fallback, and parameter guidance. It is longer than average, but each sentence carries operational value; the only slight excess is the interpretive trading guidance, which is still relevant to selecting and using the tool.

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

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

With no output schema, the description compensates by enumerating the main returned components: current OI, changes, price change, 4h series, series low/high, and fallback behavior. It also explains the points parameter's effect on output shape, so an agent has enough to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents symbol and points thoroughly. The description reinforces the points behavior (trim, omit, or suppress) and ties symbol to 'one coin', but does not add materially new parameter semantics beyond that baseline.

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

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

States a specific deliverable: current market-wide cross-exchange aggregate open interest in USD for one coin's perpetuals, plus 24h/7d changes, 24h price change, and a 4h series. This clearly distinguishes it from siblings like funding_current or market_candles, and it even references market_candles as a companion for the price leg.

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

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

Gives clear analytical context: read OI against price, use the 4h series bucket-by-bucket, and pair with market_candles at 4h for the price leg. It does not explicitly list when not to use this tool versus other derivatives-related siblings, so it misses the top bar.

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, so the read-only nature is covered. The description adds meaningful behavioral context by stating it returns the most active matching markets and enumerating the returned fields, giving the agent a clear sense of behavior 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 two sentences with no filler. It front-loads the core purpose, provides concrete examples, and immediately states the output content, making it efficient and well-structured.

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

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

For a single-parameter, read-only tool with no output schema, the description provides sufficient context: what the tool does, how the query is used, and what the response will contain. No missing information is critical for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents the query parameter thoroughly. The description adds illustrative topic examples, but does not materially extend parameter meaning beyond what the schema 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 returning prediction-market odds for a topic, with specific output elements (per-outcome probabilities, volume, resolution date). It is easily distinguished from siblings like market_quotes or funding_current by its unique focus on prediction markets despite not naming an alternative.

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: call it when you need market-implied probability odds for a given topic. However, it does not explicitly state when to prefer this over other market-data tools or mention any exclusions, so usage guidance is only implied.

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

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

Annotations already provide readOnlyHint=true, signaling a safe read operation. The description adds useful context about full-text search and the returned result fields, but it does not disclose limitations such as the exact date range for 'recent' or any pagination constraints. With annotations covering safety, a moderate score is appropriate.

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

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

The description is two tight sentences. The first sentence front-loads the core action and scope; the second sentence states the return payload. Every clause earns its place with no redundancy or filler.

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

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

For a simple one-parameter tool, the description is mostly complete: it explains both the query semantics and the output format (form type, filer, link), compensating for the missing output schema. The only minor gap is the ambiguity of 'recent' (no defined look-back period), which could affect expectations but is not blocking.

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%: the query parameter is fully documented with its own example ('a company name, ticker, or theme'). The description repeats the same examples without adding additional semantic detail beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description uses a specific verb ('Searches') and resource ('recent regulatory filings'), specifies the search mode ('full-text'), and lists the exact output fields (form type, filer, direct document link). This clearly differentiates it from siblings like news_search and market_quotes, which cover different domains.

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 (when needing regulatory filings by company, ticker, or theme) but does not explicitly state when not to use it or contrast it with alternatives. No exclusions or routing guidance are provided, leaving the context to be inferred.

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?

Beyond the readOnlyHint annotation, the description discloses meaningful runtime behavior: the tool falls back from Hyperliquid to Bybit, the response names which venue answered, and positive imbalance means more bid depth. This gives the agent expectations that annotations alone do not capture.

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

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

Two compact sentences convey the metric set, polarity convention, venue fallback, and response naming behavior. The most important scoping information is front-loaded, and every sentence adds new information.

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

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

Given a single required parameter, a high-coverage schema, an output schema, and a read-only annotation, the description covers the needed behavioral details: what the snapshot contains, how imbalance is signed, and which venue will respond. Nothing essential is missing for selecting and calling 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 sole parameter symbol is fully documented in the schema with an example, and the description reinforces that it is a coin symbol for a perpetuals contract. This meets the baseline of schema-driven coverage, but the description adds little extra semantic depth beyond 'one coin's perpetuals.'

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 concrete resource — an order-book snapshot for one coin's perpetuals — and specifies what is included: best bid/ask, spread in bps, top-of-book depth, and imbalance. It also distinguishes itself by noting the single-venue Hyperliquid/Bybit fallback behavior, which sets it apart from broader market or multi-venue 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 makes the use case clear: retrieving current order-book liquidity and depth imbalance for a single coin's perpetuals. It does not explicitly name siblings or say when not to use it, but the 'single-venue by nature' warning helps an agent avoid treating it as a multi-venue comparison tool.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral nuances: the transfer feed only covers ERC-20 tokens, native assets fall back to USDT exchange flows, and the tool interprets withdrawals as accumulation and deposits as potential sell pressure. This adds substantive context about data provenance and meaning that an agent needs to interpret results correctly.

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?

Four sentences, each with a distinct job: scope/components, asset-class caveat, interpretation, and alternative tool. The main purpose is front-loaded, and the prose is dense but not verbose. No filler or repeated schema 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 read-only aggregate tool with no output schema, the description covers data sources, scope, caveats, and interpretation. It does not specify the response shape or group/pagination behavior, but with only two simple parameters and a clear aggregation purpose, this is a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, with both `symbol` and `min_usd` already clearly documented. The description reinforces the threshold concept ('above a USD threshold') and the coin scope, but it does not add new parameter-level detail beyond what the schema provides. 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 uses a specific verb ('Aggregate') and resource ('whale context for one coin'), then enumerates the concrete components: exchange reserve changes, Binance perps positioning, and large transfers. It also explicitly states the level of detail ('cohort-level, no individual wallets'), which distinguishes it from flow_whale_positions without needing to open that 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 opens with the scope ('for one coin') and immediately contrasts with the sibling tool: 'For specific whale wallets and their live positions use flow_whale_positions.' It also provides interpretive guidance on when withdrawals/deposits matter, making the intended use case clear. This is explicit routing between alternatives.

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

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

With readOnlyHint=true already conveying the non-mutating nature, the description adds meaningful behavioral context: it auto-discovers accounts from the venue leaderboard, returns a detailed set of per-position fields, and supports following specific wallets. It could go further by noting edge cases like invalid addresses or data freshness, but it is transparent about the main 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 concise and front-loaded with the core purpose, followed by default behavior, optional parameter behavior, and a pointer to the relevant sibling tool. Every sentence earns its place with 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 single-optional-parameter read-only tool with an output schema, the description covers the default discovery mode, the optional address mode, the returned fields, and the natural alternative for cohort-level signals. Nothing essential is missing for correct selection and invocation.

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

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

The schema already covers the single parameter thoroughly with a 100% description coverage rate, including the comma-separated format, max 10 wallets, and omit-to-auto-discover behavior. The description adds only minor nuance like 'follow specific wallets instead,' so baseline 3 is appropriate.

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

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

The description clearly identifies the tool's function: returning live whale positions on Hyperliquid perps, including specific fields like equity, side, notional, entry price, liquidation price, leverage, and unrealized PnL. It also explicitly distinguishes itself from flow_whale_context, which handles aggregate cohort signals.

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

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

The description states the default behavior (auto-discover largest active whales), explains when to pass the 'addresses' parameter instead, and explicitly directs users to flow_whale_context for aggregate cohort signals. This gives clear when-to-use and when-not-to-use guidance.

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

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

The readOnlyHint annotation already covers the safety profile, so the description adds valuable behavioral context: data is merged across providers, the series can be trimmed via 'points', and the trajectory is highlighted as the key analytical signal. It discloses the aggregation behavior and output shape nuances, which go well beyond the annotation.

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 longer than strictly necessary but front-loads the core definition, then adds interpretive value that genuinely helps an agent understand the output. Every sentence earns its place, though a slightly tighter version could still preserve the key guidance.

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

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

With no output schema, the description does a thorough job of explaining the returned components: the current rate, annualized estimate, trajectory, series, and window low/high. It also explains the meaning of the sign and how the series context matters, leaving little ambiguity about what the tool returns. Minor details like exact units or error cases are not covered.

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

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

Schema description coverage is 100%, with both 'symbol' and 'points' already well-documented. The description repeats and slightly rephrases the 'points' behavior ('trim the series', 'omit for the full ~10-day window'), but it does not add material new meaning beyond what the schema already states, so the baseline of 3 applies.

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

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

The description clearly states the tool returns the current perpetual funding rate for one coin, including an hourly rate, annualized estimate, 24h/7d trajectory, and an 8h-bucket series. It is specific about the resource and the data shape, and none of the sibling tools (e.g., derivatives_open_interest, market_quotes) overlap with funding rates, so it is easily distinguished.

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

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

The description makes the purpose and interpretation of the output very clear, with explicit guidance on how to read the trajectory and the positive/negative sign. It does not name alternative tools or explicitly state when not to use this tool, but the context is strong enough that an agent can infer appropriate usage.

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

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

Beyond readOnlyHint=true, the description discloses rich behavior: the source-priority hierarchy per market (Binance/Bybit → CoinGecko/CoinMarketCap for spot; Hyperliquid/Bybit → Binance futures for perp), the fact that spot/perp error rather than substitute, response labelig of the actually-delivered market/interval/source, conditional USD volume, and the still-forming last-candle flag. This far exceeds what annotations alone 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 core purpose is front-loaded in the first sentence, and every subsequent sentence earns its place — parameter semantics, defaults, constraint behavior, response contract. Despite covering five parameters and complex market selection, the description is dense but efficiently organized with no filler.

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

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

Given the tool's complexity (deprecated param, two enums, multi-source fallback, hard constraints) and an existing output schema, the description covers everything needed: purpose, each parameter's semantics and defaults, source selection behavior, error semantics, and response characteristics. Nothing critical is left to inference.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema: the source hierarchy for 'market', the hard-constraint vs substitute behavior, the default of 'auto', and the deprecation note for 'days' being ignored when interval is given — all genuinely new semantic content for parameters.

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

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

The opening sentence states a specific verb and resource: 'OHLC(V) candle history for a coin by symbol'. This unambiguously distinguishes it from siblings like market_quotes (current prices), market_overview, and ta_technicals, so an agent can select it without opening the schema.

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

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

The description gives clear context on how to use the tool — defaults, the 'auto' fallback behavior, hard constraints for spot/perp, and the deprecated 'days' param — which is strong usage guidance within the tool. However, it does not explicitly name alternatives or state when-not-to-use-it (e.g., no pointer to market_quotes for current prices), 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?

Beyond the readOnlyHint annotation, the description discloses non-obvious behavior: IDs are case-sensitive, symbols or wrong-case IDs are resolved via search, and the response names the actually fetched ID so a resolution is never silent. This is exactly the kind of behavioral context annotations do not 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?

Two sentences contain zero filler: the first front-loads the action and data returned, the second adds the resolution caveat essential for correct invocation. Every clause earns its place.

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

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

For a one-parameter, read-only tool with no output schema, the description is complete: it names the input forms, examples, case-sensitivity behavior, and the high-level return fields. An agent has enough to call it correctly and interpret the response.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by adding multiple examples and, crucially, the wrong-case resolution guarantee ('a resolution is never silent'), which clarifies what happens with non-exact inputs.

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 ('Fetches'), a clear resource ('a coin by its CoinGecko coin ID or ticker symbol'), and the exact fields returned (price, market cap, ATH/ATL, description). This distinguishes it from sibling list/quotes tools like market_coins or market_quotes without needing to open their schemas.

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 is clearly implied: use this tool when you need detailed single-coin data by ID or symbol. However, it never explicitly names sibling alternatives or states when-not-to-use it, so the agent must infer routing based on the tool name and description.

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 readOnlyHint annotation already covers the read-only nature. The description adds only the source/scope ('from the market-data provider') and does not disclose return format, ordering, or whether the list is exhaustive. This is acceptable but minimal.

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

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

The description is a single, front-loaded sentence with no filler. It delivers the key action and resource immediately and earns its place 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 no-parameter, read-only enumeration tool, the description is nearly complete: it explains what is returned (coin symbols). It would be slightly stronger if it noted that the returned symbols can be used as inputs to market_* tools, but nothing critical is missing for correct invocation.

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

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

The tool has zero parameters and the schema has 100% coverage, so there are no parameter semantics for the description to add. The baseline for a no-parameter tool is 4, as nothing is missing here.

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 ('Lists') and a specific resource ('coin symbols available from the market-data provider'). It clearly distinguishes this tool from siblings like market_coin_details, which provide details about individual coins rather than enumerating supported symbols.

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

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

The description implies the tool is used when you need the list of supported coin symbols, but it gives no explicit guidance about when to choose this tool over alternatives. It does not mention exclusions or point to related market tools such as market_quotes or market_candles.

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, so the read-only nature is covered. The description's word 'snapshot' adds a point-in-time behavioral context, but it does not disclose data freshness, latency, or any limitations. With annotations handling the safety profile, this 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?

A single, front-loaded sentence that names the deliverable and enumerates the key metrics with no filler. Every phrase earns its place, and the structure is easy to parse quickly.

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

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

With no parameters, high schema coverage, and an output schema present, the description gives an agent everything needed to understand what will be returned. The metric list is sufficiently complete for a no-argument market snapshot tool.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify about input semantics. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the returned snapshot contains rather than parameter syntax.

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 'Global market snapshot' and names the exact metrics it returns: total market cap, BTC/ETH dominance, Fear & Greed index, and Altcoin Season index. This differentiates it from most siblings by content, though it does not explicitly contrast it with closely related tools like sentiment_fear_greed or market_quotes.

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

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

The description explains what the tool provides but gives no guidance on when to choose it over the many sibling market and sentiment tools. No alternatives, exclusions, or conditions are stated, so the agent is left to infer usage from the phrase 'Global market snapshot.'

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?

Beyond the readOnlyHint annotation, the description explains that prices come from different sources, that spot and perp fields are intentionally separate, and that the difference is the basis. This prevents an agent from misreading the combined snapshot as a single unified price.

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 sentences, each carrying distinct information: scope/fields, price-source semantics, and filtering. There is no filler or duplicated annotation 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?

With an output schema present and readOnlyHint set, the description covers the tool's purpose, data semantics, provider merge behavior, and parameter usage. No critical calling context is missing.

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 fully documents 'symbols' with an example and omit behavior at 100% coverage. The description restates that but adds no new semantic detail beyond 'covered coin'.

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 concrete noun phrase ('Per-coin market snapshot') and enumerates specific data fields, making the tool's scope clear. The per-coin scope and merged-provider wording differentiate it from market_overview and funding_current, 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?

The symbol parameter usage is explicit ('Pass symbols to filter... omit for every covered coin'), but there is no guidance about when to prefer this tool over funding_current, derivatives_open_interest, or market_candles. Usage context is implied by the snapshot wording rather than explicit.

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 readOnlyHint annotation already establishes safety, and the description adds useful context about the data scope and threshold. It does not disclose output size, sorting behavior, or whether gainers and losers are returned separately, but for a parameterless read-only list this is a mild gap rather than a serious one.

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 phrase that front-loads the key concepts: 24h gainers, losers, and trend candidates. The parenthetical threshold adds precision without extra words, and every component 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 parameterless read-only tool, the description provides enough context to understand what results will represent and to choose the tool correctly. Minor missing details such as the number of entries returned or quote currency do not affect the ability to invoke it, since there are no parameters and the read-only annotation covers the safety profile.

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

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

The tool has zero parameters and the input schema is empty, so there are no parameter semantics for the description to clarify. The baseline score of 4 applies because schema coverage is trivially complete and no invocation arguments are needed.

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

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

The description clearly identifies the resource: ranked 24h gainers, losers, and trend candidates with a >+5% move threshold. It does not use an explicit action verb like 'returns' or 'lists,' and it does not explicitly distinguish itself from sibling tools such as market_trending, though the 24h movers framing implies a different purpose.

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 usage is implied: an agent should use this for recent price movers over 24 hours with significant percentage changes. However, there is no explicit guidance about when to prefer this over alternatives like market_trending or market_overview, and no exclusion criteria are stated.

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

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

The readOnlyHint annotation already covers safety, and the description adds the temporal 'currently' scope plus that a list is returned. It does not explain what 'trending' means, the ranking basis, or additional behavior, but for a read-only, zero-parameter tool this is a reasonable baseline.

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

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

The description is a single sentence that is front-loaded with the verb and resource, containing no filler or repetition. It is appropriately sized for a zero-parameter, read-only tool.

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 zero-parameter tool, the description adequately conveys that the output is a list of currently trending cryptocurrencies. Without an output schema, it could go further by defining 'trending' criteria, but the missing detail is minor given the tool's simplicity.

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

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

The tool has zero parameters, so there is no schema ambiguity for the description to clarify. The baseline for parameterless tools is 4 because no additional meaning is needed.

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

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

The description uses a specific verb and resource: 'Lists the currently trending cryptocurrencies.' It clearly states what the tool does, but it does not explicitly distinguish it from siblings like market_top_movers or market_coins, which could overlap conceptually.

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 'currently trending' implies this is the tool to use when a user asks about trending cryptocurrencies. However, no explicit when-not-to-use guidance or alternative routing is provided, leaving the agent to infer boundaries versus similar market 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 readOnlyHint annotation already signals safe read behavior, and the description adds useful behavioral context: results are limited to the last 7 days, filtered by recency, and crypto-native headlines are conditionally merged in 'when that feed is up.' This discloses dynamic data-source behavior beyond the annotation.

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 core action and resource, then adds the time window and recency caveat in a tight parenthetical. Every clause earns its place.

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

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

For a one-parameter read-only search tool, the description covers the query semantics and result scoping well. It does not describe output structure or pagination, but given the simplicity and absence of an output schema, this 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?

With 0% schema description coverage, the description must compensate for the single 'query' parameter. It implies that query is the topic phrase to search, which is meaningful, but it does not specify format, length, language, or any special syntax requirements.

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

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

The description clearly states the action and resource: 'Searches the web for news and articles on a topic from the last 7 days.' It includes a helpful temporal scope and recency filter, but it does not explicitly differentiate from sibling tools like sentiment_twitter or filings_search.

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

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

The intended use is implied: use this tool when you need recent web news or articles about a topic. However, there is no explicit guidance about when not to use it or which sibling tool might be preferred for social sentiment, filings, or other news-adjacent data.

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 readOnlyHint annotation already covers safety. The description adds useful behavioral detail: unsupported symbols return a plain message, time ranges are 24h/7d/30d, and gas price is not covered. 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?

Two sentences with no fluff. The main data scope is front-loaded, followed by input guidance and caveats. Every sentence 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 single-parameter read-only tool with no output schema, the description is complete: what metrics are returned, what input format to use, what unsupported inputs do, and what is excluded.

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

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

Schema coverage is 100%, so the schema already documents the symbol parameter. The description adds meaning by specifying 'own token symbol', giving L1/L2 context, and adding examples like 'BNB'. This goes beyond the schema's brief description.

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

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

The description states a specific verb and resource: returns on-chain TVL and network fees/revenue for one chain. It clearly distinguishes this from market-data siblings by focusing on on-chain metrics and a single-chain scope.

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

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

Clear usage context: use a chain's own token symbol, and non-L1/L2 tokens produce a plain 'not a tracked chain' message. It also excludes gas price. It does not explicitly name alternative tools, but the guidance is still actionable.

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

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

The description is consistent with the readOnlyHint annotation and adds the scope 'each connected data provider.' However, it doesn't disclose details like what health metrics are reported, whether it pings endpoints, or how statuses are represented. Since annotations already cover the read-only safety profile, the description adds only modest behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the action and the target resource, making it easy for an agent to parse quickly.

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

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

For a parameterless read-only health-check tool, the description gives enough information to call it correctly and understand the general result. There is no output schema, but 'health of each connected data provider' sufficiently conveys what the agent should expect, even if exact field names are not 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 tool has zero parameters, and the schema covers 100% of the (empty) parameter surface. The description doesn't need to explain parameters because there are none, and the baseline for no-parameter tools is appropriately strong.

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

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

The description uses a specific verb ('Reports') and resource ('health of each connected data provider'), making the tool's function unambiguous. None of the 28 sibling tools relate to provider health, so it is easily distinguished from them without needing to open schemas.

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 usage context is clear: an agent should call this tool when it needs the health status of connected data providers. It doesn't explicitly name alternatives or exclusions, but there are no sibling tools that overlap with this purpose, so the guidance 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?

Goes far beyond the sole readOnlyHint annotation, disclosing rate-limit avoidance ('ZERO per-symbol calls'), output interpretation ('says energy is loading, never direction'), and the un-backtested nature ('no backtest behind them'). It also tells the agent that 'NO CANDIDATES' is a real outcome, reducing the risk of misinterpreting empty results.

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

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

The description is long but earns its length: the purpose is front-loaded, and the six signals are each covered with interpretive context rather than restating schema. It could be more scannable with bullets or paragraph breaks, but the density is justified for a tool with this many distinct outputs.

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?

Complete for an agent: it explains the screening approach, the liquidity-filtered universe, the per-signal meaning, the trade geometry, and the follow-up workflow into research_positioning and ta_technicals. With an output schema present, the description need not detail return fields; it still covers behavioral context and parameter effects thoroughly.

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

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

Schema coverage is 100% and the schema descriptions are already thorough, so the baseline is 3. The description adds genuine extra semantics for 'symbols' ('every symbol named there is accounted for individually in the response — selected, excluded... or not quoted at all') and reinforces the 'intervals' behavior ('changing it produces a DIFFERENT trade rather than a refinement'), warranting a 4.

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

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

States a specific verb and resource: 'Cross-sectional opportunity scan across every major and medium-cap coin at once.' It also differentiates from sibling per-coin tools by explaining what it is not ('the screener the per-coin tools cannot be looped into safely') and explicitly references three siblings (research_positioning, research_regime, risk_position_size).

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

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

Gives explicit when-to-use guidance: 'Use it to pick what to look at, then research_positioning and ta_technicals on the two or three that stand out.' It also contrasts with alternatives ('explicitly NOT the own-history percentile research_positioning reports'; 'the per-coin form of the reading research_regime computes for BTC alone'), so an agent knows exactly when to pick this tool over siblings.

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

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

The readOnlyHint annotation already marks it read-only, and the description adds substantial behavioral context: it is deterministic ('same inputs, same read'), axes degrade gracefully under data limitations ('the axis degrades rather than substituting a single venue's OI'), some axes are flagged 'informational,' and the stance is a disclosed 'sum-of-votes rule.' It also explains the non-directional reporting behavior. 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 long, but the tool is intrinsically complex with nine axes, and each clause is information-dense. It is front-loaded with a one-line summary and usage-before-detail ordering, though the single giant paragraph could be improved with bulleted axes.

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 analysis tool with complex semantics, the description covers all behavior an agent needs: every axis, the vote/stance rule, farmed synthesis, focal points, threshold monitoring, determinism, and ordering relative to research_regime. The presence of an output schema lets the description focus on semantics, and nothing material is missing.

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 fully documents the only parameter with 'Coin symbol, e.g. "BTC" or "ETH"' (100% coverage), so baseline 3 applies. The description reinforces that the tool applies to a single coin ('for one coin', 'this per coin'), but it adds no new format or edge-case semantics 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: 'Deterministic positioning read for one coin,' and frames it as 'the game-state companion to research_regime,' answering a precise question ('who is crowded, who is paying, who is trapped, and where'). It differentiates itself from siblings by describing nine named axes rather than generic insight, so an agent can distinguish it from research_regime and risk_position_size.

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 invocation pattern: 'Call research_regime first for market context, then this per coin before sizing or timing decisions.' It also states what the tool does not provide — 'Reports the board, not a direction: crowding says who is paying, not where price goes' — so an agent knows not to use it as a directional signal. This is clear, actionable usage 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 only declare readOnlyHint=true, but the description goes well beyond that by disclosing the sum-of-votes rule, the compression exception that withholds the Trend axis vote, the informational non-voting asymmetry lean, the explicit thresholds, and the deterministic behavior. This is far richer than the annotations alone and gives the agent a clear model of the tool's 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 dense but every sentence earns its place: the core classification is front-loaded, and the vote rule, exception, lean, thresholds, determinism, and usage positioning are all operationally relevant. The detail is justified by the complexity of the regime logic.

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 already covering the return shape and zero input parameters, the description supplies exactly the contextual information an agent needs: the composite nature, the exception behavior, the asymmetry lean, and when to use the tool. Nothing essential is missing.

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

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

The tool has zero parameters, so there is no parameter ambiguity and the empty input schema is fully self-contained. The description uses this opportunity to clarify output semantics and behavioral rules, which is more valuable than restating empty parameter details.

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

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

The description clearly defines the tool as a deterministic market-regime classifier across seven explicit axes and states exactly what it produces: per-axis state, supporting numbers, votes, and an overall posture. It effectively distinguishes itself from raw-data sibling tools by positioning it as a composite first-call regime read.

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

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

The description explicitly frames the tool as a first call and explains that funding, sentiment, and flows should be interpreted differently depending on this regime. This gives an agent strong context for when to invoke it, though it does not list explicit when-not-to-use cases or name specific sibling tools as alternatives.

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

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

Well beyond the readOnlyHint annotation, the description discloses that technicals are 'computed in-house from candles' (provenance), that on-chain data is conditional ('when the symbol is a tracked chain'), that the narrative is 'grounded ... with citations' (generative behavior), and that a per-section status list 'distinguishes an empty section from a failed feed' (failure semantics). The 'same ... as' cross-references are consistency guarantees. 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 core purpose is front-loaded and every clause carries distinct information — each enumerated data type maps to a sibling tool or a behavioral caveat. However, it is one extremely long run-on sentence with heavy em-dash packing; a bulleted or sectioned structure would improve scannability without losing information.

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

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

For a tool aggregating roughly fifteen data types with an output schema present, the description covers the full content breadth, conditional availability, computation provenance, consistency with sibling tools, and per-section failure signaling. Nothing an agent needs to predict the tool's behavior or interpret its output sections is omitted.

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

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

Schema coverage is 100% and the schema already documents symbol with examples ('ETH', 'BTC'). The description reinforces the single-symbol scope ('for one symbol') but adds essentially no new parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description opens with a precise verb+resource ('Aggregated single-coin dossier') and exhaustively enumerates the content sections. It actively distinguishes itself from siblings by cross-referencing 'the same enriched line as market_quotes' and 'the same numbers as ta_technicals', so an agent can tell this aggregation tool apart from the single-purpose tools without opening their schemas.

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 aggregation framing plus 'for one symbol (e.g. 'ETH')' makes the intended use clear: a comprehensive single-symbol overview. It names the overlapping siblings (market_quotes, ta_technicals) and signals that their data is duplicated here. However, it never states an explicit when-not condition, e.g. that an agent needing only the current price should call market_quotes directly instead of this heavier tool.

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

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

Beyond the readOnlyHint annotation, the description discloses determinism ('same inputs always give the same result'), the inference of direction from the stop's side of entry, the local nature of the computation, and how the optional target only affects reward:risk. These are behavioral traits that materially affect how an agent interprets results and call semantics, all provided in the description.

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 sentences, each earning its place: identity and scope, inputs and outputs, then deterministic behavior and direction inference. The most important differentiator ('not a data-provider lookup') is front-loaded. No redundant phrasing or filler.

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

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

For a 5-parameter calculation tool with an output schema, the description covers the return values, the optional parameter's purpose, the direction inference rule, and the deterministic nature. Nothing essential for correct invocation or interpretation is missing.

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

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

Schema description coverage is 100%, so the schema already documents each parameter's meaning and units. The description reinforces the inputs but adds little beyond stating that target is used 'only to report reward:risk' and direction is inferred from stop placement. Baseline 3 is appropriate since schema carries the parameter burden and the description adds marginal context.

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 'Fixed-fractional position sizing' and immediately frames it as 'a local calculation, not a data-provider lookup,' which clearly distinguishes it from the sibling data tools. It names specific outputs (units, notional, implied leverage, stop distance, reward:risk) and the direction inference rule, so an agent knows exactly what this tool does and how it differs from siblings.

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

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

The phrase 'a local calculation, not a data-provider lookup' gives an explicit when-not signal: don't use this to fetch external data. The input/output listing implies when to use it (when sizing a position from account size, risk, entry, stop), but no alternative tool is named or a conditional selection guide provided. Context is clear, exclusions are implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the index updates roughly every 15 minutes and returns a value plus label. It also clarifies the market-wide scope. This goes beyond the annotation without contradicting it.

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

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

Two short sentences pack the essential information: what the tool returns, how fresh it is, and which sibling to use for a broader view. There is no filler or redundant repetition of the tool name or title.

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, parameterless, read-only tool, the description fully covers what an agent needs: the metric, its range, update frequency, scope, and a pointer to an alternative. No output schema exists, but the return shape is adequately described as an index value plus label.

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

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

The tool has zero parameters, so the baseline for this dimension is 4. There is no parameter detail to add, and the description's mention of the 0-100 range plus label is sufficient for a parameterless call.

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

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

The description clearly identifies the resource as a market-wide Fear & Greed index with a 0-100 range and label, and positions it as a macro sentiment gauge. It distinguishes itself from market_overview by naming that sibling as the full-market alternative. A specific verb is missing, but the intent is unmistakable.

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

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

The description states that this is a macro sentiment gauge and explicitly directs the agent to market_overview when a full market snapshot is needed. It does not mention sentiment_social or sentiment_twitter, but the alternative guidance is clear enough for most selection decisions.

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 readOnlyHint annotation already signals safe read-only behavior, and the term 'snapshot' aligns with it. The description adds metric-level detail but no additional behavioral context such as rate limits, data freshness, or source scope.

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

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

Single sentence, front-loaded with the core purpose and then a compact metric list; no filler or repeated schema 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-parameter read-only snapshot, the description lists all returned metrics with relevant units and scales (0-100, %, lower-is-stronger), so an agent can call it and interpret the result without an output schema.

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

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

Schema covers the only parameter 100% with a clear example ('Coin symbol, e.g. BTC'), so the baseline applies. The description adds no further parameter semantics beyond implying the coin symbol is the required lookup key.

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

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

Clearly identifies a social-sentiment snapshot for a single coin and enumerates the specific metrics returned (galaxy score, alt rank, bullish sentiment, volume, dominance, interactions). It does not explicitly contrast with sentiment_twitter or sentiment_fear_greed, but the 'one coin' scope and metric list distinguish it from broader sentiment 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?

No when-to-use guidance is given. The description never states when to prefer this over sentiment_twitter, sentiment_fear_greed, or other sibling tools, and it offers no exclusion criteria; only the implicit 'for one coin' scope.

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 provide readOnlyHint=true, so the description doesn't need to restate safety. It adds useful behavioral detail beyond the schema: results are 'Sorted by relevance,' the latest=true switch changes that ordering, and the response includes engagement and author-reach fields. This helps an agent anticipate behavior before invoking.

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 tight sentences with no filler. The core action and output are in the first sentence, the use case in the second, and the sorting behavior in the third. Every sentence 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 search tool with a full input schema, an output schema, and readOnlyHint=true, the description covers the essential context: what it searches, what fields it returns, which use case it serves, and the key sorting option. Nothing an agent needs to decide whether to call it or how to interpret its result is missing.

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

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

Schema description coverage is 100%, with every parameter already documented in the input schema. The description reinforces the latest parameter and the relevance default, but doesn't add meaningful parameter-level meaning beyond what the schema provides. 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?

Description opens with a specific verb-resource pair: 'Searches Twitter/X and returns matching tweets with engagement...' It names the platform, the action, and the exact returned data (likes, retweets, replies, views, followers, verified). It also frames the use case as 'Raw crowd voice for judging social sentiment,' which distinguishes it from news or fear/greed indices among siblings.

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

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

The description clearly states the intended context: 'for judging social sentiment on a coin or topic,' which tells an agent when this tool is appropriate. It also explains the relevance-versus-latest sorting choice. It doesn't explicitly name sibling alternatives or exclusions, but the use-case framing plus the sibling names (news_search, sentiment_fear_greed) make the decision sufficiently 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 declare readOnlyHint=true, and the description aligns with that. It adds valuable behavioral context: the computation is local from real candles, not a vendor black box; the market routing fallback (spot preferred, perp fallback) is disclosed; and the AltFINS level append is conditional on feed availability. These details reveal dependencies and failure modes beyond the annotation's simple read-only flag.

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 intentionally dense but never redundant. It front-loads the main purpose and indicator list, then explains parameter behavior, then concludes with the conditional AltFINS feed. Each sentence earns its place, though the first sentence is long and could overwhelm an agent scanning quickly. Still, the structure is logical and efficient for the complexity.

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

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

Given that an output schema exists, the description doesn't need to detail return structures. It covers parameter semantics, defaults, external data dependency, and a downstream consumer. It is sufficiently complete for an agent to invoke the tool correctly and understand what data will be returned and how the computation differs from alternatives.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that 'intervals' picks timeframes with a default and max of 4, and that 'market' routes candle choice with specific options and a default behavior. It also provides a concrete symbol example ('ETH'). This goes beyond simply restating the schema, though it doesn't elaborate on every fixed indicator parameter.

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

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

The description opens with a specific, informative purpose: 'Multi-timeframe technical-analysis snapshot for one coin.' It enumerates the exact indicators and analytics (RSI, EMA, MACD, ATR, Bollinger, ADX, volume, trend rule), making it unmistakable what the tool returns. It also differentiates itself by noting it is 'computed locally from real candles (not a vendor black box),' which distinguishes it from any opaque analytics sibling.

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

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

The description provides clear context on what the tool does and how to configure it with defaults and allowed values for 'intervals' and 'market'. It references 'feed risk_position_size' as a downstream consumer of ATR stop suggestions, hinting at how outputs can be chained. However, it does not explicitly state when to prefer this tool over siblings like market_candles or market_quotes, 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?

The readOnlyHint annotation already covers safety, and the description adds the key behavioral detail: the output is the current UTC time in ISO 8601 format. For a stateless time-returning utility, nothing more is needed.

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

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

Two sentences with no filler. The primary behavior comes first, and the use-case motivation follows in one compact example.

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

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

For a zero-parameter, read-only tool with no output schema, this description is complete: it states what is returned, the format, and a concrete use case. Nothing an agent needs to invoke it correctly is missing.

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

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

There are zero parameters, so the schema carries no semantic burden. The description still adds value by specifying the output format (ISO 8601), which is the only relevant interface detail.

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

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

States a specific verb ('Returns') and resource ('current UTC time') with an explicit format (ISO 8601). Its purpose is immediately distinguishable from the sibling data tools, which all return market or news data rather than a time anchor.

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

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

Gives a clear context of when to use it: anchoring 'now' and judging staleness of timestamps. There are no competing sibling time tools, so not naming alternatives is acceptable; only explicit exclusions are absent.

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