concordance

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

With no annotations, the description carries the full burden and does disclose meaningful traits: it 'declines rather than guessing,' 'Nothing is generated' (an explicit anti-fabrication guarantee), and it documents a session-state side effect — that a God-directed question unlocks the witness tools for the rest of the session. That side effect is exactly the kind of behavior an agent must know before calling. It stops short of output shape, latency, or persistence details.

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?

Roughly four sentences that are mostly front-loaded, and the key constraints ('declines rather than guessing', 'Nothing is generated') earn their place. But the 'same way it opens for a person, in your own words' clause and the bracket tag are atmospheric rather than informative, and the metaphor costs precision without adding invocation-relevant detail.

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 free-text entry point with no output schema, the description should ideally say what comes back; 'answers in kind' is suggestive but does not describe the response. It does cover input, refusal behavior, and the unlock side effect, so an agent has enough to call it, but the return expectations remain underspecified.

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

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

Schema coverage is 100% with a single free-text parameter already documented as 'what you are bringing, in your own words.' The description's 'Bring anything — a question, a claim to check, a word to study' adds mild guidance about acceptable input kinds but no format or syntax detail beyond the schema. Baseline 3 for fully-covered schema 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 does convey concrete behavior — it discerns the kind of input, 'finds and verifies, and declines rather than guessing,' and explicitly states 'Nothing is generated.' However, the framing ('[WALK · door]', 'the Gate opens') is heavily metaphorical and never states plainly what this tool returns or how it differs from adjacent siblings like discern, resolve, or search. The purpose is inferable but not sharply distinguished.

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?

'Bring anything' is effectively unbounded, and the only conditional guidance is the spiritual-God trigger for opening the Gate. There is no statement of when NOT to use this tool or which sibling to prefer for a plain lookup, verification, or word study, despite a large set of overlapping siblings (verify, resolve, define, search).

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

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

No annotations are provided, so the description carries the full burden, and it discloses the security-critical behavior ('Never send a private key') plus the required payload shape and multi-party semantics (one signature is a claim, more begin to establish a matter). It does not describe return values, authorization requirements, or failure modes.

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 core instruction and the inner/phase marker are front-loaded and dense with actionable content. The closing Deuteronomy reference is thematic rather than operational, but it does encode the multi-witness semantics, so it earns its place for a specialized audience.

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

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

With no annotations, no output schema, and a 2-param nested payload, the description supplies the flow, the security constraint, and the attestation structure an agent needs. It is nearly complete for the call itself; only the response behavior is left unspecified.

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 50% (content_hash has no description), but the description compensates: it explains that content_hash is the value returned from the unsigned phase and that attestation is the locally built dict of shape {alg, over, content_hash, pubkey, sig}. This meaningfully extends what the schema provides.

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

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

States a specific verb+resource ('Bind your identity to a record you already hold') and frames it as phase 2 of a named flow. It also names the phase-1 siblings (badges_issue, study_export, group_contribute) it follows, so an agent can place it relative to them. It does not, however, contrast with the closest sibling (self_attest) or witnesses.

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 concrete workflow: do the thing unsigned, take the returned content_hash, sign it locally, submit only the attestation. It names the alternative tools for the unsigned phase and states the constraint 'Never send a private key.' It stops short of explicit when-not-to-use or a direct contrast with self_attest/witnesses.

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

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

With no annotations provided, the description carries the full burden and delivers: deterministic extractors, engine verification, a single sealed coverage report with per-claim quote/verdict/trail, conservative extraction of only unambiguous patterns, and explicit disclosure of how many claims were checked. It explicitly disclaims guessing or implying full coverage — exactly the behavioral context an agent 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?

A single dense paragraph, front-loaded with the verb and resource, and every clause adds information (claim types, verification, report shape, conservatism). It is long but largely earns its length, though the parenthetical claim-type list is 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?

