SingIt x402

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds information the annotations cannot: the call is free and requires an API key, which is a genuine auth and cost disclosure. It stops short of 5 by not saying whether held funds are reserved for in-flight jobs or how stale the figures are.

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

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

Two sentences with no filler, and the payload description is front-loaded before the usage note. Every clause carries distinct information: contents, timing of use, and cost/auth. Nothing repeats the title 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 describing returns and does so by naming the balance components. With no parameters, annotations covering safety, and the auth/free note, an agent has what it needs to call this correctly. It would be a 5 if it described the response shape, such as units and how held versus available are reported.

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 no parameters, so the schema has nothing to document and there is no semantic gap for the description to fill. The baseline for a zero-parameter tool is 4. The description correctly implies the balance is implicitly scoped to the authenticated key rather than requiring an account identifier.

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 the specific resource (the caller's SingIt API balance) and enumerates what it contains: available and held USDC, auto top-up, pending top-ups. That is concrete enough to distinguish it from every listed sibling, none of which touch account funds. It falls short of a 5 only because the leading phrase is a noun clause rather than an explicit verb+resource statement.

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

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

"Use to check funds before paid calls" gives a clear, actionable trigger tied to a real workflow. There are no competing siblings for this capability, so the absence of explicit when-not guidance or named alternatives costs little. A 5 would require stating preconditions such as what happens when the balance is insufficient.

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 read-only, open-world, non-destructive, and non-idempotent behavior. The description adds valuable operational context beyond annotations, including per-call cost from SingIt limits in USDC and the Base-only account restriction.

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 appropriately sized and front-loads the core purpose, use case, and key operational constraints. Every sentence contributes useful information with no 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?

For a no-parameter, read-only news tool with rich annotations, the description covers what it returns, when to use it, and the critical cost/account constraints. Nothing essential for correct invocation is missing.

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

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

The tool has zero parameters and the schema coverage is 100%, which sets the baseline at 4. The description reinforces this by stating it 'takes no input,' leaving no ambiguity about invocation.

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

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

The description states a specific resource and output content: crypto market headlines with sentiment from Otto AI. It clearly distinguishes the tool from siblings like get_price or web_search by emphasizing news and sentiment, but it does not explicitly name alternatives or exclusions.

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

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

It gives a clear use case: 'Use to see what is moving the market today,' and notes that the tool takes no input. It lacks explicit when-not guidance or named alternatives, so it falls short of 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?

Annotations already declare readOnly/openWorld/idempotent=false, but the description goes further by disclosing billing behavior (charged per call in USDC from the key's SingIt limits) and an account restriction (Base accounts only), which are not derivable from the structured fields.

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

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

Two tight sentences: capability and returned fields come first, then usage and cost constraints. No sentence is filler, and the most decision-relevant alternative is front-loaded.

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

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

For a single-param read tool there is no output schema, yet the description compensates by listing the returned datasets, the alternative tool, the billing model, and the account restriction. An agent has everything needed to decide and invoke correctly.

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

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

Only one parameter, and the schema already covers it at 100% with the example ticker formats (BTC, ETH, SOL). The description does not add format or validation detail beyond the schema, 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?

It names the specific resource ('funding rates for one symbol across exchanges') and enumerates the bundled data (open interest, long/short ratio, large positions, liquidations), so the agent knows exactly what it gets back and how this differs from get_hyperliquid_market.

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 use case ('compare venues or gauge positioning') and gives an explicit alternative routing rule ('use get_hyperliquid_market for one Hyperliquid contract'), and adds the prerequisite that this is paid per call from SingIt limits in USDC, Base accounts only.

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, destructiveHint=false and openWorldHint=true; the description adds genuinely new context the annotations cannot convey: per-call USDC billing drawn from the key's SingIt limits, and Base-only account eligibility. It does not cover failure behavior (e.g. unknown ticker) or why idempotentHint is false for a market-data read, which keeps it short of a 5.

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

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

Three tight sentences: what it returns first, then sibling routing, then billing/eligibility caveats. Every clause carries information an agent needs and none is redundant.

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

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

With no output schema, the description compensates by listing the returned fields, and it covers cost and account eligibility. Minor gaps remain (unknown-asset behavior, whether values are live or snapshot), but for a one-parameter read tool it is nearly complete.

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

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

The single parameter has 100% schema description coverage with its own examples (BTC, ETH, SOL), so the schema already does the work. The description's 'e.g. BTC' restates that without adding format, casing, or error semantics, 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?

Names a specific resource (a single Hyperliquid perpetual market) and enumerates what it returns: price, funding, open interest, max leverage, and size rules. It explicitly distinguishes itself from get_funding_rates, so an agent can route correctly 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?

States the use case ('Hyperliquid's own contract details') and names the alternative plus the condition that selects it ('use get_funding_rates to compare venues'). It also flags the eligibility constraint ('Base accounts only for now'), leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real context by naming the pricing source (Chainlink oracle on Base) and stating 'Free, no key needed', which removes an auth question the agent would otherwise have to guess at. It omits freshness/staleness and rate-limit behavior, which matters for price data, keeping it at a 4.

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

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

Two sentences, front-loaded with the resource and its scope, followed by routing and cost information. Every clause carries decision-relevant content and 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?

Covers what it returns conceptually, which sibling to fall back on, and the auth/cost model, which is enough for a 4-parameter read-only lookup with a fully documented schema. The one remaining gap is that callers can't tell what the response looks like (quote plus timestamp? single value?) since there is no output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the kind-to-parameter mapping that the schema only implies: tickers ('crypto/metal') versus a currency pair ('exchange rate between two currencies'), which tells the agent that fx uses base/quote while crypto/metal use symbol. Concrete examples of tickers appear in the schema, not duplicated here, so no waste.

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 ('Current price of a major cryptocurrency, gold or silver ... or an exchange rate') and bounds the scope to well-known assets and two named data families (Chainlink on Base, fx pairs). The qualifiers 'major' and 'well-known assets' implicitly separate it from get_token_price's long-tail coverage, and the pointer to list_price_symbols distinguishes it from the symbol-discovery sibling.

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

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

'Use for quick quotes of well-known assets' gives a positive usage condition, and 'call list_price_symbols when unsure a symbol is covered' names an alternative with the condition that selects it. It stops short of saying when NOT to use it (e.g. obscure tokens where get_token_price is the right sibling), so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered; the description adds genuinely new operational context: payment is charged per call against the key's SingIt limits in USDC, and only Base accounts are supported right now. Those cost and network constraints are exactly what an agent needs before spending. It does not mention rate limits or latency, and the non-idempotent hint is never reconciled with the 'fixed sample' nature of the call.

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

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

Three short sentences, each carrying distinct information: what it is, that it is a demo, and what it costs / where it works. No filler and the identity statement is front-loaded.

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

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

With no output schema, the description should say something about what comes back; it only implies a 'risk check' result without describing shape or content. Everything else an agent needs to invoke it correctly — no inputs, per-call cost, Base-only — is present.

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

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

The tool takes zero parameters and the description says so explicitly ('no input'), which is the correct treatment for a parameterless tool. Nothing more is required on this dimension.

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 operation (SingIt risk check), the platform it runs on (Bankr x402 Cloud), and the fixed sample payment request it operates on, plus explicitly notes it takes no input. That is enough to distinguish it from every sibling (prices, balances, ENS, web search). It stops short of a 5 because 'risk check' itself is never defined — the agent learns it is a demo call but not what kind of risk is being assessed.

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?

'Mainly useful to try a paid call end to end' is explicit usage guidance that frames this as a smoke-test/demo tool rather than a production risk API. It gives clear context for selection, but offers no explicit 'do not use for real risk assessment' exclusion or an alternative sibling to use instead, so it misses the top 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered; the description adds genuinely new behavior: per-call cost drawn from the key's USDC limits and a platform restriction (Base accounts only), which is exactly the kind of thing an agent cannot infer from annotations. It does not explain why idempotentHint=false (live price movement) or what happens on an unsupported symbol, leaving a small gap.

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

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

Three dense sentences, front-loaded with what the tool returns and followed immediately by the alternative and cost constraints — no filler. The clipped phrasing ('SingIt limits') and acronyms without expansion cost it a little legibility.

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?

Covers source, cost, alternative, and account restriction, and 'USD price' implicitly describes the return since no output schema exists. It omits how symbol validation relates to the available list_price_symbols sibling and what an unsupported symbol or exhausted limits yields.

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

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

Only one parameter with 100% schema description coverage including examples (ETH, BTC, SOL), so the schema already does the work. The description restates that lookup is 'by symbol' but adds no format or validation detail beyond it; 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 and resource (USD price of a major token by symbol) plus the underlying source (paid x402 price API), and explicitly distinguishes itself from the sibling get_price. An agent can tell the two apart 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 routing logic: get_price is free and covers the same majors, so prefer it, and this tool is a second source. It also names the precondition that constrains use — paid per call from the key's SingIt limits in USDC, Base accounts only.

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 read-only and open-world, and the description goes well beyond them by disclosing the cost model (paid per call in USDC, drawn from the key's SingIt limits) and an account restriction (Base accounts only). It also warns that the payload is a fixed stub, which prevents an agent from treating the output as live data.

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

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

Three short sentences, front-loaded with what the tool returns, then cost and account constraints. Nothing is repeated from the title or annotations, and every clause carries information an agent needs before calling.

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

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

With no parameters and no output schema, the description supplies everything relevant: nature of the return value (fixed example), payment mechanics, and account eligibility. Nothing material is left unresolved for a correct invocation.

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

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

The tool takes zero parameters, so the baseline is 4, and the description reinforces this by stating it takes no location. No further parameter explanation is needed or possible.

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

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

States a specific verb and resource (returns a sample weather forecast) plus its scope limits: no location input, fixed example data, demo service on Algorand. That instantly separates it from the price/crypto siblings, none of which return weather.

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

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

Explicitly says it is 'mainly useful to try a paid call end to end', which tells the agent the intended scenario. It stops short of naming a when-not or an alternative, though the 'fixed example, no location' note implies it should not be chosen for real weather data.

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

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

Annotations establish read-only, open-world, non-destructive behavior, and the description adds crucial operational context absent from annotations: paid per call, charged against SingIt limits in USDC, and limited to Base accounts for now. That materially informs an agent before invocation.

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

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

Three short sentences, front-loaded with the purpose, then use case, then cost/account caveat. No filler; each sentence contributes selection or invocation context.

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

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

For a simple one-parameter read tool with annotations covering safety, the description includes source, cost, and account restriction. It does not describe the profile fields returned, which would help an agent know what to expect since there is no output schema, so it falls just short of 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?

The single username parameter is fully described in the schema, including the 'without @' format. The description only restates lookup by username and adds no syntax or semantic 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 exactly what resource is returned (public profile data for an X/Twitter account), the lookup key (username), and the upstream API. It also frames the practical intent (check who is behind a handle), so an agent can distinguish it from unrelated price/news/search 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?

Gives a concrete use case: checking who is behind a handle. It does not spell out when not to use it or name alternatives, but among the listed siblings there is no competing profile-lookup tool, so the missing exclusion is minor.

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/idempotent/non-destructive, and the description adds genuinely new behavioral facts: the call is free, requires no API key, and the models themselves are not invoked through this server. It does not describe the response shape or price units (per token vs per image), which matters since there is no output schema.

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

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

Three short sentences, front-loaded with what the tool returns before the caveat about how to actually call the models. No filler and nothing repeated from the annotations or 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?

For a one-optional-parameter read-only lister with rich annotations and no output schema, the description supplies everything an agent needs: what is returned, that it costs nothing and needs no key, and the crucial fact that the returned models are called elsewhere.

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

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

Schema coverage is 100% and the single `kind` parameter already carries its enum and default ('Defaults to chat.'). The parenthetical '(chat, images or audio)' restates the enum rather than adding semantics, so the baseline 3 is appropriate.

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

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

The description names a concrete resource (the AI models available through SingIt, split into chat/images/audio) and what comes back with it (prices). The line about the OpenAI-compatible API endpoints and 'not through these MCP tools' cleanly separates it from every sibling, which are all price/weather/crypto/profile lookups.

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 context for use: this is the discovery step for model choice, and actual model invocation happens over HTTP at the stated endpoints rather than via MCP. That is a strong implicit when/when-not. It stops short of an explicit routing sentence (e.g. 'call this before choosing a model'), and no sibling is named as an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world hint, so the safety profile is covered. The description adds context annotations do not carry — that the call is free and requires no API key, removing a common hesitation about making a preparatory lookup. It does not describe the shape of the returned list, but this is a trivial zero-arg enumeration.

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

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

Three short sentences, each doing distinct work: what it returns, when to call it, and cost/auth. The scoping statement comes first, so the agent gets the core fact immediately.

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

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

For a zero-argument lookup with no output schema, the description conveys the content of the result well enough to decide and call. Only minor gap is whether results are grouped by asset class or returned as a flat list, which the phrase 'every crypto, metal and currency symbol' only loosely implies.

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 no parameters and the schema is an empty object at 100% coverage, so there is nothing the description must compensate for. Baseline 4 applies; no parameter detail is missing or needed.

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

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

States a specific resource (the set of symbols get_price supports) and bounds it to crypto, metal and currency. An agent can instantly distinguish it from get_price and from unrelated siblings like get_token_price or list_models.

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

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

Explicitly says to call it before get_price when unsure a symbol is covered, which names both the trigger condition and the alternative tool. The implicit inverse (skip it when you already know the symbol) is clear from that framing.

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

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds meaningful context beyond them: per-call cost charged in USDC on Base or Solana from the key's SingIt limits, and the required 'search' scope. The 8000-character truncation limit also tells the agent to expect partial content on long pages.

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: the first gives the payload and size bound, the second gives the usage trigger. Cost and auth constraints are packed into one clause rather than a paragraph.

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

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

For a single-parameter read tool with no output schema, the description covers the return type, size limit, cost model, and required auth scope — everything an agent needs to decide and invoke correctly. Nothing material is missing.

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

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

Schema coverage is 100% and there is only one parameter ('url', documented as 'The http(s) page to read'), so the schema carries the semantics. The description adds no format hints beyond that. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('The readable text of one web page'), adds the return-size cap (8000 characters) and the backend provider (Exa). The opening sentence makes clear this is single-page extraction, distinct from the search siblings in the list.

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

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

'Use after web_search, or when you already have a URL' gives both entry conditions and implicitly routes the agent away from this tool when it has no URL yet. It doesn't state explicit exclusions (e.g., what to do when a page is JS-heavy or blocked), but the routing context is clear.

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

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

Annotations already declare readOnly, openWorld, non-idempotent and non-destructive. The description adds genuinely useful undisclosed context – call cost/billing source and account-type restriction – but says nothing about failure behavior for unresolvable names or network-specific quirks.

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

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

Two tight sentences, the core behavior and example first, the cost and eligibility constraints second. 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 two-param read tool with full schema coverage and no output schema, the description covers inputs, outputs (address or primary name), cost and platform limits. Only the error/empty-resolution case is left unstated.

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

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

Schema coverage is 100%, so both parameters and their semantics are already documented. The description's mention of name-in/address-in mirrors the schema's own 'input' description, so it adds little beyond the structured fields; 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 bidirectional verb+resource: turns an ENS name into an address or an address into its primary ENS name, with a concrete example (vitalik.eth). Nothing among the siblings overlaps, so differentiation is implicit and adequate.

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 context for use plus hard constraints: pay-per-call against SingIt limits in USDC and Base accounts only for now. It stops short of naming an alternative tool or a when-not condition, but no close sibling exists to route to.

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

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds genuinely new operational facts: per-call cost drawn from SingIt limits in USDC on Base or Solana, and a required "search" scope on the key. That is exactly the cost/auth context annotations cannot express; only the non-idempotent flag (results vary between calls) goes unremarked.

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: capability and return shape first, then usage routing, then cost and auth. No filler, and the most decision-relevant facts (what it returns, when to use, what it costs) 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?

With no output schema, the description correctly summarizes the return payload, and it covers cost, auth scope and the read_page follow-up. The only material gap is search-mode selection, which neither description nor schema addresses.

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 only 67% and the one enum parameter, `type` (auto/fast/neural/keyword), has no description in the schema and is never mentioned in the description — an agent has no basis for choosing a mode. `numResults` is only glossed as "defaults to a few" in the schema, with nothing added, so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource (searches the web via Exa) plus the return shape (titles, URLs, snippets), and names the sibling read_page as the follow-up for full pages. An agent can distinguish this from read_page or get_crypto_news without opening the schema.

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

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

"Use for current or niche information, then read_page for a full page" gives an explicit when-to and routes to the alternative. It stops short of stating exclusions (e.g. not for structured/known facts or non-public data), so it is clear context rather than a full when/when-not rule set.

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