agent-tool-finder

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

No annotations are provided, so the description carries the transparency burden. It discloses the 30-day window and that the tool is 'Free,' but does not describe the output format or authentication requirements. The read-only nature is implied by 'Get' and the stats context but not explicitly stated.

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, front-loaded with the main verb and purpose. The second sentence provides a use case and cost note, both valuable. No wasted words.

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

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

For a zero-parameter, no-output-schema tool, the description covers the key information: what is measured, the time window, and a use case. It is complete for an AI agent to decide when to invoke it.

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

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

The tool has zero parameters, so schema coverage is effectively 100%. The description adds no parameter-specific semantics, but none are needed. Baseline 4 for zero parameters is appropriate.

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

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

The description uses the specific verb 'Get' and identifies the resource as 'the agent tool market' with concrete metrics (paid x402 endpoints, MCP servers, paying users, spend). This clearly distinguishes from the sibling find_agent_tools, which searches for individual tools.

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

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

Provides a clear use case: 'deciding whether a capability is well supplied before you build it yourself.' It does not explicitly mention alternatives or when not to use, but the context is clear and actionable.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It adds useful context about required authorization ('Bearer ck_live_… or X-Clink-Key') and cost ('Free'), but it does not describe the response format, error cases, or explicitly confirm this is a read-only operation beyond the word 'Check.'

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 sentence contains the verb, resource, scoping detail, auth mechanism, and cost. There is no filler, and the key facts are front-loaded.

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

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

For a zero-parameter, read-only balance check with no output schema, the description provides enough to invoke it correctly: what it returns conceptually, which key it applies to, and how to authenticate. It only omits formatting details of the returned balance, which is minor for this simplicity level.

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

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

The tool has zero parameters and schema coverage is effectively complete, so there is no parameter ambiguity. The description appropriately focuses on the non-schema details that matter for invocation: auth headers and cost.

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

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

The description states a specific verb ('Check'), a specific resource ('shop-credits balance'), and the scoping context ('for the key on this connection'). It also names the relevant auth headers, making the operation identifiable and distinct from buy_credits.

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

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

The description makes the intended use unambiguous: call this to check the shop-credits balance for the current key. It does not explicitly discuss exclusions or alternatives, but with no other balance-checking sibling and a zero-parameter interface, the context is clear enough.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the tool 'Searches 35,000+ agent-callable tools', is 'Free to use', and 'Returns what each tool does, how to call or install it, and what it costs'. However, it does not mention potential limitations, rate limits, or that it only searches (does not execute) the tools, leaving some behavioral ambiguity.

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 paragraph that opens with the core purpose and then provides supporting details. It is slightly long due to enumerating many use cases, but every sentence contributes useful information without fluff.

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

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

Given there is no output schema, the description appropriately explains what the tool returns (what each tool does, how to call/install, costs). It covers the main use cases, scope, and cost. It does not explicitly address the sibling tool or any limitations, but for a search tool of this complexity it is largely complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for the 'need' parameter with examples like 'historical lithium spodumene prices' but does not explain the meaning of each parameter in prose. It provides no additional semantic detail beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Find') and resource ('API, data source, or MCP server'). It also differentiates from the sibling tool agent_market_stats by focusing on discovery of external tools rather than market statistics.

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

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

The description gives explicit, concrete guidance on when to use the tool: 'Use it whenever you need outside data or a capability you lack' followed by numerous examples. It does not explicitly mention alternatives or exclusions (e.g., using agent_market_stats for stats), so it misses the full 'when-not-to' guidance.

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

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

With no annotations, the description carries the full burden and does so well: cost ($0.01/call), billing source (shop credits, existing key, top-ups paused), failure pricing (failed or empty call is free), input limits, and the no-OCR limitation. This is exactly the operational context an agent needs before spending credits.

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 dense sentence with no filler, front-loading the core action and then layering limits, flags, cost, and the no-OCR caveat. Every clause earns its place.

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

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

For a one-parameter, no-output-schema tool, the description still discloses return shape (page count, likely_scanned flag), cost model, and failure behavior. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% for the single 'url' parameter, and the schema already specifies it must be a public http(s) URL of a PDF. The description reinforces 'public PDF' but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Convert a public PDF to plain text') and immediately scopes the result ('full extracted text in one call'). It is unambiguous and clearly distinct from every sibling tool, none of which touch PDFs.

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

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

