Kortex

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

With no annotations provided, the description carries the full burden, and it does disclose the key behavior: it returns a full manifest and is free. It doesn't mention side effects, but 'Return' strongly implies a read-only introspection call, and 'Price: Free' sets cost 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 is compact and front-loaded with the core purpose, followed by a clear usage note. The only minor flaw is redundancy: 'Free' appears both in the first sentence and again as 'Price: Free.'

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 no parameters, no annotations, and no output schema, the description provides everything an agent needs: what the tool returns, what that manifest contains, the cost, and when to call it. The word 'full' also signals that no pagination or partial result is involved.

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 are zero parameters, so the baseline is 4. The description correctly implies that no configuration is needed by presenting the tool as a direct call returning a manifest; there is no parameter schema for it to explain.

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 ('Return') and a concrete resource ('full machine-readable manifest of Kortex'), and specifies exactly what the manifest contains: every operation, its USD price, input schema, and payment instructions. This clearly differentiates it from sibling tools like check or resolve, which are operational actions rather than capability discovery.

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 when-to-use guidance: 'Call this first if you have never used Kortex.' It does not explicitly name when-not-to-use scenarios or alternatives, but for a first-contact capability tool 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds useful behavioral context: it returns a synthesized verdict rather than raw data, and it enumerates the specific checks performed. It could also mention live-probe behavior or latency implications, but the annotations already establish the read-only safety profile.

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 opening sentence states scope and outcome, followed by clear usage guidance and pricing. Every segment earns its place, and the 'When to use' label makes the decision context easy to scan.

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

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

For a simple two-parameter read-only tool, the description gives enough information to decide when to call it and what kind of answer to expect. There is no output schema, so the enumerated checks and 'verdict' help, though the exact return shape remains 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 description coverage is 100%, so the schema already documents both 'resource' and 'probe_now' well. The description reinforces that the resource is the URL being considered for payment, but it adds little beyond what the schema 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?

The description names a concrete resource ('a single resource URL') and specifies the checks it performs: whether it is up, whether its 402 is well formed, what it quotes, and whether its payout address has been paid on-chain. It clearly communicates that the tool returns a verdict, but it does not explicitly distinguish itself from sibling 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?

A dedicated 'When to use' section tells the agent to call this when it already has a URL and wants to know whether sending money is a good idea, and even gives a cost-benefit threshold. It does not explicitly state when not to use it or name alternative sibling tools.

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

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

Annotations only indicate readOnlyHint=false and openWorldHint=false. The description adds useful behavioral context: it evaluates candidates on the same evidence, produces a payment recommendation, and costs US$0.003 per call. It does not detail any side effects beyond the paid API call, but the cost and decision-oriented outcome 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 description is three short, focused sentences: the core action, when to use it, and the price. It is front-loaded and contains no filler or redundant restating of the tool name 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 single-parameter tool, the description covers the purpose, usage context, output nature ('say which one to pay'), and cost. There is no output schema, but the description tells the agent what kind of answer to expect, which is sufficient for deciding whether and how to invoke the 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?

The input schema already has full coverage of the `resources` parameter, including format, minItems, maxItems, and a description of what each URL represents. The description reinforces the array concept with 'two or more' and 'shortlist', but it does not add meaningful parameter semantics 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 states a specific verb and resource: score multiple resource URLs side-by-side and recommend which one to pay. It clearly differentiates from the sibling `check` tool by emphasizing that it handles several URLs at once instead of checking a single URL.

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 explicit when-to-use guidance: call this when a shortlist already exists and a pick needs to be made. It also names the main alternative, `check`, and notes that `compare` is cheaper than calling `check` once per URL, making the selection condition 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 only indicate readOnlyHint=false and openWorldHint=false, so the description carries the burden of explaining side effects. It does well by disclosing the one-time on-chain settlement and that subsequent calls are debited off-chain. The phrase 'Price: Free' is slightly ambiguous because buying credit obviously costs USDC, but it likely means the tool itself has no service fee.

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 concise and front-loaded with the core action, then gives the trigger condition and a useful cost heuristic. Every sentence contributes actionable information, with no filler or repetition of 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?

