wealth-agent

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

Annotations only cover the safety profile (readOnly, non-destructive, not idempotent). The description adds critical non-schema behavior: calling returns a 402 with PAYMENT-REQUIRED and the caller must pay 0.75 USDC and resend with a PAYMENT-SIGNATURE header. That payment protocol is exactly the kind of context annotations cannot express. The mixed-language presentation slightly reduces clarity but the flow is fully 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?

Purpose and the key call-before-merging guidance are front-loaded, but the body mixes English and Japanese, includes an inline JSON example that duplicates the schema, and the payment explanation is wordy. Some content earns its place (the 402 flow) but the overall packaging is cluttered.

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 explaining returns and does so (line-numbered findings, severity, concrete fix). Combined with the payment flow and safety annotations, an agent has enough to invoke correctly. Only the language mixing leaves minor ambiguity.

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%, documenting both 'code' (10-60,000 chars) and 'language'. The description only repeats an example input object, adding no syntax or constraint meaning beyond the schema. 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 (reviews), resource (source code), and describes the output precisely: line-numbered findings with severity and a concrete fix. It even names the detection methods (static rules for eval/SQL concat/secrets/shell injection plus AI review), so the agent knows exactly what class of tool this is.

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 merging or running untrusted code', giving a clear trigger context. It does not name a when-not condition or compare to the sibling buy_* services, so it falls short of the 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 cover the safety profile (readOnlyHint, destructiveHint=false), and the description adds substantial context they do not: the 0.50 USDC cost, the 402/PAYMENT-REQUIRED challenge, and the PAYMENT-SIGNATURE header retry flow. It also discloses the return contents (cleaned CSV plus before/after quality checks and per-column stats) despite there being no output schema. This is exactly the auth/payment disclosure that annotations cannot carry.

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

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

Front-loaded with purpose, then usage, then payment mechanics — a sensible order, and every sentence carries information. The inline 'Input: {...}' example duplicates what the schema already states, and the abrupt shift into Japanese for the pricing section hurts scanability.

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 payment-gated tool with no output schema, the description supplies the missing pieces: the return payload shape, the cost, and the exact two-step payment handshake. An agent has everything needed to invoke it correctly on the first try.

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 `data` (with its 60,000-char limit) and the `format` enum. The description's 'Input: {"data": "<csv text>"}' merely restates the required parameter and omits `format` entirely, adding no syntax or format detail beyond the schema. 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 ('Cleans a CSV/TSV/JSON table') and enumerates the concrete operations (dedupe, drop empty rows, trim whitespace), so the agent knows exactly what transformation happens. It does not differentiate itself from the sibling csv-json, which an agent might reasonably 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?

'Call it before analysing or importing messy tabular data' gives a clear precondition for use. There is no explicit when-not or named alternative (e.g. when to use csv-json instead), so it stops short of full routing 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 cover the safety profile (readOnly/destructive/idempotent/openWorld). The description adds the critical, non-obvious payment handshake: a 402 + PAYMENT-REQUIRED response, a 0.25 USDC charge, and the need to resend with a PAYMENT-SIGNATURE header. That is exactly the context an agent needs before calling and is nowhere in 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?

Purpose and usage are front-loaded and efficient, but the description is bilingual with the payment mechanics carried entirely in Japanese. The content earns its place, but the language split hurts scannability for a non-Japanese-reading agent.

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

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

For a one-parameter tool with no output schema, the description covers what is returned (cited URLs, findings, gaps), the cost, and the payment flow. Only the pagination/length limits of the brief and any failure modes beyond the 402 are unstated.

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

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

Schema coverage is 100% with a single required parameter, so the schema already documents the field. The description repeats the same constraint ('5-400 chars, any language') without adding format, encoding, or example guidance, 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 ('Returns a one-page research brief with cited source URLs, key findings and open gaps') and names the concrete input shape. An agent can distinguish it from buy_code_review and buy_data_clean 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 clear selecting context: 'Call it when an agent needs a sourced answer instead of an unsourced guess.' It does not, however, name or exclude any sibling tool, so the agent still has to infer when a code-review or data-clean brief is the better buy.

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

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

Annotations already declare the safe, non-destructive, closed-world profile, so the description's added value is the non-obvious payment behavior: a 402 with PAYMENT-REQUIRED, USDC settlement, and a re-send with a PAYMENT-SIGNATURE header. It also discloses delimiter detection and typed-column inference, which an agent cannot infer from the 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?

The English portion is two tight, front-loaded sentences with no filler. The appended Japanese payment block is relevant and earns its place, but the mid-description language switch slightly hurts scannability.

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

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

With no output schema, the description should ideally characterize the returned payload; it only implies that the converted data comes back. Everything else an agent needs, including the full 402/payment retry flow, is present and complete.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the enum on "to" is self-explanatory. The description only loosely reinforces this with "in either direction" and the note about inferred target format, adding little beyond the schema baseline.

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

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