Gives clear usage conditions: input must be a public PDF, text-based only, no OCR, with explicit size ceilings (25MB / 500k chars). It does not name alternatives, but no sibling tool overlaps this capability, so the routing gap is minimal.

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

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

With no annotations, the description carries the behavioral burden well: it discloses that clink reads requests same day, buildable asks ship as pay-per-call x402 endpoints usually within a week, and it returns a request id and status URL. It also explains the notify option and the decline path.

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

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

Four sentences, front-loaded with purpose and usage, then process and return details. Every sentence adds information with no filler.

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

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

Complete for a request-submission tool: it covers when to use it, what happens after submission, expected turnaround, return values, and notification. No output schema exists, but the return shape is described sufficiently.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters. The description only reiterates the notify parameter and adds no extra meaning for want or budget_usd, making the baseline 3 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: ask clink's shop to BUILD a tool or data source that nobody sells yet. It explicitly differentiates from find_agent_tools by saying to use it right after that sibling comes back unsatisfied.

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 precise condition: use this right after find_agent_tools comes back unsatisfied. It names the alternative and leaves no ambiguity about when this tool 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?

With no annotations, the description carries the burden and does well: it discloses cost ($0.01/call from shop credits), the billing caveat that new top-ups are paused, and that failed/empty calls are free. It also states the data source and a facts-only disclaimer. It doesn't cover rate limits or explicitly confirm auth requirements beyond the credits key, leaving minor gaps.

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

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

Front-loaded with the core purpose, followed by return fields, source, disclaimer, and cost. Slightly long, but each clause (billing model, failure semantics, disclaimer) carries real decision value rather than filler.

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

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

No output schema exists, so the description usefully enumerates return fields and totals, and with no annotations it also supplies cost, source, and failure behavior. It is nearly complete for a 3-param read tool; only auth specifics and rate behavior are unstated.

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

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

Schema description coverage is 100%, so the schema already documents ticker, days (1-365, default 90), and limit (1-25, default 25). The description only references 'the window' and 'one US stock ticker', adding no format or constraint detail beyond the schema. Baseline 3 is appropriate 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+resource: SEC Form 4 insider trading for one US stock ticker. It enumerates the exact data returned (buys/sells/grants/gifts with name, role, date, code, shares, price, shares owned after, filing URL), so an agent knows precisely what it gets. No sibling tool covers insider transactions, so it is clearly distinct.

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 scope is explicit: one US ticker, over a configurable window, sourced from SEC EDGAR. It doesn't name an alternative or state when not to use it, but no sibling overlaps (ticker_brief, token_verdict, x_ticker_pulse are different data). Clear context without explicit exclusions.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: read same-day SLA, remediation on confirmed bugs, notification back to the caller, and no cost ('Free'). It omits auth requirements and what happens for edge kinds (e.g. refund), keeping it just short of a 5.

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

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

Two tight sentences, front-loaded with the core action and the sibling exclusion, followed by turnaround/resolution and cost. Every clause carries distinct, useful information with no filler.

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

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

For a feedback-submission tool with no output schema and no annotations, the description supplies purpose, routing, latency, outcome, and price. It stops short of covering auth prerequisites or the refund path, so it is strong but not fully exhaustive.

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 88%, so the schema already documents route, notify, wanted, receipt_id, request_url, tx_or_buyer, and what_happened. The description only gestures at the 'kind' values (bug, missing feature, wrong data, slow) and omits the enum's refund/other, adding little beyond the schema.

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

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

Names a specific verb (report) and resource (bug/missing feature/wrong data/slow call), scoping it to clink's shop. It actively distinguishes itself from the sibling request_agent_tool, so an agent can separate the two without opening either schema.

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

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

Gives explicit when-to-use ('for a call you already made') and when-not ('not a new capability request'), and names the alternative tool (request_agent_tool) for the excluded case. This is exactly the routing guidance an agent needs.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses per-section independent failure, the $0.04 cost and its source, that failed/empty calls are free, and the 'facts only' content disclaimer. It omits rate limits and return format specifics, but the failure and cost semantics are genuinely valuable.

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

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

Purpose and scope are front-loaded and every sentence carries information (sources, failure behavior, cost, disclaimer). It reads as a dense series of clauses rather than elegant prose, but nothing is padding.

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 must sketch the return, and it does so at section granularity plus partial-failure behavior. Combined with the pricing/failure notes, an agent has enough to invoke this correctly; only the exact response shape is unspecified.

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

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