For a single-parameter tool with no required inputs and no output schema, the description is complete. It covers what the tool does, when to use it, the payment mechanism, billing behavior, and cost expectations. An agent has enough context to decide whether to call it and what to expect.

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 fully documents amount_usd with its allowed values and default. The description doesn't add further parameter-level detail, but it doesn't need to; 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 states a specific verb ('Buy'), a concrete resource ('Kortex credit'), and the payment method ('USDC on Base over x402'). This clearly distinguishes it from the listed sibling tools, none of which involve purchasing credit. Even the title 'Top up balance' reinforces the purpose.

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 explicitly says when to use: 'Call when your balance is low.' It also provides helpful context that operations are cheap, so one deposit covers many operations. It doesn't explicitly mention when not to use it or compare it to an alternative, because no sibling is a natural alternative, so no exclusion is needed.

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

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

Annotations already declare readOnlyHint=true, and the description builds on that by detailing the exact data scope (probe outcomes, price/payout changes, on-chain history) and the per-call price. It does not mention pagination or output limits beyond the schema's days parameter, but the disclosed scope is substantial for a read-only history endpoint.

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 well-structured: a rich first sentence defines the output, a second sentence gives usage context, and a third provides pricing. Every sentence earns its place without redundancy or 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 read-only historical query with two well-documented parameters and a clear data-scope statement, the description gives an agent enough to invoke it correctly. It could be slightly more complete by describing the response shape or pagination, but since there is no output schema, the named evidence categories provide reasonable guidance.

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%, with both 'resource' and 'days' already explained in the input schema. The tool description adds general context about time-series evidence but does not add new parameter-level meaning beyond what the schema provides, so the baseline score 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 states what the tool does: it returns 'the full time series behind a score' with specific evidence categories (probe outcomes, price/payout-address changes, on-chain settlement history). This is more specific than the generic title and distinguishes it from the sibling tools by framing itself as 'the evidence itself rather than the summary.'

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 provides explicit when-to-use guidance: 'Call this when a verdict surprises you, or before committing to a service you plan to depend on.' It contrasts the tool with a summary-style result, but it does not name a specific sibling alternative or state when not to use it, so it falls just short of full alternative 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 disclosure burden. It adds important behavioral context: permanent identity creation, free cost, trial credit, and the token dependency. It does not fully detail side effects like repeat calls or failure responses, but the key behaviors are present.

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, with purpose stated immediately, then usage guidance and pricing. Every sentence adds useful information without 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?

The description gives essential context for a bootstrap tool: one-time call, token needed later, no account. However, with no output schema, it could be stronger by describing the exact shape/field of the returned token or behavior when identity already exists.

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 explains wallet, signature, message, and label. The description reinforces the wallet-to-identity relationship but does not add new details about constructing signature or message 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?

Description uses a specific verb and resource: 'Turn a wallet address into a permanent Kortex identity and an API token.' This clearly distinguishes it from sibling tools by stating its unique setup role.

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 'Call this once, before anything else' and explains that the returned token is required for every other call. It also clarifies lack of account/email/human prerequisites, giving an agent unambiguous when-to-use guidance.

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

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

Annotations only supply readOnlyHint=false and openWorldHint=false, so the description carries the behavioral burden. It usefully discloses that the report is free, only counted once the payment is found on-chain, and effectively costs at least the price of the call it describes. This is meaningful non-obvious context, though post-submission behavior is not detailed.

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 and the description is not long, but the word 'free' appears three times: 'Free, and only counted...', 'It is free', and 'Price: Free.' The rhetorical 'no probe can produce' line adds flavor but little operational value. Still, the structure is scannable and generally efficient.

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

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

For a tool with only two required parameters and no output schema, the description provides enough context to decide when to call it, what the cost behavior is, and why it matters. The main gap is the lack of any description of what happens after submission, but this is secondary for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds framing around outcome ('what you got') and on-chain verification, but it does not materially expand the meaning of individual parameters beyond what the schema provides. 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?

