falcon.sol

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries real weight here and delivers: per-call price, x402 on Base or Solana, the failure mode (PaymentRequirements returned instead of a result), and the exact remediation (_meta "x402/payment" then retry). That is genuinely actionable behavior an agent cannot get from annotations. It stops short of rate limits, failure modes beyond payment, or what a successful response looks like.

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 price is stated twice in near-identical wording ("Costs $0.03 USDC (x402)" then "Paid: $0.03 USDC per call via x402"), and the bracketed block mixes docs attribution ("falcon.sol docs.") with operational detail. The useful scoping sentence is front-loaded, but the body 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?

Payment and auth behavior are well covered, which is the hardest part. But with no output schema and no required parameters, the description should explain what a successful extraction returns and how url vs file_base64 are resolved — neither is addressed, leaving real gaps for a paid 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 67% — url and file_base64 are documented in the schema, but the type enum (auto, invoice, receipt, purchase_order, w9, bank_statement, generic) has no description anywhere, and the description adds nothing about how type changes extraction or what "auto" triggers. Baseline 3 is appropriate since the schema does most of the 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?

"Full extraction of all pages" gives a verb (extract) and a scope (all pages), but never says what is extracted — text, structured fields, or typed financial data — nor which document format. It also never names the obvious sibling preview_document, so the agent must infer the full-vs-preview distinction from the scope word alone.

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 when-to-use guidance relative to preview_document or the other finance siblings; the only procedural text is about the payment retry loop. It also does not state that one of url/file_base64 must be supplied despite required parameters being empty.

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

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

Annotations only supply readOnlyHint and openWorldHint, so the description carries the real behavioral burden and does so well: it discloses a per-call price, the exact failure mode (unpaid calls return x402 PaymentRequirements), and the recovery protocol (pay with an x402-MCP client via _meta "x402/payment" and retry). That is meaningful operational context an agent could not infer. It stops short of describing rate limits, latency, or the shape of the returned table.

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 pricing information is stated twice — once as 'Costs $0.05 USDC (x402)' and again in the bracketed block 'Paid: $0.05 USDC per call via x402 (Base or Solana)'. The opening sentence is well front-loaded with the useful content, but the bracketed duplication wastes 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 paid tool with no output schema, the description does the important work of naming the metrics returned and explaining payment/retry, but it leaves the nested 'prices' input unexplained and says nothing about error handling, partial results, or what happens when a ticker is unknown. An agent has enough to attempt the call, but not enough to use it well.

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% with two parameters, and the description only touches 'tickers' — restating the max of 12 that the schema already enforces via maxItems. The 'prices' parameter is a nested object of numbers and is left completely unexplained, so an agent cannot tell whether it is optional input prices, a currency map, or an override for the comps calculation.

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 (a trading comps table) and enumerates the exact columns returned (market cap, EV, EV/Revenue, EV/EBITDA, P/E, P/FCF, margins, peer medians) with the 12-ticker cap. This is clearly distinguishable from siblings like get_lbo or spread_bank_statement, though it never explicitly contrasts itself with get_financials or get_gpu_comps, which are the closest alternatives.

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

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

Usage context is implied by the metric list and the paid-call mechanics, but there is no statement of when to choose this over get_financials or get_gpu_comps, nor any precondition or exclusion. The retry instruction covers how to call it, not when to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds substantial non-obvious behavior: the tool is paywalled at $0.24 USDC via x402 on Base or Solana, unpaid calls return PaymentRequirements, and the client must attach payment in _meta and retry. That is valuable operational context beyond the annotations, though rate limits and failure modes beyond payment are unstated.

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, but the payment details are stated twice (the '$0.24 USDC (x402)' sentence and the bracketed parenthetical repeat), which is redundant. The duplication costs space without adding information.

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

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

