keryx

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: owner-only access, the required deliverable:read scope, that historical 'remedy:none' and missing response window remain visible, and that several deliverable variants are unavailable. This goes meaningfully beyond the structured hints.

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 short and front-loads the access scope, with no filler sentences. However, the telegraphic, colon-heavy phrasing ('Historical remedy:none') sacrifices readability and makes the structure harder to follow than the length warrants.

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 carry return-value expectations, and it partially does by noting that historical remedy:none and the missing response window stay visible. Access and availability constraints are covered. But the identifier semantics and the exact returned fields remain unspecified, leaving gaps for a read tool of this specialty.

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 single required parameter 'id' has only a regex pattern with no textual explanation. The description adds no information about the id's expected form (e.g. the a2a_<64 hex> shape) or its source, so it fails to compensate for the documentation gap.

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 resource ('prepaid A2A deliverable state') and the read intent is clear from the name/title, but the phrasing is dense jargon that is hard to parse on first read. It does draw a boundary against a semantic sibling ('Not source-decision agreement or semantic verification'), which helps differentiate. The core purpose is inferable but not stated in plain terms.

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 or routing to alternatives such as deliverable_acceptance_submit or evidence_draft. 'Requires explicit deliverable:read' is a permission prerequisite rather than usage guidance. The negative clause hints at scope exclusions but does not tell the agent when this tool is the right choice.

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 idempotentHint=true and destructiveHint=false, but the description adds material context beyond them: the required deliverable:write scope, the negative guarantee that storing a revise/reject request does not execute a revision, refund, recharge, reservation change or reward clawback, and that publishState only shares state/timestamp. These side-effect boundaries are exactly what an agent needs before calling a write 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?

Five tight sentences, front-loaded with the action and choices, then prerequisites, then side-effect boundaries. Nothing is boilerplate, though the trailing MCP-client retention note is the least load-bearing sentence.

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 nested-object write tool with 0% schema coverage and no output schema, the description covers auth, idempotency, side-effect scope, and field-level meaning well. Gaps are the semantics of the `id` token and what happens if expectedRevision is stale, which a caller would want before committing a decision.

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%, so the description must compensate, and it largely does: it maps 'expected current revision and digests' to expectedRevision/originalFingerprint/deliveredDigest, calls out the idempotency key, explains reason as private and publishState as sharing state/timestamp only. The top-level `id` parameter and the revise-vs-reject conflict behavior remain unexplained, keeping it short of 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?

