Elytrack

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

Annotations already declare readOnly/openWorld/idempotent, and the description correctly aligns with them by framing this as constructing an unsigned transaction rather than submitting one. Beyond that it adds real context: the Elytrack fee is taken out of amount_hype inside the same transaction, the fee percentage appears in the answer, and Elytrack holds no keys. It stops short of describing error conditions or what happens near the slippage bound.

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

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

Three tight sentences with the core action front-loaded and fee mechanics appended. No filler, though the fee sentence is dense enough that it may be skimmed on a first pass.

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 reasonably: quote, minimum acceptable amount, and the fee percentage shown in the answer. For a single-transaction builder with four flat parameters this is close to sufficient, missing only failure modes and chain context.

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

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

Schema coverage is 50%, and the description compensates by tying amount_hype to the fee calculation ('elytrack_fee_pct of amount_hype') and by explaining that the slippage-driven output is 'the minimum you will accept'. token and wallet are left to their patterns, which are self-explanatory address formats.

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 — 'Build a Montra buy (HYPE -> token) for your wallet' — and immediately scopes the output as a single unsigned transaction with nonce, fees and gas filled. The parenthetical direction (HYPE -> token) makes it distinguishable from the sibling build_sell_tx 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?

Usage is implied rather than stated: 'Sign it yourself' signals this is a preparation step feeding a later signing/submission step, but no sibling (build_sell_tx, send_signed_tx) is named and no when-not condition is given. An agent must infer the workflow ordering.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint; the description adds the crucial behavioural fact that this tool only constructs transactions and never broadcasts, plus the conditional approve and the ordering requirement — exactly the context an agent needs to avoid treating it as an executor. It stops short of disclosing quote freshness/expiry, that slippage defaults to 3%, or what the returned objects look 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?

Two sentences, no filler, and the most important facts — direction and the fact that the caller signs and sends — are front-loaded. Nothing is repeated from the schema or annotations.

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 carries the burden of explaining what comes back, and it only gestures at 'them' requiring signature and ordering. For a four-parameter builder with a conditional step, an agent would benefit from knowing the return shape, whether an approve entry is always index 0, and how stale quotes are handled.

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

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

Schema coverage is 50%: amount (including the 'all' sentinel) and slippage_pct ('percent') are documented in the schema, while token and wallet carry only address patterns. The description adds real meaning by fixing the direction of the trade (token is what is sold, wallet is the seller) and by implying token must be an allowance-bearing ERC-20, but it does not explain slippage behaviour or 'all' resolution.

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 and resource: builds a Montra sale transaction, with the exact direction stated (token -> HYPE) and the internal composition (conditional router approve, then the swap). The word 'sale' plus the direction cleanly separates it from build_buy_tx without the agent needing to open 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?

It gives clear workflow context: the output is unsigned, the caller must sign and send in order, and an approve appears only when needed. What is missing is naming the follow-up siblings (send_signed_tx, get_tx_status) and any exclusion, e.g. that this is not the tool to use if the wallet already holds an allowance or if the caller wants a buy.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds behavior the annotations do not: results are ordered newest first, and after_id gives incremental delivery. It omits rate-limit or payload-size behavior, so 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?

Two sentences with no waste: the content list comes first, then the polling instruction. Every clause carries information, so nothing needs trimming.

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

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

The tool is simple and read-only, and the polling model is conveyed, but it has no output schema and the description does not describe the returned item shape, including the id field that after_id depends on. An agent still has to infer what a feed entry looks like.

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 has to carry the load. It explains after_id well (largest id you have, returns only newer entries), but it never explains the group enum values, leaving 'bots' unmentioned, and says nothing about limit beyond the default that the schema already supplies.

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

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

The description names a concrete resource (live alerts) and enumerates the event types included: insider and smart buys and sells, launches, bundle and dev sells, and clusters. That is far more specific than a restatement of the title 'Live feed'. It does not, however, distinguish itself from siblings that overlap in coverage (get_news, get_launches), 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?

