Kairos Research

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description adds real value beyond them by stating 'FREE' (no cost to the caller) and disclosing that payment is a separate, paid step requiring a pay-to address and network. It does not mention rate limits, caching, or whether the catalog can change between calls, which would round out the picture.

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 cost signal 'FREE' and the ordering instruction last so it lands as the takeaway. Every clause names a distinct piece of returned content; nothing is redundant or padded.

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

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

With no output schema, the description carries the burden of describing return values, and it does so by enumerating the fields and the payment metadata. It is nearly complete for this tool's complexity, missing only the response container shape or whether the catalog is paginated.

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

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

The tool takes zero parameters, so the schema has nothing to explain and the baseline applies. The description correctly implies a parameterless global listing rather than a filtered query, though it never says so explicitly.

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 ('Lists the paid research products') and enumerates exactly what each entry carries (id, HTTP route, USD price, description). It also names the non-product payloads (pay-to address, network, credit packs, payment instructions), which no sibling tool (contract_check, market_summary, token_check, wallet_profile) covers, so an agent can separate it from the analytics siblings on the description alone.

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

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

'Call this first' gives explicit ordering guidance that no schema or annotation could convey, which is the key usage signal for a discovery step. It stops short of naming when-not-to-call or pointing to a follow-up tool, but for a zero-parameter read-only catalog 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?

Adds substantial context beyond the annotations: the $0.15 USDC-per-call cost, the Base chain scope, and the concrete fallback behavior of returning price and payment options instead of a report when credit_key is absent. It does not explain the readOnlyHint=false / idempotentHint=false pairing (payments are state-changing and each call bills again), nor mention rate limits or latency — worth noting but the billing model effectively conveys the non-idempotency.

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 decision-critical fact — that the call is paid — is front-loaded in the first token, followed by what is checked and then the payment mechanics. Two dense sentences with no filler or redundancy.

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

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

For a 2-parameter, no-output-schema tool it covers chain, cost, checks performed, and the unpaid-call behavior, which is enough to invoke correctly. The only gap is any hint of the report's shape or how failures (e.g., unverified source) surface in the response.

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 in structured form, including the credit_key fallback. The description's mention of credit_key largely restates the schema field, though 'instead of a report' usefully frames the outcome; the address parameter's Base-only constraint is left to the schema pattern and field description.

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

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

States a specific verb and resource ('Contract check on Base') and enumerates the exact checks performed: bytecode presence and size, Sourcify verification, EIP-1967 proxy/admin slots, implementation verification, plus a neutral analysis. That enumeration cleanly separates it from siblings like kairos_token_check and kairos_wallet_profile without needing to name them.

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

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

The payment path is spelled out clearly (pass credit_key to pay; omit it to get price/payment options), which is practical guidance for invocation. However, there is no explicit when-to-use statement relative to the sibling check tools — that contract addresses belong here while token or wallet addresses belong elsewhere is only implied by the resource name.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses the two facts an agent most needs: the tool is paid at $0.10 per call in USDC, and it is refreshed every 5 minutes. It also explains the auth mechanism (prepaid credit key) and the fallback response when auth is absent, which reconciles the non-read-only hint with what is otherwise a data-read tool.

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

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

Four sentences, front-loaded with the paid-cost warning, then the deliverable, then freshness, then the payment/auth branch. No filler, and the most decision-relevant fact (price) is placed first.

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 it does, enumerating top 15 assets, 24h/7d changes, global totals, and a neutral analysis, plus the alternative payment-options response. For a one-parameter, no-output-schema tool, nothing an agent needs 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% and the single parameter is already documented in the schema, so the baseline is 3. The description adds real meaning on top by spelling out the consequence of omitting credit_key — the call returns price and payment options rather than a report — which is a behavioral outcome the schema only hints at.

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: a crypto market summary of the top 15 assets by market cap with 24h/7d changes, global totals, and a neutral analysis. That scope is clearly distinct from siblings like kairos_token_check, kairos_contract_check, and kairos_wallet_profile, so an agent can route 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?

The description gives clear operational context for the two invocation modes: supply credit_key to pay from a prepaid key, or omit it and receive pricing and payment options instead of a report. It does not explicitly state when to prefer this over the sibling tools or note exclusions, but the narrow purpose makes the choice mostly self-evident.

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

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