With no output schema, the description does a reasonable job listing the output categories (leverage, coverage, FCF/debt, debt capacity, rated structures, memo). But for a tool with two nested, undocumented parameters (prices, assumptions) and no output schema, the definition leaves an agent guessing how to supply inputs beyond tickers.

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. The description only reinforces the 12-ticker cap (already encoded as maxItems) and says nothing about the 'prices' or 'assumptions' objects, which are entirely undocumented in both schema and description. It does not compensate for the coverage 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+resource: credit comps (leverage, coverage, FCF/debt, debt capacity, rated structures, memo) for up to 12 tickers. An agent can tell it produces credit-focused comps output. It does not explicitly differentiate from the sibling get_comps/get_financials, leaving the 'credit vs general comps' distinction 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?

Usage is implied by the domain (lev-fin credit comps for up to 12 tickers) and the payment mechanics are spelled out. However, there is no explicit when-to-use versus get_comps or get_lbo, and no guidance on when multi-ticker batching is preferred over per-ticker calls.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description goes meaningfully beyond them by disclosing the $0.01 USDC x402 cost, the accepted chains (Base or Solana), and the exact failure mode plus remediation path (_meta "x402/payment" then retry). It would earn a 5 with any note on rate limits, invalid-ticker behavior, or whether partial data is returned when EDGAR has 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 data scope is correctly front-loaded, but the price is stated twice ('Costs $0.01 USDC (x402)' and again in the bracket) and the bracketed section repeats the same information at length. The 'falcon.sol comps.' fragment is a non-sequitur that consumes attention without adding meaning.

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

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

With no output schema, the description does helpfully sketch the return contents (balance sheet, ratios, XBRL provenance, 15 FY + TTM), and payment mechanics are fully covered. Missing for a paid open-world tool: ticker format expectations and what a caller gets back when EDGAR coverage for that ticker is thin or absent.

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 carry the load, and it only partially does. 'Up to 15 FY' implicitly explains the `years` parameter's 1-15 range, but `ticker` gets no format guidance (plain symbol vs CIK vs exchange-qualified), which is the most likely source of a failed call.

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

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

It names a specific resource and source: standardized financials from SEC EDGAR, covering up to 15 FY + TTM, balance sheet, ratios and XBRL provenance. That is a genuine verb+resource statement an agent can act on. It does not, however, distinguish itself from the sibling preview_financials, and the stray 'falcon.sol comps.' fragment muddies rather than clarifies 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 gives clear operational guidance for the payment case: unpaid calls return x402 PaymentRequirements and the caller should pay via an x402-MCP client and retry. But it never says when to choose this over preview_financials or get_comps, which is the sibling decision an agent actually faces. Usage is implied by the data scope 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?

Annotations only say readOnly and openWorld; the description adds the crucial behavior that this is a paid call at $0.04 USDC on Base or Solana and that unpaid attempts fail with a payment challenge. It also discloses the shape of the payload (source URLs, fetched_at, min/median/max, quote percentile). The payment details are restated twice rather than expanded, 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?

Purpose is front-loaded in the first clause, which is good, but the payment terms appear twice ('Costs $0.04 USDC (x402)' and the bracketed repeat) and 'falcon.sol' is repeated. Roughly a third of the text is duplicated boilerplate.

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?

Payment/auth behavior and return fields are well covered, which matters for a paid endpoint with no output schema. What is missing is anything about the three optional inputs — an agent cannot know what values gpus and tiers accept or how target_usd_per_gpu_hr drives the percentile.

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 carry all parameter meaning, and it carries none: gpus, tiers, and especially target_usd_per_gpu_hr (clearly tied to the 'quote percentile' output) are never explained. The agent must guess accepted GPU names, tier values, and the units/effect of the target price.

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 (listed USD per GPU-hour comps) with named sources (RunPod, Modal, Lambda, CoreWeave) and the aggregate stats returned, so the agent knows exactly what it gets. It does not distinguish itself from the sibling get_comps, which an agent could easily confuse it with.

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 procedural instruction for the unpaid path (unpaid calls return PaymentRequirements; pay with an x402-MCP client via _meta "x402/payment" and retry), which is genuinely actionable. However, it never says when to choose this over the sibling get_comps, or what preconditions (wallet balance) apply.

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

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

Annotations already indicate read-only and open-world behavior, but the description adds critical context: the tool costs $4.49 USDC via x402, unpaid calls return PaymentRequirements, and payment must be made with an x402-MCP client before retrying. It also lists the return components, which helps set expectations. No contradiction with annotations.

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

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