It gives one concrete usage instruction: pass after_id with the largest id you have, to fetch only new entries. This implies polling, but the description never says when to use this feed versus get_news or get_launches, and it gives no guidance on how to choose a group or limit.

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 readOnly and openWorld behavior, and the description adds useful context about what the tool returns: launches with dev bundle, insiders' share, snipers, and smart buys. It also explains the default filtering behavior of signals_only, though it omits ordering, pagination, and what happens when signals_only is false.

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 subject of recent launches and their signal categories. It is efficient, with no obvious filler, though the term 'insiders' share' could be clearer without additional 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?

The description covers the core purpose and the default signals_only filter, which is the most important behavioral detail. However, it leaves the other optional parameters and the shape of returned launch data unexplained, and there is no output schema to fill those gaps.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It explains signals_only and its default, but it does not explain limit or min_insider_pct, leaving two of three parameters without meaningful 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?

The description clearly states the resource: recent launches across launchpads, with signal categories such as dev bundle, insiders' share, snipers, and smart buys. It distinguishes this from sibling tools like get_launchpads by focusing on launches rather than launchpad metadata, though it does not explicitly use a verb like list or get.

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

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

The description implies usage for recent launches with signals and explains the default signals_only behavior, including the 24-hour window. However, it does not explicitly say when to use this tool instead of get_feed, get_launchpads, or search_tokens, nor does it state when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile is covered. The description adds valuable scope by enumerating the returned metric set — important because there is no output schema — but it says nothing about freshness, caching, rate limits, or whether the payload is a flat table or nested per-launchpad structure.

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

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

A single front-loaded sentence that leads with the resource and comparison framing, then lists the metrics. It is dense but every listed metric earns its place given there is no output schema to carry the return-value 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 zero-parameter, no-output-schema read tool, the description discloses the full metric surface an agent needs to decide relevance. The only gaps are response shape and data freshness, which are secondary for tool selection.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies a global, unfiltered comparison.

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 ('Every Elysium launchpad') and the exact dimensions being compared (24h volume, trades, launches today/this week, token counts, dev-bundled share, top tokens), so the agent knows precisely what data comes back. It stops short of naming how it differs from the sibling get_launches, leaving the launchpad-vs-individual-launch distinction 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?

The word 'compared' and the enumerated cross-launchpad metrics imply the use case (benchmarking or ranking launchpads), but there is no explicit when-to-use, when-not-to-use, or pointer to get_launches/get_token for narrower queries. Usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered. The description adds that content is derived from on-chain events and which event classes appear, but says nothing about freshness, ordering, or how the default limit shapes the response.

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 front-loaded sentence with no filler. The category list is long but each item carries real discriminating information about what news types appear.

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, one-optional-param tool with annotations covering safety and no output schema, this is close to sufficient. Missing are ordering/freshness expectations and any hint that `limit` bounds the number of news items 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?

The single optional `limit` parameter has full schema constraints (default 20, min 1, max 50) but zero textual description coverage, and the description never mentions it. Schema constraints carry the meaning adequately, so baseline 3 applies with no added semantics from 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+resource ('Chain news from on-chain events') and enumerates the exact content categories returned: market cap milestones, launchpads, insider clusters, dev sells, bundled launches, daily recap. That enumeration distinguishes it from generic siblings like get_feed or get_launches, 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?

The description gives no when-to-use or when-not-to-use guidance and does not contrast this tool with get_feed or get_launches, which plausibly overlap. An agent must infer from context alone which of these feeds is appropriate.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description goes beyond them by defining what counts as a 'smart wallet' (early 2x track record) and an 'insider' (linked to a dev), and by disclosing that results include how many wallets still hold and the move since the first smart buy — meaningful behavioral context not present in the annotations.

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

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

It is a single dense sentence with zero filler and the core notion (tokens bought by smart wallets) is front-loaded. The two parenthetical glosses on 'smart wallets' and 'insiders' add value, though the nested clauses make it read as a run-on.

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 usefully sketches what comes back, but for a five-parameter tool with 20% schema coverage it omits how limit, min_wallets, and sort actually change results. An agent can call it with defaults but cannot confidently tune it.

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

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

