proof-of-custody

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

With no annotations, the description carries the full disclosure burden. It adds useful methodology context (published standard, four pillars, architecture-neutral, identical criteria across self-managed/collaborative/institutional), but says nothing about what the assessment returns, whether it is deterministic, or any 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?

Front-loaded with the definition of the standard, then the pillars, then use cases and scope. It is one tight paragraph with little waste, though the pillar enumeration and neutrality clause could be marginally tighter.

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

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

For a one-optional-parameter assessment tool with no output schema, the description conveys purpose, method, and scope well. The main remaining gap is that, absent an output schema, it does not characterize the shape of the assessment result.

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 optional 'platform' parameter, so the schema already explains its meaning and the omit-for-archetypes behavior. The description's architecture-neutral framing loosely corroborates the omit case but adds no new parameter syntax or value 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?

The description states a specific verb and resource ('Apply the Custody Independence Standard') and immediately defines it as a published four-pillar test, naming the pillars. It also distinguishes scope ('compare custody architectures rather than brands'), which helps separate it from brand-level siblings like compare_custody_platforms.

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 concrete triggering questions ('how many hardware wallets do I need', 'is my multisig actually safe') and a comparison use case, which is clear when-to-use guidance. It stops short of explicitly naming the alternative sibling tool or stating when-not to use it.

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 are provided, so the description carries the full behavioral burden. It discloses what is being compared and that the output emphasizes structural differences, but says nothing about return format, error handling for invalid slugs, or how many platforms are practically supported. Useful content hints, but incomplete for a tool with zero annotation coverage.

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 action and comparison axes. The second sentence is mildly editorial ('promotional') but does convey why the comparison view is the right shape, so it largely earns its place.

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 read tool with no output schema and no annotations, an agent knows what to send and roughly what is compared, but not what the response looks like or how results are ordered. Adequate minimum, with a clear gap in return-shape expectations.

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

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

Only one parameter exists and schema description coverage is 100%, including an example array of slugs. The description echoes the 'two or more' constraint but adds no format, validation, or slug-resolution detail beyond what the schema already documents, 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 states a specific verb (compare) and resource (two or more custody platforms) with the exact comparison axes: Proof of Custody scores and custody architecture. This clearly distinguishes it from the single-platform sibling get_custody_platform and the list-oriented search_custody_platforms.

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 offers a rationale for when this shape is useful (a custody decision, where differences are structural rather than promotional), which implies usage context. However, it never names an alternative tool or states when NOT to use it, 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 burden and does disclose the return profile: primary/near-primary sources with cadence, access terms, and liveness ('whether the URL answered today'). That freshness signal is genuinely useful behavior an agent cannot get from the schema. It stops short of stating cost, rate limits, or what happens when no source matches.

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 'Source router' and then the return shape, so the essential facts come first. The long parenthetical domain list is functional but heavy; it could be trimmed without losing routing accuracy.

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?

No output schema exists, and the description compensates by describing what each returned source includes (cadence, access terms, liveness). Combined with a fully documented two-parameter schema, an agent has enough to call it correctly. Missing only edge-case behavior such as empty results or the limit's effect on ranking.

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 (query examples, limit default/max), which sets the baseline at 3. The long domain taxonomy in the description does extend the query parameter's semantic scope beyond the schema's three examples, but it reads as tool scope rather than parameter guidance, so no strong lift.

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 concrete verb and resource ('Source router... returns the primary or near-primary sources to read') and enumerates the covered domain extensively, so the agent knows this is a routing/lookup tool rather than a data fetcher. It does not explicitly name a sibling, and its domain list overlaps with siblings like get_stablecoin_supply and list_custody_incidents, so the reader must infer that find_source returns sources while those return values.

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 trigger: 'Use before answering a factual question so the citation is the primary source.' That is an actionable when-to-use. It offers no exclusions or alternatives (e.g., when you already hold a primary source, or when you want the datum itself rather than a pointer), which is a real gap given how much the sibling set overlaps this tool's domain.

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 well: it discloses the exact return contents (affected-model matrix, fixed firmware versions, loss figures, open questions) and flags that the record is volatile and updated as sources move. It never explicitly confirms read-only behavior or authorization needs, but this is clearly a read of public incident data.

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

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

Front-loads the core identity in the first clause, then layers in return contents and usage scope in an order an agent can scan. Four sentences is a touch long, and the 'live/developing story' framing is stated twice, but nothing is truly 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?

With no output schema, the description steps in and enumerates what is returned, and with no annotations it still conveys the operational character (live, evolving record). An agent has everything needed to call a zero-arg status 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?