The core purpose is front-loaded, but the payment details are repeated (cost mentioned twice) and the bracketed note feels like an afterthought rather than integrated structure. It could be more concise by removing 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 complex tool with no output schema, the description adequately lists what the output includes (sources & uses, IRR grid, etc.) and covers the payment requirement, but it falls short on explaining the inputs—especially the five parameters—and how they affect the analysis, leaving agents without guidance on non-ticker arguments.

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 compensate. It only indirectly clarifies the 'ticker' parameter as a US ticker, but provides no meaning for 'peers', 'price', 'assumptions', or 'exit_multiple', leaving these parameters 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?

The description clearly states it returns an LBO snapshot with specific components (sources & uses, 3 structures, IRR/MOIC, IRR grid, memo) for a US ticker, and specifies the exit assumption at peer-median EV/EBITDA. This distinguishes it from sibling tools like get_comps or get_financials, which focus on other financial analyses.

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 implies usage for LBO analysis on a US ticker with a peer-median exit multiple, but does not explicitly state when to use this tool versus alternatives such as get_comps or get_financials, nor does it provide exclusions or preconditions beyond the ticker being US-listed.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds that the call is free (cost disclosure) and that volatility data is sourced from Deribit, which is genuine context beyond the annotations, but it says nothing about latency, refresh cadence, or failure modes.

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 sentence is front-loaded and efficient, but 'Free' is stated twice and a bracketed fragment '[falcon.sol structures. Free, no payment.]' is appended with no clear meaning, which reads as leftover noise and dilutes the payload.

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-required-param read with no output schema, the description covers what is measured (spot, implied vol, realized vol) but not the shape or units of the response, nor whether the three metrics come back together. Adequate but with a visible 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 0%, but the single parameter is a closed enum of three asset tickers that the description mirrors explicitly (BTC, ETH, SOL), so the parameter meaning is effectively conveyed. No additional syntax or format detail is needed or given.

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 specific outputs (live spot, Deribit DVOL implied vol, 30d realized vol) and specific assets (BTC, ETH, SOL), so the resource is unambiguous. It does not distinguish itself from any sibling tool, though the sibling list is mostly wallet/financials tooling, so overlap is limited.

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 call this versus alternatives, no prerequisites, and no exclusions. The reader must infer that it is a market-data read for crypto underlyings.

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

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

Goes well beyond readOnlyHint/openWorldHint: discloses the four verdicts, that 'unknown is never reported as safe', 502-with-no-charge on total source failure, charging only on non-error results, invalid-argument rejection before settlement, and cache semantics (cached/stale/cacheAgeMs). This is exactly the failure-mode and cost information an agent needs before spending money.

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 trigger and sources, which is good. But payment mechanics are stated three times (502/no-charge, 'charged only when the tool result is not an error', and the bracketed x402 pricing block), and the version string/metadata tail ('[falcon.sol solana-wallet-intel...]') duplicates earlier pricing content.

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

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

With no output schema and 0% param coverage, the description supplies the return shape (verdicts, 0-100 score, flags with evidence, missing_fields) and the caching fields, which is substantial. Remaining gap is the undocumented 'network' param and no guidance on how verdict thresholds should change agent behavior.

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 carry the load. It clarifies payTo (x402 payTo address) and endpoint (its unpaid 402 challenge, payTo mismatch, price outliers) and touches price indirectly, but never explains what the 'network' string should contain or how price is formatted/compared, leaving two of four params ambiguous.

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

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

States a specific verb and resource ('checks public sanctions lists... wallet age, activity and program status on Solana or Base') plus the endpoint's 402 challenge, and frames it as a pre-payment gate. Clearly distinct from siblings like token_check_demo, wallet_profile or pretrade, which do not combine sanctions + scam list + endpoint verification into a pay/no-pay verdict.

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: 'Call this before your agent pays an unfamiliar x402 payTo address or endpoint', which also implies the when-not (already-known payees). It names the bundle companions (seller_report, pretrade) but does not say when to pick those instead of this one.

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 cover the read-only safety profile, and the description adds useful behavioral facts beyond them: no USDC is spent and no wallet is read. It still says nothing about what the tool returns or whether it can block, but the cost and side-effect profile is well disclosed.

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

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