Description opens with a specific action: 'Tell Kortex that you paid a service and what you got.' It clearly identifies the resource (Kortex), the action (report), and the domain (post-payment outcomes). The 'after any paid call' framing also separates it from sibling tools like check or compare, which are about inspection rather than reporting outcomes.

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 'When to use' section is explicit: call after any paid call that went wrong and after ones that went right. It also gives the rationale that reports improve later verdicts. It does not list when-not-to-use conditions or alternatives by name, but the trigger condition is 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?

Annotations mark this as read-only, and the description adds meaningful context: ranking criteria, per-operator deduplication, real-world reliability statistics, and a per-call price. It does not describe output shape, pagination, or error behavior, but for a read-only discovery tool the added transparency is solid. No contradiction with annotations.

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

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

Three short paragraphs with a front-loaded first sentence. The 'when to use' note and price are useful, and the market statistic is persuasive context rather than filler. It is appropriately concise, though the statistic sentence could be trimmed without losing core meaning.

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

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

For a four-parameter, read-only tool with full schema coverage and no output schema, the description covers the main agent needs: what the tool does, why to use it, how results are ranked, deduplication, and cost. It does not specify the exact return structure, but the detailed criteria in the description largely compensate.

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

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

The input schema already documents all four parameters with clear descriptions, so schema coverage is 100%. The description reinforces the plain-language nature of 'need' and the evidence ranking, but it does not add new parameter-level meaning beyond what the schema provides. 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?

The description clearly states that the tool converts a plain-language need into ranked x402 service candidates and names concrete evidence signals (uptime, valid 402, on-chain payments). It is specific and not a tautology, but it does not explicitly distinguish itself from sibling tools like check or compare.

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 an explicit 'When to use' section: call before paying for an unverified service and instead of trusting the first directory result. This gives clear context, but it does not mention when not to use the tool or point to alternative sibling tools.

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, the description reveals that Kortex records a watch and only reports changes later ('the next time you ask'), and that callback_url will receive a POST. This adds meaningful behavioral context not present in openWorldHint or readOnlyHint, though it does not detail persistence or cancellation semantics.

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, front-loads the core action, and every section earns its place, including the targeted when-to-use and price. 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 simple watch-registration tool with two parameters and no output schema, it covers the main behavior, the use case, the optional callback, and cost. It could be more explicit about what the agent should expect immediately after calling, but the 'next time you ask' phrasing gives a reasonable expectation.

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 100% schema description coverage, the baseline is 3, and the description does not add much parameter-level meaning beyond the schema. It reinforces the idea of 'service you depend on' for resource, but the schema already documents the exact URL and optional callback.

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 ('Register interest in a service') and clarifies what is tracked (price, payout address, availability), so an agent can understand the core function. It does not explicitly contrast itself with siblings like check or compare, so it falls just short of full 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?

It gives a clear when-to-use instruction: call this for a service you depend on, with a concrete rationale about payout addresses. It does not state when not to use it or name alternatives such as check or compare, so it misses the top score.

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

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

The annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that the tool is free and that it verifies the token works, which is useful behavioral context beyond the annotations. It does not contradict the annotations and provides modest additional 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 three sentences: return content, usage guidance, and price. Each sentence earns its place, with the most important information (what it returns) front-loaded. No fluff 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 zero-parameter, read-only tool with no output schema, the description covers return fields, usage scenarios, and cost. Nothing essential is missing—agents can determine when to call it and what they will receive, making it complete for its simplicity.

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 description coverage is 100% vacuously. Per guidelines, a zero-param tool earns a baseline of 4. The description correctly omits any parameter information since none exist, and the schema requires no further elaboration.

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 that the tool returns the user's handle, wallet, balance, and usage, and the title 'Who am I' reinforces the self-identification purpose. It distinguishes itself from siblings like 'capabilities' or 'history' by focusing on the caller's own identity and account state, though it lacks an explicit verb like 'get'.

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

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

The description gives explicit when-to-use scenarios: checking balance before a run or confirming token validity. It does not mention alternatives or when not to use, but the guidance is clear and actionable for the intended use cases.

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