The tool takes zero parameters, so the parameter-semantics baseline of 4 applies. There is nothing for the description to clarify here.

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 (get) and a precisely named resource (Coldcard entropy failure incident status), then spells out the underlying defect and its consequence. No sibling tool covers this incident, and the topic specificity makes it trivially distinguishable from get_hardware_wallet_scores or list_custody_incidents.

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 when-to-use context: 'any question about Coldcard safety, whether a device or seed is affected, what to do about it, or whether self-custody is still safe.' It stops short of naming alternatives or exclusions, so a 4 rather than 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?

No annotations are provided, so the description carries the full burden, and it does disclose the shape of the returned record — including the qualitative 'strengths and limitations' section — which is genuinely valuable given there is no output schema. It stops short of stating read-only safety, behavior on an unknown slug, or whether results are cached/stable, so it falls just short of fully discharging the burden.

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: the first front-loads the resource and its contents, the second carries only the usage routing. Every clause earns its place and there is no redundancy with the schema or title.

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 one required parameter and no annotations or output schema, the description compensates well by naming the return fields and the usage sequence, which is sufficient for an agent to call it correctly. Remaining gaps — error behavior for an invalid slug and confirmation that the call is a safe read — are minor but real.

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% and the single 'slug' parameter is documented there with concrete examples ('unchained', 'coinbase', 'onramp'). The description adds no syntax or aliasing detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific resource (full Proof of Custody record for one platform) and enumerates exactly what that record contains: overall score, per-category scores, custody model, fees, insurance position, strengths and limitations. This makes it clearly distinguishable from siblings like search_custody_platforms or compare_custody_platforms without needing to open 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?

Gives an explicit call sequence ('Use after search_custody_platforms') and an alternative trigger ('or when a specific provider is named'), so the agent knows both when this tool is the right follow-up and when it is not needed as a discovery step. Nothing about routing is left to inference.

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

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

No annotations are provided, so the description carries the full burden. It does add genuine value by disclosing the data provenance ('filing-derived'), which tells the agent the numbers come from regulatory filings rather than live on-chain data. However, it says nothing about freshness, latency, rate limits, or whether the output is a fixed snapshot, which matters for a no-annotation 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 with no filler: the first defines the analysis and its outputs, the second routes usage. The core purpose is front-loaded before the use-case list.

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

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