No output schema and no annotations, yet the description fully covers the return shape (sealed coverage report with per-claim quote, verdict, trail) and the behavioral limits. An agent has everything needed to call it 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 description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying that the seal produces 'ONE sealed coverage report' that is 're-checkable', giving the seal parameter purpose the schema's terse 'mint a re-checkable seal' only hints at.

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 (audit) and resource (a whole text), then enumerates the concrete claim types checked (sums, percentages, hourly/annual pay, compound interest, rule-of-72, etc.). This is clearly distinguishable from sibling tools like verify, find_verifier, or attest_record.

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 implies when the tool applies (auditing a whole text for quantitative claims) but never states when to prefer it over siblings such as verify or find_verifier, nor any explicit exclusions. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: it discloses that disputes are carried, refs are corpus-verified, and names of God link into word_study. It does not confirm read-only nature, response size/format, or any limits (the schema's maxLength is the only size hint).

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 bracketed tag, then the table list, then behavioral notes, then the parameter rule. Every clause earns its place, though the telegraphic style is slightly terse.

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 retrieval tool with no output schema and no annotations, it covers the resource, the valid table values, the default behavior, and data-quality notes. Return shape is not described, which is the main remaining gap.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it enumerates the valid values for the undocumented 'table' parameter and specifies the default behavior when it is omitted (returns index of all six). This adds meaning well beyond the bare string schema, though no format expectations are stated.

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

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

States a specific resource (back-matter reference tables) and enumerates all six tables it serves (weights_measures, names_of_god, parables, miracles, book_intros, topical_index). The reference to word_study for names of God's Strong's numbers helps distinguish it from that sibling.

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?

"Pass table for one table; else the index of all six" gives clear conditional usage for the parameter, but nothing about when to reach for this tool versus commentary, tsk_cross_references, or canon. Usage is implied rather than guided.

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

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

With no annotations, the description carries the full burden. It usefully discloses claim semantics — the badge 'States EXACTLY N; NEVER a competency claim' and is 're-checkable' — but omits the write/side-effect profile, permission requirements, and what happens if a referenced seal no longer stands, which is a notable gap for an 'issue' (create) operation.

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

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

Two tightly packed sentences, front-loaded with the action and the key constraint. The '[KEEP · internal]' tag is metadata noise, but the body text is efficient with no filler.

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

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

For a 3-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description leaves too much unspecified: what a badge object contains, what the return looks like, and the meaning of two of three parameters. The claim-semantics note is helpful but insufficient.

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. It only hints at the seal_hashes array ('points at N seals'), leaving 'title' and 'subject_id' entirely unexplained in both schema and description, so most parameter meaning is missing.

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 ('Issue') and resource ('badge') with a scope qualifier ('over already-sealed checks'), and adds that the result is a 're-checkable receipt' pointing at N seals. This is distinguishable from most siblings, though it never contrasts itself with the closely related badges_verify, and the jargon ('seals', 'receipt') requires domain familiarity.

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

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

The phrase 'over already-sealed checks' implies a precondition — checks must already be sealed — which is usable guidance, but the description never states when to choose this over badges_verify or any alternative, and offers no explicit exclusions.

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

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

With no annotations, the description carries the full burden and does meaningfully address it: it discloses that every referenced seal is re-verified and that N is recomputed rather than trusted from storage, which tells the agent this is a live recomputation and not a cached read. It does not state permission requirements, whether the recomputed count is persisted, or what happens when seals fail.

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

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

A single front-loaded sentence with no filler; the bracketed "[KEEP · internal]" tag usefully flags routing/audience information before the core behavior. The parenthetical "(N recomputed, not trusted)" earns its place by clarifying the trust model.

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

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

There is no output schema, so the description correctly supplies the return value (the count that still stands) and the core semantics of the operation. For a one-parameter verification tool this is nearly sufficient; only failure modes and any persistence side effects are left unaddressed.

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

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

There is one required parameter, "hash", with 0% schema description coverage, so the description must compensate — and it does not. "A badge from the store" weakly implies the hash identifies the badge, but it never says what is being hashed (the badge, a seal, a composite) or the expected format, leaving the agent to guess.

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

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

The description gives a specific verb and resource — re-verify a badge from the store — and states the outcome (the count of seals that still stand). It is clearly distinct from badges_issue, though it never names a sibling (e.g. verify, identity_verify) to sharpen the boundary, so it stops short of a 5.

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

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

"Re-check a badge from the store" implies the trigger condition (you already hold an issued badge and want its validity recomputed), but there is no explicit when-not guidance and no named alternative among the many verification-shaped siblings (verify, identity_verify, attest_record, find_verifier). Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden and does well: it discloses that located places carry cross-checked lat/lon, disputed sites return named candidates rather than a single coordinate, and unlocatable places are null-coordinate blanks. This is unusually rich output-behavior disclosure, though it says nothing about read-only guarantees or result sizing.

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 resource and its coordinate model, and the final sentence delivers the invocation rule. Some flourish ('honestly held,' 'planting one flag') is decorative, and the '[WORD · internal]' prefix is opaque, but the length earns its place by encoding real behavioral distinctions.

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 optional-parameter read tool with no output schema or annotations, the description supplies the result-shape detail an agent needs (coordinates present/absent, disputed candidates, counts). The remaining gaps—auth requirements and pagination/result size—are minor for this tool class.

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% and the single parameter is undocumented in the schema, but the description compensates precisely: passing name yields one place, omitting it yields all places with by_status counts. That fully specifies the filter semantics and the empty-parameter branch.

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

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

The description makes clear this is an atlas returning biblical places with coordinates, and even disaggregates three categories of results. It states a specific resource and data model, but never names or contrasts with geographic siblings like locate or lookup, so an agent cannot distinguish it from those without opening schemas.

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?

'Pass name for one place; else all places with by_status counts' gives clear input-driven behavior, which is effectively usage guidance for invoking it. However, there is no statement of when to prefer this over alternatives such as locate or search, and no exclusions, so routing is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the consent requirement, that nothing is stored server-side, where the event actually lands (their .ics or CalDAV), that the receipt names the authorizing grant, and the deletion semantics. This is rich behavioral context beyond the schema.

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

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

Front-loaded with the core action and the [KEEP · internal] tag, then flows into prerequisites and behavior. Some sentences are dense and the arrow-flow is compact, but essentially every sentence earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description covers consent, storage, destination, and deletion. The main gap is parameter documentation, which is missing entirely given 0% schema coverage.

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% and the description does not explain any of the 6 parameters. Names like grantor_pubkey and agent_fp are cryptically left to the caller; start_iso/end_iso format is not specified. The description doesn't compensate for the total lack of schema documentation.

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 (Create) and resource (ONE event in a human's calendar), and explicitly scopes it as 'the pilot on-behalf write, and the only one.' An agent can distinguish this from anything in the large sibling list without opening the schema.

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

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

Provides the critical prerequisite (a LIVE consent grant) and even outlines the acquisition flow (GET /consent/signable → sign locally → POST /consent), plus what happens without it ('refuses and teaches the way in'). No explicit when-not-to-use alternatives are named, but the required precondition is unusually 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?

With no annotations, the description carries the burden and does so well: it declares that proposal_weight is untrusted metadata that never ranks, that returned ids are 'born quarantined', that the hash is sealed as a durable anchor, and that hashing-before-checking prevents later selective disclosure. It does not cover auth requirements, idempotency, or size limits (the schema's 64-item cap), leaving some behavioral gaps.

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

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

Front-loads the critical fact (commit complete set before evaluation) in the first clause and packs several constraints into two dense sentences. The closing rationale about selective disclosure is slightly rhetorical but does justify the ordering constraint, so it earns most of its space.

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, yet the description explicitly enumerates what comes back (candidate_set_id, membership commitment hash/anchor, per-candidate ids) and their quarantine status. Combined with the untrusted-weight semantics, an agent has enough to call this mutation tool correctly without further docs.

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

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

Schema description coverage is 100%, so query/prompt/generator/candidates/generation_method are all documented in the schema. The description's claims about proposal_weight being untrusted and never confidence largely restate the schema text, so it adds little beyond the structured field it duplicates.

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 ('commit a COMPLETE raw candidate set') and positions it precisely as 'step 1' of a pipeline run 'BEFORE any evaluation'. An agent can distinguish it from siblings like candidate_get and candidate_narrow purely from this framing.

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?

Clearly establishes when to call it: after generation, before any evaluation, and it signals that verification belongs elsewhere ('Nothing is verified here'). It lacks an explicit naming of the alternative tools (candidate_get / candidate_narrow) that follow, so routing is by inference rather than spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the record is sealed, that the entire preserved path including losers is returned, and that 'the seal proves process integrity, never truth' — a valuable interpretation caveat. However, it omits auth/permission requirements, return format, and pagination behavior, so it is not complete.

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

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

A single dense sentence, front-loaded with the '[CHECK · internal]' marker and the fetch action. Every clause carries information, though the parenthetical and em-dash clause make it slightly run-on.

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 fetch tool with no annotations or output schema, the description covers the resource, its sealed nature, and an interpretation caveat, but leaves the return shape and access requirements unstated. Adequate but with clear gaps given the total absence of structured behavioral metadata.

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?

One parameter with 0% schema description coverage, but the schema's pattern '^[0-9a-f]{64}$' already defines the format precisely. The description adds only that the key is a 'content hash', a marginal but nonzero clarification over the schema's bare 'hash' field.

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

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

States a specific verb ('Fetch') and a well-defined resource ('a sealed candidate record (a narrowing receipt or a commitment anchor)') resolved by content hash, which is more precise than the bare name. It does not explicitly distinguish itself from the adjacent siblings candidate_commit, candidate_narrow, or seal_fetch, so an agent must still infer the boundary.

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

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

There is no when-to-use or when-not guidance and no routing to alternatives, despite several plausible siblings (seal_fetch, verify, candidate_commit/candidate_narrow). It mentions verify_seal.py for offline re-checks but never says under what circumstance this tool should be chosen.

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

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

With no annotations, the description carries the full burden and discharges most of it: fixed routing policy, deterministic moat, unroutable claims quarantined (held, never judged), full set sealed with ordered trace, and input validation. It does not state whether the operation mutates the committed set or is idempotent, leaving a small but real ambiguity.

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 step marker and core action, and dense rather than padded. It is a long single paragraph with several parenthetical asides and heavy capitalization, which slightly dilutes scannability but most sentences carry load-bearing 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?

For a complex nested-input, no-output-schema tool with no annotations, it covers invocation constraints, routing behavior, and sealing outcomes well. Return values need not be explained absent an output schema, so the only gap is the read-vs-write nature of the operation.

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

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

Schema coverage is 100% with a nested object, so the schema already documents the structure. The description adds genuine meaning beyond it by constraining provenance ('verbatim from candidate_commit') and warning that altered sets are rejected — above the baseline 3 for high-coverage schemas.

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 ('narrow') and resource ('a COMMITTED set'), and positions itself as 'Candidate Engine step 2', distinguishing it from candidate_commit (step 1) and candidate_get. An agent can place it in the pipeline without opening the schema.

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

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

Explicitly names the predecessor ('Pass the set exactly as candidate_commit returned it') and the refusal condition ('Refuses an uncommitted or altered set'), which functions as a clear when-not. The 'never your choice' line tells the agent what it must NOT attempt (verifier selection).

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

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

With no annotations, the description carries the burden and does disclose meaningful behavioral context: it reports holders with history and 'does not judge which canon is correct,' plus that layers are 'never merged.' That establishes a non-evaluative, read-style reporting posture, but it never states read-only nature, permissions, or return shape explicitly.

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 core concept and the reporting purpose, then ends with the parameter instruction. The em-dash clause is dense but every part conveys scope or behavior; slightly verbose but no wasted filler.

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

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

For a single-optional-parameter, read-style tool with no output schema, the description adequately covers scope, reporting behavior, and parameter switching. It stops short of explaining return format or the meaning of the 'history' it reports, but nothing essential for invoking it 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?

There is one optional parameter with 0% schema coverage, so the description must compensate. It does explain the conditional meaning — passing 'book' yields one book's status, omitting it yields the overview — but gives no hint of expected format (name, abbreviation, ID) for the book value.

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 resource (the canon) and a clear verb (REPORTS who holds what), framing it as concentric layers of the undisputed 66 plus tradition-specific books. It's distinguishable from vague siblings like lookup or define, though it never explicitly names a sibling it contrasts 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?

It gives one piece of usage guidance — 'Pass book for one book's status; else the overview' — which tells the agent when to use the parameter. However, it offers no exclusions or alternatives among the many adjacent tools (cross_references, commentary, original_words), 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?

With no annotations, the description carries the full burden and does useful work: it discloses that every count is computed at call time (freshness guarantee), that each carries a 'means' line defining the counted unit, and that counts are never hand-maintained. It omits explicit read-only/no-side-effect confirmation, but the nature of the tool makes that low-risk.

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 tag and the core statement, then two supporting sentences about freshness and authority. Efficient overall, though 'how large the keeping is' and 'where its boundaries are' lean slightly poetic and could be tightened.

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

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

For a no-param, no-annotation introspection tool with no output schema, the description provides adequate framing: what it reports, how the numbers are produced, and why to prefer it over static prose. It could name its closest siblings to be fully 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?

Zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and schema coverage is 100% — the omission of parameter discussion is correct rather than a 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 states a specific resource — the live capability statement — and enumerates its contents (verifiability, tools/endpoints, keeping size, boundaries). It's clearly an introspection/discovery tool, and the [FIND · plumbing] tag reinforces that. It does not, however, explicitly contrast itself with near-neighbors like 'kernel', 'library_health', or 'now'.

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?

"Read this instead of trusting any count written in prose" gives a real when-to-use directive, but it is framed against prose counts rather than against sibling tools. No conditions for when NOT to call it, and no named alternatives among the many sibling tools.

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

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

With no annotations, the description carries the full burden. It usefully discloses the composition of the result (explicit links plus same-shelf siblings), but says nothing about read-only semantics, result limits, ordering, or authorization. Partial behavioral disclosure only.

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

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

A single compact line with the core operation front-loaded and no filler. It is efficient, though the bracketed tag occupies prime space ahead of the actual verb.

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

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

For a one-parameter read tool with no output schema, the description covers purpose and return composition adequately. It stops short of stating result cardinality, ordering, or read-only behavior, leaving an agent with a couple of open questions before calling it.

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

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

The single 'id' parameter has no schema description (0% coverage), so the description must compensate. 'Related to one card' implies the input identifies a card, which is minimal but real semantic grounding; it does not state the id format or whether it accepts a slug, uuid, or title.

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

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

States a specific resource (cards related to one card) and even decomposes the result set into 'explicit links + same-shelf siblings', which tells an agent exactly what it gets back. The '[FIND · internal]' tag further orients it as a lookup operation. It is distinguishable from card_get, though it never names a sibling explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named despite siblings like card_get, cards_browse, and shelf_read that an agent could confuse it with. The 'internal' marker hints at scope but gives no actionable 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?

No annotations are provided, so the description carries the full burden, and it says little: it clarifies that the return is 'the full record' rather than a partial view, but discloses nothing about permissions, behavior on an unknown/invalid id, or response shape (no output schema exists).

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

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

A single tight sentence with the action front-loaded. It loses a point because the '[FIND · door]' prefix and 'the keeping' consume space without aiding comprehension.

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

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

For a simple one-parameter read tool with no output schema or annotations, the description is marginally adequate: it says what is fetched and by what key. It is still silent on id format and failure behavior, which an agent would benefit from knowing.

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?

One parameter with 0% schema description coverage and no field-level documentation. The description only implies 'id' identifies a card; it adds no format, source, or validity guidance to compensate for the empty 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 (Fetch), resource (one card / the full record), and key (by id), which is enough to tell it apart from list-style siblings like cards_browse or daily_card. The core sentence is clear, though the bracketed tag '[FIND · door]' and the jargon 'the keeping' add noise rather than precision.

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 no explicit when-to-use, when-not, or named alternatives (e.g., cards_browse for listing, card_connections for relationships). The phrase 'by id' only weakly implies you invoke it when you already hold a card identifier.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose two concrete behaviors: results are paginated and it returns card briefs (not full cards). It omits the safety profile (read-only), ordering, and any auth or rate-limit notes.

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

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

One compact sentence with the classification tag front-loaded, and the pagination/filter facts stated before the return value. No wasted text, though the terseness comes at some cost to 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?

For a three-parameter browse tool with no output schema and no annotations, the description covers the basics (pagination, shelf filter, brief return type) but leaves the shape of a 'card brief', default page size, and ordering undocumented. Adequate but with real gaps for an agent invoking it cold.

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; it touches all three parameters conceptually ('optional shelf filter' for shelf, 'paginated' for limit/offset). However it gives no defaults, no page-size guidance, no shelf identifier format, and no ordering semantics, so it only partially closes the 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 verb 'Browse' plus the name cards_browse make the resource inferable, but the description itself says 'Browse the keeping', which is opaque jargon rather than a clear resource statement. It does signal a list operation distinct from the singular card_get, but never names or differentiates against siblings like cards_stats or card_connections.

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?

'Paginated, optional shelf filter' hints at the listing use case, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as card_get for a single card. The agent must infer that this is for enumerating cards.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only counting operation but says nothing about permissions, cost, freshness, or how results are scoped, leaving behavior largely undisclosed.

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

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

A single front-loaded sentence with the category tag first and no wasteful filler. It is compact, though the brevity comes at the cost of clarity rather than trimming 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 zero parameters and no output schema, the description is the only source of meaning for the return shape, yet terms like 'the keeping', 'shelf', and 'surface' are never explained. It is minimally adequate but should specify what the counts represent.

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 are no parameter semantics to document; the baseline for a no-param tool is 4. The description does nothing to detract from that.

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 verb 'Counts' and the dimensions 'total, by shelf, by surface' give a rough sense of an aggregate/statistics tool for cards, and the [FIND · internal] tag signals a read-oriented lookup. However, 'over the keeping' is cryptic phrasing that doesn't clearly name the resource (cards) nor distinguish this from siblings like card_get or cards_browse.

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

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

There is no statement of when to use this tool versus the many sibling card tools, no prerequisites, and no exclusions. The [FIND · internal] tag implies a lookup category but gives no actionable selection guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose payload content and one caveat (the category tag is imperfect), but says nothing about read-only nature, permission requirements, lookup/matching behavior, or output format. That is thin for a no-annotation tool.

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

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

One compact sentence with the scope framing front-loaded and no filler. The bracketed '[WORD · internal]' prefix is jargon but brief, so the structure is efficient overall.

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 or annotations, the description does useful work by stating the return payload (summary plus verses) and its known imperfection. However, it leaves the only parameter unexplained and offers no guidance on matching or invocation, so it is only minimally complete for a lookup 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 0% and the single 'name' parameter (maxLength 4000) is undocumented in both schema and description. The description implies you supply a Bible figure, but gives no guidance on name format, spelling/alias handling, or matching semantics, which matters for a dictionary lookup.

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 the specific resource (a Bible figure from Easton's Bible Dictionary) and what the payload contains (summary plus every verse that mentions them, found and attributed). That is far more informative than a sibling like characters_browse, though it never names that sibling or uses an explicit retrieval verb.

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 guidance, no prerequisites, and no mention of the obvious alternative characters_browse for browsing versus this single-figure lookup. The only framing is the cryptic '[WORD · internal]' tag, which does not tell an agent when this tool is the right 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?

With no annotations, the description carries the full behavioral burden and delivers almost nothing: no indication of result format, ordering, pagination, or what happens when search and letter are combined. Only the vague 'internal' marker hints at any access constraint, and it is unexplained.

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 single sentence is short and front-loads the resource, but the '[WORD · internal]' prefix is opaque noise that consumes space without informing selection or invocation.

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 three-parameter tool with zero schema descriptions, no annotations, and no output schema, the description leaves too much unspecified: it never explains the limit/letter/search semantics or the shape of returned entries. An agent could guess, but not confidently.

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 all three parameters (limit, letter, search), and the description does not compensate: it never mentions the limit, the letter-based browsing, or how search interacts with them. The phrase 'people, places, terms' loosely gestures at what can be searched but adds no parameter-level meaning.

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 verb (browse/search) and a resource (Easton's Bible Dictionary) with a scope hint (people, places, terms), so the general purpose is graspable. However, the name 'characters_browse' suggests people only, while the description claims places and terms too, and it does nothing to distinguish itself from sibling tools like search, lookup, define, or character_get.

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

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

There is no statement of when to use this tool versus alternatives, despite siblings such as search, lookup, define, character_get, and original_words covering overlapping territory. The '[WORD · internal]' tag implies some internal restriction but never explains it.

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

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

With no annotations, the description carries the full burden, and it discloses only one genuine behavioral trait: it will never grade a child. That is a useful boundary, but nothing is said about what the tool returns, whether it reads or writes state, or how it relates to the other coach tools. For a tool with zero annotation coverage this is a substantial gap.

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

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

A single short sentence, front-loaded with the scope tag and the boundary constraint, with no filler. Its brevity is appropriate, though the phrasing is cryptic rather than economical.

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

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

With no annotations, no output schema, and a zero-parameter schema, the description is the only source of information — and it leaves the return content, the read/write nature, and the tool's place among the coach_* family unspecified. It is not yet sufficient for confident 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?

The tool takes no parameters, so per the rubric the baseline is 4. There are no arguments whose meaning could be clarified or obscured by the description.

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 restates the tool's own name ('Coach — what it does') without naming a concrete verb or the artifact it returns. It never distinguishes itself from the six closely-named siblings (coach_overview, coach_next, coach_recommend, coach_subjects, coach_unit, coach_mastery), so an agent cannot tell which coach_* tool to pick. Only the boundary clause ('never grades a child') hints at actual content.

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 bracketed '[WALK · internal]' tag implies an internal walkthrough context, but there is no statement of when to call this versus coach_overview or coach_recommend, and no preconditions or exclusions. The agent is left to infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden, and it does add some context: the result is a 'receipt for progress, never a grade,' and it returns a 're-checkable seal.' That conveys intent and non-evaluative nature. But it omits side effects, whether the seal persists, idempotency, or permission 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?

One compact sentence plus a trailing clause, with the category tag front-loaded. No padding, though the density of unexplained jargon ('seal', 'WALK') slightly hurts scannability.

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

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

For a 1-param, no-annotation, no-output-schema mutation tool, the description is thin: it never explains what a 'unit' string should contain, how the seal is produced, or how it is verified. The return value is alluded to ('re-checkable seal') but not elaborated despite there being no output schema.

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

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

Schema coverage is 0% and the sole parameter 'completed' takes an array of strings (up to 200), yet the description describes an 'HONEST INTEGER count.' This mismatched mental model of the input could actively mislead the agent into passing a number rather than a list of unit identifiers.

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 action (seal a count of completed units) and frames it as a progress receipt, which is more than a restatement of the name. However, 'seal' is unexplained jargon and the description never distinguishes this tool from the many other coach_* siblings (coach_next, coach_unit, coach_recommend), leaving the agent to guess where it fits.

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 '[WALK · internal]' tag hints this is an internal/companion action, but there is no explicit when-to-use, when-not-to-use, or named alternative among the coach_* family. The agent gets no routing guidance.

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

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

With no annotations, the description carries the full burden. It discloses one behavioral trait ('deterministically'), but says nothing about whether this is a read-only lookup, what a returned lesson contains, or what happens when there is no next unit — significant gaps for a navigation 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?

Front-loaded with the coach framing followed by the two key rules in a compact, well-structured pair of sentences. The '[WALK · door]' tag consumes space without evident value 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?

For a simple 2-parameter read tool with no output schema and no annotations, the description adequately explains how to invoke it but omits the return shape and the end-of-sequence behavior. It is minimally viable 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?

Schema coverage is 0%, so the description must compensate, and it does explain both parameters: `after` as the preceding unit id (omit for the first) and `subject` as the path selector. It stops short of clarifying accepted `subject` format (id vs. name) or the meaning of the 4000-char limit.

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

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

States a specific resource and action: retrieving the next lesson/unit within a subject, with an explicit deterministic ordering. However, it does not distinguish itself from the many coach siblings (coach_unit, coach_subjects, coach_guidance), so an agent must infer the boundary.

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

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

It gives clear calling conventions — omit `after` for the first unit, pass a unit id for the following one, and `subject` selects the path — which is useful usage guidance. But it never says when to prefer this over coach_unit or coach_subjects, so alternative selection 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?

With no annotations, the description carries the full disclosure burden. It usefully states 'Verbatim; never generated', signaling the data is source-faithful rather than synthesized, but it says nothing about permissions, caching, or mutation risk (a read). Meaningful but incomplete for a no-annotation tool.

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

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

A single dense line that front-loads the tag, then the resource, then the contents and the only parameter. No filler; every clause earns its place, though the bracketed tag and 'K-3 tutor' framing add a slightly cryptic flavor.

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 does the work of describing the return ('unit count, tracks, ordered unit briefs'), which is sufficient for a simple single-parameter read. It stops short of covering ordering guarantees or size, but the core call information is present.

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

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

Schema coverage is 0%, so the description must compensate for the single undocumented 'subject' parameter. It does: '?subject= selects the path (default 'read')' clarifies both the parameter's effect and its default value, adding real meaning beyond the bare schema. Format constraints (maxLength 4000) remain unstated.

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

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

Names a specific resource ('Coach overview') and enumerates its contents (unit count, tracks, ordered unit briefs), which distinguishes it from single-unit coach_unit and listing sibling coach_subjects. The purpose is clear from the description alone, though it never names a sibling to contrast 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?

The '[WALK · internal]' tag and the note that ?subject= selects the path give implied usage context and a default. However, it never states when to reach for coach_overview versus coach_unit, coach_next, or coach_subjects, so the agent must infer the routing.

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

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

With no annotations, the description carries the full burden. 'Found, never generated' is genuinely useful behavioral disclosure (deterministic lookup, not model generation) and 'grows with the student' signals adaptivity. It omits what happens when no lesson qualifies, whether the result is cached, and any auth/permission expectations.

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

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

A single dense sentence plus a bracketed tag; the key constraint (prerequisite filtering) is front-loaded. Nothing is padded, though the notation 'WALK · internal' and embedded quotes add slight parsing friction.

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 annotations and no output schema, so the description must stand alone. It does explain the return conceptually ('the next lesson'), but for a tool with no required parameters it leaves the empty/no-match case and the expected id format unspecified.

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. It does reference both parameters informally ('in a subject', 'completed unit ids'), which is meaningful, but gives no format guidance such as how unit ids are shaped or that completed is an array of up to 200 strings.

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: it returns the next lesson whose prerequisites are met given completed unit ids, within a subject. That is clear enough to distinguish it from most siblings, but it does not differentiate itself from the very similar coach_next or coach_guidance in the sibling list, leaving ambiguity about which 'next' tool to pick.

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

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

The phrase 'given completed unit ids, the next lesson whose prerequisites are met' implies the calling context, and '[WALK · internal]' hints at internal usage. However, there is no explicit when-to-use vs when-not, and no reference to the near-duplicate coach_next, so routing relies on inference.

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

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

No annotations provided, so the description carries full behavioral burden. It doesn't state that this is a read-only listing, whether it's cached, or what the unit-count structure looks like. '[WALK · internal]' and 'the door in' imply an entry/routing concept but leave it opaque.

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

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

One compact sentence, but the bracketed tag and 'the door in' metaphor consume space without adding operational meaning. Front-loading is fine; clarity-per-word is mediocre.

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-param read tool this covers the essentials (what it returns: subjects + unit counts). But with no output schema and no annotations, a fuller note on return shape or how it fits into the coach_* family would improve it.

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

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

Zero parameters, so baseline is 4. The description cannot add parameter meaning, and correctly avoids inventing any.

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

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

States a specific resource: the subjects a learner can study, with enumerated examples and a note that each has a unit count. The '[WALK · internal]' prefix is cryptic metadata that doesn't clarify purpose. Sibling differentiation from coach_overview/coach_unit/coach_mastery 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?

No indication of when to use this vs. siblings like coach_overview, coach_unit, or coach_next. The phrase "'read' is the door in" hints at an entry point but doesn't say under what conditions an agent should call this tool.

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

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

No annotations are provided, so the description carries full burden. 'VERBATIM as authored' usefully signals no transformation or regeneration, but nothing is said about the return shape, whether it is read-only, or what 'internal' implies for the caller.

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

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

A single compact bracket-tagged sentence; nothing is wasted. Slightly cryptic, but structure and front-loading are good.

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 2-param, no-annotation, no-output-schema tool sitting among ~15 coach_* siblings, the description is too thin: no behavior, no param meaning, no routing vs siblings. The verbatim guarantee is the one genuinely useful piece of context.

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% over two params (id required, subject optional). The description never mentions either parameter, and this tool's purpose is returning authored unit content, so the subject filter's meaning and the id's role are undocumented anywhere.

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 (coach) and resource (one unit) and clarifies it returns content verbatim as authored. However, 'unit' is undefined jargon and the description gives no way to distinguish it from the many sibling coach_* tools beyond the vague word 'one'.

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 instead of coach_next, coach_mastery, coach_recommend, or coach_subjects. The '[WALK · internal]' tag hints at an internal flow but never says when the agent should call it or what precedes/follows it.

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

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

With no annotations, the description carries the full burden, and it does disclose a meaningful behavioral guarantee: content is 'found and cited, never generated' (a provenance/no-hallucination trait) and is public-domain and attributed. It stops short of permissions, rate limits, or response shape, so a moderate score is warranted.

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

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

A single dense sentence that front-loads the resource and its key provenance guarantee. The cryptic '[WORD · internal]' prefix adds little signal but costs few tokens; overall structure is 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?

For a lookup tool with no output schema and no annotations, the description should explain the reference format, what 'source' controls, and roughly what comes back. None of this is present, leaving significant gaps an agent would need to guess at.

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 two parameters. The description maps loosely onto 'ref' via 'on a reference' but says nothing about the expected format, and the 'source' parameter is entirely undocumented in both schema and description. With the description unable to compensate for the coverage gap, this is below baseline.

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

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

The description names a specific resource (public-domain, attributed commentary by Matthew Henry) on a reference, which is concrete and distinguishable from generic siblings like teachings or narratives. It is clear what is returned, but never explicitly contrasts itself with adjacent tools that might also surface commentary-like material.

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

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

There is no statement of when to use this versus siblings such as teachings, narratives, original_words, or word_study, and no prerequisites or exclusions are given. The agent must infer usage entirely from the description's topic.

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

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

With no annotations, the description carries the full behavioral burden and does disclose key traits: results are ordered newest first, every card is a member's own work at the 'member' tier, and the library amplified but did not verify it. It does not mention auth needs, rate limits, or pagination behavior, but the verification caveat and ordering are substantive behavioral context.

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 two sentences plus a short internal tag, with the core scope front-loaded and no redundant restatement. The second sentence adds a distinct verification caveat rather than padding, though the bracket prefix is slightly extraneous metadata.

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

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

For a simple one-parameter read tool with no annotations or output schema, the description conveys purpose, ordering, and verification status. It is incomplete on the 'limit' parameter and on when to use it over sibling read tools, which leaves gaps an agent would need to resolve elsewhere.

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

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

Schema description coverage is 0% for the single 'limit' parameter, and the description never mentions 'limit' or explains what it controls. With low coverage, the description must compensate, but it provides no parameter semantics at all.

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

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

The description states a specific resource ('the commons') and its contents ('promoted member work'), plus ordering ('newest first'), so the agent knows what this tool reads. However, it does not differentiate this read path from siblings like shelf_read, cards_browse, or card_get, leaving sibling selection to inference.

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 gives no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternative tools. The '[KEEP · internal]' tag hints at restricted use but does not constitute actionable usage direction against the many read 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?

With no annotations, the description carries the full burden. It discloses the scope of consent (only acting on a human's behalf with their data) and hints that the failure response teaches the remediation path, but it never states that this is a safe read-only check, nor what the success/failure response actually contains. Behavioral coverage is suggestive rather than complete.

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 purpose before the scope caveat and the remediation flow, and each sentence adds distinct value. The inline '[KEEP · internal]' tag and the somewhat lyrical phrasing ('teaches the way') add minor noise but don't obscure the point.

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 three-param tool with no annotations and no output schema, the description covers the concept, scope, and remediation flow well, but leaves gaps: grantor_pubkey's meaning is only implied and the actual return payload for both authorized and unauthorized outcomes is left vague.

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?

Three required params at 0% schema coverage, so the description must compensate. It clarifies agent_fp ('this agent's key fingerprint') and verb ('a named verb'), but grantor_pubkey is only implied by 'the human issues a grant' and never explicitly defined, leaving one parameter's semantics under-specified.

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: check whether a human has authorized this agent's key fingerprint for a named verb. It also carves out the important boundary that acting as yourself needs no consent, which sharpens the purpose. No sibling tool is named, but the scope is clear enough to distinguish it from the many unrelated siblings.

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

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

Gives explicit when-to-use context (the covenant's 'request human authorization before writes') and a clear when-not (speaking as your own key is not proxying, so no consent is needed). It even routes the unauthorized case through the grant flow (GET /consent/signable, sign, POST /consent), providing the alternative path, though no sibling tool is named.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two behavioral traits beyond structured data: the result is 'deterministic and found' and it is 'ranked by shared-word count'. It says nothing about permissions, limits, or error behavior, so it is only partial.

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

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

A single dense sentence with no wasted clauses; the mechanism and ranking are front-loaded. The bracketed '[WORD · door]' tag adds noise rather than 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?

For a simple one-parameter tool with no output schema, the description conveys the core output ordering, but with zero annotation coverage and an unspecified parameter format it leaves gaps an agent must guess at.

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 the single 'ref' parameter, so the description must compensate. It only implies that 'ref' is 'a reference' and gives no format, syntax, or example (e.g., 'John 3:16'), leaving the parameter largely 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 names a specific resource (verses) and mechanism (connected by shared original-language words / Strong's), so an agent knows what it produces. However, it lacks a verb and the leading tag '[WORD · door]' is cryptic, and it never explicitly distinguishes itself from the sibling 'tsk_cross_references'.

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 guidance, no conditions, and no named alternatives despite an obvious competing sibling (tsk_cross_references). The agent must infer selection from the mechanism alone.

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

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

With no annotations, the description carries the full burden and does well: it discloses auth requirements per action, the append-only nature ('acts are appended, never replaced'), and the precise side effect of a refusal (withholds amplification only; the drop stays on the member's own shelf). It does not describe the success response or failure/error behavior, which leaves a gap for a mutation tool with no 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?

Dense but front-loaded: the action list comes first, then the reason invariant, then the authorization matrix. A few clauses ('a refusal without a reason teaches the community nothing') are rationale rather than instruction, which is slight padding for a definition this compact.

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 7-parameter, nested-object, no-output-schema mutation tool, the description covers authorization, action semantics, immutability, and the refusal side effect. It omits return/confirmation behavior and error conditions, the main remaining completeness gap.

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

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

Schema coverage is only 43%, and the description compensates substantially by mapping credentials to actions (token for promote/refuse; fields+signature for withdraw), naming the three valid action values, and clarifying that steward is a name rather than authority. It still leaves card_id and the exact shape of the nested fields object to the schema, so it is strong but not exhaustive.

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: it records one act (promoted / refused / withdrawn) on a single drop, and names the sibling (curate_signable) it is not. An agent can distinguish it from curate_queue and curate_signable 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?

Explicitly routes by action and actor: promote/refuse require the steward token, withdrawing your own card requires fields+signature from curate_signable instead. It also states the invariant that a name plus a reason is always required, and warns that a typed name is not authority.

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

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

No annotations exist, so the description carries the full behavioral burden. It does hint that this is a non-promoting gate that merely flags when a person must look, which is some disclosure. But it omits whether the operation is read-only, whether it mutates state, who can call it, and what the side effects are — substantial gaps for a tool with zero annotation coverage.

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

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

The description is short and front-loaded, which is good, but the '[KEEP · internal]' prefix is internal bookkeeping that does not help an agent select or invoke the tool. Both sentences are terse, yet the core semantics remain cryptic rather than 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?

With no parameters, no annotations, and no output schema, the description has to carry nearly the entire burden of meaning, and it does not. It never explains what a caller receives or how to act on a queue entry, leaving the tool's practical contract undefined.

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, so there is nothing for the description to explain at the parameter level. Baseline 4 applies for a zero-parameter tool where the schema imposes no semantic demands.

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 conveys the resource — a queue of items awaiting a human steward — but supplies no verb. It never says whether the tool lists, inspects, or drains that queue, so the agent must guess the operation. This is vague relative to a name like curate_queue, and it is not differentiated from siblings such as curate or curate_signable.

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 guidance and no mention of when not to use it. The sibling set contains several related tools (curate, curate_signable, moderation_signable) that the agent must disambiguate on its own. The 'counter never promotes' line hints at the tool's role but does not tell the agent when to reach for it.

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

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

With no annotations, the description carries the full burden and does disclose two valuable traits: no permission is required for your own card, and the signing key must be the same key that signed the original drop (an identity/authorization constraint). It does not describe the return shape (raw bytes), format, or any side effects of the subsequent curate call.

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

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

Three tight sentences with the purpose front-loaded and the next-step instruction at the end. The '[KEEP · internal]' tag is meta-noise that does not help an agent, but the rest earns its place.

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

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

It covers purpose, the no-permission auth model, and the handoff to `curate`, which is most of what an agent needs for a two-param byte-generation tool. It still leaves parameter formats and the exact nature of the returned bytes undocumented, which is a meaningful gap at 0% schema coverage.

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 neither parameter is explained in the schema. The description only implies that 'card_id' is your own card and 'member' is you; it gives no format, length, or identity semantics 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?

States a specific output (the canonical signing bytes) and a specific action (withdrawing your own card), which distinguishes it from the other *_signable siblings such as moderation_signable or shelf_signable. It is clear what the tool produces, though the noun-phrase phrasing ('The canonical bytes for...') is slightly indirect about the verb.

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 names the follow-up step explicitly ('then call `curate` with them') and scopes usage to your own card, implying self-service. It does not explicitly name the sibling it is not (e.g. moderation_signable for others' cards), so the exclusion 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses determinism ('same all day') and marks the tool as internal, but says nothing about permissions, side effects, failure modes, or what the card payload looks like. For a zero-annotation tool this is thin.

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

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

A single short sentence with the category tag front-loaded and the defining property (deterministic, stable all day) placed early. It is efficient and has no padding, though the compressed jargon trades clarity for brevity.

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

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

With no annotations, no output schema, and an undocumented parameter, the description is the only source of behavioral information and it is far too sparse. It should at minimum explain the seed parameter, the return shape, and whether authentication or an identity is required.

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 'seed' parameter has 0% schema description coverage and is not even required, yet the description never mentions it. This is especially confusing given the stated determinism: an agent cannot tell whether seed changes the daily card or is ignored. No meaning is added beyond the bare 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 identifies the resource (the card of the day) and asserts a key property (deterministic, same all day), which does separate it from siblings like card_get and cards_browse. However, the verb is only implied by the '[FIND]' tag and the phrase 'from the keeping' is opaque jargon that an agent cannot resolve. Purpose is inferable but not stated cleanly.

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 statement and no alternatives named, despite many plausible siblings (card_get, cards_browse, deck_open, card_connections). The '(same all day)' clause hints that repeated calls are pointless, but the agent is left to infer 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?

No annotations are provided, so the description carries the full burden. It conveys that results are ordered and query-free, but says nothing about whether the call is read-only, permission/auth needs, error behavior, or what the unmentioned `limit` does — thin for a tool with zero structured behavioral coverage.

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

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

Reasonably short and the purpose is front-loaded after the '[KEEP · internal]' marker, with examples placed last. The metaphor-heavy phrasing and marker consume some space without adding operational meaning, but there is no real padding.

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

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

There is no output schema or annotations, so the description must be self-sufficient. It does explain the id source and that cards come back in order, but omits `limit` semantics and error/edge behavior, leaving gaps an agent would need before invoking confidently.

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 for both parameters. It explains only `id` (from `decks`); the optional `limit` parameter is never mentioned, leaving the agent without guidance on its meaning despite a schema that offers no description either.

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 verb+resource (open a deck) is present and it distinguishes itself from the sibling `decks` (which it cites as the source of `id`). But the core output is described only in opaque internal jargon — 'frontloaded hand — the cards that situation calls for' — which an agent cannot fully decode without prior ecosystem knowledge.

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

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

It offers example deck names ('water-safe', 'first-aid-far') and a use case ('ideal for anticipating need'), which implies when to reach for it, and notes 'NO query needed'. However it names no alternative or exclusion, so an agent cannot tell when another tool (e.g. `cards_browse`, `ask`) would be preferred.

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

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

With no annotations, the description carries the full behavioral burden, and it partially delivers by disclosing that each entry reports a live card count and that `need: true` flags situation decks. It does not state that the operation is read-only, whether counts are cached, or anything about pagination/ordering, so the agent is left guessing on the operational profile.

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

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

It is a single compact sentence with the core distinction ('by-situation' vs 'by-domain') and the `need` flag front-loaded. The leading '[KEEP · door]' token is unexplained noise that costs a little clarity but does not bloat the text.

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 explain the return shape — it partly does (live card count, `need` flag), which is adequate for a zero-parameter listing tool. However, it never confirms the core action (listing) or the fields of each deck entry, leaving a small but real gap for a tool whose return surface is entirely undocumented elsewhere.

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. The description correctly adds no parameter detail because there is nothing to parameterize; the mention of `need: true` describes returned data rather than an 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 the resource precisely (curated card SETS, split into by-situation and by-domain) and surfaces a distinguishing data attribute (`need: true`). It never states the verb — whether this lists, counts, or opens decks — so an agent must infer 'list/overview' rather than being told.

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 guidance on when to reach for `decks` versus the obvious siblings `deck_open`, `cards_browse`, or `card_get`. The bracketed '[KEEP · door]' marker is internal jargon that gives the agent no actionable routing condition.

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

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

With no annotations, the description carries the full burden and does well: it discloses sources, that each sense is labeled with its source, and that the result is empty for unknown words or when no dictionary is loaded. It omits richer output/format detail but covers the key behavioral edge cases.

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 a category tag and a one-line essence ('what an English word MEANS'), followed by sources, edge case, and sibling routing. Dense but each clause carries information; no filler.

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

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

With no output schema, the description must explain returns, and it does — senses labeled by source, empty on unknown words. For a single-param lookup tool this is nearly complete; only return format/structure detail is left unspecified.

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 'word' param is self-evident and at 0% schema coverage the description compensates by specifying it must be an English word and noting the unknown-word edge case. It adds the meaningful constraint the schema lacks, though no format/length guidance 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+resource: the dictionary meaning of an English word, with named sources (Webster's 1913 + supplement). It explicitly distinguishes itself from thesaurus (synonyms) and word_study (original languages), so an agent can route 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?

It names the alternatives (thesaurus, word_study) and states the boundary — define handles English word meaning and 'points to them, never duplicates'. This gives clear routing context, though it stops short of explicit when-not conditions (e.g. non-English terms).

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it proposes but never confirms ('no verdict, no seal'), holds back private/framing context ('not sent'), routes crisis cases, and generates nothing. The privacy disclosure (private context not sent) is a genuinely valuable trait beyond the schema. It omits rate limits, auth, or return-shape specifics, keeping it at 4.

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

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

It is front-loaded with the core function, but the metaphorical framing ('WALK · door', 'proposal half of the engine, laid open') and a redundant close ('It PROPOSES, never confirms' / 'no verdict, no seal' / 'nothing is generated') inflate a one-parameter tool's description. Information density is high, but several clauses do not 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?

There is no output schema, so the description must explain returns — and it does, enumerating KIND, the reduced claim, the (domain, spec), and routing, plus the handoff to verify. For a single-input tool this is largely complete, though return format/structure detail is left somewhat 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 coverage is 100% and there is only one parameter ('text', maxLength 4000), so the schema already documents it. The description restates the same semantics ('a claim, a question, or a messy statement') without adding format or constraint detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

It states a specific verb (discern) and describes the concrete transformation: take a claim/question/messy statement, return its KIND, the reduced necessary claim, the (domain, spec) the gate would verify, and where it routes. It also explicitly distinguishes itself from its sibling ('The twin of the verify door', 'It PROPOSES, never confirms'). The heavy metaphor ('WALK · door', 'proposal half of the engine') adds fog, but the functional identity is recoverable.

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 names the alternative and the handoff condition explicitly: 'hand the returned `claims` to `verify` to dispose', plus the crisis routing rule ('routed to real people, never the gate'). This gives a clear workflow and selection boundary versus verify. It stops short of stating when NOT to call discern (e.g., when a verdict is already wanted), so it is not a full 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses determinism ("no model"), the return shape ("ranked domain candidates with the literal words that matched"), and notable edge behaviors (crisis deferral, ambiguity returning candidates "never a single guess"). It stops short of describing auth needs or rate 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 core question is front-loaded and each sentence carries behavioral information (determinism, return value, edge cases). Some overhead comes from the unexplained "[CHECK · door]" tag and the "agent twin of GET /find_verifier" note, which are marginal.

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 tool with no output schema and no annotations, the description covers the essential behavior — determinism, return format, and edge handling. It is nearly complete; only explicit query-format guidance would push it higher.

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?

One parameter with 0% schema description coverage, so the description must compensate. It characterizes the input as "a plain-language claim," which is meaningful, but adds no detail on format, length limits, or what makes a good query — only partial compensation.

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: identifies which verify DOMAIN handles a plain-language claim, and flags it as the deterministic resolver with no model. It distinguishes itself from the sibling `verify` by positioning itself as the pre-step that feeds it. The bracketed tag "[CHECK · door]" is jargon that adds little, keeping this 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?

Implied workflow is present ("to confirm and pass to `verify`"), and edge cases are noted ("Crisis defers to real help"). However, there is no explicit statement of when to use this versus alternatives like `verify`, `resolve`, or `search` — the agent must infer the routing.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the safety profile ('read-only') and describes the shape of the returned data (scaffold members, depth, neighbors, umbrella children), which is useful for a find tool. But it says nothing about value format for `axis`, pagination, or authorization requirements.

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

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

Two tight sentences with the resource and scope front-loaded right after the compact category tag. Every clause carries information; nothing is padded or restated.

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

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

With no output schema and no annotations, the description must do more, and it does describe the return contents. But it omits how to specify the axis value and how this relates to grid_dimension, so an agent still has open questions before invoking it correctly.

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

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

Schema coverage is 0% — the single `axis` parameter has only a type and maxLength, no description. The description compensates partially by explaining the omit-behavior, but it never says what value `axis` expects (identifier vs. name) or its format, so the semantics remain half-specified.

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 operation (a read-only view) and a resource (one axis) and enumerates what it exposes: scaffold members, depth, neighbors, umbrella children. An agent can tell it is an axis-lookup, though it never distinguishes itself from the sibling grid_dimension, which shares the same naming family.

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 one concrete usage rule: 'Omit `axis` for an overview of all axes,' which tells the agent when to use which calling mode. However, it offers no guidance on when to prefer this over grid_dimension or other browsing tools, leaving the main alternative-selection question unanswered.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing beyond a terse purpose. It does not say whether an unknown dimension yields an empty set or an error, whether the result is paginated, or whether the operation has any side effects.

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

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

One sentence with a bracketed category tag up front — efficient and front-loaded, with nothing that could be trimmed. It is terse rather than wasteful, though the terse form is part of why the other dimensions suffer.

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 annotations, and an undocumented parameter, the description is the only guidance available and it is not nearly enough. An agent cannot confidently predict the return shape or the meaning of a valid dimension value from this text 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 parameter has no schema-level documentation, but the description does imply that 'dimension' identifies the scaffold member whose axes are returned. That is a genuine, if minimal, semantic contribution, though it adds no format, syntax, or validity constraints.

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?

It states a find-style purpose and a resource (the axes attached to a given scaffold member), but the domain vocabulary — 'scaffold member', 'dimension' — is opaque and undefined. It also does not distinguish itself from the sibling grid_axis, which appears to operate on the same conceptual territory.

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 '[FIND · internal]' tag hints that this belongs to a read/lookup family, but there is no statement of when to call this versus grid_axis or any other lookup sibling, and no prerequisites or exclusions. An agent is left to infer usage entirely.

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

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

With no annotations, the description carries the full burden but only partially delivers: it discloses that content is attributed to the caller's handle, optionally signed, and explicitly not engine-verified ('verbatim; a member's own words'). It omits whether membership is required, whether contributions are reversible/editable, and what happens on success.

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 reasonably front-loaded — the core action leads and the qualification about verification follows. However, the '[KEEP · internal]' tag is unexplained jargon that spends characters without clarifying behavior.

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

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

A mutation tool with no annotations, no output schema, 8 parameters at 13% coverage, and a nested attestation object. The description should compensate for the missing structured guidance (membership, mutability, param meanings) but does not, leaving key operational context absent.

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 only 13%, so the description must compensate. It explains handle (attribution) and, via 'optionally signed', gestures at attestation, but leaves kind, refs, topics, subject_id, and id entirely undocumented — the majority of 8 parameters carry no meaning in either place.

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 (add) and resource (verse/note/question to a group's shared study), which distinguishes it from sibling group tools like group_create, group_join, and group_get. It does not explicitly name an alternative it is not, but the purpose is unmistakable.

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 '[KEEP · internal]' marker hints this is an internal/supported tool and context implies contribution to an existing group study, but there is no explicit when-to-use vs alternatives (e.g., study_import or mesh_post) nor any stated prerequisites such as group membership.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose meaningful traits: creation is pseudonymous (handle only, no personal info) and restricted to adults, with a hard separation from the children's surface. It does not cover permissions, duplicate/error behavior, or what the call 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?

Two compact sentences with the core action front-loaded. The '[KEEP · internal]' tag is wasted tokens, but the rest is tight and earns its place.

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

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

A 5-parameter creation tool with no annotations, no output schema, and 0% schema coverage needs more than two sentences. Missing parameter semantics (subject_id, title, description) and any notion of the result or failure modes leave an agent under-equipped 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% across 5 parameters, so the description must compensate. It only alludes to 'topic' and 'handle' ('pseudonymous; a handle, no personal info'), leaving title, subject_id, and description entirely undocumented in both the schema and the description.

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: 'Open a study group around a topic.' An agent can distinguish this from group_join/group_get/groups_list since those operate on existing groups. The '[KEEP · internal]' prefix is meta-noise but doesn't obscure the purpose.

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 scope constraint ('For grown believers') and a boundary ('the children's coach is a separate, never-joined surface'), which implies who should and shouldn't call it. However, it never says when to create a new group versus joining an existing one via group_join, nor any 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.

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

With no annotations, the description carries the full burden. It does disclose one genuinely useful behavioral trait: the payload contains member handles with 'no ids/PII', telling the agent the result is privacy-safe to surface. It says nothing about permissions, behavior on an unknown/unauthorized id, or whether the result is cached/limited.

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

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

One short sentence, so there is no bloat, but the leading '[KEEP · internal]' tag is curation metadata that consumes the most prominent position without helping an agent decide or invoke. The useful content is not front-loaded.

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

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

For a one-parameter getter with no output schema, describing the returned entity (topic, member handles, shared cards) is the right kind of content and is partially complete. Missing: what the id identifies, error/empty behavior, and any access constraints — the same gaps the absent annotations would otherwise have covered.

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 required 'id' parameter has 0% schema description coverage and the description adds nothing about it — it never says what kind of id is expected (group id vs. member handle vs. slug) or its format. The 'no ids/PII' note refers to the response, not the input parameter.

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 never states a verb; it only characterizes the payload ('A study group: topic, member handles, and shared-study cards'). From the name group_get an agent can infer retrieval, but it is not differentiated from siblings like groups_list or group_contribute, so the purpose is only implied.

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 guidance, no mention of prerequisites (e.g. membership), and no routing to alternatives such as groups_list for enumeration. The agent must infer that this fetches a single group by id.

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

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

With no annotations, the description carries the full burden, and it does disclose three real behavioral traits: consent is required, identities are pseudonymous, and the operation is idempotent (so retries are safe). That is meaningful for a mutation, but it omits failure modes, permission requirements, and what happens when the caller is already a member.

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

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

A single front-loaded sentence with no filler or redundancy. The bracketed internal-use tag is process metadata rather than agent-facing content, but it costs almost nothing.

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 mutation tool with no annotations, no output schema, and three completely undocumented parameters, this description is far too thin. An agent cannot determine the required `id` semantics, membership preconditions, or the result of joining an already-joined group.

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

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

Schema description coverage is 0% for three parameters, so the description must compensate and largely does not. It never explains what the required `id` refers to, nor how `handle` differs from `subject_id`; "pseudonymous" only faintly gestures at handle/subject_id semantics.

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 ("Join a study group"), which is unambiguous on its own. However, it does nothing to differentiate itself from nearby siblings like group_create, group_get, group_contribute, or groups_list, so an agent gets no help choosing among the group_* family.

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, no prerequisites, and no named alternative. The only contextual hint is the bracketed "[KEEP · internal]" marker, which signals internal tooling but does not tell an agent when this is the right call versus group_contribute or group_create.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavioral traits: results are pseudonymous, members appear as handles only, and no PII is returned. It omits result limits, pagination, and any auth requirements, so coverage is partial.

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 clauses with the topic-vs-person distinction front-loaded, so the key routing signal comes first. The '[KEEP · internal]' prefix is editorial clutter that adds no value to an agent and slightly dilutes the opening.

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

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

With no output schema and no annotations, the description should ideally sketch the return shape; it does give one hint (members are handles only) but says nothing about pagination, result caps, or ordering. For a discovery/list tool that is adequate but incomplete.

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

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

Schema description coverage is 0% for the single q parameter, so the description must compensate. It partially does by saying q filters over topic/title/description, but gives no matching semantics (substring vs. fuzzy), no syntax, and no empty/missing 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?

States a specific verb (Discover/list) and resource (pseudonymous shared-study groups) plus the scoping dimension (by TOPIC, not by person). This clearly separates it from group_get, group_create, and group_join. The only weakness is the bracketed '[KEEP · internal]' tag, which is operational metadata rather than purpose.

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 parenthetical '(not by person)' implicitly tells the agent this is the topic-based discovery path, which is useful routing guidance. However, it never names a concrete alternative tool or states when not to use it, so the guidance 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.

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: results are 'found, verbatim WEB text, never generated' and grouped by ministry phase. It omits other behavioral context such as authorization needs, pagination, or response size limits for the full list mode.

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

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

A single dense sentence with a parenthetical, front-loaded with the core purpose and then the two operating modes. Efficient, though the bracket tag and parenthetical make it slightly harder to parse at a glance.

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 convey return shape — and it does, distinguishing a single-event side-by-side view from a phase-grouped event list. Given the low complexity (one optional param), this is close to complete.

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

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

Schema coverage is 0% for the single id parameter, so the description must compensate. It does add meaning by explaining that id selects one event versus the default full listing, but it gives no guidance on id format or where such an id comes from.

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

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

States a specific resource and behavior: 'Harmony of the Gospels — one event of Christ's life, every gospel that records it, side by side.' An agent can tell what it returns, though the description never names or distinguishes itself from adjacent siblings like read_passage, search, or cross_references.

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 clarifies the two modes — 'Pass id for one event; else lists every event grouped by phase of the ministry' — which is useful implied usage guidance. It does not, however, say when to prefer this over alternatives such as read_passage or a plain search, so selection guidance 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?

With no annotations, the description carries the full burden and does add useful behavioral context: key generation happens client-side, no private key crosses the wire, and the server only handles public keys. It also states the return is guidance rather than a key. It doesn't describe error modes or side effects, but for a no-parameter guidance tool this is fairly complete.

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 core message is front-loaded, but the bracketed '[KEEP · door]' tag and the parenthetical sibling list add noise without explaining terms. The sentences are somewhat dense and could be tightened, though they remain readable.

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?

Without an output schema, the description should explain what the returned guidance consists of, but it only says 'returns guidance, not a key' and never describes the form or content of that guidance. For a zero-parameter tool with no annotations, this leaves the agent uncertain about next steps after 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?

The tool has zero parameters, so the baseline is 4. The description appropriately does not invent parameter semantics and focuses on the operation's nature, which is correct for a no-arg 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?

The description states a specific action (create a SOVEREIGN identity) and its key property (keys are born on the user's device). It differentiates from siblings identity_verify and identity_fingerprint by naming them and their server-side role. However, 'returns guidance, not a key' and the '[KEEP · door]' tag add mild ambiguity about what the tool actually produces.

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

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

It names sibling tools and implies a division of labor (client-side key generation vs server-side public-key handling), which gives implicit usage context. But it doesn't say when an agent should call this versus alternatives, nor does it provide a clear trigger or prerequisite, leaving usage to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the derivation is 'deterministic' and produces a 'stable' id, which is meaningful behavioral context for a pure function. However, it omits auth/permission requirements and any error 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?

A single front-loaded sentence with no padding; the output is stated before the input. The bracketed '[KEEP · internal]' marker is minor noise but does not obscure the meaning.

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 cover the return value; it names the 'fingerprint id' but does not describe its format. For a simple single-parameter deterministic tool this is adequate but leaves 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?

Schema description coverage is 0% and there is one parameter. The description implies the single input is a public key but adds no format, encoding, or length detail beyond what the parameter name already conveys.

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 (derive) and resource (stable public fingerprint id from a public key), which is clear enough to distinguish it from identity_create and identity_verify. It doesn't explicitly contrast with those siblings, but the deterministic derivation function is well defined.

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 says what the tool does but never states when to use it versus siblings like identity_create or identity_verify, nor any preconditions. No when/when-not guidance is present.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two meaningful behavioral traits: the call never raises and returns True/False, which is genuinely useful for error handling. It says nothing about key/signature encodings, supported algorithms, or whether verification is pure/local.

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

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

A single compact sentence with the key fact (never raises; True/False) front-loaded inside parentheses. No filler. The bracketed internal marker is terse and informative rather than wasteful.

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

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

For a simple boolean verification helper with no output schema and three flat string params, the description covers the essential contract (what it does, return type, no exceptions). It leaves encoding and algorithm assumptions undocumented, which matters for a crypto-adjacent 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 0% and none of the three required params have descriptions. The description maps each param to a conceptual role (sig over message against public_key), which is some compensation, but omits encoding format (hex/base64), key type, and any length or format expectations.

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: verify a signature over a message against a public key, with the exact input roles spelled out. It does not, however, differentiate itself from the sibling 'verify' or 'badges_verify', so an agent must infer which verifier 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?

The '[KEEP · internal]' tag hints at intended audience but gives no explicit when-to-use or when-not-to-use guidance. With siblings like 'verify', 'badges_verify', and 'find_verifier' in the list, the description should state what distinguishes this call, and it does not.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Read it before you write' implies a safe, side-effect-free read, but the description never states the return format, idempotency, or that it modifies nothing. The remaining text describes conceptual content rather than the tool's runtime 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?

The identity and the 'read before write' imperative are front-loaded, and the middle clause compactly lists the kernel's contents. It is dense with domain jargon, but each clause maps to real content rather than padding.

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-param reference tool with no output schema and no annotations, the description usefully enumerates what the caller receives (five moves, covenant, KINDS, lattice, gate record). It omits the response format, but coverage of the payload content is adequate.

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 of 4 applies. Schema coverage is 100% and there are no arguments to mis-specify.

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 artifact ('THE GATE KERNEL — the law you keep here, in one call') and enumerates its contents (five moves, eight-rule covenant, six KINDS, authority lattice, nine-field record), so an agent knows this is a reference-fetch for the governance kernel. The action verb is implied ('read it', 'in one call') rather than stated, and it never names the sibling kernel_gate to differentiate scope.

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?

'Read it before you write' gives a clear usage context and ordering cue for when to call this relative to write operations. There are no explicit exclusions or named alternatives, but the precondition is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool decides and records only, never persists, and never replaces signature/consent checks. It also details internal logic for CONFIRMED vs. quarantine. It doesn't cover rate limits or side effects beyond recording, but it's rich for a no-annotation tool.

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

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

The description is two sentences, front-loaded with the core action and outcome, then the rule and conditions. It is dense but every sentence earns its place. Slightly verbose with parentheses, but 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?

Given the tool's complexity (10 params, nested object, no output schema, no annotations), the description covers the essential decision logic and caveats. It could mention the nine-field record's purpose or error handling, but it's largely complete for an agent to use it correctly.

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

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

Schema coverage is 70%, so the schema documents most parameters. The description adds meaning by explaining that 'content' is scanned for RED/FLOOR moral constraints and that 'witness' must differ from 'author'. However, it doesn't clarify parameters like 'artifact', 'kind_hint', 'contradicts', 'authority_in', 'wait_satisfied', or 'in_kind_checked'. 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 states a specific verb+resource: 'Route ONE proposed state-change through the kernel and get back the verdict (REJECT / QUARANTINE / CONFIRMED) plus the nine-field record.' This is clear and distinguishable from sibling tools like candidate_commit or verify. It does not explicitly name a sibling to differentiate from, 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 says 'so you can DISCERN before you write', implying when to use it (pre-write discernment). It also clarifies what CONFIRMED requires: a real verification that HELD, an independent witness, and the wait. However, it doesn't explicitly state when NOT to use it or name alternative tools like candidate_commit or consent_check, so it's not a full 5.

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

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

With no annotations, the description carries the full burden; it implies a read-only health/diagnostic operation with no parameters, which is a reasonable inference from 'is the keeping loaded and sound'. However, it never explicitly states that it is side-effect-free or returns a status report, leaving the agent to infer the safety profile.

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

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

A single compact sentence with the category tag front-loaded. It wastes no words, though the terseness comes partly at the cost of clarity in the jargon-heavy clause.

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

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

There is no output schema and no annotations, so the description must explain what a health report contains. It gestures at this with '(totals, shelves, surfaces)' but does not describe the shape or fields of the response, leaving a genuine gap for a zero-input diagnostic 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?

The tool takes zero parameters, so there is no parameter semantics to document. Per the baseline for 0-param tools, a 4 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 identifies a diagnostic about corpus health, which is a recognizable purpose, but the verb is implicit and the framing language ('the keeping loaded and sound', 'shelves', 'surfaces') is opaque domain jargon. A sibling like 'audit' or 'verify' cannot be confidently distinguished from this without more wording.

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 '[FIND · plumbing]' tag hints at a category but gives no when-to-use conditions and no comparison against near-neighbors such as audit, verify, or capabilities. The agent must guess whether this is a status check, a validation, or a navigation aid.

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

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

With no annotations, the description carries the full burden, and it does disclose the matching strategy (id, then title, then ranked search), which is genuinely useful behavioral context. It says nothing about whether the call is read-only, what permissions are needed, or what is returned, leaving meaningful gaps for an unannotated tool.

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

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

A single compact sentence that front-loads the verb, resource, and scope, then states the fallback chain. No filler and nothing to trim.

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

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

For a one-parameter finder with no output schema and no annotations, the description covers purpose and matching behavior, but omits the return shape (single card vs. list), read-only status, and ambiguity behavior when multiple cards match. Adequate but with clear 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 single parameter q has 0% schema description coverage, so the description must compensate. It does so by explaining that q can be an exact id, a title, or a ranked search phrase, which is real meaning beyond the bare type/maxLength schema.

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

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

The description names a specific verb (find) and resource (the card) and even discloses the resolution order (exact id, then title, else ranked search), which tells an agent exactly what this tool resolves. It does not explicitly differentiate itself from close siblings such as card_get, lookup, or search, 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?

The '[FIND · internal]' prefix implies this is an internal-facing lookup tool, and the resolution order implies it accepts flexible queries. However, there is no explicit statement of when to use this versus search, lookup, or card_get, so usage must be inferred.

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

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

With no annotations, the description carries the full burden and does well: it declares determinism, offline public-domain sourcing, source-returning behavior, and the 'found=false (never a guess) when unknown' contract, plus the kind-listing fallback. It omits auth/permission requirements and any rate/limit context, which keeps it from a 5.

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

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

Front-loads the core purpose and packs the kind enumeration efficiently. Some phrasing is redundant ('consolidated like verify into one tool', 'The agent twin of GET /lookup') and could be trimmed, but the description is not bloated.

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 and no annotations, yet the description covers return semantics ('Returns the value + its source') and the unknown-result case, so an agent has what it needs to call correctly. Minor gaps around auth and per-kind edge behavior keep it just under complete.

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

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

Schema coverage is 0%, so the description must compensate, and it does by enumerating the kind values and their expected params (molar_mass {formula}, element {symbol|name|atomic_number}, convert {value, from, to}). The generic params object structure is only implied rather than described, so it falls short of full documentation.

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 ('Look up a VALUE deterministically from the engine's offline, public-domain data') and explicitly positions it against the sibling verify ('the found-value twin of verify'). An agent can distinguish it from verify and the other lookup-like siblings (define, resolve, find_verifier) 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 a clear use pattern ('look it up, then verify it') and a fallback ('Call with an unknown kind to list the current kinds'). It names verify as the counterpart but does not fully spell out when to prefer lookup over the many other lookup-ish siblings, so it stops short of explicit when-not/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?

With no annotations, the description carries the full burden. It usefully discloses the pipeline (verify -> seal -> hash-chained ledger), that the engine verifies while the engineer assigns the label, and that 'nothing is invented' (deterministic). It omits permission/auth requirements, error behavior, and whether the ledger write is irreversible.

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 sentence, followed by behavioral context and then the calc spec enumeration. Sentences are dense and jargon-laden, but each clause contributes (function, ledger behavior, accepted calc shapes) with no padding.

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

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

No output schema exists, and the description does state what is reported (the disposition values CALCULATED/CONTROLLED/PROVISIONAL/OPEN). For a nested-input tool with 0% schema coverage and no annotations, it covers the critical unknown (the calc spec) and the return concept, leaving only auth/error details unstated.

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

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

Schema coverage is 0% and calc is a free-form nested object, so the description must compensate. It enumerates the four accepted MFG_VERIFY spec shapes with their exact field names (tolerances/claimed_rss, dpmo/claimed_sigma, SPC limits, Cp/Cpk), which is substantial value the schema does not provide. claim is described only loosely and disposition's input semantics are implied by the output-label listing.

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: route an engineering claim and its numbers through a manufacturing verifier, seal, hash-chain to a ledger, and report a disposition. It is identifiable as a manufacturing-calc verification tool distinct from generic siblings like verify or find_verifier. The heavy jargon ('Conductor's shop-domain calc door') adds noise but doesn't obscure the core function.

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 implies usage ('route an engineering claim + its numbers') but never states when to prefer this over verify, find_verifier, or attest_record. There is no explicit when/when-not or alternative routing, so the agent must infer that this is the manufacturing-domain entry point from the name and description alone.

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

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

With no annotations, the description carries the full behavioral burden and it does disclose the key authentication mechanism in real detail: pass `at` (unix seconds) and `sig` over the exact string nh-mesh-read:v1:<fp>:<at>. That is genuine auth context beyond structured data. However, it says nothing about failure modes, whether reads are non-mutating, rate limits, or pagination behavior despite a `limit` parameter.

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

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

Two tight sentences with the purpose front-loaded before the signing requirement, so the agent gets intent first and mechanics second. The '[KEEP · internal]' tag is minor noise but does not obscure meaning.

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 annotations and no output schema, the description covers the purpose and the auth contract but omits the `limit` semantics, pagination expectations, and error behavior on a bad signature. The passing mention that results come 'each with its verification' partially covers the return shape.

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

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

Schema coverage is 0%, so the description must compensate and largely does: it defines `at` as unix seconds, describes `sig` as a signature over a specific canonical string, and ties `<fp>` into that signing scheme, adding meaning far beyond the bare typed schema. The `limit` parameter is left entirely unexplained, which keeps this 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?

The description conveys a read operation on a personal resource ('Read the words left on YOUR door — the whiteboard others wrote to you'), but it does so through metaphor rather than a plain verb+resource statement. It does not differentiate from the very similar sibling mesh_inbox, so an agent cannot confidently pick between them from the text 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?

'Yours alone' hints that this is scoped to the caller's own key, which is mild context, but there is no explicit when-to-use, no when-not-to-use, and no mention of alternatives such as mesh_inbox or mesh_map. The agent must infer the routing from sibling names.

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

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

With no annotations, the description carries full burden. It usefully discloses the auth requirement (sign with your own key, never send the key) and the trust model (verify by proof, not by server trust), but says nothing about pagination, error behavior, or what 'limit' does.

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

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

Two sentences, reasonably front-loaded, but padded with flowery framing ('trust it by proof rather than by this server's word') and a noisy metadata tag ('[KEEP · internal]') that adds no invocation 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?

For a 4-param tool with no annotations and no output schema, the core purpose and auth flow are covered, but the description omits pagination/limit semantics, failure modes, and any differentiation from the mesh family, leaving real 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?

Schema coverage is 0%, so the description must compensate. It richly documents two params ('at' as unix seconds, 'sig' with the exact signed string nh-mesh-read:v1:<fp>:<at>), but leaves the required 'fp' and the 'limit' parameter entirely unexplained.

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

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

The description conveys the resource (the messages that reached you) but never states a clean verb+resource pair, relying on prose ('the messages that reached you') and the tool name to imply 'read my inbox.' It also fails to distinguish this read tool from mesh siblings like mesh_map, mesh_door, mesh_post, or mesh_signable.

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 guidance on when to use this tool versus the many mesh_* siblings. The only instruction given ('prove your key — pass at and sig') is parameter mechanics, not a use/don't-use condition.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a signature is mandatory, that unsigned notes are refused, and that a private key will not be accepted. These are non-obvious security/validation behaviors. It omits persistence, permissions, and success behavior, keeping it below 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?

Two front-loaded sentences with the purpose stated first and the signing workflow second; no filler. The '[KEEP · internal]' tag is noise, but the body is tight and appropriately sized.

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

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

This is a complex cryptographic-signing mutation with 7 parameters, no annotations, no output schema, and 0% schema coverage. The description explains the signing flow and refusals but leaves the majority of required parameters and the result behavior undefined, so it is not complete enough to call correctly without guesswork.

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. The description only gestures at 'target' (via mesh_signable with target) and 'signature'; fp, kind, text, nonce, and created_at are entirely unexplained in both schema and description. It leaves most required fields 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?

States a specific verb and resource ('Leave a word on one believer's door') and distinguishes the operation from broadcasting ('rather than a post to everyone near you'). The metaphor is softened by that contrast, so an agent can differentiate it from mesh_post/mesh_door, though the sibling tools are never named directly.

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 usage context: use it for directed, one-to-one encouragement rather than a broadcast. It also outlines the required signing workflow (get bytes from mesh_signable with target, sign locally, send the signature). It stops short of naming the alternative tools or stating explicit when-not conditions.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose genuinely useful traits: an auth prerequisite (a confession bound to the caller's fp) and the concrete failure behavior (unconfessed callers are routed to the door instead of the network). It does not state read-only semantics, rate limits, or what the 'hops' parameter changes, so it is strong but not complete.

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 core description is two compact sentences with the scope claim front-loaded before the prerequisite, so an agent gets the essentials first. The '[KEEP · internal]' prefix is metadata noise and the phrasing is heavily metaphorical, but there is no redundant filler.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description still feels serviceable because it names the resource, the auth requirement, and the failure mode. Missing pieces are material, though: the 'hops' parameter is unexplained and the return shape is only gestured at ('the believers immediately around you'), which the agent must infer.

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 for both parameters. It explains fp only loosely ('your fingerprint', with no format or max-length hint) and never mentions the 'hops' parameter at all, leaving an integer parameter with no meaning, defaults, or bounds in prose despite the schema exposing range limits of ±1e12.

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

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

The description states a specific resource and scope: 'the believers immediately around you in the Fellowship Mesh — your view only, never a global map,' which tells an agent it returns a local, caller-scoped view rather than a full graph. The verb is implicit (a map/list operation) and there is no explicit differentiation from mesh siblings like mesh_inbox or mesh_door, but the 'never a global map' scoping does real distinguishing work.

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 precondition ('requires your fingerprint and a confession already bound to that key') and a failure path ('unconfessed callers get the path to the door'), which implies when the tool succeeds. However, it never contrasts this tool against alternatives such as mesh_inbox or mesh_door, so the when-to-use-vs-sibling guidance is only implied.

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

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

With no annotations, the description does real work: it states the private key never leaves the machine and the tool will not accept one, that the operation is 'Refused unless the signature verifies', and that content is attributed to the caller. This is meaningful behavioral disclosure beyond what a bare schema provides, though broader side effects, idempotency, and network propagation behavior are not covered.

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 '[KEEP · internal] Step 2:' prefix and two dense sentences front-load some context, but the sentence combining key safety, signing values, and verification is packed and not clearly structured; the task itself is not stated first.

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 an 8-parameter, 5-required mutation tool with 0% schema coverage, no annotations, and no output schema, the description covers signing/verification behavior but leaves the key parameters and the post semantics essentially undocumented, which is not a complete definition for calling the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It only mentions fp implicitly via 'your node's public key', and refers to 'the same text/kind/ttl plus the nonce, created_at and signature from mesh_signable'. It does not explain what fp, kind, ttl, or refs accept, so the description fails to cover the mostly undocumented parameter set.

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 frames itself as 'Step 2: speak to the nodes around you' and a signature-carrying post, which implies a posting/broadcast action, but the name 'mesh_post' and the schema (fp, text, kind, ttl, refs) suggest a signed mesh-network message. It never explicitly states this is a write/publish operation to a mesh network, and it is hard to distinguish from mesh_signable, mesh_inbox, mesh_door, and mesh_leave_on_door without opening schemas.

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 'Step 2' framing and the instruction to reuse values 'from mesh_signable' imply this must follow mesh_signable and that the signature must verify. However, it never explicitly says 'use this only after mesh_signable produces nonce/created_at/signature' or states when NOT to use it versus the other mesh_* 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?

With no annotations, the description carries the full burden and does well: it discloses the return format (base64url), that the response includes nonce and created_at to send back, that signing is done locally, and that output is deterministic ('Reproducible offline — sorted-key JSON'). It omits auth requirements, rate limits, and whether the call is non-mutating, keeping it short of a 5.

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

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

The purpose and output format are front-loaded, and the sentences are mostly information-dense. The '[KEEP · internal]' tag and the trailing 'so you can compute and check it yourself' add a little flourish, but overall it stays tight.

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 annotations and no output schema mean the description must be self-sufficient, and it covers the core workflow and return shape reasonably. But with 5 parameters at 40% coverage and two undocumented params (fp, ttl), plus no downstream tool reference, it leaves gaps an agent would need to fill.

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 40%, so the description must compensate but largely does not. It references 'a message' generically but never explains the required 'fp' parameter or the 'ttl' parameter, both of which are undocumented in both schema and description; only 'kind' and 'target' have schema descriptions.

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 ('get the exact canonical bytes to sign for a message') and situates it as 'Step 1 of speaking to your fellowship.' It's clear what the tool produces, though it never names the mesh sibling (e.g., mesh_post) that consumes the signed result.

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?

'Step 1 of speaking to your fellowship' implies the workflow position and the instruction to 'sign them locally with your own key' gives the immediate next action. However, it does not name the follow-up tool or state any when-not/alternative conditions versus other mesh_* tools, so usage is only implied.

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