The description gives a specific verb and resource: convert tabular data between CSV/TSV and a JSON array of objects, in either direction. That is unambiguous and clearly distinct from siblings like diff, regex, or the buy_* services, though it never explicitly names or contrasts a sibling tool.

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 it when a tool returns CSV but your pipeline needs JSON (or the reverse) and you do not want to run a parser yourself" gives a concrete triggering condition. It stops short of naming exclusions or alternative tools, and the payment precondition is stated as mechanics rather than as a when-to-use rule.

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=false, so the agent knows this is a safe, non-destructive, local read operation. The description adds a payment flow (402 response, USDC payment, PAYMENT-SIGNATURE header), which is valuable behavioral context. However, it does not describe output format beyond a brief mention of hunks, nor does it warn about input size limits or rate limits. A 3 is appropriate given annotations cover the safety profile and the payment detail adds some value.

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 starts with the core function, then lists use cases, and finally explains the payment flow. It is front-loaded and each sentence serves a purpose, though the payment details in Japanese are somewhat verbose and could be more concise.

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

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

The tool is simple (two string parameters, no output schema). The description explains the return format (added/removed/unified hunks with counts) and the payment requirement, which is unusual and important. It lacks information about maximum input size or error handling, but with annotations covering safety, it is largely complete.

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

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

Schema description coverage is 100%, so both parameters (a and b) are fully documented in the input schema. The description does not add any parameter syntax or meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description states a specific verb (return), resource (line-level diff between two texts), and output shape (added/removed/unified hunks with counts). It clearly distinguishes this tool from siblings like csv-json and regex, which perform entirely different transformations.

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 lists concrete use cases: reviewing a patch, comparing API responses, and pre-checking whether documents differ to save tokens. This gives the agent clear when-to-use context, and the nature of the tool makes alternatives obvious.

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, so the safety profile is covered. The description adds the useful 'free to call' cost detail, but discloses nothing about return volume, ordering, or pagination — acceptable but thin for a zero-parameter listing 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?

A single compact phrase with no filler; the scope (paid services on sale) is front-loaded before the payload (prices, payment terms) and the cost note. It reads as a noun phrase rather than a full sentence, but nothing is wasted.

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

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

For a trivial read-only catalog tool with no parameters and no output schema, the description covers what it returns (services, prices, payment terms) and that it is free. It omits return shape and ordering, which is a minor gap given the tool's 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 schema has zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4.

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+resource: a 一覧 (list) of 販売中の有料サービス (paid services currently on sale), plus what each entry contains (価格・支払い条件). It is clearly distinguishable from the buy_* siblings, which perform a purchase rather than a catalog lookup, though it never names those siblings explicitly.

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

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

The only usage signal is '(無料)', indicating the call costs nothing, which implies this is the safe browse-before-you-buy step preceding the buy_* tools. There is no explicit when-to-use statement, no prerequisites, and no named 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=true and destructiveHint=false, so safety is covered. The description adds genuinely non-structured behavior: server-side execution, determinism, and a full payment handshake (402 + PAYMENT-REQUIRED, 0.01 USDC, resend with PAYMENT-SIGNATURE) — that is real operational context. It stops short of 5 by omitting rate limits, failure modes other than 402, and by presenting the payment flow only in Japanese.

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

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

Front-loaded with purpose and return value, then determinism, then the payment mechanics, which is a sensible order and every sentence carries information. Minor deductions for the mixed English/Japanese block and the stray '。。' punctuation, which make it slightly harder to parse than it needs to be.

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 correctly spells out the return value (matches, indices, capture groups), and it covers the non-obvious 402/payment path an agent must handle. Combined with 100% schema coverage and safety annotations, an agent has what it needs; only error and rate-limit behavior remain unaddressed.

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% (text, flags, pattern all documented with limits), so the baseline is 3. The description adds only the constraint that a single pattern is applied per call, which the schema does not state; it offers nothing about flags syntax or pattern flavor.

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 — 'Apply one regular expression to a text blob on the server' — plus the return shape ('every match with its index and capture groups'). This clearly separates it from siblings like diff, csv-json and url-meta, which transform or fetch rather than pattern-match.

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?

Names concrete use cases ('log triage, field extraction and validation at scale') and the payment procedure needed to actually get a result. It gives no when-not conditions or sibling alternatives, so it falls short of a 5, but the 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 carry only the safety profile, and the description adds substantial behavior beyond them: 4xx/5xx are returned as data rather than errors, and the full x402 payment handshake (402 + PAYMENT-REQUIRED, USDC payment, resend with PAYMENT-SIGNATURE header) is disclosed. This payment gating is essential to invoking the tool correctly and would be invisible otherwise.

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 English portion is front-loaded and dense with no waste, stating purpose, return shape, and use cases before the payment blocks. The bracketed payment section is necessary but shifts into another language, slightly reducing at-a-glance readability.

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 correctly enumerates return fields, and it also documents error semantics and the payment flow. For a one-parameter tool this is complete enough to call 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 coverage is 100% for the single parameter, and the description only restates it ('one public URL', 'public page') without adding syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the work.

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 (fetch) and resource (one public URL) and enumerates exactly what is returned: status, title, meta/og description, canonical URL, language, link count, text sample. This is clearly distinguishable from the paid buy_* tools and local utilities (csv-json, diff, regex) among the 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 concrete use cases ('link previews, source triage and citation checks') so the agent knows when this applies. It does not name alternative tools or state when not to use it, but the context is clear.

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