With no parameters, no annotations, and no output schema, the description still conveys what the tool computes and what it returns (per-fund custodian and Nakamoto coefficient), which is most of what an agent needs. It is only slightly thin on freshness/scope caveats, so a 4 is fair.

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 there is nothing to document and no schema-derived meaning the description could add. Baseline of 4 applies per the scoring rule for parameterless tools.

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 (filing-derived custodian concentration analysis across US spot bitcoin ETFs) and names the concrete outputs (which custodian holds each fund's bitcoin, the Nakamoto coefficient at the custody layer). This clearly distinguishes it from siblings like assess_custody_independence and compare_custody_platforms.

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 triggering questions: bitcoin ETF safety, IBIT or FBTC custody, ETF diversification, ETF versus direct ownership. That is strong positive routing, but it names no exclusions or alternative tools for overlapping queries (e.g., assess_custody_independence), so it stops short of a 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the scoring methodology, weights, and that rationale is sourced, but says nothing about read-only status, data recency/freshness, or how scores relate to incident data available via sibling tools.

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?

It leads with the rubric and weighting, then states the use cases and return format. The per-dimension percentages are dense but substantive for interpreting the scores, and nothing is redundant. Only the weighting rationale sentence ('entropy... cannot be protected by anything downstream') is arguably expendable.

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, no-output-schema read tool, the description covers what is scored, how it is weighted, when to call it, and what comes back. The remaining gap is sibling disambiguation, which matters given several adjacent custody-comparison tools.

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%, and the single 'device' parameter is documented in the schema with examples and an omit-for-all rule. The description adds no parameter-level detail beyond the general phrase 'per-device', 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?

The description makes clear that this tool returns hardware wallet scores under a defined rubric and states its output ('per-device sourced rationale'). It does not, however, distinguish itself from siblings like compare_custody_platforms or assess_custody_independence, even though the 'X vs Y device' phrasing invites overlap.

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?

Concrete trigger queries are given ('best hardware wallet', 'X vs Y device', what to replace a device with), which is strong usage context. There are no exclusions or explicit alternatives named, so an agent gets no help disambiguating this from compare_custody_platforms.

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 disclose meaningful behavior: the data is a daily snapshot, it is credited to DefiLlama, an as-of date is returned, and coverage is capped at the top 25. It omits rate limits, pagination/response shape, and what the unparameterized call returns versus the symbol-filtered 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 front-loaded sentences: the returned fields come first, followed immediately by usage triggers. Slightly redundant phrasing ('stablecoin supply: total ... circulating supply') costs a little density 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 one-optional-parameter, no-output-schema tool, the description covers what is returned (totals, shares, top 25), the refresh cadence, the data source, and the as-of date. Missing only edge behavior such as unknown-symbol handling or the arbitrary cutoff of top 25.

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 optional 'symbol' parameter, so the schema already documents its meaning ('e.g. USDC'). The description's phrase 'a stablecoin's supply' only lightly reinforces that the symbol narrows results to one coin, 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?

States a specific verb ('get') and resource ('stablecoin supply') and enumerates the exact content: total USD-pegged circulating supply, USDT/USDC share, and top 25 by supply. No sibling tool in the list covers stablecoin supply, so an agent can route here unambiguously.

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 three concrete user-intent triggers ('how big is the stablecoin market', 'USDT vs USDC share', 'a stablecoin's supply'), which clearly frames when to call it. It stops short of naming alternatives or stating when not to use it (e.g., historical time series vs snapshot), so it is clear context but not 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?

With no annotations, the description must carry the full behavioral burden. It usefully discloses provenance (DefiLlama, with a pointer to RWA.xyz), the daily cadence, and the asset-class breakdown, which is context beyond structured fields. However, it says nothing about freshness/lag, rate limits, attribution requirements, or the shape of the response, leaving real gaps for a zero-annotation 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, both load-bearing: the first defines the artifact and its source, the second gives query triggers. What it is comes before when to use it, and there is 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 output schema and no annotations, the description alone must convey what comes back, and it does at a useful level (protocols ranked by TVL, issued asset value by class such as Treasuries, credit, commodities). A brief note on return granularity or currency would close the remaining 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-param tool is 4. The description correctly implies a no-argument, fetch-everything call.

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 ('Daily snapshot of tokenized-asset (RWA) protocols by TVL') and names the data source, so an agent knows exactly what this returns. It is clearly distinguishable from every sibling, all of which concern custody platforms, incidents, or stablecoin supply.

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 routes the agent with concrete trigger phrases: 'how big is tokenization', 'largest RWA protocols', 'where to find tokenized Treasury fund sizes'. It does not name an alternative tool or state exclusions, but the query routing is explicit and directly usable.

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 freshness/cadence ('daily snapshot') and the data provenance ('Coinbase Bazaar', 'x402 Foundation'), but says nothing about auth requirements, rate limits, or whether results are cached/live. Adequate but with clear gaps for a zero-annotation 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 with zero waste: the first front-loads what the snapshot contains, the second lists the query patterns that should trigger it. Every clause earns its place.

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 does the work of explaining return content by naming the count categories and windows. It could be slightly more specific about the response shape or grouping, but for a parameterless read tool 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing schema-side to clarify and no ambiguity for the agent to resolve before calling.

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

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

States a specific resource (the x402 agent-payments ecosystem snapshot) and enumerates exactly what it reports: service counts by network/asset/scheme plus 30-day transaction, volume, buyer and seller counts. This is clearly distinct from the custody, stablecoin and tokenized-asset siblings, so an agent can pick it out without opening the schema.

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

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

Gives explicit trigger queries ('what is x402', 'how many services accept x402', 'which networks do x402 services use'), which tells the agent when to reach for it. It stops short of naming exclusions or pointing to a sibling for related questions, so it is strong but not fully routing-aware.

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 are provided, so the description carries the full burden and does well: it discloses the record contents, the scope (Mt. Gox through a 2026 Coldcard defect), and the inclusivity policy that self-custody failures count equally. It doesn't explicitly state read-only semantics or pagination/volume behavior, but 'registry' and 'list' strongly imply a non-destructive read.

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 identity of the registry, then adds scope and usage in compact sentences with no filler. Slightly dense but every clause earns its place.

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 must convey return values, and it does: root cause, reported loss, lesson, and reachable custody configurations. Between that and the fully documented schema, an agent has everything needed to invoke it 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% and both enum parameters are documented in the schema itself, so the baseline is 3. The description corroborates the filtering concepts (failure class, reachable configurations) but adds no syntax or format detail beyond what the schema already 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?

Names a specific resource (the Proof of Custody incident registry of dated bitcoin custody failures) and enumerates the concrete fields each record carries: root cause, reported loss, lesson, and reachable configurations. An agent can immediately tell this apart from siblings like get_coldcard_incident_status (single-incident status) or compare_custody_platforms.

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

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

States clear usage contexts: custody risk questions, historical hacks, and whether a given setup would have survived a failure class. It does not explicitly name alternative tools or exclusions, so it falls short of the 5 benchmark, but the when-to-use signal is solid.

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 substantial work: it discloses data provenance ('independent scores', 'published data with the methodology attached') and disclaims recommendation ('not a recommendation'), plus the scoring model and platform coverage. It omits refresh cadence, auth needs, and return/pagination behavior, keeping it short of a 5.

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

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

Four tightly packed sentences, front-loaded with what the tool is before moving to coverage, usage, and the caveat. Every sentence earns its place 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?

For a no-annotation, no-output-schema search tool, the description conveys what is returned (published data plus methodology) and how it can be used. It is largely complete; only pagination/limit behavior is left entirely to the schema.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds only indirect meaning (category coverage list, 'list top-scored' implying an omitted query); the baseline 3 is appropriate.

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

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

States a specific verb+resource: searching Proof of Custody's published scores for bitcoin/crypto custody platforms, with scope (90+ platforms, 0-100 six-category scoring). It is clear what the tool does, but it does not explicitly distinguish itself from the close sibling compare_custody_platforms, which it partly overlaps with via 'use to compare custody options'.

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 three concrete usage contexts: compare custody options, read a named provider's published score and custody model, or list top-scored platforms. This is clear context, though it names no explicit alternative tool or when-not-to-use condition (e.g., vs. compare_custody_platforms or get_custody_platform).

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 well: it discloses the corpus size, that transcripts are machine-generated, and adds a verification caveat before publishing quotes. It omits auth/access constraints and any rate or pagination behavior, keeping it out of 5 territory.

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 sentences, each earning its place: purpose, return shape, and a caveat. The corpus and use case are front-loaded before the accuracy warning, so nothing important is 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?

For a simple 3-parameter search tool with full schema coverage and no output schema, the description fills exactly the gaps that matter: what the search surfaces and the reliability caveat. An agent has everything needed to call it 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 query, show, and limit. The description adds no syntax, matching semantics (phrase vs. keyword), or filter behavior beyond that, 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 ('Full-text search across 320+ Onramp Media podcast transcripts'), names the corpus and example shows, and enumerates the returned fields. This is self-evidently distinct from the custody/ETF-centric siblings, so an agent can route to it without opening a schema.

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

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

Gives explicit use cases ('what did X say about Y', sourcing a quote), which is clear contextual guidance. It stops short of naming an alternative or a when-not-to-use condition (e.g., vs. find_source for sourcing generally), so it is not 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?

With no annotations the description carries the full load, and it does disclose meaningful behavior: the tool is a read that returns per-counterparty intelligence and, notably, 'Nothing is logged about the names passed in,' a real privacy assurance. It does not address auth requirements or rate limits, leaving some behavioral ground uncovered.

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 sentences, front-loaded with the purpose and ending on the privacy note. The middle sentence is a dense run-on enumerating five return fields, which is informative but heavy; a tighter list would read better without losing content.

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 and no annotations, the description must explain returns — and it does, enumerating custody model, SPOF, incidents, hardware rubric status, and corrections. Combined with the input-type taxonomy and privacy statement, an agent has everything needed to call it 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%, so the baseline is 3. The description adds value by expanding what 'names' accepts — exchanges, custodians, ETFs, IRA providers, hardware wallets — a taxonomy beyond the schema's examples, and frames 'since' as a change window, which reinforces its documented default. This is useful clarification rather than mere repetition.

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

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

States a specific resource (a holder's counterparties) and enumerates the exact return payload — custody model, single point of failure, registry incidents, hardware rubric status, and score changes since a date. This is clearly a batch monitoring tool, implicitly distinct from single-lookup siblings like get_custody_platform. It never names a sibling to route the agent explicitly, 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 concrete use cases — 'anything I should know about where I hold bitcoin' and scheduled checks — which tell the agent when this tool is the right call. It offers no exclusions or named alternatives (e.g. when to prefer get_custody_platform for a single counterparty), so it lacks the routing precision of a 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?

No annotations exist, so the description carries the full burden; it discloses the content types included and the default 30-day window, implying a safe read. It does not state return format, pagination, or whether the window can be widened, leaving real behavioral gaps.

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?

One dense sentence plus a short usage/default clause, with the core purpose front-loaded. The parenthetical category list is long but each item is informative, so little 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 one-parameter read tool with no output schema and no annotations, the description supplies purpose, scope, categories, use cases, and the default window. Missing only return-shape or staleness semantics, which are minor here.

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 'since' parameter, including its ISO format and default, so the schema already does the work. The description only restates the 30-day default, adding no syntax or format detail beyond it.

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

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

Names a specific verb+resource (what changed on Proof of Custody) and enumerates the change categories covered, which lets an agent distinguish it from siblings like list_custody_incidents or get_stablecoin_supply.

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 two concrete use cases — a scheduled briefing and checking whether a cached answer went stale — which is clear situational guidance. It does not name an alternative sibling or state when NOT to use it, so it stops short of a 5.

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