With annotations only saying readOnly=false, openWorld=true, idempotent=false, destructive=false, the description adds real substance: an explicit $0.25 USDC price, a prepaid-key payment path, and the non-obvious fallback where an unpaid call returns pricing instead of an error or a report. It stops short of covering failure/refund behavior or rate limits, but the payment semantics are the key trait and they are disclosed.

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

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

The cost warning is front-loaded in caps, which is the right call for a paid tool, and the whole definition is two dense sentences with no filler. The list of check categories is slightly compressed but each item earns its place as scope 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 two-parameter tool with no output schema, the description carries the burden of describing the return value and does so at a reasonable level — it names the check categories and the neutral analysis, plus the alternate pricing response. It would be stronger with a note on how flags are summarized, but nothing essential to 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?

Schema description coverage is 100%, so both address and credit_key are already documented in structured fields. The description reinforces the credit_key payment behavior but adds no new format, sourcing, or constraint detail beyond what the schema states, 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?

The description names a specific verb and resource — a token rug/honeypot check on Base — and enumerates the dimensions checked (GoPlus flags, taxes, ownership, holders, DEX liquidity, source verification). It is clearly a token-level tool rather than a wallet or generic contract tool, though it never explicitly contrasts itself with kairos_contract_check, which an agent could plausibly confuse it with.

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

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

It gives one concrete usage rule: pass credit_key to pay, otherwise you get pricing and payment options back instead of a report. That is genuinely useful, but there is no guidance on when to prefer this over kairos_contract_check or kairos_wallet_profile, and no statement of when a token check is unnecessary.

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

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

Goes well beyond the annotations by disclosing the paid model ($0.01 per call, USDC), the bearer-credit-key payment path, and the important behavioral quirk that omitting credit_key returns pricing/payment options rather than a report. That fallback behavior is exactly the kind of surprise an agent must know before calling.

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 most decision-relevant fact (PAID, price) and then covers scope, tier positioning, and payment in four compact sentences. 'Same sources as token-check at a fraction of the price' is slightly promotional but still carries comparative information.

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

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

With no output schema, the description still characterizes the return as raw data across named sources and flags the alternative return shape when unpaid. It does not describe the output structure or error/failed-payment behavior, which is a modest gap for a paid 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 coverage is 100%, so both address and credit_key are already documented in the schema, and the description largely restates the credit_key semantics ('Pass credit_key to pay ... without it this returns the price'). It adds no syntax or format 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?

States a specific verb and resource ('Entry-tier token check on Base') and enumerates the exact data covered: GoPlus honeypot, tax, ownership and holder flags plus DexScreener liquidity. It also positions itself against the sibling kairos_token_check ('same sources ... at a fraction of the price'), so an agent can distinguish the tiers 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?

The description clearly routes the agent: cheap raw-data tier versus the pricier token-check with written analysis, and it states the fallback mode when no credit_key is supplied. It stops short of an explicit 'use X when you need narrative analysis' instruction, but the tier distinction and payment prerequisite are unambiguous.

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

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

The annotations only declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false; the description adds material behavior beyond that — a $0.10 USDC charge per call and the dual-mode response where a missing credit_key yields pricing info instead of a report. That fallback behavior is exactly the kind of surprise an agent needs warned about. Credit-consumption semantics and error cases on failed payment are still unspecified.

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 that front-load the most decision-relevant fact (it is paid) before contents and payment mechanics. The '?chain=base|base-sepolia' query-string phrasing is slightly redundant with the schema enum and reads like URL syntax rather than tool-argument guidance, a minor blemish.

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

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

With no output schema, the description carries the burden of describing returns and does so by enumerating the report fields and noting the neutral analysis section. Combined with the payment/fallback explanation, an agent can call this correctly. Remaining gaps are secondary: shape of the analysis text and error handling on invalid or unpaid requests.

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 all three parameters are already documented in the input schema, including the chain enum and the credit_key fallback note. The description restates the chain values and the credit_key behavior rather than adding new syntax or constraints, 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 concrete resource and enumerates its exact contents (ETH balance, tx count, contract-or-EOA, proxy slots, token holdings, neutral analysis) on Base, so an agent knows precisely what it gets. It does not explicitly differentiate itself from kairos_token_check or kairos_contract_check, which cover overlapping territory, 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?

Gives a clear usage rule for the payment path: pass credit_key to pay from a prepaid key, otherwise the call returns price/payment options rather than a report. However it offers no guidance on when to choose this tool over the sibling checks (token_check, contract_check, market_summary), which is the more consequential routing decision.

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