Schema coverage is 100% with only one param (ticker, 'e.g. NVDA'), so baseline would be 3. The description adds a real constraint by scoping the ticker to US stocks, which the schema does not convey; that is more than a restatement.

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

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

States a specific deliverable (a bundled US stock ticker brief) and enumerates exactly what is aggregated: 24h X/Twitter activity, 90d SEC Form 4 insider activity, and the latest 8-K. 'One-call ... bundled' implicitly separates it from the single-source siblings (sec_insider, x_ticker_pulse), though it never names 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?

Gives useful context — cost per call, that empty/failed calls are free, and that credits come from an existing key with top-ups paused — but never states when to prefer this bundle over calling sec_insider or x_ticker_pulse separately. Usage is implied rather than delimited.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses pricing ($0.02), the billing source, that top-ups are paused, and that 404/503/failed/empty calls are free. Missing only rate-limit or latency notes.

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?

Dense but every clause carries return-field or cost information; the owner framing and chain list are front-loaded. It is a single long block, but there is little filler to cut.

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

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

With no output schema, the description compensates by enumerating the full return content (top-10 detail, concentration label, creator share, LP %, buyers) and the error/free cases. An agent knows what to expect without a 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 both parameters are documented in the schema, so baseline is 3. The description adds only light context (default base, chain list) that largely duplicates the schema's chain enumeration.

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

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

Opens with a specific framing 'Who owns a token' and enumerates exactly what is returned (holders, share, concentration label, creator wallet, LP locked, first buyers). This distinguishes it clearly from siblings like token_whales and token_smart_money 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?

It lists supported chains and explains cost/failure semantics, which indirectly signals when it applies, but it never states when to prefer this over token_whales or token_smart_money. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full burden and does so: it discloses pricing ($0.02/call from shop credits, top-ups paused), that failed or empty calls are free, the 404 behavior below the follower floor, and the strong vs. weak (exact address vs. cashtag) match semantics — exactly the behavioral context an agent needs before spending credits.

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 dense paragraph that front-loads what you get back before cost and failure semantics; every clause carries information, though the list of return fields is slightly run-on and cost/credit terms could be separated for scannability.

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

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

With no output schema and no annotations, the description fully compensates: it enumerates the response fields (handle, followers, verified, post count, first_call_at, kol_count, total_reach, buzz label, price change), lists supported chains, and explains cost and empty-result 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 100% with enums and defaults already documented, so the baseline is 3. The description adds only marginal semantics — the 8-chain scope and the existence of a follower floor — and says nothing about the 'window' parameter or how min_followers interacts with the 404 rule.

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

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

The description opens with a specific verb+resource framing ('send a token contract, get the big X/Twitter accounts posting about it, ranked by followers') and enumerates the returned fields, so an agent can distinguish it from siblings like token_smart_money, token_holders, or x_search without opening the schema.

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

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

It implies the usage context (token-level X/Twitter KOL buzz for a given contract) and states the empty-result condition, but it never names an alternative tool or says when to prefer token_smart_money / x_search / token_verdict over 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?

With no annotations provided, the description carries the full behavioral burden and does so: per-call pricing ($0.05 from shop credits, top-ups paused), free on failure or empty result, and truthful 'checked:false, never guessed' semantics for unfinished checks. It also enumerates every scoring input (honeypot, taxes, mint, owner balance, proxy, LP lock, top-10 holders), which an agent can rely on when interpreting the verdict.

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

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

The purpose is front-loaded in the first clause and the dense enumeration of signals is packed into a single informative sentence. Slightly long and run-on, but nearly every clause adds decision-relevant information such as price, failure policy and the checked flag.

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

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

There is no output schema, so the description must describe the return shape, and it does: score 0-100, four verdict labels, and the accompanying metrics (liquidity, 24h volume, buys/sells, age) plus the checked flag. Nothing an agent needs in order to call this tool or 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 the schema already documents defaults and ranges, so the baseline is 3. The description adds real value by listing the legal chain values in context and framing what the liquidity and window filters select from (newest pools in a time window above a liquidity floor).

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

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

The description states a specific verb and resource: the newest DEX pools on a chain, each with a safety verdict. 'Newest pools' as a discovery surface is clearly distinguishable from sibling verdict tools such as token_verdict or token_verdict_batch, which operate on a given token.

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 supplies concrete operating context: default chain base, the eight supported chains, the 1h/6h/24h window, and the 404/free outcome when no pool qualifies. It stops short of naming an alternative tool or stating when not to call this one, so a 4 rather than a 5.

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

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

