Pulse Verity

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

Goes well beyond the safety annotations by disclosing quota accounting semantics the annotations cannot express: the monthly allowance is account-wide across every key and app, perMinute is per-key, and the call itself does not consume allowance. That is exactly the kind of operational context an agent needs for budgeting API calls.

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 verb and endpoint, then three tight sentences of quota context. The one inefficiency is enumerating return fields ('plan, used, limit, remaining, resetAt...') when an output schema already exists, which is somewhat redundant ink for its purposes.

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 an output schema carrying return values and annotations covering the safety profile, the description fills the remaining gap: shared-vs-per-key quota semantics and the self-exempt accounting rule. Nothing an agent needs to call it correctly is missing, though it could say which sibling to use for plan changes.

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 baseline is 4 per the rubric. The description correctly refrains from inventing parameter semantics and instead spends its words on the response shape and quota behavior.

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+resource: reads this connection's Pulse Verity plan and usage, with the exact endpoint path and the returned field set. It is clearly distinct from price/history/batch siblings, though it never explicitly differentiates itself from the adjacent get_upgrade_options, which the mention of 'upgradeUrl (the plans page)' brushes against.

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 rather than stated: an agent can infer this is the tool for checking quota before heavy calls, but there is no explicit 'use this when...' line and no pointer to get_upgrade_options for actually changing plans. Context is discernible but 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?

Goes well past the readOnly/openWorld annotations: it explains that successful rows are individually signed, that per-symbol errors occur for unavailable rows, that the specific error code TOO_MANY_SYMBOLS is returned, that the v2 block signs quality fields while batch metadata is unsigned, and that there are no automatic retries.

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 the key limit, then moves to error/verification detail; nearly every clause carries operational information. It is dense with semicolons and could be split for readability, but 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?

An output schema exists so return shapes need no explanation, and the description still covers everything an agent needs to call correctly: plan-dependent limits, refusal code, signature scope, and verification path. Nothing material is missing.

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

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

