phantomoperator

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

With no annotations, the description carries the full disclosure burden and does well: it states the $0.10 USDC charge on Base via x402 (a real cost barrier), that the call is keyless, and that passwords are checked via k-anonymity SHA-1 prefix and emails sent to named third parties. It stops short of describing what a result looks like or what happens on lookup failure.

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 compact sentences with no filler; the functional purpose is front-loaded and the cost/mechanism follow it. Every clause (providers, optional password, payment rail) carries information an agent needs.

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

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

For a paid, 2-parameter tool with no annotations and no output schema, the description covers cost, inputs, and privacy mechanism but says nothing about the shape or content of the response, which matters when the caller is spending USDC. It is adequate but leaves a meaningful gap.

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 baseline is 3. The description adds the source services behind the email lookup and reinforces the SHA-1 prefix mechanism for the password, but contributes no new constraints, formats, or validation rules.

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 ('email breach intelligence check') and even identifies the underlying data providers (XposedOrNot, HIBP), plus the optional password lookup. It is clear what the tool does, though it does not explicitly contrast itself with nearby siblings like threat-scan or full-privacy-sweep.

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

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

There is no explicit when-to-use guidance, no conditions for choosing this over threat-scan/full-privacy-sweep, and no prerequisites stated beyond an implied paid call. The word 'optional' on the password parameter is the only usage signal, and it lives in the schema rather than the description.

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

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

No annotations exist, so the description carries the full burden; it does add a genuinely useful behavioral fact — the operation is paid and settles $5.00 USDC on Base via x402. It omits everything else: that this is a read-only OSINT audit rather than a data-removal action, how submitted PII (email, fullName) is handled, expected latency, and what happens when parameters are missing.

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 module list is front-loaded, which is good. However the dense parenthetical mixes '+' and '$XMR' notation, and the '6-operator' label conflicts with the seven items enumerated, which invites misreading of scope.

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 five-parameter, zero-required, paid, PII-consuming composite tool with no output schema and no annotations, this is too thin. An agent still cannot determine invocation prerequisites (payment setup, minimum inputs), output shape, or the privacy implications of submitting an email and full name to a service marketed on privacy.

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 0%, so the description must compensate, and it largely does not. The module list lets an agent guess the mapping (url→web metadata, email→breach check, fullName→OSINT, walletAddress→EVM hygiene, xmrAddress→Monero audit), but no field is named, no format is given (e.g. EVM vs XMR address syntax), and optionality is unexplained.

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 deliverable (a 'Comprehensive... Dossier') and enumerates the six/seven operator modules it bundles, so an agent knows this is the aggregate report rather than a point tool. It does not explicitly say it is the bundle of the sibling tools (metadata-audit, threat-scan, breach-check, etc.), leaving the parent/child relationship to be inferred.

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

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

There is no statement of when to use this dossier versus calling the individual sibling tools, nor any guidance on which inputs are needed to activate which module. With required parameters listed as zero, an agent cannot tell whether all five fields are needed, whether any single field is enough, or what happens on a partial submission.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that output is a reviewable draft rather than a submitted request, that explicit authorization is a precondition, and that invocation costs $0.50 USDC on Base via x402. Remaining gaps are the mechanics of an unsupported broker match and any failure/refund behavior on the paid 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, front-loaded with the action, then the safety constraint, then the payment term. Nothing is redundant and each sentence contributes a distinct fact 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?

For a two-parameter tool with no output schema and no annotations, the description covers what is produced (a drafted request), the authorization gate, and the cost model. It stops short of describing what the draft contains or what happens when no removal path matches, which is the only meaningful omission.

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

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

Schema coverage is 100% with only two documented parameters, so the schema already explains 'link' and 'fullName'. The description adds only the qualifier that the link should be an authorized listing, which is marginal meaning 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?

The description names a specific verb chain and resource: it matches a data-broker listing to removal paths and drafts a CCPA/GDPR request. That is far more precise than the audit/scan siblings (opsec-score, threat-scan), though it never explicitly contrasts itself with full-privacy-sweep or spam-caller-removal, so the sibling boundary is inferred rather than stated.

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

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

Usage context is implied by 'authorized data-broker listing' and the no-submit-without-authorization clause, which tells an agent this is a single-listing drafting step, not a bulk sweep. However, it never says when to prefer it over full-privacy-sweep or what to do when a listing has no supported removal path, so the agent must infer the routing.

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

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

With no annotations, the description carries the full burden, and it does disclose a real behavioral trait: a $1.00 USDC charge on Base via x402, which tells the agent this is a paid, wallet-settling call. It says nothing about what data is actually retrieved, how inputs are used, or what the report contains beyond 'structured,' leaving significant gaps for a mutation-free but paid tool.

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

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

Two short sentences, front-loaded with the capability and then the price. Nothing is padded and no sentence 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 paid aggregate tool with no output schema and no annotations, the description at least establishes the composite nature of the report and the payment requirement. It falls short on how the four identifiers are consumed and how the result differs from sibling scans, but the core contract 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?