The core sentence is short and front-loaded with the key fact: this is a free health check that does not spend USDC. The trailing bracketed string ('[falcon.sol solana-wallet-intel. Free, no payment.]') is low-value noise that slightly dilutes 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, annotation-covered liveness tool, the description covers purpose, cost, and side effects. It omits what a successful or failed response looks like, but with no output schema that 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?

The tool takes zero parameters, so the 4 baseline applies. The description correctly implies no inputs are needed.

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

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

The description states a specific purpose: a free health check that confirms the MCP server is up. It also distinguishes itself from the wallet-oriented siblings by stating it does not read a wallet and does not spend USDC, so an agent can tell it apart from wallet_profile or wallet_quick.

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

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

The description gives clear context for when to use it (a free server liveness check, with no cost and no wallet read). However, it never explicitly names alternatives or states when not to call this tool, so the guidance stays 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?

The description discloses many behaviors beyond the readOnly/openWorld annotations: per-factor failure handling, the 3-second cap, 404 for unknown mints before payment, 502 when all factors fail with no charge, x402 pricing, 402 behavior for unpaid calls, and cache/stale semantics. These details materially help an agent understand cost, failure, and payment behavior.

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

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

The core purpose and checks are front-loaded, which is good, but the description is long and includes duplicated pricing text in both the body and the trailing bracket. It is informative but not efficiently structured.

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

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

For a paid, multi-factor tool with no output schema, the description explains return verdicts, confidence, limits, caching, payment outcomes, and failure semantics well. The remaining notable gap is parameter meaning, especially for the optional parameters.

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

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

Schema description coverage is 0%, and the description explains almost none of the five parameters. It indirectly implies that mint is a token address via the 404 behavior, but payTo, symbol, network, and endpoint are 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?

The description states a specific pre-trade action for Solana tokens and enumerates the five checks it runs, so the tool's purpose is unmistakable. It also distinguishes itself from the bundled payee_check by noting that an x402 payee check is optional within this call.

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 clearly says to call this before an agent buys a Solana token, which gives strong usage context. However, it does not explicitly compare against alternatives such as token_check_demo or explain when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond them: only page 1 is processed, document type is auto-detected, results carry per-field confidence, and there is no payment/cost. It still omits error behavior for bad URLs or unsupported PDFs.

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 sentence is front-loaded and dense, but 'Free' appears twice and the bracketed '[falcon.sol docs. Free, no payment.]' fragment is noise that repeats the pricing point without adding information.

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

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

For a tool with zero required parameters and no output schema, the description should clarify that at least one of url/file_base64 must be supplied and what the response contains. It gives only 'per-field confidence' and never addresses the required-input gap, so an agent could invoke it with no arguments.

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 67%, so the baseline is 3. The description usefully explains that the 'type' parameter's values correspond to auto-detected document classes (invoice/receipt/PO/W-9/bank statement), but it does not clarify url vs file_base64, which is the key ambiguity in this 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: extract page 1 of a PDF, with auto-detection of five document types plus per-field confidence. The 'page 1'/'preview' scope is clear, but it never names or distinguishes itself from the sibling extract_document, leaving the agent to infer that this is the truncated, free-tier variant.

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?

'Free: ... Free, no payment' signals this is the no-cost preview path, implicitly contrasting with a paid extraction tool, but no explicit alternative is named and there are no when-not conditions. An agent can guess this is the cheap first-look call, but the routing rule to extract_document is never stated.

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

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

The annotations already establish that this is a read-only, open-world tool. The description adds useful context: the data comes from SEC EDGAR, covers the latest fiscal year, and is free with no payment, but it does not clarify preview limitations, rate limits, or authentication behavior.

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

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

The description is short and front-loads the core purpose. It does contain redundant vendor branding and repeats the free/no-payment point, but the overall length is appropriate for a simple one-parameter tool.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers the returned metrics, data source, fiscal-year scope, and accepted identifier types. Minor gaps remain around output formatting and CIK syntax, but nothing critical is missing for basic 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?