Specific verb ('Record') plus the exact resource (an acceptance decision on the original customer's retained delivery) and an enumeration of the three possible choices (Accept / Request revision / Reject). An agent can distinguish this from the sibling deliverable_acceptance_read without opening either schema.

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

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

The framing 'for the original customer's exact retained delivery' and the required revision/digest preconditions imply this is the write counterpart to deliverable_acceptance_read, but the description never explicitly states when to use this versus that sibling or when not to submit. Usage is inferred rather than stated.

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 declare read-only/idempotent/closed-world, but the description adds real behavioral context: deterministic lexical comparison rather than semantic review, the four verdict types with verbatim excerpts, the rule that a source without supplied text is always source-unavailable, the absence of network/model/database/history/payment I/O, and a client-side retention/privacy warning.

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?

Dense and front-loaded: the core split-bind-compare action leads, verdict/return behavior follows, and constraints and the privacy caveat are correctly placed last. Five information-packed sentences are on the long side, but each earns its place and nothing is redundant.

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

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

With no output schema, the description carries the burden of explaining return values and does so (verdict types plus verbatim excerpts), while annotations cover the safety profile. For a one-parameter tool with closed-world, idempotent, read-only behavior, nothing needed to call it correctly 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?

The single parameter is fully documented in the schema (100% coverage), which sets a baseline of 3, but the description adds format-level meaning the schema lacks: the citation markers accepted ([3], cite{key}, [@key], Author (Year)) and the reference-list formats (BibTeX, RIS, DOI/link). That goes beyond restating 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 chain (split, bind, compare) over a precise resource (a private passage's cited claims vs supplied source text) and enumerates the exact verdict vocabulary. It is clearly distinguishable from siblings like evidence_draft or paper_lookup without opening 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 clear context for when this applies (comparing a draft's cited claims against source text the caller supplies) and implicitly rules out fetching by stating 'No fetching, model, database, history...'. It never names an alternative sibling or an explicit when-not condition, so it stops short of full routing guidance.

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

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

Beyond the readOnly/idempotent/closed-world annotations, the description discloses substantial behavior: statements naming a paper are withheld unless a citation and a selected retained excerpt accompany them, exported citations and BibTeX/RIS entries are validated one-to-one, and exact matching explicitly does NOT authenticate imported reports or verify semantic support. The privacy/retention caveat about the MCP client also adds operational 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?

Purpose is front-loaded and each sentence carries real content: withholding rule, one-to-one validation, matching caveat, I/O boundary, retention note. It is dense and jargon-heavy ("Include paper records," "Keryx report rows"), which slows parsing, but there is little outright 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, the description must convey what comes back, and it does: an exported draft/citations with a defined withholding and validation behavior, plus a note that the returned draft may be retained client-side. Combined with 100% parameter coverage, an agent has enough to invoke it correctly, though the return structure itself remains abstract.

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 there is only one parameter, so the baseline is 3. The description elaborates on what is assembled and mentions "caller-supplied" inputs, but it does not add format or contract detail for the `draft` parameter beyond what the schema already documents (byte limit, append/regenerate modes, readingStatuses).

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 ("Assemble") and clearly scopes the resource: a private retained-evidence draft built from claim spans, quote themes, saved Include paper records, and caller-supplied Keryx report rows. An agent can tell this is an assembly/composition step rather than a fetch or check, though no sibling (e.g. draft_check, evidence_procurement) is named to sharpen 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?

Usage is implied through negative constraints — "No fetching, model, database, history, payment or reward I/O" — which indirectly steers an agent away from evidence_procurement or history_* tools when those I/O classes are needed. However, there is no explicit "use this when / not when" statement and no alternative tool is named, leaving routing 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 declare read-only, idempotent, non-destructive, closed-world behavior, and the description is consistent with them. It adds meaningful context beyond annotations: signature/content-binding checks do not establish delivery quality or buyer authority, selections and reviews are assertions not financial authorization, and inputs/results may be retained by the MCP client. These are genuine behavioral/liability boundaries a caller needs.

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, which is good, but the description then stacks several negative clauses and disclaimers ('does not establish...', 'No fetching...', 'are assertions, not...') that read as legal boilerplate and dilute the operational signal. It is somewhat over-long for a single-parameter 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?

With no output schema, the description should carry more of the return-value burden, and it only touches results obliquely ('Inputs and results may be retained'). Still, for a one-param, read-only, closed-world tool it supplies strong behavioral and privacy context, leaving mainly the output shape under-described.

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 'packet' parameter is documented there with size and version constraints. The description adds little about the parameter itself beyond 'Amounts are exact integer micro-USDC', which concerns packet contents rather than the param's shape. 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?

The description names a specific verb and resource: 'Assess missing evidence requirements, supplied provider offers, selections, deliveries and caller reviews with the shared private evidence procurement contract.' An agent can grasp it inspects/procures private evidence packets. However, it does not explicitly distinguish itself from near siblings like evidence_draft or deliverable_acceptance_submit, so differentiation is only implicit.

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 when-to-use or when-not-to-use guidance. The clause 'No fetching, model, provider, database, history, purchase, escrow or reward I/O' lists what it will not do, but never states the condition under which an agent should choose this tool over evidence_draft or the deliverable_acceptance siblings.

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 establish readOnly/idempotent/non-destructive/non-open-world, so the bar is lower. The description does add real behavior beyond them: a required scope (history:read) and explicit truncation/continuation for the export. However, phrases like "Current store, bounded filters/keysets; missing membership/claims stay explicit" are too cryptic to count as clear 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 four sentences contain no filler, but they open with the least intelligible line (the API-contract reference) instead of front-loading a plain statement of what the export does. Density without orientation costs it clarity.

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 and no output schema, safety is covered by annotations, but the description asserts truncation/continuation and "explicit" membership/claim handling without explaining how continuation is driven or what the output looks like. Adequate for invocation but leaves meaningful gaps.

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 and schema coverage is 100%, so there is nothing for the description to clarify. Per the rubric this is the baseline 4.

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

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

The description leans on an opaque internal reference ("Same owner-private v2 contract as /api/me/asks") rather than plainly stating what the tool returns, so the actual purpose is carried mostly by the title. It does convey scope (owner-private history metadata export) and implicitly separates itself from research/payment/public-ledger siblings via the exclusion list, but the verb+resource framing is buried in jargon.

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

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

It gives a prerequisite ("Explicit history:read required") but never states when to choose this over the many close siblings (history_owned_read, history_private_jobs_export, run_owner_export). The trailing exclusions ("No research, signer, payment, public-owner selector") hint at boundaries but are capability limits, not routing guidance to alternatives.

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 readOnly/idempotent/non-destructive/closed-world, yet the description adds genuine behavioral context: an explicit history:read scope requirement, that it reads the 'current store' with bounded filters/keysets, that missing membership/claims stay explicit rather than silently empty, and that no mutation authority exists. This is real value beyond the annotations, though the phrasing is cryptic.

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 text is terse but telegraphic and jargon-heavy ('owner-private v2 contract', 'bounded filters/keysets', 'stay explicit'), and it front-loads an unresolvable endpoint reference instead of the core purpose. Compactness here reflects under-specification rather than deliberate concision.

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, so the description would need to carry more return-shape information, and it only partially does (truncation/continuation for export, explicit missing membership). For a security-scoped read tool acknowledged as complex, the reliance on an external '/api/me/asks' contract leaves an agent without a self-contained picture.

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 zero parameters the baseline would be 4, but the description references 'bounded filters/keysets' that the empty schema does not expose, creating a mismatch an agent must reconcile. The schema provides no coverage to clarify, so the description neither compensates nor avoids confusion.

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 title 'Read your owned history' plus the read verb identify this as a history-read operation, and the exclusions ('No research, signer, payment, public-owner selector or mutation authority') carve out scope relative to siblings. But 'Same owner-private v2 contract as /api/me/asks' points to an external endpoint an agent cannot resolve, and the resource being read (history of what?) is never stated plainly. The purpose is only inferable.

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?

'Explicit history:read required' states a prerequisite, and the contrast with export ('Export has explicit truncation/continuation') implicitly frames the non-export case. However, nothing routes the agent among the many nearby siblings (history_read, history_private_jobs_list, history_export), so when-to-use 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 declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false. The description goes further by disclosing auth scoping, the required history:read scope, pagination behavior ('bounded scan/continuation'), and a genuine data-quality caveat ('unknown provenance and NULL own spend/creator settlement remain explicit'). That is meaningful behavioral context beyond the structured hints.

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 access scope, which is good, but the prose is dense jargon-heavy fragments, and the trailing laundry list ('No wallet selector, public report/share link, model prompt, research, source fetch, signer, purchase or mutation authority') spends a full sentence on negatives of low routing value.

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 values need not be explained, and annotations carry the safety profile. The remaining gaps are the undocumented 'id' parameter and the lack of any sibling routing, which for a member of a large history_* family leaves the agent under-informed about correct invocation.

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%, so the description must carry the parameter burden, and it does not. The single 'id' parameter is never mentioned; only the schema pattern (^prv_[a-f0-9]{64}$) hints at its format, and the description adds no explanation of what identifier to pass.

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 the resource ('completed private jobs in the current store') and scope ('private data for this authenticated caller only'), and the title adds 'Read one of your completed private results'. However the verb is absent from the description and it never distinguishes this detail tool from siblings like history_private_jobs_list or history_private_jobs_export, leaving the agent to infer the single-record semantics from the name alone.

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 one prerequisite ('explicit history:read required') and a negative constraint ('No wallet selector'), which is useful. But it gives no when-to-use guidance relative to the many sibling history_* tools (list vs export vs detail vs owned_read), so the agent cannot route between them from this text.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value on top: bounded scan behavior, continuation handling, "complete/truncated" status, and that "result bodies are excluded." This is genuinely useful disclosure about output shape and safety posture beyond 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?

The scope and permission constraints are front-loaded effectively, but the long negative list ("No wallet selector, public report/share link, model prompt, research, source fetch, signer, purchase or mutation authority") is padded and partly redundant with the readOnly annotation. Dense but not maximally efficient.

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

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

An output schema exists so return values needn't be explained, and the description covers auth, scope, and pagination semantics well. However, for a 7-parameter tool where nothing documents the parameters, the definition is not fully complete for correct invocation.

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?

All 7 parameters have 0% schema description coverage and the description explains none of them. "Bounded scan/continuation" only loosely gestures at limit/cursor; from, to, search, network, and surface are entirely undocumented in both places, leaving the agent to infer semantics from enum values and patterns 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 states a specific verb+resource ("Manual finite JSON metadata export") and narrows the scope precisely: "Exact-payer completed private jobs in the current store." It is clearly different from history_private_jobs_list/detail in intent, though it never names those siblings directly, so it falls 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?

It gives prerequisite context ("Private data for this authenticated caller only," "explicit history:read required") but never says when to choose this over history_private_jobs_list, history_private_jobs_detail, history_export, or run_owner_export. Usage is implied by scope rather than stated as an explicit when/when-not routing rule.

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

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

Annotations already cover read-only/idempotent/non-destructive/closed-world, and the description adds real context beyond them: caller-scoped privacy, the history:read permission requirement, bounded scan with continuation (pagination behavior), and explicit handling of unknown provenance and NULL spend/settlement values. This materially helps an agent predict 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?

Three sentences, front-loaded with the privacy scope, and distinctly terse for the amount of information conveyed. The long negation list is dense but each clause removes a specific capability, so most sentences earn their 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. But with 7 undocumented parameters and no explicit alternatives, the definition is only adequate for a tool of this complexity.

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 7 parameters, so the description must compensate, and it largely does not. It explains the absence of a wallet selector and hints at limit/cursor via 'bounded scan/continuation', but to, from, search, network, and surface are left for the agent to infer from names 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?

States a specific verb+resource (listing completed private jobs) scoped to 'this authenticated caller' in 'the current store', and the title reinforces it. It also disambiguates from siblings via the negative list (no public report/share link, no research). However, dense jargon like 'exact-payer' and 'creator settlement' muddies the core purpose slightly.

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 declares a prerequisite ('explicit history:read required') and negatives ('No wallet selector'), which imply usage boundaries, but it never says when to choose this over history_owned_read or history_private_jobs_detail. Guidance is inferred rather than stated.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description still adds real value beyond that: it discloses pagination ('bounded pages'), a required scope, case-sensitive literal search semantics, and two caveats about interpretation ('storeNetwork describes the deployment, not per-run settlement'; 'Recorded spend/allocation is not a payment receipt').

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?

Compact and front-loaded: the purpose leads, followed by prerequisite and caveats, with no filler sentences. The telegraphic clause stacking ('No wallet selector, linked accounts, archive, private jobs, research or payment') hurts readability slightly but every clause carries information.

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?

Annotations are rich and there is no output schema to explain, so the remaining burden is parameter meaning and the description partly meets it. With 7 parameters at 0% schema coverage, the absence of any explanation for from/to, funding, and surface leaves an agent guessing at field semantics.

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% for 7 parameters, so the description carries the full burden. It clarifies pagination (limit/cursor) and search semantics ('literal case-sensitive'), but says nothing about from/to date behavior, the funding enum values, the surface enum values, or the 50-item limit. It even references a 'storeNetwork' concept that is not a parameter 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 ('Read bounded pages') and a scoped resource ('the verified API-key wallet's ordinary current-store runs'), and the trailing 'No wallet selector, linked accounts, archive, private jobs, research or payment' carves it away from the many history_* and research siblings. The jargon ('ordinary current-store runs') is opaque but the resource boundary is still discernible.

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?

'Requires explicit history:read' states a prerequisite, and the exclusion list clearly signals which adjacent scopes (archive, private jobs, research, payment) belong to other tools. It never names a specific sibling to route to, so the guidance is strong but stops short of explicit alternatives.

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 establish readOnly/idempotent/non-destructive, so the bar is low; the description nonetheless adds real context: no spending or execution authority, privacy boundaries (exact books and customer jobs stay private), null-on-missing-capability behavior, and precise timing semantics (createdAt→updatedAt, not first-answer or settlement). This is well beyond what the annotations convey.

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 sentences, front-loaded with the verb and scope, each carrying distinct information (scope, timing definition, null behavior, authority/privacy limits). Dense but not padded, though the latency-cohort enumeration is slightly jargon-heavy.

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 input schema fields and no output schema, the description must describe the returned shape, which it does reasonably well (latency cohorts, hold/review rationale, nulls). The only gap is the absence of explicit routing guidance to sibling 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 ('Observe') and a concrete resource set: public prepaid research operations, queue, completion latency cohorts, and hold/review rationale. It is distinguishable from ledger/outcome siblings by its focus on operational latency cohorts, though it never names a sibling to contrast with.

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

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

The description never says when to call this versus keryx_status, keryx_public_job_ledger, or keryx_purchase_outcomes, all of which are adjacent observability tools. Usage is only weakly implied by the scope of what is observed.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: pending, ambiguous, and batched-attribution legs are excluded from settled totals, and a checksum is explicitly not proof of authenticity or independent settlement. These caveats materially change how an agent should interpret results.

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 purpose is front-loaded, but the opening sentence is a comma-spliced fragment stack ('partial selected-network public web-dispatch transfer ledger and balanced exact micro-USDC vouchers') that is hard to parse. Density serves the tool's many caveats, yet the phrasing could be tightened without losing any of the disclosed constraints.

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

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

For a read-only, single-parameter ledger with no output schema, the description covers the essential gaps: what the ledger contains, what never enters settled totals, what data is deliberately absent, the export endpoint, and the checksum caveat. An agent can call and correctly interpret this tool from the description plus annotations alone.

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 single 'days' parameter is undocumented in the schema, so the description must carry it. It supplies the meaningful missing piece — the default of 7 — and reiterates the 1–31 bounds; only the bounds duplicate the schema's min/max, so added value is real but modest for a one-parameter tool.

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-resource pair (inspect a public web-dispatch transfer ledger and micro-USDC vouchers) and scopes it as 'partial' and 'selected-network'. The 'public' qualifier implicitly separates it from the private siblings (history_private_jobs_*, history_private_jobs_detail), though the heavy domain jargon ('balanced exact micro-USDC vouchers', 'sponsorship') blurs the purpose for an outside agent.

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?

Provides a strong when-not boundary by enumerating what the ledger deliberately excludes (customer questions/identities, private invoices, complete business books, margin, cash balance, signing/execution authority), which steers the agent toward the private/job-detail siblings. It also notes browser funding and Keryx sponsorship are separate concerns. It stops short of naming an explicit alternative tool to use instead.

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 annotations already covering the safety profile (readOnly, idempotent, non-destructive, closed-world), the description goes further and discloses real limitations: 'Recorded settlement is not revalidated on chain' and unmeasured cohort/regret metrics. That caveat-load is genuinely useful for interpreting results, though it stops short of describing pagination, error behavior, or what an empty dispatch returns.

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 purpose and the return shape, and the teletype-style negative list compresses several exclusions into one sentence. It is dense and jargon-heavy ('exact-version', 'micro-USDC'), which costs some readability, but little is redundant.

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, so the description appropriately enumerates the return contents (bounded sample counts, citation hit rate, calibration bands, integer micro-USDC cost) plus the limits on those values. For a single-param, read-only tool this is close to complete, missing only error/empty-case behavior.

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%, so the description carries the burden, and it does add meaning by requiring an existing dispatch ID and forbidding a URL. However, it does not convey the identifier's regex constraints, length limits, or format beyond that single restriction, so it only partially compensates.

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 a public dispatch's retained exact-version BUY/citation/payment observations'), so the agent knows the operation and the data domain. It does not name a sibling tool, but the exclusion list ('No research, paid read, current-source backfill...') implicitly separates it from `research`. Clear, though sibling differentiation is left to inference 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?

'Use an existing dispatch ID, never a URL' is a concrete usage constraint, and the negative list scopes out adjacent activities (research, paid read, backfill). It never names a specific alternative tool to prefer, so it falls short of explicit when-to-use/alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond them: settlement is not independently revalidated, live learned selection and exploration are withheld with zero allowance, and private inspection is excluded. This is meaningful disclosure of data-provenance and staleness limits.

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 purpose is front-loaded and most sentences are terse, but the middle is an unstructured noun list of returned artifacts and the value is diluted by repeated negative clauses ('No questions, wallets or receipt identifiers' ... 'No research, source read, payment...'). Some sentences earn their place; the list-style fragments are harder to parse than 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?

For a tool with no output schema, the description usefully enumerates the returned fields (topics, counts, citation contribution, average access price, uncertainty, shift flag) and behavioral limits. But the sole input parameter is undocumented and there is no statement of the identifying key's meaning, so an agent could call it without understanding what sourceId must be.

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

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

There is a single required parameter (sourceId) with 0% schema description coverage, so the description carries the burden of explaining it. It never mentions sourceId, its format, or what constitutes a valid identifier, leaving the agent with only the regex/pattern 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 gives a specific verb ('Read') and a resource ('bounded observational source/topic record') and constrains scope to write-time independently classified/funded outside observations. However, the phrasing is heavily jargon-laden ('bounded observational source/topic record', 'recorded citation contribution') and never names or contrasts any sibling tool, so the agent must infer which read tool among the many history_* and profile_* siblings applies.

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 qualification rules (only write-time independently classified/funded outside observations; owners, unknown and private history excluded) and lists negative capabilities (no research, source read, payment, private inspection or policy activation), which implicitly routes away from sibling tools like research or history_private_jobs_read. But there is no explicit 'use this when' or named alternative, so the guidance is implied rather than directive.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns payment behavior and caller tier, which provides some extra context beyond annotations, but does not elaborate on side effects or details of the return. No contradiction with annotations.

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

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

The description is a single sentence, front-loaded with the action. It is concise but uses the imperative 'Describe' rather than a declarative statement, which slightly reduces clarity. No wasted words.

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

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

The description mentions the high-level outputs (surface, payment, caller tier) but does not detail what 'MCP surface' means or the format of the response. Without an output schema, a more explicit description of the return would improve completeness. It is adequate but leaves ambiguity.

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

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

There are 0 parameters, so schema coverage is trivial (100%). The description does not need to add parameter meaning. Baseline of 4 is appropriate given no parameters.

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

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

The description clearly states the tool describes the MCP surface, payment behavior, and active caller tier. It is a specific verb-resource pairing, though it could be more precise (e.g., 'returns information about...'). It distinguishes from the sibling 'research' tool by implying different functionality.

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?

No guidance on when to use this tool versus alternatives. The description does not provide context for selection or exclusions. The only sibling is 'research', but no comparison is made.

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 carry readOnly, idempotent and non-destructive hints, but the description adds meaningful behavioral context beyond them: the API-key scope requirement, the disabled-by-default gate, and an explicit list of authorities it does NOT have (cash probe, signer, custody, spending, release, refund, scheduler). This clarifies the safe blast radius well.

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 action and the key auth gate, and no sentence is pure filler. But 'Partial native history remains unknown with zero safe/advisory surplus' is near-opaque jargon that consumes space without conveying actionable meaning to 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?

No output schema exists, so the description must frame the operation, which it does via scope, gating, and explicit authority exclusions for a zero-parameter read. It is largely complete for a read tool, with only the return-shape and the ambiguous 'projection' semantics left unexplained.

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 (schema coverage 100%, additionalProperties false), so there is no parameter surface to document; baseline 4 applies. The description reinforces the zero-selector design with 'No caller owner/role selectors.'

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 clear verb (Read) and resource (obligation projection for the server-delegated reader), and the title reinforces 'Read delegated Operator obligations'. The qualifiers 'conservative' and 'projection' are opaque jargon, but the core action is discernible and it is distinguishable from history/profile siblings.

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

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

It specifies a real precondition -- requires server-delegated reader identity and explicit operator:read API-key scope, and is disabled without protected reader/role configuration. However, it never names alternatives or tells the agent when to prefer a sibling like history_read or keryx_operator_status, leaving selection 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 read-only/idempotent/open-world safety, but the description adds real behavioral context: default reads retained catalog metadata with observation times, external lookup is capped at two requests with no paper-body reading, and unknown fields (missing DOI, peer review, withdrawal/replacement status) are explicitly disclosed as 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?

Purpose is front-loaded and every clause carries information, but the single dense block repeats the same ideas ('without research or payment' vs 'before requesting paid research'; 'no paper-body reading' vs 'original paper text is not required'), so it is longer than strictly needed.

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 compensates by describing the return shape (field-scoped bibliography card with provenance, short reference, reusable BibTeX/RIS) and its limitations, plus full parameter coverage via the schema. Nothing needed to call the tool correctly 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 it by framing searchRepositories as an opt-in external call with a request cap ('at most two requests') and clarifying that language affects only bibliography labels, not preserved titles/authors.

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 and resource set: 'Find paper titles, recorded contributors, DOI and exact repository versions.' It also implicitly distinguishes itself from the paid 'research'/'research_monthly' siblings by scoping the tool to recorded catalog metadata rather than full-text research.

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 routing: use it for exact title/author/year/journal/DOI/version questions 'before requesting paid research.' It also constrains the one risky parameter ('Set searchRepositories=true only to explicitly send the query to arXiv/Crossref'), which is a clear when-not rule.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the required authorization scope and explicitly rules out side effects (no OAuth, no linking/unlinking, no payment) and any target selection. It stops short of describing the returned payload, but the behavioral surface is well disclosed.

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

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

Three short sentences, front-loaded with what is read before the constraints. Every clause earns its place: scope requirement, exclusions, and the pointer to the interactive linking page. No filler or restated 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?

For a zero-parameter read tool with full annotation coverage, the description supplies purpose, auth scope, exclusions and the mutation alternative, which is enough to invoke it correctly. The only remaining gap is the shape of the returned identity data, which matters slightly since 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?

The tool takes no parameters at all (0 params, additionalProperties false), so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter documentation gap exists.

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 (read) and resource (the verified key owner's saved ORCID/GitHub identities), with the exact scope qualifier 'verified key owner's' that tells the agent there is no wallet/target selection. It also enumerates what it is not (wallet selector, provider OAuth, linking, unlinking, research, payment), which separates it from linking flows and from sibling read tools like profile_read and research.

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 precondition ('Requires explicit profile:read scope') and redirects the mutating counterpart to the private profile browser page for interactive linking. It does not name a sibling tool as the alternative for reading other profile data, so the routing guidance stops just short of fully explicit.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the authorization requirement (explicit profile:read scope) and the nature of the payload (private profile plus attributed activity), which annotations cannot convey.

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 primary action and followed by the authorization precondition and the exclusion boundary. No filler, no repetition of the 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 no parameters, no output schema, and a fully self-contained schema, the description carries only the burden of stating what is returned and under what authorization. It does that ('private profile and attributed activity', 'profile:read scope'), though it gives no detail on the shape of the returned payload.

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 for the description to disambiguate, and the schema is trivially complete.

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 (read) and resource (the verified key owner's private profile and attributed activity), and explicitly scopes out public identity, research, and payment data. This lets an agent distinguish it from sibling tools like profile_identities_read, research, and keryx_purchase_outcomes without opening 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?

The description names the required 'profile:read' scope, which is actionable precondition guidance, and the exclusion clause ('No public identity, research or payment') implicitly routes the agent away from this tool for those needs. It stops short of naming the alternative tools to use instead, so it is clear context without explicit alternatives.

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 non-readonly, idempotent, non-destructive, closed-world semantics, so the bar is lower. The description still adds real value beyond them: the required profile:write scope, the fact that this is a full replacement, and the exclusion of wallet/identity/payment concerns. It omits validation-failure behavior, which keeps 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 tight sentences: purpose first, then the scope prerequisite, then the boundary exclusions. Every sentence carries information an agent needs before calling, and nothing is repeated from the schema or annotations.

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 mutation with no output schema, the description covers purpose, auth requirement, replacement semantics, and scope exclusions, which is enough to call it correctly. The only gap is what happens on invalid handles/links or rejected scope, which an agent might want to anticipate.

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 nested schema description already spells out 'Complete replacement; empty text clears a field' along with link constraints, so the schema carries the load. The description's field list (display name, handle, bio/purpose, links) mirrors the schema without adding format or syntax detail, landing at the baseline 3.

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 ('Replace the verified key owner's private display name, handle, one-line bio/purpose and links') and enumerates exactly which fields are affected. It is unambiguous against profile_read / profile_identities_read by virtue of the update verb, but it never names a sibling explicitly, so it stops short of full differentiation.

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

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

Gives a clear precondition ('Requires explicit profile:write scope') and draws explicit boundaries ('No wallet selector or identity verification; no payment/history changes'), which tells the agent when this tool is and is not the right call. It does not, however, point to profile_read as the alternative for read-only needs.

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, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description's 'Never buys or redeems a plan' reinforces read-only behavior but is largely redundant with readOnlyHint=true; it adds only the mild clarification that this is a quote/handoff read rather than a transaction.

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 with the action front-loaded and no filler. The 'four-request, 30-day' phrase is dense but compact rather than padded.

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 carry some burden for explaining what comes back; it only gestures at this ('The current quote identifies its payment network') and leaves 'handoff' and the four requests undefined. Adequate given the rich annotations and zero parameters, but not 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 the baseline is 4. There is nothing for the description to disambiguate, and it does not need to.

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 (Read) and resource (the Research Monthly quote and handoff), so an agent knows this retrieves an artifact rather than performing an action. It stops short of differentiating itself from the sibling tools keryx_status and research, and the jargon 'four-request, 30-day' is not unpacked.

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 a capability exclusion ('Never buys or redeems a plan'), which is a weak when-not signal, but no guidance on when to pick this over keryx_status or research. The agent is left to infer selection criteria.

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 establish readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real context beyond them—the required history:read scope on the verified key, no wallet selector or signing, and the storage-admission prerequisite. These are meaningful auth and prerequisite disclosures, though the phrasing is cryptic rather than plain.

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 with the operative clause front-loaded and little outright waste. But the density is achieved through opaque terminology ("current-store," "storage admission") rather than clarity, so it is terse without being readily parseable.

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, no schema parameter descriptions, and annotations covering only the safety profile, the description should carry more. It covers auth prerequisites but omits any explanation of the two required params or what an export returns, leaving significant gaps for an agent 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 0% and both parameters (id, requestId) are undocumented in the schema, yet the description explains neither—it never mentions what id or requestId identify, nor their relationship. With two required, undescribed params, the description fails to compensate for the coverage gap.

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 an "Owner-private current-store read using the verified key's explicit history:read scope," which conveys that it reads the owner's own record under a specific scope. However, the title says "Export" while the body says "read," and the jargon ("current-store," "storage admission") obscures the core action, leaving it unclear how this differs from siblings like history_export or history_owned_read.

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 partial when-not guidance by stating that "Visibility, defaults and erasure require the interactive web session" and that no wallet selector or signing is used, which routes some cases away. But it never names or distinguishes the closely related sibling tools (history_export, history_owned_read, history_private_jobs_export), so the agent must infer which export variant to pick.

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 readOnly/idempotent/closed-world/non-destructive, and the description goes beyond them by disclosing the required history:read scope, the admission requirement, and that no wallet selector or signing is involved. It does not state what happens on an unadmitted request or what the response contains, which keeps 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?

Three short, front-loaded sentences with no filler; the core scope statement leads. The density of unexpanded domain terms ('current-store', 'storage admission') costs a point in readability, not length.

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

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

With no output schema, the description should say what a read returns, and it doesn't; nor does it explain the id. It does cover authorization and session constraints well, which is the harder half, so it lands as adequate-but-incomplete rather than deficient.

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 single 'id' parameter has no pattern explanation, description, or example. The prose never mentions the identifier at all, so an agent gets zero help on what the id refers to or what form it takes, leaving a real gap for a 1-param required input.

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 read operation and a scope ('Owner-private current-store read using the verified key's explicit history:read scope'), but 'current-store' and 'question privacy' are internal jargon that never resolve into a concrete resource an agent can picture. It also does not differentiate itself from the many sibling reads (history_read, history_owned_read, profile_read, history_private_jobs_detail). The verb/resource pairing is present but opaque.

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?

'Visibility, defaults and erasure require the interactive web session' is a genuine when-not rule, and 'No wallet selector or signing' + 'Storage admission is required' are preconditions. However, no sibling alternative is named for the cases this tool doesn't cover, so routing remains implied rather than explicit.

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