Schema description coverage is 0% across four parameters, and the description adds no meaning for email, handle, fullName, or walletAddress. In particular it does not say whether only fullName is needed or whether the optional identifiers sharpen the sweep, so the agent gets no help from prose.

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 composite output: public-exposure checking, privacy scoring, and removal guidance rolled into one structured report. That is more specific than a tautology, but it never distinguishes this aggregate from overlapping siblings such as opsec-score, threat-scan, or data-removal, so an agent must infer the boundary.

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

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

There is no statement of when to pick this sweep over breach-check, opsec-score, or data-removal, and no exclusions or prerequisites beyond the price. The only actionable context given is the payment mechanism, which is a cost notice rather than usage 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?

No annotations exist, so the description carries the full burden. It does disclose a genuinely important trait: the $0.05 USDC charge on Base via x402, which tells the agent this is a paid, outbound-network operation. It does not say whether payment is charged on failure, whether internal/private URLs are permitted, timeout/rate-limit behavior, or whether results are stored – significant omissions for an unannotated tool.

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

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

Two sentences, purpose front-loaded, with the cost constraint second. Nothing is wasted and no sentence merely restates the tool name.

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 fetch tool the description covers purpose and pricing, and no output schema means return values need not be explained. However, an unannotated paid network tool should still state failure/charge behavior and any fetch restrictions; those gaps leave the agent uncertain about consequences of calling it.

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

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

The schema documents the single 'url' parameter at 100% coverage as an 'Absolute HTTP/HTTPS URL to audit.' The description's phrase 'any HTTP/HTTPS URL' only reinforces the scheme restriction already in the schema, adding no new semantics such as SSRF restrictions, redirect handling, or auth requirements.

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

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

Specific verb ('Fetch') plus resource ('any HTTP/HTTPS URL') and an enumerated list of what is extracted: headers, meta tags, HTML comments, trackers. That is enough to distinguish it from siblings like threat-scan or breach-check, though it never explicitly names which sibling covers adjacent needs.

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

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

Usage is implied by the verb and extraction list – an agent can infer 'call this when you want to know what a URL leaks.' There is no explicit when-to-use, when-not-to-use, or alternative named among the many privacy-sweep siblings, so routing still requires guesswork.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the notable cost of $0.25 USDC on Base via x402 plus some expected outputs like Spend Key, View Key, and checksum. However, it omits important behavior such as payment flow, whether all operations are read-only, nodeMode privacy implications, and what the MMR proof or telemetry responses contain.

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

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

The description is a single dense but efficient sentence with no filler. It is somewhat run-on because it lists four distinct capabilities in one breath, but it front-loads the core decoder identity and includes the cost without unnecessary prose.

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?

This is a complex, multi-capability tool with five optional parameters, no annotations, and no output schema. The description lists capabilities and cost but does not adequately explain how to invoke each capability, what nodeMode does, what results are returned, or what payment/auth steps are required before use.

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 60%, so the baseline is around 3. The description loosely maps capabilities to parameters, such as address decoding to xmrAddress and swap correlation to evmAddress/swapAmountXmr, but it adds no concrete meaning for nodeMode or the undocumented parameters and does not clarify parameter combinations.

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 specific resources and operations: Cryptonote Base58/Keccak-256 Monero address decoding, RingCT telemetry, EVM/XMR swap correlation, and MMR proof. It is clear what the tool does overall, but it does not distinguish itself from the sibling wallet-opsec-audit or explain whether this is primarily an address decoder, telemetry probe, or multi-purpose audit 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?

There is no explicit guidance on when to use this tool, when not to use it, or which siblings are alternatives. The description also does not explain how to choose among its multiple capabilities or how the optional parameters trigger different modes.

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

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

There are no annotations, so the description carries the full burden. It does disclose output format (score and grade) and a notable behavioral trait—cost of $0.25 USDC on Base via x402—which is useful. However, it omits whether the tool is read-only, how inputs are handled, and any permission or rate-limit considerations, leaving significant gaps for an unannotated tool.

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

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

Two sentences, front-loaded with the core purpose and output, followed by cost and payment details. Every sentence adds value with no filler.

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

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

With no annotations, no output schema, and 0% schema coverage, the description must do more. It adequately covers purpose, output format, and pricing, but it is incomplete on parameter usage and operational behavior, leaving the agent without enough information to call it correctly in all cases.

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 0%, and the description never mentions the three parameters (email, handle, fullName). The listed vectors imply identity-based inputs, but there is no explanation of which identifier to use, whether combinations are allowed, or what happens if none are supplied (all are optional).

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: a multi-vector OPSEC exposure score (0–100, grade A–F) covering four named data sources. It is clear what the tool produces, but it does not explicitly differentiate itself from siblings like full-privacy-sweep or threat-scan, leaving the agent to infer the distinction.

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

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

The description explains what the tool is but gives no guidance on when to choose it over alternatives, no prerequisites, and no conditions for use. The only practical note is the cost, which is not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does add genuinely useful context — a $25.00 USDC price, Base chain, and x402 payment rail — which hints that invocation triggers a paid checkout. But it never states whether payment is automatic on call, what is delivered or returned, or how delivery occurs.

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 compact sentences with no filler, and the pricing/payment fact is stated plainly at the end. The first sentence is dense with product jargon that delays comprehension, but overall length is appropriate.

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?