Although the schema has 0% description coverage for the single required parameter, the description compensates by saying the identifier can be a US ticker or CIK. It does not give format examples or explain CIK formatting, but it adds meaningful semantics beyond the bare string schema.

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

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

The description clearly states the resource and fields: latest fiscal-year revenue and net income for a US ticker or CIK, sourced from SEC EDGAR. It is specific about what the tool returns, but it does not distinguish itself from the sibling get_financials tool.

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

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

It indicates the tool is free and requires no payment, which implies a preview use case, but it does not explicitly say when to use this tool versus get_financials, get_comps, or other financial-data siblings. No exclusions or alternative-selection guidance is provided.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), yet the description adds real value: results are indicative and rounded to 0.5%, there is no payment/charge, and it scopes itself to falcon.sol structures. It doesn't say whether the quote is deterministic for a given seed or how stale it can be, which keeps 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?

Two compact sentences with the core capability front-loaded and no filler. The bracketed trailing tag "[falcon.sol structures. Free, no payment.]" is slightly noisy but still carries information.

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

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

For a one-parameter tool with no output schema and a fully documented nested schema, the description covers the essentials: what is computed, that results are rounded and indicative, and what artifacts come back. The only real gap is the missing explicit contrast with `price_note`.

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 single `termSheet` parameter already carries a pointer to /schema/term-sheet.json plus a full worked example, so the schema does the heavy lifting. The description adds only the general domain (falcon.sol structures) and mentions which fields the output derives from, not 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 verb+resource and enumerates the outputs: an indicative quote with fair coupon/participation, probabilities and a payoff diagram. It's clear what the tool returns, but it never names or contrasts with the sibling `price_note`, so an agent must infer the preview-vs-price distinction 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?

"Free indicative quote" and "Free, no payment" imply this is the no-cost, non-binding path taken before a firm price, but no alternative (e.g. `price_note`) is named and no explicit when-to-use/when-not statement is given. Usage is inferable but not 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?

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context: Monte Carlo on live Deribit implied vol, the free-preview limitation, and the x402 payment-requirements retry flow. This is valuable beyond the annotations, though the pricing/payment detail is repeated rather than refined.

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 sentence is well front-loaded, but the $0.02 USDC / x402 payment terms are restated three separate times, wasting space. Effective content is there, but the repetition costs 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 single nested-object param with no output schema, the description compensates by naming the returned outputs (coupon, probabilities, greeks, scenario grid, payoff data) and the payment mechanics. Only the preview_note relationship is left 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% and the single termSheet param has a rich inline example, so the baseline is already 3. The description adds semantics by enumerating supported product types and the returned quantities (coupon/participation, probabilities, greeks, scenario grid), going 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?

States a specific verb+resource ('structured-note pricing for crypto') and enumerates the product types it handles (autocallable, barrier reverse convertible, range accrual, principal-protected, shark fin). It doesn't distinguish itself from the sibling preview_note, so it stops short of a 5.

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

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

Clearly says to send a JSON term sheet on BTC/ETH/SOL and explains the free-preview vs paid full-quote flow, plus what happens on an unpaid call. It does not explicitly route an agent to preview_note or name when-not-to-use, so no 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the exact cost ($0.40 USDC per call), the payment rails (Base or Solana), and the failure mode (unpaid calls return x402 PaymentRequirements that must be settled via _meta "x402/payment" then retried). That is substantive behavioral context an agent cannot infer from structured fields.

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 clause is well front-loaded, but the price is stated three separate times ('Costs $0.40 USDC (x402)', 'Paid: $0.40 USDC per call via x402', and the bracketed 'falcon.sol docs' note), which reads like leftover documentation injected into the field. Trimming the redundant payment restatement would make it materially 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?

With no output schema, the description carries the return-value burden and does so by enumerating the metrics produced, plus it fully covers the paid-access/auth flow. The remaining hole is parameter-level guidance (especially the `type` enum), which leaves the agent guessing on call construction.

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

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