With one parameter and the schema only carrying maxItems/minItems, the description supplies the non-obvious constraint that the effective cap is plan-dependent (lower than the schema's 100) and is discoverable via get_account_status. It adds real meaning beyond the schema, though it doesn't restate the ticker format the schema already documents.

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 with batching scope ('Read signed prices for up to 100 symbols per request'), which cleanly separates it from the singular get_index_price sibling. The distinctness is reinforced by naming the batch endpoint and the per-symbol error behavior.

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 routing guidance: check batchMaxSymbols via get_account_status, split the request when TOO_MANY_SYMBOLS is returned, and verify rows with verify_print. It stops short of stating explicitly when to prefer this over get_index_price for a single symbol, but the batching context makes that near-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?

Adds substantial behavior beyond the read-only/idempotent annotations: each call counts as one API call, the plan determines whether history is included and how far back, rangeClamped signals a shortened window, historyLimit names the limiting plan, signed rows require includeSignedRows=true, and an empty page means no recorded history rather than a zero price. That is exactly the operational context an agent cannot get from annotations.

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

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

Front-loaded with what is read, then dataset semantics, plan behavior, cost, pagination and the empty-page caveat in order of importance. Dense and mostly waste-free, though the dataset explanation partially restates the enum description in the schema.

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

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

Despite the tool's complexity (9 params, plan-driven clamping, signed vs unsigned data, pagination) the description covers every decision the agent must make. With an output schema present it needn't describe return shapes, and it still supplies the interpretive cues for rangeClamped, historyLimit and empty pages.

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 schema already documents all 9 parameters and the baseline is 3. The description adds value the schema lacks: the verified/reconstructed provenance distinction, the requirement that signed rows be verified with verify_print, and the cursor-reuse rule tying cursor to the same symbol/dataset/interval.

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?

Opens with a specific verb+resource ('Read price history for one crypto symbol from /api/index/v1/history') and enumerates the candle fields and intervals it returns. It implicitly distinguishes itself from lighter siblings like get_index_price and get_index_batch by scoping to candle history with metrics and pagination.

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 conditions for choosing dataset=verified vs reconstructed (reconstructed is 1h/1d only and unsigned at the time), plus concrete pagination instructions ('pass pagination.nextCursor as cursor with the same symbol, dataset and interval'). It does not explicitly route the agent away from sibling tools such as get_index_price or get_index_batch, so it falls short of full alternative coverage.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing signature semantics (v1 does not cover tier/confidence/dispersionBps/interval/sources/engine/cadence; v2 signs them with the price), that priceText must be preserved verbatim, and the critical failure mode that a stale or unavailable response means no price, never zero. This is exactly the kind of behavioral context 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-loads verb, resource, and endpoint, then layers verification and signing caveats. Four dense sentences with little waste, though the v1/v2 signing sentence is heavy enough that it borders on overload for a single-parameter read tool.

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?

Even though an output schema exists, the description fills the gaps that schema cannot: which returned fields are signed by which version, how to forward the print, and how to interpret an empty/stale result. An agent has everything needed to call and correctly chain this tool.

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

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

Schema description coverage is 100% and the single symbol parameter is already documented with example tickers, so baseline 3 applies. The 'coverage changes: use list_index_assets' note hints that some symbols may be uncovered, but it does not explain symbol format or validity rules beyond the schema.

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

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

States a specific verb and resource ('Get a current signed crypto index price') plus the underlying endpoint, which immediately distinguishes it from history/batch siblings. The mention of verify_print and list_index_assets anchors it in the tool family so an agent can place 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 clear follow-up routing: pass the whole print (v2 included) to verify_print, and use list_index_assets to discover assets. However, it never says when to prefer this over get_index_batch or get_index_history, so selection among the price-fetch siblings 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?

Annotations already cover the read-only/idempotent safety profile, and the description adds substantial non-obvious behavior: sampling and retention are bounded, a recorded print may differ from a live read, deltaMs is unsigned and measures sampling distance, and qualityRecorded is only populated for prints from 1 Oct 2026. The alias note further clarifies invocation behavior.

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 action and endpoint, then layers field-level caveats in short clauses. Dense and mostly waste-free, though the number of caveats (deltaMs sign, qualityRecorded cutoff, alias) makes it feel like a compact spec rather than a crisp summary.

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 lookup whose safety profile is in annotations and whose return shape is in an output schema, the description supplies everything else an agent needs: nearest-sample semantics, bounded sampling/retention, unit ambiguity of the answer, and the alias. Nothing material is missing.

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

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

Schema coverage is 50% (only symbol is documented), and the description compensates by stating the accepted formats for 'at' (ISO-8601 or epoch milliseconds), which the schema does not convey. It adds only partial interpretation guidance for that parameter, hence not a 5.

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 ('Get the recorded signed index print nearest a requested time') with the backing endpoint, and distinguishes the resource from a live read ('a recorded print need not equal a separate live read'), which separates it from siblings like get_index_price and get_index_history.

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 downstream guidance ('Check deltaMs', 'Preserve priceText, kid and the v2 block when present for verify_print') and discloses the legacy alias, so the agent knows how to consume the result and that the old name still works. It stops short of an explicit when-to-use-this-vs-the-live-read rule, so it is clear context rather than full 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?

Annotations already declare read-only, idempotent, non-destructive and closed-world, but the description adds genuinely new context: it does not count toward the allowance, and nothing is purchased by the tool or by opening a link (payment happens on Stripe). It also discloses the current-plan marking and recommendation logic. Return format is left to the output 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?

Purpose is front-loaded in the first clause and every subsequent sentence carries non-redundant information about side effects and recommendation behavior. The prose is dense and clause-heavy, which costs some readability, but there is little 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?

With an output schema present, return values need not be explained; the description still covers the key ambiguities an agent would face: no purchase occurs, links only open the portal, current-plan marking, and how refusal reasons drive recommendations. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema by explaining the interaction: reason supplies a non-most-recent refusal code, and a known refusal or supplied reason triggers a recommendation of the smallest fixing item. That relational context is not derivable from the enum alone.

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 (List) and resource (Pulse Verity plans, prepaid call packs, extra stream connections) with scope (limits, prices, portal links). It is unmistakably distinct from the sibling tools, which all concern index data, prints, or account status.

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 clear conditional usage: when a recent plan refusal is known or a reason code is supplied, the smallest fixing item is recommended, which tells the agent when and how to call it. It stops short of explicit when-not guidance or naming an alternative, but no sibling competes for this purpose.

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 valuable context beyond that: rows are unsigned, availability changes over time, total is a catalog count not a fresh-price count, and there is no automatic pagination. These are meaningful behavioral disclosures.

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?

Every sentence earns its place: endpoint, purpose, unsigned-data warning, availability/count caveat, pagination note. Front-loaded with the operation and scope, then caveats. No redundancy.

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

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

With an output schema present, the description needn't explain return values. It covers the unsafe/unsigned data caveat, mutation of availability, and pagination. The main gap is explaining the band and status filter semantics, which are important for effective querying.

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 only 25%, so the description must compensate. It explains pagination limits via 'bounded page' and 'No automatic pagination,' and the schema does document limit behavior well. However, the description does not explain the band or status enum semantics, which carry real meaning for filtering and are undocumented elsewhere.

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 ('Read one bounded page from /api/index/v1/verity/catalog') and clarifies scope ('Discover crypto symbols and their current coverage status and measured cadence'). It implicitly distinguishes from get_index_price/get_index_batch by warning those are for signed receipts.

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 names get_index_price and get_index_batch as alternatives for signed receipts, which routes the agent appropriately. It lacks explicit when-not-to-use conditions or guidance on combining filters, but the core 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 only say readOnly=false, destructive=false, idempotent=false, openWorld=true; the description goes well beyond them by stating the return is 'a durable receipt and duplicate flag, not a promise of a fix,' that 'no code or production behavior changes automatically,' and that the server cryptographically checks a signed quote against Verity's published keys. It also discloses how to check status afterward via GET /api/index/v1/feedback/<id>, which is real operational context an agent cannot infer from the annotations.

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

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

Purpose and the submission gate are front-loaded, and nearly every clause carries information. The quote sentence, however, is a long semicolon-chained run that is harder to parse than it needs to be, and could be split 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?

For a write tool with an output schema, the description covers the essentials: privacy constraints, side-effect profile, duplicate/receipt semantics, and follow-up status lookup. The remaining gap is that it never characterizes the required report fields or the surface enum, though the enum values are self-describing tool/endpoint names.

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 9 parameters, so the description must carry the load. It does this well for the nested quote object, naming price, at, source, grade, signature and kid and explaining why the signature matters, but it says nothing about the five required core fields (category, surface, expected, actual, reproduction) or about symbol, requestId and observedAt, leaving half the surface undocumented.

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 opens with a specific verb and resource: 'Write one structured bug, missing capability, or data quality report for private human triage.' That instantly separates it from every sibling, which are all read-only lookup tools (get_index_price, verify_print, list_index_assets), and it names the three report categories the tool accepts.

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 an explicit gating condition — 'Only submit when the user requests reporting' — plus concrete exclusions ('do not include keys, passwords, transcripts or attachments') and a conditional branch for price problems that tells the agent exactly which extra fields to add. There is no competing sibling for reporting, so the absence of a named alternative is not a gap.

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?

Far beyond the readOnly/idempotent annotations, it explains key ring caching (5 min TTL, 30 sec refresh on failure), kid selection semantics, bounded ring fallback for old prints, exactly what valid=true authenticates vs excludes, v2 record verification semantics, recordValid vs metadataSigned, and the important caveat that an invalid signature may not mean tampering. This is unusually rich behavioral disclosure.

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 long and dense, packed with important caveats, but it is not front-loaded; key verification scope warnings appear late. While every sentence conveys non-trivial information, the lack of structure (paragraphs/bullets) makes it harder to scan than necessary for an 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?

Given the 19-parameter schema, output schema, and nested v2 object, the description covers the verification logic and output semantics thoroughly. It could go further in explaining the many ancillary fields (cadence, interval, etc.), but it provides enough to invoke correctly and interpret results.

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 low (32%) across 19 parameters, but the description compensates selectively: it defines the canonical string components (symbol, priceText or String(price), at, grade), explains kid selection, and describes v2.signedFields/mismatches. However, many parameters (tier, engine, cadence, interval, confidence, dispersionBps, kind, closeDay, assetId) have no explanation in the description, leaving substantial gaps.

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 specifically states 'Verify a signed print locally with ECDSA P-256/SHA-256', naming the exact cryptographic operation and resource. It is clearly distinct from sibling tools like get_recorded_print or get_index_price, which fetch rather than verify.

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 verification scope and warnings ('require recordValid before trusting quality fields', 'indicative data must not be used for settlement'), but there is no explicit statement of when to choose this tool over alternatives or prerequisites for calling it.

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