Schema description coverage is only 20% across five parameters, so the description needs to compensate and largely does not. It touches only the window ('within a window') and the default ordering ('most wallets first'), leaving limit, min_wallets, the sort enum values, and montra_only undocumented in either place except the one inline schema description.

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

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

The description names a specific resource (tokens) and a specific filter (bought by smart wallets and insiders within a window), plus the return content (holder counts and move since first smart buy). That makes it clearly distinguishable from list-style siblings such as get_feed or get_top_wallets, 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?

There is no explicit when-to-use or when-not-to-use guidance and no pointer to alternative siblings like search_tokens or get_launches. Use is only inferable from the data it returns (smart-money discovery), which leaves the agent to guess at 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description's real contribution is disclosing the content of the payload (market metrics, holder/insider labeling, dev bundle and sniper flags, bots excluded). It does not address error behavior for a non-token or non-existent address, which is the main remaining behavioral unknown.

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 dense sentence, front-loaded with the scope and then the payload contents; nothing is wasted. The nested parentheticals are slightly cramped but still parseable.

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 usefully substitutes as a return-value summary, which is a lot of the needed work. But for a one-argument lookup it omits the meaning of that argument and any guidance for invalid or unknown addresses, so it is not fully self-sufficient.

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% for the single required parameter, and the description never mentions it. The 0x{40} pattern implies an EVM address, but the description leaves genuinely ambiguous whether that address is a token contract or a pool/pair address — a distinction that materially changes the 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?

"One token:" plus an enumeration of the data returned (market, smart wallets/insiders, launch quality, earliest wallets) makes it clear this is a single-token deep-dive, distinguishable from list-oriented siblings like get_launches and search_tokens. It never states the verb or the resource name explicitly, but the intent is unambiguous.

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

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

No when-to-use guidance and no alternatives named. The agent must infer that this is the single-address lookup versus search_tokens for discovery, and nothing tells it what to do if it only has a symbol or name rather than an address.

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 this as a read-only, open-world operation. The description adds some behavioral context by indicating that smart wallets are ranked by skill and insiders by evidence, but it does not explain ranking mechanics, result ordering, limits, or what the returned wallet entries contain.

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 very short and front-loaded, with no unnecessary wording. However, its fragment-like structure is under-specified rather than efficiently concise.

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

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

With no output schema, three undocumented parameters, and 0% schema description coverage, the description is too thin to fully prepare an agent to invoke the tool correctly. It should clarify sorting, limits, the scam view, and the shape or meaning of ranked 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 0%, so the description should compensate, but it only partially maps the view enum values and omits the 'scam' view entirely. It also does not explain the sort options or the limit parameter, leaving most parameter meaning undocumented outside the raw enum and default values.

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

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

The description clearly identifies the resource as ranked wallets and distinguishes its main view categories, including smart, insiders, all, and sniper bots. It lacks an explicit verb like 'list' or 'retrieve', but an agent can still infer that it returns a ranked wallet collection rather than a single wallet.

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 the available view categories but does not state when to use this tool instead of siblings such as get_wallet. There is no guidance on whether it should be used for discovery, screening, or comparison, and no exclusions are provided.

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

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

The annotations already establish that this is a read-only, open-world operation. Beyond that, the description adds useful behavioral detail by listing the possible transaction states, including landed status with block and success information, which helps the agent interpret outcomes.

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 wording. It efficiently communicates the tool's purpose and the possible status values.

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 status lookup, the description covers the possible status outcomes reasonably well. However, it omits parameter semantics for hash and does not explain polling behavior or how unknown or invalid hashes are handled.

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

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

The input schema has only one parameter, hash, but its description coverage is 0%, so the schema does not explain the parameter's meaning beyond its name and regex pattern. The tool description does not mention the hash parameter or clarify that it is the transaction hash to look up.

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

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