The description says nothing about any of the three parameters. With only 67% schema coverage, the undocumented `type` enum is the critical gap: for a bank-statement-specific tool it is unclear whether the agent must set type="bank_statement" or leave it on "auto", and the description does not resolve this or clarify url vs file_base64 precedence.

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 arrow notation states the input resource (bank statement) and enumerates the exact output (every transaction plus ADB, NSF, MCA/loan positions, revenue trend, DSCR inputs, tamper flags). This level of specificity distinguishes it from the generic sibling extract_document/preview_document without needing to name them.

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

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

The payment prerequisite is explicit (needs an x402-MCP client, pay and retry), which tells the agent how to invoke it successfully. However, there is no guidance on when to choose this over extract_document or preview_document, and no exclusions for non-bank-statement documents despite the generic url/file_base64 inputs.

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

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

Annotations already mark it as read-only and open-world, but the description adds useful behavioral context: it is free, requires no payment, uses SIC-based ranking, and is scoped to US companies. It still omits details like rate limits or behavior when no peers 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?

The description is short and front-loaded, but the bracketed suffix repeats 'falcon.sol', 'comps', and 'Free' without adding much new information. It is usable but contains redundancy rather than tight economy.

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

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

For a simple two-parameter suggestion tool with no output schema, the description covers the core purpose, ranking method, and downstream use. However, it leaves gaps around limit behavior, ticker format, and expected result shape that an agent would need to infer.

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 compensate. It only indirectly clarifies that ticker refers to a US company and says nothing about the optional limit parameter, leaving parameter meaning largely 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?

The description clearly states the tool suggests peer tickers for a US company using SIC classification and revenue closeness ranking. It also explicitly names get_comps as the downstream consumer, which helps differentiate it from that 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 states the intended workflow: get peer tickers, then pass them to get_comps. It also clarifies the free/no-payment context. However, it does not explicitly say when not to use it versus other comps-related siblings like get_gpu_comps.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the data source (free public data only), a 60-second per-mint cache, and a 20 calls/minute per-client rate limit, plus that this route returns only a subset of flags versus paid routes. These are operationally relevant traits an agent would otherwise have to discover by trial.

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, but the text carries promotional framing ('Try free, then pay per call') and a trailing bracketed banner ('[falcon.sol solana-wallet-intel. Free, no payment.]') that adds no invocation guidance. Every sentence should earn its place; a couple of them don't.

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

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

With no output schema, the description compensates by listing the returned fields and the one-line verdict. Combined with the rate limit and cache notes, an agent has enough to call it correctly; only error behavior and output shape details are left to the 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% and already documents the single base58 mint argument and the 400 on invalid input. The description only adds that it is one mint per call and that the route is free, which is marginal 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?

States a specific verb and resource: pass one Solana token mint, get a rug-check. It even enumerates the returned fields (riskScore, riskLevel, verdict, flags, liquidity, market cap, age, pump.fun status), so an agent knows exactly what it produces. It is not explicitly contrasted with sibling tools like token_trending, which keeps it from a 5.

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

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

'Free demo. Try free, then pay per call' plus 'The paid routes return every flag, the full on-chain checks, and wallet intelligence' establishes clear context for choosing this cheap/free subset over paid tiers. No explicit when-not-to-use or sibling alternative is named, 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?

Goes well beyond the annotations: it discloses the x402 pricing model, the 402 behavior for unpaid calls, that invalid signed arguments are rejected before settlement and not charged, and the cached/stale/cacheAgeMs semantics. It also documents data fallbacks (public RugCheck report at medium confidence), 'unknown' handling that never reports a check as safe, and how thin/new/wash-like books are ranked down.

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, but the text is heavily repetitive: riskScore/riskLevel/one-line verdict are described twice, and the liquidity/market cap/5m/1h/24h price and volume fields appear in two separate blocks. The same three or four facts could carry the paragraph in half the length.

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

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

With no output schema, the description fully explains the return payload (risk breakdown, evidence, confidence, market flags, summary block) and covers payment, caching, and error-charging behavior. An agent has everything needed to call it 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 100% and its descriptions already cover limit, maxRisk, and minLiquidity, including the unknown-liquidity exclusion. The description adds only one piece of meaning beyond the schema: maxRisk leaves out tokens whose riskLevel is unknown. 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: returns trending Solana memecoins with a per-token rug check. It is clear what the tool produces, but it never names the closest sibling (token_check_demo) or explains how this list differs from a single-token check.

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

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