A five-parameter, monetized tool with no annotations, no output schema, and zero parameter documentation leaves the agent unable to call it correctly. It cannot tell which fields to supply, whether calling charges the user, or what it gets back.

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 0% for five parameters, so the description must compensate and largely does not. The mention of 'XMR Atomic-Swap' and USDC payment faintly implies xmrAddress and walletAddress, but url, email, and organization are never explained, nor is any parameter marked optional or required.

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 identifies a specific product (an OPSEC retainer package with an atomic-swap treasury blueprint and takedown binder), so the agent knows what is being obtained. However, it is written as a marketing title rather than a verb+resource statement — it never says what invoking the tool actually does (purchase? generate a report? register an order?).

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

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

The phrase 'Enterprise & DAO' gives a faint audience hint, but there is no statement of when to choose this over the many closely related siblings (full-privacy-sweep, monero-opsec-audit, data-removal, cyberpunk-redteam-dossier). No prerequisites, exclusions, or alternatives are named.

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

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

No annotations exist, so the description carries the full burden, and it does disclose two costly-to-miss behaviors: it does not submit anything, and it costs $0.10 USDC on Base via x402. That payment and no-side-effect disclosure is exactly the kind of context annotations would normally supply. It does not say what happens if authorization is missing or false, which keeps it from a 5.

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

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

Three short sentences, no filler, and the core action is front-loaded before the no-submit caveat and the price. Every sentence carries information the agent needs.

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

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

There is no output schema and no annotations, and the description does not describe what the returned 'steps' look like or how the x402 payment is settled. The scope, cost, and non-submission behavior are covered, which is the minimum for a paid tool with an undocumented enum parameter.

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 67%, and the one parameter that would benefit from explanation, the 'provider' enum (truecaller/hiya/robokiller/whitepages), is undocumented in both the schema and the description. The description never mentions provider selection, defaults, or whether all four are consulted. It only echoes the authorization framing already present in 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 names a specific verb and resource: preparing official caller-ID unlisting and spam-label dispute steps for a phone number. That distinguishes it from siblings like data-removal or breach-check, which cover different resources. It stops short of explicitly naming an alternative, so it is clear but not fully differentiated.

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 precondition 'for an authorized phone number' and the exclusion 'Does not submit requests', which tells the agent this tool plans rather than executes. However, it never names an alternative tool for actually filing the requests or explains when a caller should skip this, so the routing guidance is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the public-web scope, PII categories, and cost/payment mechanism ($0.10 USDC on Base via x402), but does not describe return format, result limits, or other operational constraints.

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 tightly written sentences. Purpose and PII scope are front-loaded, and the cost/payment sentence is essential. There is no waste.

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 search tool with no output schema, the description covers the core purpose and payment model. However, it omits return value details, which are especially important because no output schema 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% for the single parameter, and the description adds no detail beyond what the schema already communicates about 'fullName'. 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 ('Search'), resource ('public web'), and target ('mentions of a person's name containing exposed PII'), including the PII types. It does not explicitly name or differentiate from siblings like breach-check or full-privacy-sweep, 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?

The description explains what the tool does but gives no guidance on when to use it versus alternatives such as breach-check, data-removal, or full-privacy-sweep. There are no exclusions or prerequisites beyond the implied payment requirement.

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 does earn credit for disclosing that the call is paid ($0.50 USDC on Base via x402) and that a deterministic $XMR subaddress is involved — real behavioral context an agent cannot get from the schema. It does not state whether the audit is read-only, what the report contains, or whether payment failure aborts 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?

Two short clauses, front-loaded with the core audit purpose and followed by the cost. The '+ deterministic $XMR settlement subaddress' fragment is dense jargon that costs clarity, but nothing is wasted or buried.

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?

One-parameter tool with no annotations and no output schema, so the description carries the full burden. It covers cost and one artifact but never says what the audit returns (a score? findings list?) or how it differs from the several privacy siblings. Adequate to invoke, thin for deciding whether to.

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% ('0x EVM wallet address'), so the schema already carries the parameter meaning and baseline is 3. The description's 'Base/EVM wallet' wording reinforces but does not extend it — no format, validation, or chain-ambiguity guidance is added.

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

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

States a specific verb+resource: an on-chain Base/EVM wallet deanonymization and hygiene audit. The 'Base/EVM' qualifier implicitly separates it from the Monero-focused sibling, but it never explicitly names monero-opsec-audit, full-privacy-sweep, or opsec-score as alternatives. The trailing '+ deterministic $XMR settlement subaddress' muddies what the tool primarily produces.

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

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

Usage is only implied by the resource type — an agent can infer 'call this to audit an EVM wallet address'. There is no when-to-use/when-not guidance and no routing to the many overlapping privacy siblings (full-privacy-sweep, opsec-score, monero-opsec-audit). The payment note signals a precondition but not a selection rule.

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