With no annotations at all, the description carries the whole burden and does so: it discloses the exact grading methodology (30-day realized PnL plus win rate), the output shape, the 404/free and 503/free error semantics, and a full cost model ($0.02 per call drawn from existing shop credits, new top-ups paused, failed or empty calls free). That is exceptional behavioral disclosure for an unannotated 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 dense sentences, zero filler, with the core output definition front-loaded and the cost/error clauses pushed to the end where they belong. Every clause carries information an agent would otherwise have to discover by calling.

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

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

There is no output schema, and the description compensates by enumerating the returned fields and their possible values, plus error and cost behavior. The one gap is that it never says whether the wallet list is paginated or whether fewer than 10 wallets can be returned, so an agent must discover result cardinality empirically.

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

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

Schema coverage is 100%, so the baseline is 3, and the description beats it by stating that only Base is supported even though the chain enum exposes eight chains — a constraint the schema actively misleads on. It also implies the window parameter drives the aggregation shown. It doesn't explain how 'window' interacts with the 30-day grading horizon, so not a 5.

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

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

The description names a specific resource (top-10 smart-money wallets on a token) and enumerates exactly what each entry contains: buys, sells, net, trades, a smart/profitable/mixed/losing grade, and a smart_lean verdict. That is far more than a restatement of the name. It stops short of 5 because the closely related siblings token_whales and token_holders are never named or contrasted, so the agent must infer the distinction.

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?

'Base only for now' is a real usage constraint, but there is no explicit statement of when to pick this over token_whales or token_holders, and no guidance on which window to choose. Usage is implied by the metric set rather than spelled out, which fits the 'minimum viable' band.

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

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

With zero annotations, the description carries the full behavioral burden and does well: $0.01 per call, billing source (clink shop credits, an existing key), free conditions for 404/503/failed/empty calls, and the eight supported chains. It falls short of a 5 by omitting rate limits, latency, and whether the credit charge is debited before or after the check completes.

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 value proposition and output payload are front-loaded in the first sentence, and every later sentence adds real signal (checks performed, chain count, failure billing, pricing). The one long comma-chained sentence listing metrics is dense but each item earns its place given the absent output schema.

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

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

There is no output schema, and the description compensates by enumerating the return shape (verdict enum, 0-100 score, risk level, red/green flags, summary, specific metrics, card, post counts). Combined with the checks performed, chain coverage, and billing rules, nothing material an agent needs before invoking it 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 parameters are already documented, including the chain enum and the default of 'base'. The description adds only the loose '8 chains' note, which the enum already conveys. Baseline 3 is appropriate 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 (send a token contract, get a safety verdict) and enumerates exactly what the verdict contains: score, risk level, flags, metrics, card. This is clearly distinguishable from siblings like token_holders (raw holder data) or token_verdict_batch (implied multi-token), so an agent can pick it without opening the schema.

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

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