Gives an explicit use trigger ('before you buy, swap, or recommend a Solana memecoin') and notes the free preview endpoint for testing. No 'when not to use' or named alternative is provided, so the agent must infer that a single-token lookup belongs elsewhere.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses pricing ($0.009 USDC / 9000 base units), the x402 payment handshake, that unpaid calls return 402 regardless of query validity, that invalid signed arguments are rejected before settlement, and that stale/cached/cacheAgeMs can be set on a served result. It also notes labeled exchange hot wallets are excluded from clustering, which materially affects interpretation of results.

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

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

Purpose is front-loaded correctly and the payment/caching caveats are genuinely needed, but the $0.009 USDC / x402 pricing is stated three separate times (mid-description, the HTTP GET sentence, and the bracketed falcon.sol suffix), which is redundant bulk an agent does not need repeated.

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

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

With no output schema, the description does the work of explaining the return surface (cluster id, plain-language sybil reasons, cached/stale/cacheAgeMs) plus the full billing and payment flow. It stops short of describing the response shape or what a null/absent funder looks like, which is the main remaining gap for a paid query tool.

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

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

Schema description coverage is 100%, so both address and peers are already documented in the schema, making 3 the baseline. The description adds only marginal meaning, restating that peers compares up to 8 wallets and that peers are folded into the cluster analysis alongside the primary address.

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 chain: find a wallet's first SOL funder, flag wallets sharing that funder or a CEX deposit address, and return a cluster id with sybil-risk reasons. That is far more specific than siblings like wallet_profile or wallet_quick, but the description never names or contrasts those siblings explicitly, leaving differentiation to inference.

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 this when you need a wallet's first SOL funder and whether other wallets look like the same operator" gives a clear trigger condition, and the peers note explains when to expand scope. There is no explicit when-not-to-use or named alternative among wallet_quick, wallet_profile, or suggest_peers.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds non-obvious commercial behavior: it is free, does not spend USDC, and invalid input fails before any payment request. It also enumerates the returned fields in the absence of an output schema. It stops short of rate limits or latency expectations, so not a full 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 free-tier and call-first framing is front-loaded, followed by returns and upgrade paths in a logical order. The trailing bracketed tag '[falcon.sol solana-wallet-intel. Free, no payment.]' is largely redundant with the opening sentence and slightly dilutes an otherwise tight 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 a single-parameter read-only teaser with no output schema, the description covers cost, input format, error behavior, and the exact return fields. Nothing an agent needs in order to decide to call it or to interpret the result is missing.

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

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

Schema coverage is 100% and already documents base58 length and an example, so the schema carries most of the burden. The description still adds validation semantics ('invalid addresses return an error and do not ask for payment') and the cardinality constraint 'Pass one base58 Solana address'.

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 plus the exact payload returned (SOL balance, last active time, 24h landed transaction count, dormant/active label), and explicitly positions itself as the free entry point relative to wallet_quick, wallet_profile, and wallet_funding. An agent can distinguish it from all wallet siblings 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?

Explicitly instructs 'Call this before any paid wallet tool' and gives a routing map for each upgrade path with the distinguishing capability of each. It also states the when-not case indirectly by noting invalid addresses error out without asking for payment.

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?

Adds substantial context beyond the annotations: $0.009 USDC x402 pricing, unpaid HTTP returns 402 even on malformed queries, invalid signed calls are rejected pre-settlement and uncharged, and cached/stale/cacheAgeMs semantics. However the final bracketed block restates the x402 payment boilerplate already covered in the body, diluting the net added value for what is already a long disclosure.

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 before output details, routing, and billing, which is the right ordering. It is dense but mostly earns its place; the main waste is the duplicated payment statement ('Costs $0.009 USDC... via x402' in the body and again in the bracketed falcon.sol block).

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 still spells out the return payload (holdings, PnL windows, win rate, labels, copyTradeScore/Grade composition, null-score condition) plus billing and caching behavior. Nothing an agent needs in order to call this correctly and interpret the result is missing.

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

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

