MangroveAI

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains the 180-day regime read, the completed-run search with specific floors, random selection, saving from the run, and backtesting on fixed 90-day or 30-day windows. It also discloses that nothing is saved or spent when no run fits and describes payment/authentication access.

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 use-first directive is front-loaded and most details earn their place by clarifying a complex operation. However, the long algorithm sentence and dense payment bracket make it less crisp than ideal.

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

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

For a complex multi-step tool with no output schema, the description covers selection logic, fixed inputs, failure behavior, cost implications, access, and marketplace exclusion. It does not explicitly describe the successful return value or result shape, which keeps it from being fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful conditional meaning: provide the asset, provide candle_size only when the user named one, and do not pass other filters, a regime, or dates.

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: running the Strategy Engine route to build a strategy in one call. It also distinguishes the tool from siblings by specifying that it is used first when building a strategy with no named signals and that it does not search the marketplace.

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 explicit when-to-use guidance with examples: whenever someone asks to build or make a strategy and names no signals. It also states what to pass (asset, optional candle_size), what not to pass (filters, regime, dates), and what to do when nothing fits.

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

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

No annotations exist, so the description carries the full burden and does: it discloses the 'unscored' volatility fallback with bands returned alongside, refuses windows shorter than 15 sessions with a close, explains ticker resolution defaults (listed tickers read from exchange-session daily series, everything else as crypto), notes that venue reports which feed was read, and states the x402/API-key payment paths.

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?

Front-loaded with purpose and the sibling routing before the ticker list and payment note. The enumerated ticker universe and the doubled venue-feed explanations run long, but nearly every sentence carries operative constraints rather than 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 an 8-parameter, no-output-schema, no-annotation tool this is thorough: it describes return shape, degraded-return behavior, minimum history, ticker coverage and exclusions, auth/payment, and the interaction between the two input modes. An agent could call it correctly from this text alone.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning the schema lacks: quote_token and market_data_venue must be supplied together for an exact crypto market, candle_size is constrained to 1d on explicit ranges, and the asset/catalog-window mutual exclusivity plus ticker-universe fallback rules go beyond the field text.

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 ('Classify one stretch of market: a date range, or a catalog window by file name') and immediately names the deliverable — direction band, volatility band, trend character plus the three features. It also distinguishes itself from get_market_regime in the same breath, so an agent can route 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?