Usage is implied by the pricing and failure semantics ('404/free if no source knows the token') rather than an explicit when-to-use rule. It never names the obvious alternatives (token_verdict_batch for multiple tokens, token_holders for raw data), so an agent must infer the routing. Cost preconditions ('paid from clink's shop credits, top-ups paused') are useful but not selection guidance.

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

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

With no annotations, the description carries the full burden and does so: cost ($0.10/call), billing source (clink shop credits via an existing key, top-ups paused), and the free conditions (404 no known token, 503 sources down, failed/empty call). It also enumerates every returned field so the agent knows the shape of the result.

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

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

Front-loads the core capability and output fields, then moves to chains and billing. One long clause-chain sentence is dense but every clause adds usable information; only the repeated address/chain enumeration slightly duplicates the schema.

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

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

No output schema exists, yet the description lists the exact return fields plus per-verdict counts and a not_found list. Combined with supported chains, the 25-token cap, and the cost/failure model, an agent has everything needed to call it and interpret results.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description restates the chain list and the 1-25 address limit but adds no format or edge-case detail beyond the schema, making baseline 3 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+resource (token safety verdicts) with explicit scope: batch of up to 25 tokens, one row per token. The output field enumeration (verdict, score, flags, liquidity, holders) makes the result unmistakable, and the batch framing separates it from the sibling token_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?

The batch limit and 'in one call' phrasing imply when to prefer this over the single-token sibling, and the chain default is stated clearly. It never explicitly names token_verdict as the alternative for single lookups, so the routing is left partly to inference.

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

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

With no annotations, the description carries the burden well: it discloses per-call pricing ($0.01 from shop credits), that failed or empty calls are free, the 404 and 503 free-failure semantics, and that new top-ups are paused. It stops short of stating rate limits, data freshness/latency, or what an empty response body 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?

Front-loaded with the payload (whale trades, newest first), then secondary aggregates, then chains, then cost/failure terms — a sensible information hierarchy. It is a single densely packed run-on paragraph, so scanning costs more than it should.

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, no-output-schema tool this covers most agent needs: return fields are enumerated (time, side, USD, token amount, price, wallet, tx, pool, dex), chains are listed, and pricing/failure modes are stated. Missing is any note on response shape for the aggregate sections or freshness of the trade feed.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including enums, defaults and ranges. The description adds the supported chain set and ties the 'no trade above the floor' behavior to min_usd, giving baseline-plus value.

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

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

Specifies the verb and resource precisely: latest whale buys/sells on a token address, plus net-buyer/net-seller wallets, flow totals and top pools. The density of enumerated outputs makes it functionally distinct from siblings like token_holders or token_smart_money, though it never names an alternative to contrast against.

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 use case (whale flow on a token) is implied clearly enough to infer, and the min_usd 'floor' note hints at how to tune sensitivity. But there is no explicit when-to-use statement, no exclusion against the many adjacent token_* tools, and no guidance on choosing a window or limit for a given analysis.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the 2,000-char cap, per-call price ($0.01), the credit source and that top-ups are paused, and that failed/empty calls are free. It also states the return shape. It stops short of rate limits or error-mode specifics, but this is strong unannotated 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?

Three tight sentences, front-loaded with purpose, limits, and cost. Every clause carries information (length cap, cost, failure pricing) with no filler.

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

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

Although no output schema exists, the description explicitly describes the return (detected source language plus full translation), covers cost and limits, and notes failure pricing. Only unusual error modes are left implicit, which is minor for a straightforward translation call.

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

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

Schema coverage is 100%, so the baseline is 3. The description restates the char limit and source auto-detection, which the schema already documents, and adds no format guidance for target_lang beyond what the schema's own example provides.

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

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

Specific verb (translate) plus resource (text) with scope stated up front: 2,000-char limit, any language pair, source auto-detection. None of the sibling tools overlap with translation, so the agent can position it immediately. The purpose is unmistakable.

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

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

There is no competing sibling for translation, so no alternatives need naming, but the description never explicitly states when to reach for it versus other routes (e.g. web_answer for quick lookups). Usage is implied by the character limit and cost note rather than stated.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses pricing ($0.02/call, from shop credits, top-ups paused), free conditions (404/empty, 503 chain-down, failed calls), and that results are 'facts only, not investment advice.' This is exactly the behavioral context an agent needs.

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

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

Front-loads the core purpose and packs billing/error behavior efficiently into one paragraph. It is dense but every clause about cost and failure modes earns its place; slightly overstuffed for a single sentence.

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

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

No output schema exists, yet the description enumerates the return payload (per-token in/out/net table, USD totals, swap count, top 5 counterparties) thoroughly. Complete enough for correct invocation, though the sibling differentiation gap remains.

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 days, limit, and address are already documented in the schema. The description only loosely reinforces a time window and the returned fields; it adds no syntax or format 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?

States a specific verb+resource: 'What a Base wallet bought, sold and moved lately' with concrete output fields. It reads as an activity feed and is distinguishable from wallet_pnl/wallet_verdict by content, but it never explicitly names or contrasts those siblings.

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

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

Usage is implied by the 'lately' activity framing and the mention of a time window, but there is no explicit when-to-use vs wallet_pnl or wallet_verdict, nor when-not guidance. The agent must infer the choice.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the $0.02 cost, that credits come from clink's existing shop key with top-ups paused, that failed/empty calls are free, and the exact meanings of 400, 404, and 503 responses. It also explains that 404 means no swaps in the window and 503 means the chain read is down, which materially affects invocation expectations.

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

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

The description front-loads the report-card contents and then covers pricing and error behavior, which is dense but relevant information for a paid tool. It is slightly long, but every sentence provides useful operational context rather than filler.

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

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

There is no output schema and no annotations, so the description must explain return contents and operational behavior; it does both by enumerating the report-card fields and covering cost, failure modes, and free-call behavior. Combined with a fully documented input schema, an agent has enough to call the tool correctly and interpret common responses.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema, including the enum for days and the address format. The description adds only broad context ('one Base wallet' and a 'window') without new syntax or format details, so the baseline of 3 is appropriate.

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

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

The description clearly identifies a single-wallet trader report card and enumerates the specific metrics returned (realized P&L, win rate, positions, top wins/losses, grade). It is not tautological, but it does not explicitly differentiate itself from similar siblings like wallet_verdict or wallet_activity.

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 by calling itself a 'trader report card for one Base wallet' and notes the address must not be a contract, but it never states when to use this tool versus wallet_verdict, wallet_activity, or other wallet tools. No explicit exclusions or alternative-routing 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?

With no annotations, the description carries full burden and does most of it: pricing ($0.02), the funding source (shop credits from an existing key, top-ups paused), and free outcomes for 404, 503, and failed/empty calls. It stops short of stating rate limits, latency, or whether results are cached, so not a 5.

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

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

The core capability is front-loaded in the opening clause, followed by tightly packed pricing and failure semantics. The long enumeration sentence is dense but each clause maps to a real returned field; minor cost is the volume of comma-separated items in one breath.

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

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

There is no output schema, so the description must describe the response — and it does, field by field, down to the trust score range and the deciding rule. Failure modes and billing outcomes are also covered, leaving no material gap for an agent deciding whether to call 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 coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description reinforces the address scope ('Base wallet') and implicitly explains why 'chain' is effectively fixed, but adds no format or validation detail beyond the schema.

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

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

States a specific question ('who is behind a Base wallet') and enumerates concrete outputs: entity kind, Basename, age, balances, first funder, flags, and a trust verdict with score. An agent can immediately distinguish it from wallet_activity or wallet_pnl, which return raw history/performance rather than an identity-and-risk judgment.

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 (due diligence / risk screening on an address) rather than stated, and no sibling is named as an alternative or exclusion. The cost and free-failure conditions do inform when a call is economically safe, which lifts it above 'no guidance'.

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

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

With no annotations, the description carries the full burden and does well: it discloses the pipeline, the returned artifacts (verbatim quotes, source URLs, confidence), the $0.03 cost drawn from existing credits, that new top-ups are paused, and that failed/empty calls are free. It omits latency, rate limits, and auth requirements, 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?

Front-loaded with the core capability and payoff, then cost and scoping details. It is dense but every clause carries information; only the parenthetical about paused top-ups is slightly off-topic for tool selection.

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 fills the gap by describing the return shape (quotes, URLs, confidence) and the failure/cost semantics. What remains missing is pricing/rate context beyond the per-call fee and any permission prerequisites, but for a one-shot answer tool this is close to complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters with format and bounds. The description restates the since format and the 5-domain cap but adds no syntax or behavior beyond what the schema provides, so the baseline 3 applies.

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

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

Names a specific verb (ask a question) and resource (cited web answer) and spells out the mechanism: live Exa neural search + page read + AI synthesis in one call. The 'Not a raw SERP' line cleanly separates it from a generic search tool, so an agent can place it immediately.

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 context of use (question in, short synthesized answer out) and the optional scoping levers (since:, up to 5 domains), and explicitly rules out the SERP-style use case. It stops short of naming an explicit alternative tool or when-not-to-use beyond 'not a raw SERP', so it is clear but not fully routing.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the per-call price ($0.05), the billing source (clink shop credits, an existing key), a usage constraint (new top-ups are paused), and failure semantics ('A failed or empty call is free'). It also describes what the paid output contains. This is rich, decision-relevant behavioral 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?

Front-loaded with the core value proposition and dense with information in a compact two-sentence block. The parenthetical about paused top-ups is slightly tangential but still billing-relevant, so it just misses a 5.

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

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

For a one-parameter tool with no output schema, the description covers purpose, query syntax source, cost, billing mechanics, and failure behavior, and enumerates the summary's contents. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema coverage is 100% for the single query parameter, so the baseline is 3. The description adds one useful cross-reference ('Same query syntax as x_search'), but provides no syntax or format detail beyond the schema example.

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 (X/Twitter trend digest) and explicitly differentiates it from the sibling x_search by adding 'live tweet search PLUS an AI-written summary: sentiment, key themes, driving accounts, notable posts.' An agent can distinguish it from x_search and x_ticker_pulse without opening any schema.

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

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

Gives clear selection context: it is a superset of x_search ('Same query syntax as x_search') and discloses the $0.05 cost, which lets an agent weigh it against the cheaper plain search. It stops short of an explicit when-to-use/when-not rule (e.g. 'prefer x_search when you only need raw tweets'), so not a full 5.

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

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

With no annotations, the description carries the full load and does well: it discloses pagination depth (up to 4 pages), enrichment scope (top 10-15), cost ($0.20), the credit/key dependency including paused top-ups, and that failed/empty calls are free. It stops short of stating the response shape or any rate limits, but the behavioral picture is unusually complete for an unannotated tool.

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

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

Purpose, mechanism, use cases, and cost are delivered in a compact front-loaded block with no filler sentences. The parenthetical about paused top-ups is directly actionable for the caller, so it earns its place.

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

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

There is no output schema, so the description must describe returns, and it does: clusters of enriched people with website/email/LinkedIn/GitHub data and a one-line match rationale. It does not describe the response structure or error behavior beyond 'a failed call is free', leaving a small gap for a multi-step 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 parameters are already documented, making 3 the baseline. The description adds a little context on enrichment volume ('top 10-15') but that slightly conflicts with the schema's 1-15 range and default of 10, and it adds nothing about query syntax beyond what the schema shows.

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

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

The description names a specific verb and resource ('deep lead finder') and explicitly spells out the pipeline it runs: search -> profile -> contact chain. It also differentiates itself from siblings like x_search and x_person by promising the whole chain in one call rather than a single step.

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

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

It gives concrete contexts for use (recruiting, B2B prospecting, cofounder/investor search) and pricing that informs whether to invoke it. It never explicitly names an alternative sibling tool it should be preferred over, so the routing decision is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost ($0.05/call), the billing source (clink shop credits via an existing key), that top-ups are paused, and that failed/empty calls are free. It also documents ordering and dedupe behavior. It does not cover rate limits or error semantics beyond the free-call rule.

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

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

Front-loaded with the core capability in sentence one, followed by the operational constraint and pricing. Every clause is informative, though the billing sentence is dense and could be tightened.

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 describing the return shape (combined tweets, dedupe, per-handle counts, cursor). Cost and auth context are included, making it largely sufficient for a 3-parameter tool, with only rate/error behavior unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: the 2-50 handle range (schema only shows comma/space-separated syntax) and the semantics of the since-cursor ('only-what's-new next time'). Only 'limit' is left to the schema, which already documents it fully.

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

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

States a concrete verb+resource: batch-fetch recent tweets for 2-50 handles in one call, with the output shape (combined, newest first, deduped, per-handle counts, since-cursor). The 'No from:-OR-splitting' note implicitly distinguishes it from hand-built multi-handle search queries, but no sibling tool is named, so differentiation is inferred rather than explicit.

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: use this for multi-handle watchlists rather than OR-splitting a query, and reuse the since-cursor for incremental fetches. However, it never says when to prefer x_person, x_search, or x_digest instead, and there are no stated exclusions beyond the from:-OR note.

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

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

With no annotations, the description carries the full burden and does well: it discloses the cost ($0.15), the billing source and its constraint (paid from existing clink shop credits, new top-ups paused), and that failed/empty calls are free — all decision-relevant behavior. It also honestly scopes the contact data as 'emails actually found on their site/bio', implying no fabrication. It does not state whether the lookup is live or cached, nor typical latency.

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 but front-loaded paragraph: purpose first, then return contents, then pricing. The long enumeration of card fields is justified because no output schema exists, and the cost/payment caveat is placed last where it belongs. Slightly overstuffed for a single sentence, but nearly every clause 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 paid external-call tool with no annotations and no output schema, the description supplies the two things that matter most: the shape of the return value and the billing/failure behavior. Gaps are minor — no rate limits, no statement on invalid or suspended handles, and no comparison to the adjacent x_profile/x_leads_deep tools.

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

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

There is a single required parameter with 100% schema description coverage, including an example ('naval'), so the schema fully documents it. The description adds no syntax or format detail beyond the schema, which is the expected baseline-3 outcome 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 — 'X/Twitter person lookup' — and then enumerates exactly what the returned card contains (name, role, company, contact routes, stats), so an agent knows precisely what it gets. It frames the audience ('lead/recruiting/sales agent'), which implicitly separates it from the raw x_profile sibling, but never names that sibling, so differentiation is inferred 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?

The mention of 'a lead/recruiting/sales agent' implies the intended use case and the $0.15-per-call / free-on-failure pricing gives a concrete decision input. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. x_profile for a cheap raw profile, x_leads_deep for bulk), leaving the agent to guess which X-person tool to pick.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the $0.01 per-call cost, the billing source, the paused top-up situation, and that failed or empty calls are free. It also lists the returned profile fields, though it does not cover rate limits or output structure in more detail.

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

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

The description is compact and front-loaded: the core lookup purpose comes first, followed by pricing and failure behavior. Every sentence adds useful information without repetition.

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 lookup with no output schema and no annotations, the description is nearly complete: it names the return fields, cost, billing source, and failed-call behavior. More detail on output format or rate limits would make it fully complete.

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

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

Schema description coverage is 100%, and the single username parameter is already documented with an example. The description reinforces that the input is one handle, but it adds no syntax or format details beyond the schema.

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

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

The description uses a specific verb and resource: profile lookup for one X/Twitter handle, and it lists the key fields returned. It is clear what the tool does, though it does not explicitly distinguish itself from potentially overlapping siblings such as x_person or x_search.

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

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

The phrase 'for one handle' implies this is a single-profile lookup rather than a search or batch tool, and the pricing note gives cost context. However, there is no explicit when-to-use guidance versus sibling tools like x_search, x_list, or x_person.

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

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses $0.02 cost per call, the credit source, that failed/empty calls are free, and the return shape (up to 20 newest tweets with author, likes, retweets, views, URL). It omits rate limits or auth requirements, keeping it short of a 5.

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

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

Front-loads purpose, then syntax, then output shape, then cost. Four dense clauses, each earning its place with no filler or repetition.

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 naming the return fields; cost and failure semantics are also covered. For a single-param search tool this is essentially complete.

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

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

With one parameter at 100% schema coverage the baseline is 3, but the description enumerates concrete advanced operators (from:user, "exact phrase", #hashtag, since:/until:, min_faves:, lang:) that meaningfully extend the schema's single terse example. Real added syntax value.

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

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

States a specific verb+resource: 'Live X/Twitter search'. The word 'Live' distinguishes it from the digest-style sibling x_digest, but it never names or contrasts with siblings like x_list, x_leads_deep, or x_digest explicitly. Clear purpose, weak sibling differentiation.

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

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

No explicit when-to-use or when-not, and no routing to alternatives among the many x_* siblings (x_digest, x_list, x_profile, x_person, x_leads_deep). Usage is only implied by 'search' plus the syntax examples, which help query construction but not tool selection.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the $0.02 per-call cost, that it is paid from clink's shop credits, that top-ups are currently paused, and that failed/empty calls are free. It also flags the 'facts only, not investment advice' framing, which matters for a finance tool. It stops short of 5 because return format details, rate limits, and auth requirements beyond the existing key are not covered.

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

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

Purpose is front-loaded, the content list uses a tight parenthetical enumeration, and the two trailing sentences (disclaimer, pricing) each carry distinct, non-redundant information. No filler; every sentence earns its place.

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

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

There is no output schema and no annotations, so the description must carry both — and it does reasonably well by enumerating the returned content and disclosing cost/billing behavior. What is missing is any note on data freshness/latency or how the ticker and window interact, but for a two-parameter read tool this is close to complete.

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

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

Schema description coverage is 100%, so both parameters (ticker, window) are already documented, including the 24h/7d enum. The description adds only marginal semantics — 'one US stock ticker' (a US-only constraint not in the schema) and 'vs the prior window'. Baseline 3 is appropriate 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 resource and scope: 'X/Twitter activity for one US stock ticker', and enumerates the returned content (post volume vs prior window, top posts, most active accounts, keyword flags). The verb is implicit (activity/aggregation) but the resource is unmistakable. It does not, however, distinguish itself from siblings like x_search or ticker_brief, 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?

Usage is only implied: the 'one US stock ticker' scope and the social-activity framing tell the agent roughly when this applies, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. x_search for broader X queries, ticker_brief for fundamentals). Adequate but leaves routing to inference.

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