Schema coverage is 100%, so both address and txLimit are already documented with range, default and example. The description only restates the txLimit range and default, adding no new semantic meaning (e.g. what a larger window costs or changes). Baseline 3 applies when 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 verb-and-resource pair: priced holdings plus windowed PnL for exactly one Solana wallet. It also enumerates the returned artifacts (USD valuation, summary, realized/unrealized PnL, win rate, labels, copyTradeScore), which lets an agent distinguish it from wallet_preview and wallet_quick 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?

Explicit routing: use free wallet_preview first if only SOL balance and last-active time are needed, or wallet_quick for a cheaper copy-trade screen. That is a direct when-to-use-this vs when-to-use-a-sibling statement naming both 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?

Goes far beyond the readOnlyHint/openWorldHint annotations: exact price ($0.002 USDC / 2000 base units), the x402 payment flow, that unpaid HTTP calls return 402 even for invalid queries, that signed calls with invalid arguments are rejected before settlement and not charged, and that charging only occurs on non-error results. It also discloses cache behavior — cached, stale, and cacheAgeMs — and explains that stale=true means a prior result was served during refresh or upstream failure.

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 correctly, but the payment portion repeats itself: the price is stated, then restated for HTTP GET, then the no-charge-on-error rule is stated twice in different words. The trailing bracketed vendor/payment boilerplate duplicates information already given earlier in the prose, diluting a description that would be stronger at two-thirds the length.

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

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

No output schema exists, and the description compensates by enumerating the returned fields, the scoring components, and the cached/stale/cacheAgeMs envelope semantics. Combined with the full payment and caching disclosure, 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?

The single address parameter is fully documented in the schema (base58, 32-44 chars, with a worked example), so the schema carries the weight. The description adds nothing about the address itself, which is acceptable but yields only the baseline score at 100% coverage.

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

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

States a specific verb and resource ('cheap copy-trade screen for one wallet') and enumerates exactly what comes back: windowed realized PnL, win rate, closed trades, bot/exchange flags, copyTradeScore and copyTradeGrade with its component math. It also distinguishes itself from the paid full report (/wallet/profile) and the free teaser (/wallet/preview), so an agent can separate it from wallet_profile and wallet_preview 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?

'Use this for a cheap copy-trade screen before paying for a full profile' gives an explicit selection rule, and the two endpoint pointers make the alternative tiers concrete (free preview vs. full paid profile). When-not guidance is implied strongly enough by the cost ladder that an agent knows to reach for this instead of wallet_profile when price matters.

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?

Discloses cost and unit (15000 base units), the 402 on unpaid calls even with invalid queries, that invalid signed args are rejected before settlement and not charged, that billing occurs only on non-error results, and explains the cached/stale/cacheAgeMs semantics including what stale=true means. Far beyond the readOnlyHint/openWorldHint annotations, and fully consistent with them.

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?

Core behavior is front-loaded, but the bracketed tail block repeats the $0.015 USDC / x402 payment facts already stated two sentences earlier, and the GET /wallet/quick/batch pricing note is tangential to invoking this tool. Roughly a third of the text 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?

No output schema exists, so the description carries the return contract by enumerating the fields (PnL, win rate, score/grade, bot/exchange, net-winner and dormant flags) and the cache metadata. Payment failure modes and validation behavior are also covered, leaving nothing an agent needs 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 coverage is 100% and the description's 'Pass addresses comma-separated' merely restates the schema's '1 to 10 comma-separated base58 Solana wallet addresses'. No added detail on base58 format or what happens at 11 addresses. 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 (quick screen), specific resource (Solana wallets, up to 10, batched), the exact metric set returned, the ranking key (realized PnL), and the price. The word 'batch' plus the 'up to 10' cap cleanly separates it from sibling wallet_quick/wallet_profile.

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

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

Gives concrete invocation guidance: 'Pass addresses comma-separated', 1-10 limit, and the payment precondition via x402. It does not name a sibling as the alternative for single-wallet or profile lookups, so routing is implied rather than explicit.

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