The description clearly identifies the resource as a sent transaction and explains what is returned: its current status. It enumerates concrete states such as queued, posted, landed, and dropped, but it does not explicitly distinguish itself from sibling tools like send_signed_tx.

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 phrase "sent transaction," suggesting it should be called after sending a transaction. However, there is no explicit guidance on when to use this versus alternatives, when not to use it, or whether polling is expected.

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 useful scope (a fixed 7-day trade window, derived signals like skill and insider evidence), but says nothing about behavior for an unknown address, data freshness, or response shape beyond the field list.

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

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

A single short sentence with the key scope (one wallet, 7-day trades) front-loaded and no filler. It is terse to the point of being telegraphic, but nothing is wasted.

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 carry the return-value burden and lists the main categories returned, which is helpful. However, for a single-parameter lookup tool it omits any treatment of the required address input, error cases, or how the trade window is anchored, leaving real gaps.

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

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

Schema description coverage is 0% and the description never mentions the sole required 'address' parameter, so the agent gets no meaning beyond the schema's regex pattern. It does implicitly establish that only one wallet is fetched, which is the only semantic added.

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 fragment 'One wallet: skill, early calls, holding habits, insider evidence and its trades of the last 7 days' makes clear this is a single-wallet lookup returning analytics plus recent trades, which separates it from the list-style sibling get_top_wallets. It lacks an explicit verb, but the resource and scope 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?

There is no when-to-use guidance at all: nothing says when to call this versus get_top_wallets, get_feed, or get_token, nor any prerequisite such as needing a valid address first. The reader must infer usage from the name alone.

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 real behavioral detail beyond them: case-insensitive matching and market-cap-descending ordering, which an agent cannot infer from the schema. It says nothing about empty results, pagination behavior, or that the token universe is open-ended.

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 front-loaded sentence with no filler; the matching rule and sort order both earn their 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 small two-parameter search tool with no output schema, the definition covers the core matching contract adequately. It is incomplete on the limit parameter, on result-shape expectations (does it return names, addresses, or full token objects?), and on what an empty match looks like.

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 parameter meaning, and it only partly does: it clarifies that 'query' is a symbol prefix and is case-insensitive, but never explains 'limit' (default 10, max 20) or the 20-character query cap. Half the parameters remain undifferentiated from the raw schema types.

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 ('Find tokens') plus the matching rule ('by symbol prefix, case-insensitive') and result ordering ('largest market cap first'), which separates it from single-token lookup siblings like get_token. It does not explicitly name a sibling, so it stops short of a 5.

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

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

The phrase 'by symbol prefix' implies usage for partial/prefix lookups rather than exact lookups, which weakly routes agents away from get_token. There is no explicit when-to-use, when-not-to-use, or alternative named, so guidance is only implied.

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

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

Annotations already declare this is a non-read-only, open-world, non-destructive operation, so the bar is lower, and the description still adds real context: the rate limit of 10 per minute per client and the fact that the hash is returned. It omits that a broadcast is irreversible and what happens on rejection or duplicate submission, which matters for a mutating 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?

Two short sentences, front-loaded with the action, then return behavior, then the rate limit. No filler and nothing that could be cut without losing information.

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

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

For a single-parameter, no-output-schema tool this covers the essentials: what it does, that it returns a hash, how to verify the result, and the throughput ceiling. What is missing is failure semantics and the non-idempotent nature of resubmission, which an agent calling a broadcast endpoint would benefit from knowing.

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 one parameter and 100% schema description coverage, the schema already documents 'signed_tx' as a 0x-prefixed signed transaction. The description reinforces that the payload must already be signed but adds no encoding or size detail beyond the schema, so 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?

Uses a specific verb and resource ('Send a transaction you signed') and names the target network/RPC path, which separates it from the unsigned-building siblings build_buy_tx and build_sell_tx by implication of 'you signed'. It stops short of explicitly naming those siblings as prerequisites, 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?

It gives one clear follow-up route ('check it with get_tx_status'), which is genuinely useful sequencing guidance. However it never states the precondition that the transaction must first come from a builder tool, nor any when-not condition (e.g. don't resend an already-broadcast tx), leaving usage partly implied.

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