Gives explicit when-to-use ('a period the person names', 'to see what a window a sweep selected contains') and an explicit when-not with the alternative ('For an asset's current conditions use get_market_regime instead'). It also spells out the input-mode split — explicit date ranges require 1d candles, catalog windows keep their stored interval.

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

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

With no annotations at all, the description carries the full burden and does disclose the critical trait: the deletion is permanent and requires a confirmation step on name and ID. It does not say what happens to attached backtests/evaluations or whether errors are returned for unknown IDs.

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 short sentences, action first, then the gating rule, then the precondition. No filler and no repetition of the tool name.

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 destructive one-parameter tool with no annotations and no output schema, the description covers the safety essentials. It leaves out side effects on dependent artifacts and the failure mode for invalid IDs, which would matter for an irreversible operation.

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

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

Schema coverage is 0%, so the description must compensate. It mentions only that the strategy is identified 'by its ID' and that a name should be confirmed, but never states the ID's format, source, or that no other parameter exists — close to the minimum for a single-param tool.

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 ('Permanently delete a strategy') plus the keying parameter ('by its ID'). That is unambiguously distinct from the get_/list_/update_ siblings in the same namespace.

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 an explicit gating condition: 'Use this only when the user explicitly asks to delete a strategy', which functions as a when-not rule. It stops short of naming the non-destructive alternative (e.g. update_strategy_status) that an agent should reach for when the user only wants to deactivate.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful context beyond that: 'Free, public read' (no auth/quota cost) and 'without executing them' (side-effect-free discovery), which is the trait that most affects invocation decisions. No mention of result-size limits or pagination, keeping it at 4.

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, front-loaded with purpose and side-effect safety before the mode selection detail. No filler, though the mode enumeration in one sentence is dense enough that a reader must parse carefully.

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 carries the return-shape burden and does so adequately by describing what summary and schema modes yield. Selector union semantics and the areas-with-no-selectors constraint are covered. It leaves minor blanks (whether summary includes area groupings, or result caps) but nothing that would cause a wrong call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics not present in the schema: the three detail modes and what each returns, and critically that 'combined selectors form a union' — a non-obvious interaction rule for the areas/names arrays. It also clarifies that areas are names returned by detail=areas, tying the two parameters together.

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 ('Discover Mangrove managed tools') and immediately adds the key differentiator 'without executing them', which separates it from the many get_*/list_*/run_* siblings. An agent can tell this is a metadata-catalog tool, not a data-fetch tool, 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?

Gives concrete directive guidance per mode ('Use detail=areas for the functional area index') and defines default behavior (summary), which is exactly the routing information needed. It stops short of saying when to prefer this over siblings like list_strategies or get_execution_config_schema, so it is strong but not exhaustive.

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

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

With no annotations, the description does add real behavioral context: the tool is paywalled at 0.05 USDC via x402 PAYMENT-SIGNATURE header, and API-key clients pay nothing — information an agent cannot get from the schema and that affects whether/how it calls. It says nothing about latency, rate limits, or what an evaluation result contains.

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 tightly written sentences with the capability front-loaded and the access/payment note clearly bracketed as secondary. No filler, though the payment aside is slightly long relative to the core statement.

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 9-parameter tool with a dual live-mode/dataset_key operating model and no output schema, the description does not explain the two modes or the shape of results, relying on the schema to convey mode switching. Adequate but with a notable gap around what an evaluation returns.

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 parameter meaning is already fully carried by the schema. The description only adds the high-level notion of optional signals and a date range, which the schema restates; baseline 3 applies.

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

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

States a concrete verb (evaluate) and resource (chart data plus optional signal triggers) over a range, so the agent knows it produces evaluations rather than raw data. It does not explicitly differentiate itself from the closely named siblings evaluate_signal and evaluate_strategy, which leaves ambiguity about the multi-signal scope.

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

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

The description says what the tool does but never states when to choose it over evaluate_signal (single signal) or evaluate_strategy (strategy-level). The bracketed text covers payment/auth mechanics, not usage selection, so the agent is left to infer the batch-vs-single case from the schema's 'up to 20 signals'.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the access model: 0.02 USDC via x402 PAYMENT-SIGNATURE header or an API key with no per-call charge. That is genuinely valuable and beyond structured fields. It says nothing about what the evaluation computes, error conditions, or whether the operation is read-only.

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 a single sentence, and the access note is set off in brackets. Both parts earn their place, though the payment explanation is verbose relative to the single-sentence purpose.

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

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

For a 3-parameter tool with a nested, essentially empty MarketDataBar definition, no output schema, and no annotations, the description is too thin. An agent still cannot tell what a bar in market_data must contain or what an 'evaluation' returns.

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 33%: signal_name is trivially labeled, while market_data is an array of an empty MarketDataBar definition and parameters is an undescribed object. The description adds no meaning to any of the three parameters, so the opaque market_data shape is left entirely unexplained.

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+resource ('Evaluate a signal') with the inputs it consumes, so the agent knows it is an evaluation call rather than a data fetch. It does not distinguish itself from close siblings such as evaluate_multiple_signals_series, evaluate_strategy, or validate_signal_params, so 4 rather than 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 offers no when-to-use or when-not-to-use guidance and never names an alternative. The bracketed text is about how to pay, not about which evaluation tool to pick.

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

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

With no annotations provided, the description carries the full burden and does well: it declares the operation read-only, states no orders are placed, and describes the return payload (current asset price plus order intents). Gaps remain around auth/permission needs, behavior when strategy_id is invalid, and rate limits.

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

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

Three sentences, front-loaded with the core action and the critical read-only disclaimer, then the return shape, then the usage trigger. 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?

No output schema exists, so the description appropriately summarizes the return values (asset price and order intents), which is the key missing piece otherwise. The only remaining gap is sourcing/format of strategy_id, which is a minor omission for a single-parameter 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?

Only one parameter, strategy_id, and schema description coverage is 0% — the schema supplies no explanation of what the value should be. The description refers to "a specific strategy" but never says strategy_id is the identifier obtained from list_strategies/list_playground_datasets or what format it takes.

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 ("Evaluate a strategy") plus scope ("against current live market data"), and explicitly disclaims order placement. It distinguishes itself semantically from signal-level siblings like evaluate_signal and backtest siblings like run_backtest, but never names an alternative, so it falls 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?

Gives an explicit trigger: "Use this when the user asks whether a strategy should be entering or exiting right now, or wants to know the live signal state for a specific strategy." That is clear context for invocation. It does not state when NOT to use it or name a sibling (e.g., evaluate_signal for a single signal, run_backtest for historical analysis) as the preferred alternative.

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

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

No annotations are present, so the description carries the full burden, and it does disclose non-obvious traits: the tool is readable while a sweep is still running, results are ranked by a caller-chosen metric with no inherent winner, and calls cost 0.005 USDC via x402 unless an API key is used. Gaps remain on pagination behavior and what a returned run row actually contains, beyond the passing mention of regime_fit.

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?

Front-loaded with scope, then sorting discipline, then filtering discipline, then access/cost. Most sentences earn their place, but the band-filter point is made in the prose and again restated in the schema for max_delta_vs_benchmark, and the anti-'best strategy' lecture runs slightly long.

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 39-parameter tool with no output schema and no annotations, the description supplies the decision framework (sort choice is the question, filter before sort, bounds are bands) and the operational facts (running-sweep readability, payment model). It stops short of describing row shape or pagination semantics for offset/limit, which an agent paging results would want.

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, but the description adds real meaning: sort_by is framed as the question being asked, order as best-first vs worst-first, min/max pairs as a single band query, and matches the schema's note that execution filters require experiment_id. It reinforces rather than replaces the per-parameter docs, so it does not reach 5.

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?

Opens with a concrete scope statement: runs from one sweep, or from every sweep the caller owns, filtered and sorted by the engine. The scoped-vs-cross-sweep distinction is made explicit ('LEAVE experiment_id OUT to search them all'). It does not name a sibling tool it is an alternative to, so it falls short of the 5 bar for sibling differentiation, but the resource and action are unambiguous.

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

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

Gives explicit operating instructions: omit experiment_id to search across sweeps, always set min_trades before sorting, filter before sorting, set bounds as a band rather than paging and thinning, and state which metric you sorted by when reporting. The 'A SWEEP HAS NO WINNER' warning and the ban on calling the top row 'the best strategy' preempt the most likely misuse.

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 are empty, so the description carries the full burden, and it does real work here: it discloses the dual access model (0.001 USDC via x402 PAYMENT-SIGNATURE header, or API key with no per-call cost) and states that x402-capable clients auto-pay. That is exactly the kind of cost/auth context an agent needs before invoking. It doesn't state read-only semantics explicitly or mention rate limits/error behavior, which keeps it from a 5.

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

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

The functional statement is front-loaded in one dense sentence, followed by usage guidance and a bracketed access note. Every element earns its place, though the bracketed payment block is somewhat verbose for what it conveys.

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?

There is no output schema, so the description must convey return content, and it does by enumerating the returned fields. Combined with the auth/payment disclosure, an agent has enough to call it correctly. A note on not-found behavior for an unknown symbol would close the remaining gap.

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

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

Schema coverage is 100% and the single `symbol` parameter is documented with an example (BTC/ETH), so the schema does the heavy lifting. The description reinforces 'one crypto asset' (single-symbol semantics, no batch), but adds no format or normalization guidance beyond the schema. Baseline 3 applies.

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

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

The description names a specific resource (one crypto asset on the Mangrove platform) and enumerates exactly what the payload contains: approval status, risk score breakdown, regulatory status, and identifiers. It also separates itself from price-oriented siblings (get_market_data, get_ohlcv) by framing the scope as approval/risk metadata 'rather than a live price.'

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

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

It gives an explicit trigger ('when the user asks about a specific asset's approval or risk detail') and an explicit exclusion ('rather than a live price'), which steers the agent away from the market-data tools. It stops short of naming the direct alternative (e.g., list_approved_assets for bulk listing vs. this single-asset lookup), so routing between the two is left partly to inference.

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

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

With no annotations, the description carries the full burden and usefully discloses the access model: pay 0.001 USDC via x402 or authenticate with an API key, including auto-pay and free API-key calls. It also says the response includes the execution config used, but it does not describe failure behavior for an unknown ID or broader return details.

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

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

The purpose and usage guidance are front-loaded in the first two sentences, with payment/access details cleanly separated in a bracket. The text is appropriately sized and every part contributes useful selection or invocation context.

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 retrieval tool with complete schema coverage and no output schema, the description covers purpose, sibling routing, payment/access, and that execution config is returned. It omits edge-case behavior such as what happens when the backtest ID is not found, but otherwise gives an agent enough to call it correctly.

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

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

Schema description coverage is 100%, and the sole parameter is already documented as the run's UUID as returned by run_backtest. The description reinforces that the lookup is by id but adds no syntax or format detail beyond the schema, so the baseline 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 states a specific verb and resource: 'Fetch a backtest that already ran, by id, with the execution config it used.' It explicitly distinguishes itself from run_backtest, making the purpose unambiguous against a key 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?

It gives explicit when-to-use guidance: whenever the user refers to a previous result or wants to compare two runs, and explicitly says to use it instead of run_backtest in those cases. It also explains why re-running is undesirable by citing allowance cost and the stored record of what actually happened.

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

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

With no annotations, the description carries the burden and does well: it discloses that results are SIMULATED, that long runs are paged via offset, and spells out the auth/payment model (x402 per-call charge vs. API key). It stops short of stating ordering, max page size, or what an empty/expired backtest_id returns.

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

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

Front-loaded with what the tool returns, then disambiguation, then the simulated-vs-real warning, then paging, then access. Every sentence carries distinct information; the payment block is bracketed so it doesn't obscure the core purpose.

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

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

For a paged read tool with no output schema and no annotations, the description covers return content, data provenance, pagination, and cost. Minor gaps remain around ordering and page-size behavior, but nothing that would cause a mis-call.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real signal: it tells the agent that offset exists because long runs are paged and should be passed to 'read on', which the schema's generic pagination text does not convey.

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+resource ('the individual trades a backtest made') and enumerates the payload (entry/exit prices and times, P&L, close reason). It explicitly distinguishes itself from get_backtest (summary metrics) and list_trades (real trades), so an agent can route without opening a 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?

Gives the exact trigger ('when the user asks what a backtest actually traded'), names the alternative for summary metrics, names the alternative for real trades, and adds the paging condition. Both when-to-use and when-to-use-something-else are covered.

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

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

With no annotations, the description carries the full burden and does disclose the access model: 0.005 USDC per call via x402 PAYMENT-SIGNATURE or free with an API key, with auto-pay noted. It does not cover failure modes (invalid asset, reversed dates) or caching, so it is strong but not exhaustive.

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?

Front-loads the definition, then the usage rationale, then the access terms in a bracketed block. The middle sentence ('a return with nothing to compare it against does not answer whether the strategy was worth running') is slightly rhetorical but does real work as justification.

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

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

No output schema, but the description states what comes back (a percentage) and covers cost and auth, which is most of what an agent needs. The one gap is the asset-vs-token-triple alternative addressing scheme, left to the schema to hint at.

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 nothing about the parameters beyond the general concept of an asset and a date window, and does not clarify how the optional base_token/quote_token/market_data_venue triple relates to the required asset field.

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

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

States a specific verb and resource ('Buy-and-hold return for an asset between two dates, as a percentage') with the unit of the return spelled out. It also explicitly separates itself from run_backtest, which already embeds the same metric for its own window.

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 concrete trigger ('use it whenever you state what a strategy returned') and names the alternative plus the exact condition that selects it ('call this for a different asset or a different period'). No inference required.

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 are empty, so the description carries the burden. It discloses a critical behavioral constraint that payment is required via x402 or API key authentication, and it explains what the tool returns. It does not state read-only behavior explicitly or discuss rate limits, but the access and return behavior are meaningfully covered.

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 purpose and return value are front-loaded in two sentences, followed by a compact access note. Every sentence carries useful information, and the payment/authentication detail is worth the space.

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 read tool with no output schema, the description covers what it returns, when to use it, and how access is paid for. Nothing essential to correct invocation appears to be 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 is one required parameter, chain, and schema description coverage is 100%. The description repeats example chain names but adds no format or syntax guidance beyond the schema, 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 states a specific resource and scope: total value locked for a whole blockchain, with examples such as Ethereum, Base, and Solana, and says it returns USD TVL plus top protocols. This distinguishes it in spirit from the protocol-level sibling, but it does not explicitly name get_protocol_tvl as the contrasting 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?

It gives a clear usage condition: use when the user asks about a chain's overall DeFi footprint. It does not explain when not to use it or explicitly point to get_protocol_tvl for protocol-level TVL, so it stops short of full alternative routing.

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

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

With no annotations at all, the description carries the full burden. It does disclose a genuinely important behavioral trait that no structured field covers: access requires either a 0.01 USDC x402 payment via PAYMENT-SIGNATURE header or an API key, and x402-capable clients auto-pay. It says nothing about the lookback window, update cadence, or whether flows are daily/aggregate, which matters for interpreting the result.

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 blocks: the metric definition and its interpretation first, then the access/payment note in brackets. Front-loaded and waste-free. The bracketed payment paragraph is longer than the substantive content, but it is operationally necessary given no annotations cover it.

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

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

No output schema and no annotations, so the description must carry everything. It conveys what the metric is and how to read it, but omits the shape of the response (per-asset breakdown? time series? latest snapshot?) and the time horizon covered. For a no-parameter data tool those are the remaining unknowns an agent would want.

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 (empty object schema), so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies a fixed-scope, no-argument fetch rather than leaving the agent hunting for filters.

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 resource and metric ('Crypto ETF net flows -- institutional inflows and outflows for spot BTC and ETH ETFs'), which is unambiguous against siblings like get_smart_money_flows, get_token_flows and get_stablecoin_metrics. It also adds an interpretive frame (net inflows = bullish, outflows = bearish) that tells the agent what the number means.

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?

Explicit trigger conditions are given: 'Use it when the user asks about ETF flows, institutional demand or spot ETF activity.' That is clear routing guidance. It does not name an alternative (e.g. get_smart_money_flows) for the overlapping 'institutional demand' phrasing, so exclusion guidance is absent.

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

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

With no annotations, the description usefully discloses access requirements and pricing: x402 auto-pay or API-key authentication. It does not explicitly state read-only behavior or error/rate-limit characteristics, but the get-style read operation is clear from the content.

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

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

The description is front-loaded with what the tool returns, followed by when to call it, then access details. The information is dense but every sentence earns its place, and the access note is clearly separated.

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 tool without an output schema or annotations, the description adequately explains what each returned execution-config entry carries, including defaults, bounds, effects, and classifications. It also covers access requirements and intended timing, leaving no critical gap for an agent to call it correctly.

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

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

The tool has zero input parameters, so parameter semantics are not a meaningful source of ambiguity. Baseline 4 is appropriate because there are no parameters for the description to clarify.

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 precise resource and scope: 'Every execution-config parameter a strategy can carry.' It also enumerates the metadata returned for each parameter, making the tool's purpose unmistakable 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?

It gives a clear usage rule: 'Call it before discussing or overriding any risk parameter.' It explains the motivation, avoiding memory-based descriptions, but does not name alternatives or when not to call 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?

No annotations exist, so the description carries the full behavioral burden, and it does disclose the important operational facts: payment of 0.005 USDC via x402 PAYMENT-SIGNATURE header or API-key auth, with auto-pay for x402-capable clients and free calls for API-key clients. It does not mention caching, rate limits, or freshness of the snapshot, which keeps it from a 5.

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

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

The core purpose sentence is front-loaded and dense with useful specifics, followed by a bracketed access note that is short and operationally necessary. Two blocks, no filler, though the access note could be marginally tighter.

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?

There is no output schema and no annotations, yet the description lists the returned metrics and covers authentication and cost, which is what an agent needs to call it correctly. Minor gaps remain around units/formatting of the returned figures and snapshot freshness.

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 zero parameters and a declared 100% schema coverage baseline, there is nothing to document; the description correctly implies a parameterless call. No misleading or missing parameter information.

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

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

The description names a specific resource and verb — 'Global crypto market snapshot' — and enumerates exactly what it returns: total market cap, BTC dominance, total 24h volume, and the 24h change. It also explicitly contrasts the scope against a 'per-asset reading,' letting an agent separate it from get_asset and get_market_data without inspecting 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?

It gives a clear use condition: 'when the user asks about overall market conditions or wants a macro view rather than a per-asset reading.' The contrast is conceptual rather than naming a specific sibling tool to use instead, so routing among the many market-data siblings still requires inference, but the guidance is solid.

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

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

No annotations exist, so the description carries the full burden, and it does add real behavioral context: the output shape, the per-account scope, and the full access/payment model (0.02 USDC via x402 with PAYMENT-SIGNATURE, or API key with no per-call charge). Missing are error behavior (what happens for an unknown handle) and rate limits, which is why it is not a 5.

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

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

The core purpose and trigger are front-loaded in the first sentence, the scope boundary follows immediately, and the billing detail is isolated in a bracketed second block. No sentence is redundant.

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?

There is no output schema, and the description compensates by naming what is returned (a 0-100 score and follower count) and what the scope is (single account, not topical). Combined with the payment/auth disclosure, an agent has everything needed to call it correctly.

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

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

The single parameter is fully documented in the schema at 100% coverage ('X/Twitter handle, with or without the leading @'). The description adds nothing about the parameter itself, so the baseline 3 applies.

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

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

States a specific verb and resource: an influence score for a single X/Twitter account, and names the return values (0-100 score, follower count). It also draws a boundary ('per-account snapshot, not a topic aggregate') that separates it from the social/topic tools in the sibling list, though it does not name a specific 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?

Gives an explicit trigger ('when the user asks about a specific influencer or KOL, or wants to know how much weight an account carries') plus an exclusion against topic-level aggregation. It stops short of naming the alternative tool an agent should use for topic aggregates, so the routing is implied rather than spelled out.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses access requirements: pay 0.01 USDC via x402 or authenticate with an API key, with auto-pay for capable clients. It does not disclose data freshness, rate limits, or return granularity, which keeps it from a 5.

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

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

The description is front-loaded with purpose and use cases, and the access/payment details are compact. The two usage-focused sentences overlap slightly, but every part is relevant.

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 tool with no output schema and no annotations, the description covers the core return concept, when to use it, and authentication/payment behavior. Missing freshness and protocol-coverage detail keeps it from a 5.

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

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

There are zero input parameters, so the baseline score of 4 applies. The description does not need to explain parameter semantics and appropriately avoids inventing any.

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 data resource: per-pool borrow rates across named DeFi lending protocols such as Aave, Compound, and Morpho. An agent can identify it as a lending/borrow-rate lookup, though it does not explicitly distinguish itself from sibling rate or yield tools.

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

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

It gives clear usage triggers: rate-spread arbitrage screens, stablecoin yield analysis, and user questions about lending rates, borrow costs, or DeFi yield. It does not name exclusions or specific alternative sibling tools, so it falls short of the top score.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses an external API dependency, rate limiting, a spot (non-streaming) read, and both auth paths including per-call x402 pricing. It also mandates surfacing price_as_of and price_stale, which is exactly the kind of output caveat an agent needs. Missing: failure behavior for unsupported symbols/markets and what 'aggregate' market cap actually spans.

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?

Front-loads what the tool returns, then the parameter rule, then the reporting obligation, then usage context. Sentences are dense and mostly earn their place; the access/payment block is verbose but carries non-obvious cost information. Slightly over-packed for a single read 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?

No output schema, but the description enumerates the returned fields (price, market cap, 24h volume, quote, venue, price_as_of, price_stale) and covers cost/auth and rate limits. What remains thin is error/edge behavior and the meaning of the aggregate market cap across the selected venue.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics the schema does not: quote_token and market_data_venue must be passed together to honor a requested exchange, and omission triggers server-side market selection with the chosen quote/venue returned. That pairing constraint and default-resolution rule are only in the prose.

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 — 'Latest trade price for a selected market, plus aggregate market cap and 24h volume' — and frames it as 'a spot reading from an external API.' It doesn't name any sibling (get_ohlcv, get_asset, get_symbol_exchanges) to draw a boundary, so an agent must infer the split from 'latest/spot' on its own.

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 concrete trigger: 'when the user asks what an asset is doing now, or when a live price is needed to ground a recommendation,' plus a reuse rule ('call it once per asset and reuse the answer'). There is no explicit when-not or named alternative for historical/time-series needs, which is the main gap.

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

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

With no annotations, the description carries the full burden and does well: it discloses the x402/0.001 USDC per-call cost with API-key alternative, and a real data-scope constraint ('names only; the creator's tuning is never exposed'). It does not cover failure behavior when the id is unknown or whether non-marketplace strategies are rejected.

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?

Front-loaded with the payload description and usage instruction, then the access/payment note in its own bracketed paragraph. Every sentence is doing work, though the payment paragraph is proportionally long for a one-parameter lookup.

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-param tool with no output schema, the description compensates by enumerating the returned fields and stating the access model. Remaining gaps are edge behavior (not-found, unauthorized, non-listing ids), which keeps it from a 5.

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

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

Schema coverage is 100% with a single required strategy_id already described as 'The strategy's UUID.' The description adds nothing further about the parameter (e.g. must it be a marketplace listing rather than an owned strategy), so the baseline 3 applies.

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

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

Specific verb+resource: returns one marketplace listing in full and enumerates what comes back (metrics, signal names, backtest summary, in-account flag). The 'marketplace listing' framing implicitly separates it from get_strategy (own strategies) and search_marketplace (discovery), so an agent can pick 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?

'Use it before describing or offering a specific listing, so what you say is what the marketplace holds' gives an explicit trigger condition tied to a downstream action. It stops short of naming the alternative (e.g. search_marketplace for discovery vs this for detail), so it is clear context without full when-not routing.

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

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

With no annotations present, the description carries the full burden and does so: it discloses default resolution behavior (listed tickers read from exchange-session daily series), the fallback rule (any unlisted ticker treated as crypto), refusal conditions (min 15 sessions with a close), the calendar-days-vs-sessions interpretation of the lookback, that `venue` reports which feed was read, and the full auth/payment model (0.02 USDC via x402 or API key). That is unusually complete for a mutation-free read tool.

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

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

Purpose and the strategy-style rationale are front-loaded, and every sentence carries information. However, the description is one dense semicolon-chained paragraph, and the 28-ticker enumeration is bulky for content that arguably belongs behind list_approved_assets. Slightly heavy but not wasteful.

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?

There is no output schema, so the description must describe the return shape — and it does, in detail (three-horizon bands, annualised volatility as a percentage, bucket, z-score against the asset's own baseline, and per-length sweep labels). Combined with the auth/payment note, the supported universe, and the minimum-history refusal rule, an agent has everything needed to call this correctly and interpret the result.

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 already 100%, but the description adds semantics the schema cannot express: `asset` resolution rules (catalog membership vs. implicit crypto fallback, plus the DIA/META disambiguation note), the pairing requirement 'supply quote_token and market_data_venue together' for an exact crypto market, how `provider`/market args switch to the crypto history path, and that `lookback_days` means calendar days (~250 sessions at 365) for listed tickers. These are real constraints an agent could not infer from the schema alone.

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

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

Opens with a specific verb+resource: 'Classify an asset's regime using a lookback of 1-365 days of daily closes', then enumerates exactly what the classification contains (return, bull/neutral/bear band at 90/180/365d, annualised vol, bucket, z-score, sweep-catalog labels). This is the regime classifier, distinct from neighbours like get_market_data/get_ohlcv (raw series) and build_strategy_for_regime (downstream action). No ambiguity about what comes back.

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 when-to-use ('Use it before recommending a strategy style, because a mean-reversion design and a trend-following design suit opposite regimes') and explicit when-not conditions (a ticker not in the listed catalog 'cannot be read'; fewer than 15 sessions is 'refused as too little history'). What's missing is naming the sibling alternative it hands off to — build_strategy_for_regime is never mentioned, so the sequencing must be inferred from the generic phrase 'before recommending a strategy style'.

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

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

With no annotations, the description carries the burden and delivers the key operational fact: the call is paid (0.01 USDC via x402 PAYMENT-SIGNATURE) or API-key authenticated with zero per-call charge, and auto-pay behavior for capable clients. It omits return format, granularity of candles, and what happens when lookback exceeds available history, keeping it below a 5.

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

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

Front-loaded with what the tool returns and when to reach for it, then a compact override-selection sentence, then payment terms in a bracketed aside. No redundant restatement of the name or schema fields.

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

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

No output schema exists, and the description implies OHLCV rows without specifying candle granularity, timezone, or truncation behavior for long lookbacks. For a single-required-parameter read tool with full schema coverage and disclosed payment terms, it is otherwise complete enough to call correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: quote_token and market_data_venue must be supplied together to pin an exact market, provider routes to an external source, and omitting all of them falls back to a Mangrove market. That coupling constraint is not present in 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?

States a specific verb and resource (daily OHLCV history for one crypto asset) plus scope (1-3650 day lookback). It explicitly distinguishes itself from the current-price path ("reason about past price movement rather than the current spot"), which separates it from sibling get_market_data.

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 trigger conditions: price history, chart data, past price movement. It also explains the market-selection decision (quote_token + market_data_venue together, or provider, or omit for the Mangrove default). It never names the alternative tool explicitly, so the routing is implied rather than 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?

With no annotations, the description carries the full disclosure burden and does well: it explains the x402 per-call payment vs. API-key authentication model, the WETH normalization of native ETH, and the chain-deployment constraint. It still omits pagination/row caps, the default date window, and error behavior, which prevents a 5.

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

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

The main paragraph is front-loaded with purpose, then metric names, then parameter constraints, then the usage rule — a logical order. The bracketed access/payment note is longer than necessary but contains information the agent would otherwise lack, so it earns most of its space.

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 an 8-parameter tool with no annotations and no output schema, the description covers purpose, metric vocabulary, interval/top_n semantics, provider, auth, and return shape ('bar-indexed series'). The main residual gaps are the default/absent date window behavior and any row limits, which matter for a series endpoint.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond it: it constrains interval to 1h/4h/1d/1w (the schema advertises 15m too, which is a useful narrowing), defines top_n as the holder count HolderConcentration sums (the schema's 'Return only the first this many' is vague), and states nansen is the only provider.

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?

Opening sentence names a specific verb and resource ('Per-bar on-chain metric time series for a token') and enumerates the metric families available, so the agent knows exactly what the tool returns. It also distinguishes itself from generic point-query siblings by framing the output as a bar-indexed series.

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 last sentence gives a clear selection rule: prefer this over firing many point queries when the user wants a historical or trailing-window view. It also states prerequisites (token must be deployed on the requested chain, native ETH read as WETH). It does not name a specific sibling like get_smart_money_netflows as the alternative, 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?

No annotations exist, so the description carries the burden; it does well by disclosing the access/payment model (x402 auto-pay vs API key, 0.01 USDC per call) and the sign semantics of the returned values. It does not describe aggregation granularity, refresh cadence, or which venues are covered.

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 semantic content is front-loaded and tight: purpose, interpretation, and use case in two sentences. The bracketed access block is necessary but is placed last, which keeps the core definition scannable.

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

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

With no output schema and no input parameters, the description is the only source of information about what comes back, and it never says whether rates are per-venue, per-symbol, current or historical, or over what window. An agent knows why to call it but not what shape of answer to expect.

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 the schema has nothing to explain and there is no parameter meaning for the description to add. Baseline for a parameterless tool 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?

States a specific verb and resource ('Aggregated DeFi perpetual funding rates across venues') and distinguishes itself from the lending-rate sibling by naming the perpetual/leverage domain. The sign convention sentence further pins down what the tool returns.

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

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

Explicitly names the triggering situations: 'when the user asks about perp funding, crowded positioning or leverage bias.' No explicit exclusion or named alternative (e.g., get_lending_rates for lending markets) is given, 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?

With empty annotations, the description carries the full disclosure burden and mostly fails it: nothing about timeframe/granularity, date-range limits, pagination, whether the data is freeform user-created playground content, or how errors surface for an unknown key. Only the read-nature is implied by 'Return'.

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

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

One short sentence with the resource and scope front-loaded and no filler. It is efficient, though the brevity is under-specification rather than true density.

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 data-retrieval tool with no annotations, no output schema, and an undocumented required parameter, the definition should say what shape of OHLCV comes back and where to obtain the key. Neither is present, leaving an agent unable to call this confidently without trial and error.

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

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

Schema description coverage is 0% and the single parameter dataset_key has no type detail beyond 'string'. The description only restates that it identifies a 'specific playground dataset' and gives no format, source, or example, so it adds almost nothing over the schema.

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

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

The description gives a specific verb ('Return') and resource ('OHLCV chart data') scoped to a 'playground dataset'. That is clear enough to act on, but it never distinguishes itself from close siblings like get_ohlcv or get_market_data, which also return OHLCV-style data.

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

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

There is no statement of when to use this versus get_ohlcv/get_market_data, and no hint that dataset_key values come from the sibling tool list_playground_datasets. An agent must infer the whole selection and discovery flow.

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

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

With no annotations, the description carries the full burden and does real work: it discloses the dual access model (0.01 USDC via x402 PAYMENT-SIGNATURE header, or API key with no per-call cost) and the return shape (USD TVL plus per-chain breakdown). It does not mention rate limits or error behavior for unknown protocol names, keeping it short of a 5.

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

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

Three tight sentences: purpose and return first, usage trigger second, access/payment logistics last as a bracketed aside. Nothing is redundant and the most decision-relevant information is front-loaded.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, return contents, routing context, and payment/auth mechanics. The only real gap is what happens with an unrecognized protocol name or how the per-chain breakdown is keyed.

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

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

Schema coverage is 100% and the single parameter already documents itself as a 'Protocol slug or display name, e.g. aave or uniswap.' The description repeats the examples without adding format constraints, so the baseline 3 applies.

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

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

States a specific resource and scope ('Total Value Locked for a single DeFi protocol') with concrete examples (Aave, Uniswap, Curve) and notes the per-chain breakdown. It implicitly separates itself from get_chain_tvl by scoping to a single protocol, but never names that sibling explicitly.

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

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

Gives an explicit trigger: 'Use it when the user asks how much capital is locked in a specific protocol.' That is clear positive guidance, but it offers no exclusions (e.g. 'for chain-level TVL use get_chain_tvl'), leaving the agent to infer routing against get_chain_tvl.

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

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

No annotations exist, so the description carries the burden. It does disclose a real behavioral trait that structured fields do not: the x402 pay-per-call pricing and the API-key alternative, plus auto-pay behavior for x402-capable clients. It omits anything about the cost/behavior of an unknown signal name, caching, or response shape, leaving meaningful gaps for a no-annotation tool.

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

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

The purpose is front-loaded in a single tight sentence, and the bracketed access clause is clearly separated. The payment paragraph is somewhat verbose for what it conveys but is not wasted, given no annotations exist.

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?

There is no output schema, so the description should say something about what "complete metadata" includes (fields, dimensions, labeling) and what happens for an unregistered name. That is left entirely unspecified, which for a lookup tool with no annotations is a real gap.

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

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

Schema coverage is 100%, but the schema's own text is only "Signal name", so the baseline is 3. The word "exact" is the one piece of added meaning: it tells the agent matching is exact rather than fuzzy or prefix-based.

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 ("Get complete metadata for a ... signal") and the qualifier "exact registered signal name" distinguishes it from fuzzy-search siblings like search_signals and match_signals. It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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?

"Exact registered signal name" implies this is a lookup-when-you-already-know-the-name tool, which is useful implied guidance against search_signals/list_signals. However, no alternative is named and no condition for when-not-to-use it is given.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses the paginated return shape, the fields returned, and the two auth/payment paths (x402 per-call payment vs. API key with no per-call cost). It stops short of stating rate limits, sort defaults, or whether the passthrough filters are validated.

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 paragraphs with purpose, return shape, and usage condition front-loaded. The bracketed access note is longer than ideal but the payment detail genuinely matters for an agent deciding whether it can call the tool, so it mostly 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?

There is no output schema, but the description enumerates the returned fields (token, side, size, wallet metadata) and pagination behavior, which covers the main gap. The remaining weakness is that the nested `filters` and `order_by` passthrough objects are left unexplained, which is a real ambiguity for a nested-object 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 coverage is 100%, so all five parameters are documented structurally, which sets the baseline at 3. The description adds nothing about `chains`, `order_by`, or the opaque `filters`/`order_by` passthrough objects beyond what the schema already says.

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 — 'recent DEX trades from smart-money wallets across chains' — plus what the response contains. It implicitly separates itself from get_smart_money_flows/netflows and get_smart_money_perp_trades by emphasizing a raw DEX swap feed, though it never names those siblings explicitly.

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

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

'Use it when the user asks what smart money is trading on DEXs, or wants a raw feed of smart-money swap activity' gives a clear triggering condition. There are no explicit exclusions or named alternatives (e.g., vs get_token_dex_trades or get_smart_money_perp_trades), so it falls short of a 5.

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

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

With no annotations, the description carries the load and does it well: it discloses pricing/auth paths (0.02 USDC via x402 with PAYMENT-SIGNATURE header, or API key at no per-call cost), the native ETH-as-WETH read behavior, and the constraint that the token must exist on the requested chain. It stops short of stating failure modes or rate limits, so it is not exhaustive.

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?

Front-loaded with the outcome and the anti-pattern warning before the mechanics; the access/pricing note is separated cleanly. It is dense but nearly every sentence carries an actionable constraint, with only slight redundancy between the one-response claim and the 'don't fetch per category' instruction.

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 3-parameter, no-output-schema read tool, the description covers return content (net flows and wallet counts per category), the aggregation axis, chain/token handling, and payment semantics. Only error behavior and any pagination/limits on the response are unaddressed.

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, but the description adds real value by enumerating allowed timeframe values (5m, 1h, 6h, 12h, 1d, 7d) that the schema only gestures at with 'e.g. 24h, 7d'. Note the mild mismatch: the schema example '24h' is not in the description's list, which could confuse an agent.

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

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

States a specific verb and resource: returns net USD flows and wallet counts across five named wallet categories in a single response. It also distinguishes itself from the similarly named sibling get_token_flows by scope (category summary snapshot vs. individual flow records).

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?

Explicitly says when to use (trailing-window category summary, including past 24h via timeframe=1d), explicitly says what not to do (don't fetch a separate token-flows page per category), and names the alternative for the other case (get_token_flows for explicit start/end dates or paginated records).

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

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

With no annotations, the description carries the full burden; it does add a real behavioral fact — the x402 per-call cost of 0.02 USDC and the auto-pay vs API-key behavior — which is genuinely useful. It says nothing about how pagination behaves, what window is returned when date_from/date_to are omitted despite both being optional, or how the pass-through filters/order_by objects are shaped upstream.

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?

Front-loaded with the core 'what' in the first sentence, then usage, then access constraints in a bracketed aside that is easy to skip. Two short paragraphs with essentially no filler; the payment note is verbose for what it says but its placement is correct.

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?

Seven optional parameters, nested filter/order_by objects, no output schema and no annotations — yet the description never explains the default behavior when no date range is supplied, which is the single most likely agent question given zero required params. Return values are covered at a high level, which offsets some of the gap.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema and baseline 3 applies. The description adds only the notion of a date window and per-category grouping; it gives no guidance on the opaque 'filters' and 'order_by' pass-through objects that are the hardest params to fill in.

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: 'Historical snapshots of what smart-money wallets held on specific dates', plus the return shape ('per-wallet-category holdings with USD values'). It implicitly contrasts with the current-holdings sibling get_smart_money_holdings by emphasizing 'historical' and 'on specific dates', but never names that sibling explicitly, so a 5 isn't earned.

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 two explicit use conditions: seeing how smart-money positioning changed over time, and pulling historical on-chain portfolio data for a date range. No exclusions or named alternatives are offered (e.g. when to use get_smart_money_holdings for current state instead), which keeps it below a 5.

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

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

With annotations empty, the description carries the full burden, and it does add valuable non-obvious context about access: x402 payment of 0.02 USDC or API key auth. However, it does not disclose the return shape, whether holdings are a live snapshot vs cached, or pagination behavior, leaving behavioral gaps.

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

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

Front-loads the resource and scope, follows with a concrete use case, and brackets the access/payment note so it doesn't obscure the main purpose. Efficient 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?

For a four-optional-param read tool with no output schema and no annotations, the description covers purpose, selection condition, and payment/auth requirements. It could say more about what a holding record contains, but it is adequately complete 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 all four parameters are already documented. The description only adds that results are 'sorted by USD value' and hints at the Fund/Smart Trader label scope, which the include_labels schema also covers. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific resource and scope: 'Current smart-money holdings: what funds and smart traders are holding right now, sorted by USD value.' This clearly distinguishes it from trade/flow siblings like get_smart_money_flows, though it only implicitly differentiates from the very close get_smart_money_historical_holdings via the word 'current' rather than naming it.

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?

Explicit when-to-use guidance: 'Use it when the user asks what smart money currently owns or has positions in.' There are no exclusions or named alternatives (e.g., historical holdings for past positions), 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?

With no annotations, the description carries full burden and does the highest-value piece of that work: it discloses the access model (0.02 USDC via x402 PAYMENT-SIGNATURE, or API key with no per-call charge, auto-paid by capable clients). It does not state read-only/non-destructive nature or describe the response shape, but the 'aggregated' wording makes the read semantics clear.

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?

Front-loaded with what the tool returns, then when to use it, then access mechanics in a bracketed aside. No redundant sentences; only the payment note lengthens it, and that 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 four-optional-param, no-output-schema read tool, the description covers purpose, trigger, and cost/auth. It doesn't specify the shape of the aggregated netflow results (ranking, fields, units) or pagination behavior, which is the main remaining gap.

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

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

Schema description coverage is 100%, so baseline is 3; the limit, chains, timeframe and include_labels params are all documented in the schema. The description only adds the framing that results are aggregated across the whole market, which mildly clarifies scope but adds no syntax or format detail 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?

Names a specific resource (smart-money netflows), a scope (aggregated, market-wide across all tokens), and what it reveals (accumulation vs. distribution). It implicitly separates itself from token-level siblings like get_smart_money_flows, though it never names an alternative explicitly.

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

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

Gives explicit trigger conditions: 'Use it when the user asks what smart money is buying or selling, or wants to see market-wide on-chain trends.' No when-not-to-use or named alternative, 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?

With no annotations, the description carries the burden and does disclose the unusual commercial behavior: 0.02 USDC per call via x402 PAYMENT-SIGNATURE header, or free with an API key, plus the note that x402-capable clients auto-pay. It omits data freshness, result caps, and pagination behavior for a 100-per-page dataset.

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?

Front-loads what the tool returns, then when to use it, then the access model — a sensible order. The bracketed payment paragraph is longer than the rest but each clause carries distinct information (price, header, alternative auth, auto-pay behavior).

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

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

No output schema exists, and the description gives no sense of what a trade record contains (fields, wallet identity, leverage, timestamps), nor what the nested passthrough filter/order objects accept. For a tool whose main parameter is an undocumented passthrough, this leaves an agent guessing at invocation details.

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

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

Schema description coverage is 100%, so pagination parameters are already documented. The description adds nothing about the opaque `filters` and `order_by` passthrough objects, which are the parameters most in need of explanation; baseline 3 applies.

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

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

States a specific verb and resource — perpetual futures trades from smart-money wallets on Hyperliquid — and adds the interpretive gloss that these are leveraged directional bets by sophisticated traders. It is clearly separable from siblings like get_smart_money_dex_trades, get_token_dex_trades, and get_smart_money_holdings.

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 activation conditions: smart-money perp positions, high-conviction leveraged activity, Hyperliquid-specific questions. It does not name which sibling to use when the user wants spot/dex trades instead, so routing away from alternatives is left implicit.

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

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

With no annotations, the description carries the burden and does well: it discloses the data source (smart-money wallet net flows), the categorical output, and the access model — 0.02 USDC via x402 PAYMENT-SIGNATURE header or API key, with auto-pay for capable clients. It stops short of noteable operational details such as rate limits, latency, or behavior on unsupported chains/symbols.

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?

Purpose and return values come first, the disambiguation against the social-sentiment sibling follows, and the access/payment block is confined to a final bracketed note. No filler sentences.

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?

There is no output schema, but the description compensates by naming the label set and the flow-direction field. Access and payment mechanics are covered, so an agent can invoke it correctly; only edge-case behavior (unknown symbol, non-default chain effects) is left unstated.

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 both the symbol and chain parameters (including the ethereum default) are already documented. The description reinforces that the subject is a token symbol but adds no new semantics such as accepted symbol formats or chain-specific limitations, so the baseline 3 applies.

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

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

The description gives a specific verb and resource: an on-chain sentiment read derived from smart-money wallet net flows, plus the exact return shape (bullish/bearish/neutral label and net USD flow direction). It is clearly distinguishable from the flow-level siblings like get_smart_money_netflows and from get_social_sentiment.

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

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

It states the triggering user question ('what smart-money sentiment is for an asset') and explicitly routes social-media sentiment requests to get_social_sentiment. Both the when-to-use and the when-to-use-something-else conditions are spelled out.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses the result cap ("at most 10 posts"), that a total match count is returned alongside, and the complete access/payment model (x402 auto-pay of 0.02 USDC via PAYMENT-SIGNATURE header, or API key with no per-call charge). Gaps are minor — no statement on rate limits or failure behavior when no posts match.

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?

Front-loaded with what the tool returns, then the usage rule, then the access note. Every clause is substantive, though the bracketed payment paragraph is dense enough that it slightly dilutes the primary 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?

There's no output schema, so the description must describe returns — and it does (post text, id, timestamp, match count, cap). Parameters and access are covered. The only real defect is the 10-vs-20 result-cap inconsistency with the schema default.

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

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

Schema coverage is 100%, so all three parameters are already documented, and the description adds little parameter-level meaning beyond "recent". There is also a conflict worth flagging: the description says "at most 10 posts" while the schema's limit parameter defaults to 20, which may confuse an agent setting pagination expectations. Baseline 3 holds with that caveat.

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

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

The description names a specific verb (fetch/return) and resource (recent X/Twitter posts about a crypto asset or topic) and enumerates the returned fields (text, id, time). It also explicitly separates itself from get_social_sentiment by contrasting raw posts with an aggregated sentiment score, so an agent can route correctly without opening either 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?

"Use it when the user wants to see what is actually being said, or wants raw posts rather than an aggregated sentiment score" gives an explicit selection condition and names the competing alternative. No inference required.

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

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

With no annotations, the description carries the full burden and does well: it discloses the x402 micropayment (0.02 USDC) vs API-key access, the null-score/insufficient_signal edge case and how to report it, the 70/30 label thresholds, and the returned fields. It does not cover latency, failure modes other than no-signal, or rate limits beyond per-call metering.

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?

Front-loaded with purpose, then computation, then return semantics and reporting rules. Dense but nearly every sentence adds actionable content; the trailing access/payment note is boilerplate but necessary for invocation.

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

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

No output schema exists, yet the description fully specifies the return shape (score, bullish/neutral/bearish label with cutoffs, post count) and the null case. Combined with 100% schema coverage, an agent has everything needed to call it and interpret results.

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 both parameters are already documented, and the description only adds that topic is treated as a cashtag ($TOPIC). hours_back gets no added meaning in the description. Baseline 3 is appropriate when the schema does the parameter work.

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+resource: 'keyword-polarity sentiment for a crypto cashtag on X/Twitter', and explains the exact computation (counts positive vs negative keyword posts, 0-100 score = positive share). This is much richer than a tautology. It stops short of distinguishing itself from adjacent siblings like get_social_mentions or get_smart_money_sentiment, so it is clear but not sibling-differentiated.

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?

Explicitly says 'Use it when the user asks about market mood or social sentiment for a token,' and adds a reuse rule ('ask once per topic and reuse') driven by metering. No exclusion or named alternative (e.g., get_social_mentions for raw mention counts) is given, so it is clear context without 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 no annotations, the description carries the full burden. It discloses the payment/auth model (0.005 USDC via x402 or API key) which is valuable context, but it does not explicitly state that the operation is read-only, what the response format looks like, or any rate limits or data freshness characteristics.

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

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

The description is front-loaded with the core purpose, followed by a concise use-case sentence, and ends with a bracketed access note. Every sentence earns its place with no redundancy.

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

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

For a simple no-param read tool with no output schema, the description covers the purpose, use cases, output content (total supply, per-chain breakdown, top stablecoins), and access requirements. It could be slightly more complete by mentioning data freshness or response structure, but it is adequate.

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 parameter semantics are minimal. The schema is empty and the description does not need to document parameters, meeting the baseline for a no-param tool.

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

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

The description states a specific verb+resource ('Global stablecoin metrics') and enumerates the contents: total supply, per-chain breakdown, top stablecoins by market cap. This distinguishes it from most siblings, though it does not explicitly name an alternative like get_global_market or get_market_data.

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

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

It gives a clear use case: 'Use it when the user asks about stablecoin supply, USDC or USDT dominance, or overall market liquidity.' However, it does not specify when NOT to use it or name a sibling tool that should be used instead.

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

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

With no annotations, the description carries the burden and does add real non-schema context: the x402 pay-per-call cost of 0.005 USDC versus free API-key auth, including that an x402-capable client auto-pays. The notable gap is that both parameters are optional yet lookup clearly requires at least one; the failure behavior when neither is supplied is undisclosed.

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

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

What the tool returns and how to select a record comes first; the when-to-use rationale follows; the access/payment note is bracketed and skimmable. Every sentence carries distinct information and none restates the 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 two-parameter read tool with no annotations and no output schema, the description does the heavy lifting well: it lists the fields returned, explains the id/name selector, and discloses the auth/payment model. The only missing piece is the at-least-one-identifier constraint implied by zero required parameters.

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

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

Schema description coverage is 100%, so both parameters are already documented in structured data. The description adds the either/or semantics ('Accepts either strategy_id or name') and precedence ('name, if the id is unknown'), but no format specifics beyond the schema's UUID note. 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?

States a specific verb and resource ('Fetch one saved strategy in full') and enumerates the returned content fields (entry/exit signals, asset, timeframe, status), which distinguishes it from list_strategies, get_marketplace_strategy and get_backtest. An agent can tell it retrieves stored, owned strategies rather than market-listed ones.

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 an explicit when-to-use rule: call before discussing or changing a strategy so you describe stored state rather than conversation history. It also states the id-or-name acceptance mode. It stops short of naming alternatives (e.g. list_strategies to resolve an unknown id, update_strategy for mutation), so a 4 rather than 5.

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

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

With no annotations, the description carries the full burden and does disclose the key operational facts: a per-call cost of 0.001 USDC via x402 with a PAYMENT-SIGNATURE header, or free access with an API key, plus that x402 clients auto-pay. It stops short of describing the return shape or what happens for an unlisted or unknown symbol.

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?

Purpose and usage lead, with access/payment details quarantined in a bracketed block so they do not dilute the front-loaded routing signal. The payment note is long but earns its place given zero annotation coverage of auth requirements.

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 tool with no output schema, the description supplies purpose, exclusion, and the full cost/auth model, which is the most important unknown. Remaining gaps (venue coverage, behavior on unknown symbols, result ordering) are modest but real.

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

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

Schema coverage is 100% and the single 'symbol' parameter is already documented with examples (BTC, ETH). The description only restates it as 'one specific token', adding no format or normalization guidance beyond the schema, so the baseline 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?

Names a specific resource (exchanges listing a given token) with the qualifier 'per-venue metadata', which tells the agent exactly what comes back. It also draws a line against price-lookup tools. It does not distinguish itself from the sibling list_exchanges, which an agent must infer covers the venue catalogue rather than a single token's listings.

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?

Explicit trigger condition: 'use it when the user asks where a token trades or which venues carry it', plus an explicit exclusion ('rather than for a price on any one of them'). No mention of when to prefer list_exchanges or get_market_data, so the routing vs. those siblings remains implicit.

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

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

With no annotations, the description carries the burden and does well: it discloses the payment/authentication model (x402 auto-pay or API key, per-call cost), what the response contains ('raw swap events with wallet, size and pool metadata'), and two real gotchas (native ETH read as WETH; token must be deployed on the requested chain). It omits pagination behavior and any failure/empty-result 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?

The core capability, the return shape and the two caveats are front-loaded in two tight sentences, followed by a bracketed access note that is clearly separated by purpose. No wasted prose, though the payment block is somewhat verbose relative to the functional description.

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

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

For an 8-parameter, nested-object tool with no annotations and no output schema, the description covers what is needed: what comes back, which token/chain combination is valid, and how access is paid for. Missing only pagination/result-size guidance, which matters given per_page defaults to 100.

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

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

Schema coverage is 100%, so the schema already documents all eight parameters, making 3 the baseline. The description adds modest value by framing date_from/date_to as a 'date window' and by constraining the chain parameter with the 'must be deployed on the chain asked for' rule, but says nothing about the pass-through behavior of filters/order_by 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 opening sentence gives a specific verb+resource+scope: 'DEX trades for a specific token across all participants in a date window', which contrasts implicitly with the smart-money siblings. It does not name an alternative tool, so the distinction from get_smart_money_dex_trades must be inferred from 'all participants'.

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?

'Useful for post-hoc flow analysis on a single token' implies the intended context, giving the agent a rough sense of when this fits. However, there is no explicit when-not guidance and no named alternative (e.g. use get_smart_money_dex_trades for curated wallets), so routing remains partly guesswork.

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

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

With no annotations, the description carries the full load and does well: it discloses cost and auth paths (0.02 USDC via x402 PAYMENT-SIGNATURE, or API key with no per-call charge), symbol normalization (native ETH read as WETH), chain-existence and stablecoin availability constraints, and that results are paginated. It stops short of describing what a 'flow record' contains or how the upstream pass-through filters behave.

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?

Front-loaded with the core purpose and scope, then the sibling routing, then availability caveats, then a bracketed access note. No sentence is redundant; the payment line is dense but carries decision-relevant information for an agent choosing whether to call.

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 9-parameter read tool with no annotations and no output schema, the description covers scope, exclusions, cost/auth, and routing, which is most of what an agent needs. The only shortfall is that the nested filters/order_by pass-through parameters and the shape of returned flow records are left to the upstream provider.

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 meaning on top by constraining 'label' to a single wallet category and framing date_from/date_to as an explicit required window rather than optional fields. It leaves the nested 'filters' and 'order_by' pass-through objects unelaborated, which is the remaining gap.

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

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

States a specific verb and resource (paginated historical flow records) plus the exact scope: one non-stablecoin token, explicit start/end dates, optional single wallet label. It explicitly names the sibling it is not (get_smart_money_flows) and why, so an agent can distinguish the two without opening either 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?

Gives an explicit positive condition (date-range records or pagination) and an explicit negative/alternative condition (trailing-window net USD flows plus wallet counts across categories → get_smart_money_flows). It also states an exclusion ('Not available for stablecoins') and a precondition (the token must exist on the requested chain).

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 are empty, so the description carries the full load — and it does disclose non-obvious behavior: Nansen aggregates across chains so no chain argument should be passed, and access is gated by x402 payment (0.02 USDC) or API key. It stops short of stating pagination or any edge cases, but the auth/payment and cross-chain aggregation context are exactly the kind of traits annotations would normally supply.

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?

Front-loaded with the purpose and metric list, followed by usage triggers, then a bracketed access note kept in its own paragraph. Every sentence is functional; the payment block is slightly verbose but is necessary operational context rather than 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?

There is no output schema, and the description compensates by naming the three returned values. With one required parameter, a stated chain-agnostic resolution rule, and explicit auth/payment instructions, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100% with a single documented parameter, so the baseline is 3. The description exceeds that by adding a real constraint beyond the schema: 'pass the symbol only and do not pass a chain argument', explaining that symbols are resolved chain-agnostically — meaning an agent won't try to disambiguate with a chain field.

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

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

The description opens with a specific verb+resource — 'on-chain token holder distribution for a token' — and enumerates the exact metrics returned (holder count, top-10 concentration percentage, concentration score). It is distinguishable from siblings like get_smart_money_holdings or get_token_flows by its distribution-specific focus, though it never names a sibling directly.

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 concrete triggering questions: 'how many wallets hold a token', 'holder count', 'holder concentration', 'whale ownership', 'distribution risk'. That is strong positive routing guidance, but no when-not-to-use or explicit alternative is offered (e.g. when to prefer get_smart_money_holdings).

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

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

With no annotations, the description must carry the full burden; it does disclose the access model in useful detail (0.01 USDC via x402 PAYMENT-SIGNATURE header, or API key with no per-call charge) and offers an interpretive frame (heavy near-term unlocks = supply-shock signal). However, the scope of the returned data is ambiguous — it says 'per token' yet exposes no way to specify a token, so an agent cannot tell whether this returns all tokens, a default set, or something else.

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?

Front-loaded: the first sentence states what data is returned, the second supplies the signal interpretation, the third the usage trigger, and the payment note is cleanly bracketed so it does not crowd the core semantics. The payment sentence is long but contains information an agent genuinely needs before calling.

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 and no parameters, the description is the only source of truth about the response, and it does not say whether results cover all tokens, a single token, or a default universe, nor what time horizon 'upcoming' implies. The access/payment detail is complete, but the data-shape half is under-specified for a tool with zero structured schema support.

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 is empty (0 parameters), which is the baseline-4 case per the scoring rules; there are no parameters whose meaning the description needs to enrich. The description's 'per token' phrasing creates mild tension with the parameterless schema, but that is a scope question rather than parameter semantics.

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 resource (token unlock schedules and supply metrics) with concrete sub-content (upcoming vesting cliffs, total supply movement per token) and no sibling covers unlocks, so differentiation is implicit but clear. Slightly held back because 'per token' implies a token selector that the tool exposes nowhere.

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 trigger language: 'Use it when the user asks about unlocks, vesting or supply overhang.' No alternatives are named because none exist among the siblings, but there is also no when-not 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?

There are no annotations, so the description carries the full behavioral burden. "Get" implies a read operation, but it does not clarify pagination, limit behavior, return shape, or whether the result is read-only in any explicit way.

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 and front-loads the core action before giving usage context. There is no wasted wording.

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

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

With no annotations, no output schema, and no parameter descriptions in the schema, the definition is thin. It does not explain limit semantics, ordering, pagination, or what trade records are returned.

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

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

Schema description coverage is 0%, so the description must explain parameter meaning. It indirectly explains strategy_id as the strategy's ID, but it says nothing about the optional limit 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 states a specific verb and resource: get trade records for a specific strategy by ID. It clearly scopes the retrieval to one strategy, though it does not explicitly distinguish itself from siblings like list_trades or get_backtest_trades.

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

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

It gives a use case: when the user asks about trades or performance for a named strategy. However, it does not name alternatives or exclusions, and mentioning "performance" may overlap with evaluate_strategy.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses access requirements: x402 payment or API-key authentication. However, it does not cover freshness, coverage, rate limits, or error behavior, so the transparency is adequate but incomplete.

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

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

The description is front-loaded with purpose, then usage guidance, then access details. Every sentence contributes useful information, and there is 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?

For a zero-parameter, read-oriented data tool with no output schema, the description gives enough context to understand what is returned and how access works. It could be richer about data coverage or response shape, but it is broadly complete.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool applies, and the description does not introduce confusion about 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 resource and content: DeFi protocol treasury holdings, including how much a protocol holds and which tokens it owns. It is clearly distinguishable from generic market or TVL tools, though it does not explicitly contrast itself with the closest sibling, get_protocol_tvl.

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 concrete user-intent triggers: protocol treasuries, DAO holdings, or protocol-owned liquidity. It lacks explicit exclusions or alternative-tool routing, but the intended usage context is clear.

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

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

No annotations are present, so the description carries the full burden, and it delivers the most important operational fact: access requires either an x402 micropayment of 0.005 USDC via PAYMENT-SIGNATURE header or an API key, with auto-pay behavior noted for capable clients. It does not describe the shape of the returned list or whether the ranking is refreshed on a schedule, which keeps it from a 5.

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

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

The purpose and usage conditions are front-loaded in the first sentence, and the access mechanics are separated into a bracketed block. The payment paragraph is slightly dense but every clause (cost, header, auto-pay, API-key exemption) affects whether an agent can call it.

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, no-output-schema tool, the description supplies what an agent needs to decide to call it and how to authenticate. It stops short of indicating what the response contains (e.g., a ranked list of symbols with volume figures), which is the one gap given there is no output schema.

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

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

The tool takes zero parameters, so there is no per-parameter semantics to document; the baseline of 4 applies. The description correctly implies no filtering input is required or accepted.

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+resource+ranking criterion: crypto assets trending by 24h search volume. It also contrasts itself with a specific-asset lookup (get_asset), so an agent can distinguish it without opening any 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?

Gives concrete triggering conditions: user asks what is popular, what the market is paying attention to, or wants a discovery view rather than a specific asset lookup. This is a clear when-to-use with an implicit exclusion, though it does not name sibling tools like get_social_mentions that also touch attention signals.

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

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

No annotations are supplied, so the description carries the full disclosure burden, and it does substantial work: it declares this a read, states the 6000-character default and character-based offset/next_offset units, and warns that has_more alone is not a reason to continue paging. It does not describe failure behavior for unknown slugs or the response envelope, so it falls short of a 5.

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

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

Front-loaded with the core action and the routing decision first, then mechanics. It is dense but nearly every clause carries a rule the agent would otherwise guess wrong; a lighter paragraph split would improve scanability but nothing is truly redundant.

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 6-parameter read tool with no annotations and no output schema, the description covers routing, view selection, pagination units, page-size defaults, the full-download restriction, and a caveat that executable signal identities come from the runtime registry rather than the document. An agent has enough to call it correctly on the first try.

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 a 3 is the floor; the description goes beyond it by fixing the unit of offset/next_offset as characters within the selected body (the schema only says 'result units') and by tying section_anchor to a value returned by overview or search. It slightly restates the schema's view and full semantics rather than adding new meaning there.

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 ('Read a requested KB guide or a known source section by slug') and immediately separates itself from the graph/query tools. It is clearly distinguishable from kb_search, kb_list_documents and query_knowledge without opening any 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?

Gives explicit when-to-use ('use directly when the user requests the document itself; no preliminary graph call is required'), an explicit alternative with its own trigger ('for a general explanation use query_knowledge op=ask'), and a resolution path when the slug is unknown (kb_search / kb_list_documents). It also routes between view modes and restricts full=True to explicit full-document requests.

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

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

With no annotations, the description still discloses the important behaviors: the 6000-character default body, that offset/next_offset count characters within the selected body, that continuation should happen only for requested missing text, and that full=True is reserved for explicit downloads. It is silent on what happens with an unknown anchor or slug and on any rate/permission constraints, which keeps it short of a 5.

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

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

The purpose and the shortcut relationship come first, followed by view, pagination, and then the two routing exclusions, so an agent can stop reading once it has what it needs. It is dense with directives and slightly overpacked for a single document reader, but no sentence is 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 five-parameter, zero-required read tool with no annotations and no output schema, the description covers trigger, alternatives, view selection, pagination continuation, and the full-download escape hatch. Nothing an agent needs in order to call it correctly is missing, and the absence of an output schema is offset by the paging contract described.

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 already 100%, but the description adds meaning the schema does not: which view to pick for which need, the relationship between offset, next_offset, and character counts inside the selected body, and the rule that full cannot be combined with paging and should be used only on explicit download requests. This is genuine semantic guidance, not restatement.

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

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

The description names a specific verb (read) and resource (the Signals Quick Reference guide) and explicitly states it is the document-reading shortcut for kb_get_document slug=10-signals-quick-reference rather than an extra validation step. An agent can distinguish it from kb_get_document, query_knowledge, and the runtime catalogue without opening any 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?

It gives an explicit trigger (user asks for that guide or its documented entries), points to view=overview for outlines and view=section with an anchor for passages, and routes two adjacent cases elsewhere: query_knowledge op=ask for conceptual combinations and the runtime catalogue for executable signal names. When-not-to-use is as clear as when-to-use.

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

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

With no annotations, the description carries the behavioral burden itself and discloses meaningful traits: case-insensitive matching, possible partial matches, no prerequisite graph call, and guidance to answer directly from the result. It omits any statement about result limits or error behavior for a non-matching term, keeping it below a 5.

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

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

Front-loaded with the purpose and the alternative-routing rule; four sentences all carry information. The final sentence slightly restates the earlier 'no preliminary call' idea, which is minor 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 one-parameter, non-destructive lookup with no output schema, the definition covers purpose, routing, matching semantics, and post-call behavior sufficiently for an agent to invoke it correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds lookup behavior beyond the schema: matching is case-insensitive and may yield partial matches, which affects how the agent should interpret the single 'term' argument.

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 ('Return the KB glossary entry') and constrains it to an explicitly requested definition or exact term, which cleanly separates it from the sibling query_knowledge op=ask path.

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 conditions (explicit glossary request, no preliminary graph call needed) and an explicit alternative with its triggering condition ('For a general question such as what RSI means... start with query_knowledge op=ask'), plus a stated non-recommendation about following up with graph/document searches.

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

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

With no annotations present, the description carries full behavioral burden and does disclose that this is a read operation returning every document's slug, title and summary. It does not mention result-set size, ordering, or any pagination/limits, which matters for an unfiltered 'every document' listing, but the essential read-only contract is conveyed.

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 short sentences, front-loaded with what is read and what it returns, then the alternative, then the use condition. Every sentence carries distinct information with no repetition of the title or name.

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, annotation-free, output-schema-free listing tool, the description supplies the return fields, the read-only nature, and sibling routing — everything an agent needs to call it correctly. Nothing material is missing 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 takes zero parameters, so the baseline is 4; the description correctly implies nothing is configurable. No parameter confusion is introduced by the text.

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 ('Reads the Mangrove Knowledge Base package') and enumerates the exact fields returned (slug, title, summary). It also distinguishes itself from kb_search and kb_get_document by naming both siblings, so an agent can place it precisely in the KB tool triad.

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?

Explicitly routes the agent: keyword search goes to kb_search, and this tool is for browsing or for obtaining a slug before calling kb_get_document. Both the when-to-use and the alternative conditions are stated outright, leaving nothing to inference.

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

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

With no annotations, the description carries the burden well: it discloses the result shape (snippets and section anchors, not full articles), AND matching semantics ('all query terms must match'), and that a tag disables synonym expansion. It does not cover auth/permissions, result limits, or empty-result behavior, so it stops short of full behavioral coverage.

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

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

Purpose is front-loaded in the first sentence and most sentences carry actionable routing or workflow guidance. It runs long (eight sentences) and repeats the tag/synonym behavior already stated in the schema, which is mild redundancy rather than 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 five-parameter, read-style search tool with no annotations and no output schema, the description supplies the return shape, the search-string convention, and the correct follow-up path. Minor gaps remain around limit/default behavior and what happens when nothing matches.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds meaning by telling the agent how to phrase q ('do not send a full question or split it into speculative keyword searches') and by surfacing the AND-matching consequence of multi-term queries. The tag/expand interaction it mentions is already in the schema, so not all of it is incremental.

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 ('Locate KB articles or source sections') plus the input form ('short topic keywords'). It explicitly distinguishes itself from query_knowledge op=ask and clarifies it returns snippets/anchors rather than full articles, so an agent can separate it from kb_get_document and query_knowledge without opening a 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?

Gives explicit when-to-use ('user asks to find written material', 'explanation missing a specific fact'), when-not-to-use ('for general definitions, explanations, comparisons and combination/caution questions, start with query_knowledge op=ask'), and names the alternative. It also bounds the follow-up loop: read one section with kb_get_document only if a fact is still missing, and do not re-search or read every result.

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

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

With no annotations present, the description carries the full burden and does a solid job: it discloses that approval is independent of risk assessment, that unassessed scores come back null, and it spells out the auth/payment model (0.001 USDC via x402 payment header, or free with an API key). These are non-obvious operational traits an agent could not infer from 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 core purpose and null-semantics warning are front-loaded, and the access/payment note is clearly bracketed off. Minor redundancy ('Approval is independent of risk assessment' partially overlaps the null warning) but nothing wasteful.

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-optional-param read tool with no output schema, the description covers purpose, return contents ('market metadata and risk scores'), null semantics, and the payment model. The only gap is the shape/fields of the returned metadata, but that is reasonable to omit 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?

Only one optional parameter (top_n) with 100% schema description coverage, so the schema already documents it fully. The description adds nothing about truncation ordering or defaults for top_n, so it sits at the baseline for high-coverage schemas.

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+resource ('List assets approved by Mangrove') and scopes the content (supported stablecoins and tokens). It implicitly separates itself from the singular get_asset by framing this as an enumeration of the approved universe, though it never names a sibling explicitly.

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

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

Usage is implied — call this to obtain the set of Mangrove-approved assets — but the description never says when to prefer it over get_asset, screen_candidates, or search_marketplace. The only explicit guidance is interpretive ('do not interpret null as zero'), not selection guidance.

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

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

No annotations exist, so the description carries the full burden, and it delivers non-obvious context: listed availability does not guarantee historical coverage, and submission validates the chosen window. It also prescribes a confirmation workflow before saving or running. Missing only return shape and any read-only/pagination characterization, which "list" implies but does not state.

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?

Front-loaded with the purpose, then layered caveats. The last two sentences overlap somewhat ("do not force a selection step" vs. "suggest an available match and obtain confirmation"), but both address distinct risks and nothing is pure 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 one-parameter read tool with no annotations and no output schema, the description covers what is returned (venue and quote-token options), when to call it, and the key caveat about historical coverage. Only the concrete returned fields and any pagination behavior are left unstated, which is a minor gap.

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

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

There is a single parameter (asset) with 100% schema description coverage providing an example format, so the schema already does the work. The description adds no meaning about the asset parameter itself, matching the baseline for fully documented schemas.

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 pair — list execution venue and quote-token choices — scoped explicitly to backtests, which separates it from generic venue tools like list_exchanges. It never names an actual sibling, so sibling differentiation is implied by scope rather than stated.

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 both a use trigger ("user wants alternatives or market details are missing") and an explicit when-not ("A complete supplied or recorded market is already the default: do not force a selection step"). It stops short of naming a specific alternative tool for the fully-specified case.

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

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

No annotations exist, so the description carries the full burden. It discloses ordering (newest first), the optional strategy filter, and payment/auth requirements. However, it does not describe the shape of returned backtest entries or any pagination behavior beyond the limit parameter, leaving some behavioral gaps.

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

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

The description is front-loaded with purpose and usage, but it repeats 'newest first' twice (once in the opening phrase and again in 'Results are newest first'). That redundancy and the bracketed payment note slightly dilute conciseness, though nothing is egregiously verbose.

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 and no annotations, the description needs to be self-sufficient. It covers purpose, filtering, ordering, the alternative tool, and access/payment requirements. It leaves the exact return fields undefined, which is a gap for a list tool, but the core information an agent needs to invoke it correctly is present.

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 explaining that strategy_id optionally restricts results to one strategy's runs and that results are ordered newest first. It does not add syntax details beyond the schema, so it remains slightly above baseline.

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

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

States a specific verb and resource ('recent backtest runs, newest first') and explicitly names the sibling get_backtest for fetching a single result. An agent can distinguish it from list_strategies, run_backtest, and get_backtest without opening any 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?

Names the triggering user intents ('what they have run', 'refer to an earlier result without giving an id'), the alternative tool to use next (get_backtest), and the behavioral benefit ('avoid re-running'). No significant ambiguity remains about when to choose this 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?

With no annotations present, the description carries the full burden and does disclose meaningful behavior: per-evaluation market snapshots, signal decisions, order intents, and a success/error flag. It leaves out pagination behavior, ordering guarantees, and default limit, but the read-only nature is strongly implied by 'decision log'.

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 return contents and the usage triggers lead the description, and the sentence order is sensible. There is mild redundancy between 'bar-by-bar decision log for a strategy' and 'every time the agent checked signals for this strategy', but nothing wasteful.

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

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

No output schema or annotations exist, so the description does the work of explaining the return payload at a useful level of detail. The remaining gap is the pagination/ordering contract for limit and offset, which an agent needs to page through a potentially long log.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate and does not. strategy_id is only obliquely referenced ('for a strategy'), and limit/offset are never mentioned, leaving pagination semantics entirely undocumented.

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 resource and scope: a bar-by-bar decision log of every signal check for a given strategy. The phrasing 'every time the agent checked signals' clearly separates it from sibling tools that *run* evaluations (evaluate_strategy, evaluate_signal) or return trades (get_trades_for_strategy).

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

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

Provides four concrete user-intent triggers ('what did the agent decide', 'why did it not trade', evaluation history, last check time) that map directly to invocation. It stops short of naming an alternative tool or an explicit when-not-to-use case (e.g. 'use evaluate_strategy to run a new evaluation').

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

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

With no annotations, the description carries the behavioral burden and does disclose important access behavior: x402 payment versus API-key authentication, including per-call cost. It does not explicitly state read-only status, rate limits, or pagination behavior, but for a zero-parameter listing tool the access disclosure is the main missing-risk information.

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

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

The description is front-loaded with the core purpose and return fields, followed by a clear usage rule. The bracketed access note is compact and earns its place by explaining payment/authentication requirements.

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 list operation, the description covers purpose, return metrics, usage guidance, and access requirements. Since there is no output schema, it could more fully describe the response shape, but it gives enough for an agent 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?

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline score of 4 applies because the description does not need to explain inputs and the schema is already empty.

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 exactly what the tool returns: every exchange tracked by Mangrove, including tier and 24h volume. It also distinguishes the scope from a single-venue lookup, making it easy to separate from siblings such as get_symbol_exchanges.

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

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

It gives an explicit use case: when the user asks what exchanges are supported or wants to browse the exchange universe. It also names the contrasting condition, 'rather than a single venue,' which routes the agent away from venue-specific tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a safe read-only listing by saying 'Return metadata' and 'all available', but it does not disclose pagination, authentication, cost, or the response shape. For a zero-parameter read tool this is minimally adequate, not rich.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action, scope ('all available'), and resource ('playground CSV datasets') immediately.

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 listing tool with no output schema, the description tells the agent what is returned at a high level but not what fields the metadata contains or how to follow up with get_playground_data. It is minimally complete but leaves key integration details unstated.

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 are no parameter semantics to explain. The description correctly avoids inventing parameter details, and the baseline for zero-parameter tools is 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?

The description uses a specific verb+resource ('Return metadata for all available playground CSV datasets'), which is clear and distinguishable from data-fetching siblings like get_playground_data. However, it does not explicitly name the alternative tool or state the metadata-vs-data distinction, leaving sibling differentiation implicit.

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 no guidance on when to use this tool versus alternatives such as get_playground_data. It implies listing datasets but does not state when-not-to-use or what prerequisites exist.

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

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

Annotations are empty, so the description carries the full disclosure burden. It reveals that results are scoped to 'the current user' and can be open-only or all, but says nothing about authentication requirements, defaults for open_only, pagination/limit behavior, result ordering, or what a position record contains.

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; the core action and mode come first, followed by filtering and usage triggers. No filler, though the parenthetical '(or all)' is slightly awkward phrasing.

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 annotations, no output schema, and four parameters at 0% schema coverage, the description would need to explain result shape, pagination, and parameter defaults. It covers filters and intent only, so an agent still cannot predict the response or the meaning of `limit`.

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

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

Schema description coverage is 0%, so the description must define all four parameters. It names the strategy ID and asset filters and hints at open_only via 'open (or all)', but never explains `limit` or states the default value of `open_only`, leaving half the parameters undocumented anywhere.

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 ('List ... positions') plus scope ('for the current user') and a default/mode distinction ('open (or all)'). It does not explicitly distinguish itself from the very similar sibling list_trades, leaving the agent to infer the difference between a position and a trade.

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 triggering conditions: 'when the user asks about their current positions, open trades, or what they are currently holding.' That maps directly to user phrasings, but there is no when-not guidance and no named alternative (e.g. list_trades) for overlapping requests.

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