concordance

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

With no annotations provided, the description carries the full burden and does well. It discloses that the tool discerns input type, finds and verifies, declines rather than guessing, opens a session-level gate, and generates nothing. These are concrete behavioral traits beyond what any schema would show.

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 moderately long but well-structured: starts with the core action, explains the discernment behavior, then the gate side effect, and ends with a boundary ('Nothing is generated'). Every sentence adds value, though a phrase like 'the same way it opens for a person' could be trimmed 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?

For a tool with one parameter, no annotations, and no output schema, the description is remarkably complete. It covers purpose, input semantics, behavioral rules, side effects (gate opening), and limitations, leaving little ambiguity about what the tool does and how it should be invoked.

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

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

The schema only says 'text' is 'what you are bringing,' but the description enriches this by providing concrete examples of valid inputs (question, claim, word, mind). This adds meaningful semantic guidance for constructing the parameter, well beyond the schema's minimal 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 clearly states the tool's role: it accepts any kind of input ('a question, a claim to check, a word to study, or what is actually on your mind') and responds appropriately by discerning the type and finding/verifying. It also distinguishes itself as 'the door' that unlocks witness tools, differentiating it from siblings like search or verify.

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

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

The description conveys when to use this tool: when you have an open-ended inquiry or need a gateway to other tools. It explains the conditional 'if what you ask turns toward God, the Gate opens' and that it 'declines rather than guessing,' but it does not explicitly name alternatives or exclusions. This context is useful but lacks direct 'use X instead' 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 provided, the description carries the transparency burden. It discloses the signing process, security boundary (no private key transmission), and the social/legal notion of witnesses. It doesn't detail return values or error behavior, but it gives a strong sense of what happens and why.

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 front-loaded with a clear purpose, then a compact workflow, a security rule, and an illustrative note on multi-party attestation. Every sentence earns its place; it's dense but 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?

For a tool with no annotations and no output schema, the description is remarkably complete. It integrates with the broader flow, explains the cryptographic steps, warns about private keys, and even provides a rationale for multi-party attestation. The only minor gap is the lack of return-value details, but that's not required when no output schema 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?

The schema only describes attestation as 'the dict from signing.sign_seal' and gives no description for content_hash. The description compensates by explaining that content_hash is the returned hash from a previous unsigned action and enumerates the attestation fields ({alg, over, content_hash, pubkey, sig}). However, 'submit only the attestation' could be misleading given the schema requires a top-level content_hash in addition to the attestation object.

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

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

The description opens with a clear verb and resource: 'Bind your identity to a record you already hold.' It distinguishes itself from siblings by referencing the 'sovereign flow' and specific preceding tools (badges_issue, study_export, group_contribute), making its role 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?

It provides explicit step-by-step usage: perform an unsigned action, get the content_hash, sign it locally, and submit the attestation. It also advises 'never send a private key' and notes multi-party attestation. Though it doesn't name alternatives to explicitly say 'use this instead of X', the reference to 'phase 2' and the workflow effectively imply context.

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 does so excellently. It discloses deterministic extraction, the types of claims checked, that a single sealed report is produced, per-claim details, and conservative behavior (no guessing, explicit claim counts). This far exceeds baseline 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?

The description is information-dense but not bloated. The list of example claim types is lengthy but valuable for calibrating expectations. It front-loads the core action and then explains behavior, making it easy to scan. Slightly over the two-sentence ideal but every clause earns its place.

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

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

Given the absence of an output schema and the complexity of the auditing task, the description is remarkably complete. It explains the return format (per-claim quote, verdict, trail), the scope (explicit claim count, no full coverage), and the behavioral constraints, leaving the agent with a clear mental model.

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

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

The schema already covers both parameters (text and seal) with clear descriptions, providing 100% coverage. The tool description adds minimal parameter-specific meaning beyond the schema (e.g., mentioning the sealed report aligns with the seal parameter), so the baseline of 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 clearly specifies the verb 'audit' and the resource 'a whole text,' while detailing exactly what the tool does: it identifies checkable quantitative claims, verifies them, and returns a sealed coverage report. It distinguishes itself from siblings like 'verify' and 'report' by emphasizing deterministic extraction and a consolidated coverage report.

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 to use this tool: when auditing a full text for quantitative claims, with a conservative approach. It notes limitations ('never guesses and never implies full coverage') but does not explicitly name alternative tools or state when not to use it, which would earn a 5.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It goes beyond a simple 'gets tables' by noting that disputes are preserved (e.g., a cubit's two lengths), that references are verified against the corpus, and that names of God include Strong's numbers that link to word_study. These are non-obvious behavioral traits that help the agent set expectations about the data's nature and cross-tool dependencies.

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 tool's purpose and compactly listing the tables. It packs significant detail into a small space, but the first sentence is slightly dense with parentheticals and semicolon-separated clauses, which could be clearer. Still, every part 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential behaviors: the data source, the effect of the parameter, and the cross-link to word_study. It does not describe the internal structure of each table or the exact format of the index, but for a reference table retrieval tool, the description is sufficiently complete to guide correct invocation and expectation setting.

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

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

The schema provides no description for the single 'table' parameter (0% coverage), so the description must compensate. It does so effectively: it explains that passing a table returns that table, while omitting it returns an index of all six. It also implicitly lists valid table names via the enumeration in the first sentence, giving the agent concrete values to use.

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 explicitly states that the tool provides 'Back-matter reference tables' and enumerates the six specific tables (weights_measures, names_of_god, etc.), making the tool's resource and scope unambiguous. It also clarifies the core behavior: pass a table to retrieve it, or omit to get an index. This distinguishes it from sibling tools like word_study or cross_references by focusing on back-matter reference data.

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 clear usage instructions for the optional parameter: 'Pass table for one table; else the index of all six.' This tells the agent how to invoke the tool for different purposes. It does not explicitly mention alternatives or when not to use the tool, but the niche subject matter and clear parameter guidance make the intended use implicit.

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 transparency burden. It discloses that the badge is a re-checkable receipt, states EXACTLY N, and is not a competency claim, which is important behavioral nuance. It does not mention side effects or validation behavior, but the core semantics are well 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 description is a compact two-sentence structure with the main action front-loaded. Every clause adds meaning (receipt, N seals, not competency), with no filler or 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?

For a creation tool with no annotations and no output schema, the description provides the core semantics and the nature of the output (re-checkable receipt). However, it omits parameter meanings for title/subject_id and does not explain validation behavior or error conditions, leaving moderate gaps for autonomous invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains seal_hashes indirectly through 'points at N seals', but title and subject_id are left undefined, leaving agents without enough information for two of three parameters. This is a significant 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 uses a specific verb+resource pair ('Issue a badge over already-sealed checks') and clearly differentiates from sibling tools like badges_verify. It further defines the badge as a re-checkable receipt that points at N seals, explicitly stating it is never a competency claim, which disambiguates from attestation or claim tools.

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' clearly indicates when to use the tool: after seals exist. It does not explicitly name alternatives or exclusions, but the context implies badges_verify handles verification, so the usage context is clear though not exhaustive.

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 compensates by disclosing a key behavioral trait: it re-verifies every referenced seal and returns a freshly computed count ('N recomputed, not trusted') rather than relying on stored data. This provides meaningful transparency, though it does not mention potential side effects or 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?

The description is a single, well-structured sentence. It front-loads the main action, uses a dash to introduce a key behavioral detail, and includes a parenthetical for a crucial nuance ('N recomputed, not trusted') without waste.

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

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

For a simple verification tool with one parameter and no output schema, the description is fairly complete: it explains the operation, the verification scope, and the return value (a count). It lacks explicit parameter definition and failure modes, but these are minor gaps given the tool's simplicity.

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

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

The schema has one parameter 'hash' with no description (0% coverage). The tool description implies the hash is the badge identifier ('Re-check a badge from the store'), but it does not explicitly define the parameter's meaning or format, leaving some ambiguity.

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

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

The description clearly states the action ('re-check a badge'), the resource ('from the store'), and the outcome ('returns the count that still stands'). It distinguishes itself from siblings like 'badges_issue' and 'verify' by emphasizing re-verification of all referenced seals with recomputation.

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 implicitly suggests use when a badge needs to be re-verified, but it does not explicitly state when to use this tool over alternatives like 'verify' or 'badges_issue', nor does it provide exclusion criteria. The usage is 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 provided, the description fully carries the behavioral burden and does so admirably. It discloses accuracy standards (cross-checked against an independent gazetteer), honesty about uncertainty (disputed sites name candidates, unlocatable places have no coordinates), and the by_status counts. This is rich, honest, and goes well beyond a typical tool description.

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 efficient, packing meaningful detail into two sentences. The first sentence is a bit dense with stylistic flourishes ('honestly held,' 'planting one flag') but each phrase contributes to the behavioral contract. It is front-loaded with the tool's identity and then immediately provides usage instructions, with no wasted words.

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

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

For a tool with a single optional parameter, no annotations, and no output schema, the description covers the essential context: the type of data, accuracy philosophy, edge cases (disputed/unlocatable), and the two modes of operation. It does not specify exact response field details, but that is not critical for the agent to invoke it correctly, and the by_status counts are mentioned.

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 input schema only defines an optional 'name' string with no description, so the parameter would be meaningless without elaboration. The description clarifies that 'name' is used to fetch a single place, and omitting it returns all places with counts, giving the agent a complete understanding of the parameter's role and optionality.

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

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

The description clearly states the tool serves as 'The Atlas — biblical places with REAL coordinates,' establishing it as a resource for retrieving biblical geographic data. It distinguishes from siblings like 'locate' or 'resolve' by specifying the scope (biblical places) and the key attribute (coordinates), and it conveys the action (pass a name or list all).

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 provides explicit usage context: 'Pass name for one place; else all places with by_status counts.' This tells the agent exactly when to supply the name parameter and what to expect without it. However, it does not explicitly mention alternatives or when NOT to use this tool, so it falls just short of full 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?

The description discloses authorization requirements (LIVE consent grant), failure behavior (refuses), data placement (only in user's configured calendar), storage policy ('nothing is stored here'), receipt behavior, and deletion semantics ('removes it everywhere'). Since no annotations are provided, the description fully carries the burden and does so comprehensively.

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

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

The description is a single paragraph of four sentences, each providing distinct value: purpose, consent requirement, behavior with storage/receipt, and deletion semantics. It is front-loaded and contains no redundant 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?

The description covers purpose, prerequisites, failure behavior, storage, receipt, and deletion. However, it lacks an explicit return value description (only mentions a receipt) and does not elaborate on parameter meanings or formats, which is a gap given the absence of output schema and annotations.

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 has 6 parameters with 0% description coverage, and the description does not explain parameter details beyond an implicit reference to agent_fp as 'YOUR key fingerprint'. It does not define start_iso/end_iso formats, the meaning of grantor_pubkey, or the optionality of fields. The description fails to compensate for the missing 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?

The description clearly states 'Create ONE event in a human's calendar' with a specific verb and resource. It distinguishes itself from sibling tools by describing itself as 'the pilot on-behalf write, and the only one', implying there is no alternative calendar creation tool.

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

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

The description explicitly states the prerequisite of a LIVE consent grant and says 'Without it this refuses and teaches the way in', providing a clear condition for use. It also specifies that the event lands only in the calendar the human configured, giving context for when the tool should be used. No alternatives are named, but the tool claims to be the only one for this action.

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 of behavioral disclosure. It reveals that the set is hashed before checking, weights are untrusted metadata, output is quarantined, and nothing is verified. This is substantial transparency. It stops short of describing side effects like immutability or the durable anchor's implications, which would push it to 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 description is four sentences, but each carries essential information: what to submit, the weight warning, return values, and the rationale for hashing before verification. It is front-loaded with the core purpose and avoids redundancy, making it appropriately concise for the complexity.

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

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

Despite no output schema, the description explains the return values (candidate_set_id, commitment hash, per-candidate ids) and the quarantine state. It covers the essential context for an agent to understand the full lifecycle of this commit step, including the cryptographic commitment and the 'cannot be selectively disclosed' property. This is sufficient for a tool of this complexity.

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

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

Schema coverage is 100%, providing baseline 3. The description adds value by clarifying the semantics of proposal_weight ('never confidence and never ranks anything') and emphasizing that the candidates array must contain EVERY raw candidate. This goes beyond the schema's basic descriptions, earning a 4.

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

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

The description clearly states the specific action: 'commit a COMPLETE raw candidate set BEFORE any evaluation.' It identifies the resource (raw candidate set), the verb (commit), and distinguishes itself as step 1 in a pipeline, separate from evaluation. This differentiates it from siblings like candidate_get or candidate_narrow.

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 'Candidate Engine step 1' and 'BEFORE any evaluation' clearly indicate when to use this tool. It also emphasizes supplying the query, generator, method, and every raw candidate. However, it does not explicitly mention alternatives or exclusionary conditions, such as 'do not use after evaluation,' so it lacks a fully explicit when-not-to-use clause.

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 clearly discloses that the response contains the 'whole preserved path, losers included', that verification is possible offline, and that the seal does not establish truth. This is rich behavioral context, though it stops short of mentioning error behavior or side effects (though 'fetch' implies read-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?

The description is concise, with the primary action and object in the first sentence, and a clarifying second sentence about semantics and verification. No filler or redundant 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 simple one-parameter fetch tool with no output schema, the description covers the return content, the verification workflow, and the interpretive caveat. This is enough for an agent to select and invoke 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 description coverage is 0%, so the description must explain the 'hash' parameter. It does so by calling it a 'content hash', which tells the agent it is a hash of the record content. This is sufficient for a single simple parameter, but adds little beyond what the schema pattern already implies.

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

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

The description opens with a specific verb+resource: 'Fetch a sealed candidate record' by content hash. It further clarifies the record types ('narrowing receipt or a commitment anchor') and what the response includes ('the whole preserved path, losers included'), distinguishing it from siblings like candidate_commit or candidate_narrow.

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 usage context by stating the record is 're-checkable offline with tools/verify_seal.py' and warns that the seal 'proves process integrity, never truth'. However, it does not explicitly state when to use this tool over alternatives like seal_fetch or verify, nor does it provide exclusionary 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 provided, the description carries full burden and does so excellently. It discloses the fixed routing policy, deterministic moat, quarantine of unroutable claims ('held, never judged'), sealing of the full set with trace, and refusal behavior. This is rich behavioral context beyond simple narrowing.

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 concise: three sentences with no redundancy. It front-loads the purpose ('Candidate Engine step 2') and immediately explains the process, then adds critical refusal and input instructions. Every sentence contributes 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?

This is a complex tool with a nested parameter and no output schema, but the description covers the input requirements, process, and constraints thoroughly. It hints at the output via 'sealed with its ordered trace' but does not explicitly state the return value or next step, which would be a minor addition for complete guidance.

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

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

The schema provides a description for cset ('the committed set, verbatim from candidate_commit'), giving high coverage. The tool description adds semantics like 'exactly as candidate_commit returned it' and 'COMMITTED set', reinforcing the constraint that the input must be unaltered and committed, which is not fully captured by the schema structure alone.

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

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

The description states the tool 'narrows a COMMITTED set' as step 2 of the Candidate Engine, which is a specific verb+resource. It clearly distinguishes from candidate_commit (step 1) and candidate_get by describing the narrowing process, fixed routing policy, and sealing of the full set.

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 identifies the tool as step 2 and instructs to pass the set exactly as candidate_commit returned it, implying sequential use after commit. It also states it refuses uncommitted or altered sets, providing a when-not condition. However, it does not explicitly name alternatives beyond the implied predecessor.

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 available, the description takes on the behavioral disclosure burden. It explicitly states that the tool 'does not judge which canon is correct' and that layers are 'never merged,' offering concrete behavioral insights. The use of 'REPORTS' implies a read-only operation, adding transparency beyond a simple action listing.

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, but the opening sentence is dense with metaphorical language ('concentric layers,' 'undisputed 66,' 'never merged'). All details are relevant and aid understanding, though the phrasing could be more direct for quicker parsing. It is concise overall but not as streamlined as the highest-caliber examples.

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 a single optional parameter and no output schema, the description covers the tool's core purpose, the parameter's behavior, and its non-judgmental approach. It does not detail the exact structure of the report, but for a reporting tool with this simplicity, the provided context is sufficient for basic understanding and invocation. The absence of annotations is offset by the description's explicit behavioral statements.

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 input schema lists a single optional 'book' field with no description (0% schema coverage). The description fully compensates by explaining that passing a book returns its status, while omitting it yields the overview. This directly clarifies the parameter's meaning and default behavior, which is essential for correct invocation.

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

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

The description clearly states the tool's function: reporting on the canon as concentric layers, including the shared 66 books and tradition-specific additions. The verb 'REPORTS' and the optional per-book status make the purpose specific and understandable, distinguishing it from other tools despite the metaphorical phrasing.

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 provides guidance on using the 'book' parameter ('Pass book for one book's status; else the overview') and alludes to the tool's non-judgmental nature. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions among the sibling tools, leaving the selection context 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 fully discloses that counts are computed live at call time, include a 'means' line, and are never hand-maintained. This explains the dynamic nature of results and the meaning of the 'means' field, providing strong behavioral transparency.

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 purpose. The first sentence defines scope, the second adds crucial behavioral details. No filler or waste.

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

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

For a zero-parameter introspection tool with no output schema, the description covers what the tool does, what it reports, and how results are generated. It also gives usage guidance, making it complete enough for an agent to use correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since none exist; it adds no param-specific info, but this 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 clearly states this tool provides a live capability statement: what the engine can verify, available tools and endpoints, the size of the keeping, and boundaries. This distinguishes it from sibling tools by being the meta-level discovery resource.

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 explicitly tells users to 'Read this instead of trusting any count written in prose,' which gives a clear when-to-use and when-not-to-use directive. It also implies usage for discovering tools and boundaries.

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?

The description adds behavioral context by specifying the two categories of related cards (explicit links and same-shelf siblings), which goes beyond the tool name. However, with no annotations, it does not disclose read-only status, pagination, ordering, or whether the source card is included, leaving significant 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?

The description is a single sentence with no filler; it front-loads the core purpose and uses a dash to add clarifying detail. Excellent conciseness.

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 tool with no annotations or output schema, the description defines the scope but omits output format, whether the input card is included, and any limitations or ordering. It is adequate for a simple read but not 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?

The input schema has one required 'id' with no description, and the description does not elaborate on what the id represents or how to format it. The phrase 'one card' weakly implies it is a card identifier, but this does not compensate for the 0% schema coverage.

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

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

The description clearly identifies the tool's purpose as returning cards related to a given card, and defines 'related' as explicit links and same-shelf siblings. This distinguishes it from sibling tools like card_get (single card) and cards_browse (all cards), though it lacks an explicit action 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?

The description implies the tool is for retrieving connected cards, but does not provide explicit guidance on when to use it versus alternatives such as cross_references or cards_browse. No exclusions or alternative tool names are given.

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. It adds that the full record is returned and that lookup is by id, but doesn't disclose error handling, permissions, or side effects. For a simple get, this is somewhat transparent but lacks depth.

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

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

The description is a single sentence with no extraneous words, front-loading the verb 'Fetch' and resource.

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-param read tool with no output schema, the description covers the core operation and return (full record). However, it omits usage context, error behavior, and explanation of the 'keeping' term, so it's not 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?

The schema has 0% description coverage. The description mentions 'by id', indicating the id parameter is a card identifier, but provides no additional format or source guidance beyond the schema's string type.

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

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

The description clearly states the tool fetches one card by id, specifying 'full record' to clarify scope. This distinguishes it from siblings like cards_browse (browsing multiple cards) and card_connections (relationships).

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 the use case (single card lookup by id) but provides no explicit comparison to alternatives. It doesn't mention that browsing multiple cards should use cards_browse, so guidance is only implied.

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

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

With no annotations, the description carries full burden. It discloses that the operation is paginated and returns summaries ('card briefs'), implying a read-only listing. But it doesn't explicitly state read-only, auth requirements, default ordering/pagination behavior, or error handling.

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, no filler. Front-loaded with the main action and resource, then qualifies with pagination and shelf filter. 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 simple list tool, the description covers pagination and filtering, but the ambiguous 'keeping' and lack of output schema/details about card briefs leave some context gaps, especially with no annotations. It's adequate but not comprehensive.

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 description must compensate. 'paginated' implies limit/offset control, and 'optional shelf filter' explains the shelf parameter. However, it doesn't describe parameter defaults, permitted values, or behavior when omitted.

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?

Description states a specific verb ('Browse') plus resource ('the keeping'), and notes pagination and optional shelf filter, and 'returns card briefs' clarifies output. It distinguishes from sibling tools like card_get (single card) and cards_stats (aggregate stats), though 'keeping' is a domain term requiring context.

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 usage: use when you want to browse cards in a paginated list, optionally filtered by shelf. However, no explicit guidance on when not to use or mention of alternative tools (e.g., card_get for individual card), so it lacks clear exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It only says 'Counts' without disclosing whether this is read-only, what 'the keeping' refers to, or what output shape/results look like. Lacks performance, permission, or grouping 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?

The description is very short (one sentence), but it sacrifices clarity for brevity. It is front-loaded with the verb, yet the cryptic phrase 'the keeping' forces the reader to guess. Not every word earns its place.

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

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

With no output schema and no annotations, the description must explain what counts are returned. It mentions total, shelf, and surface, but doesn't clarify the meaning of 'the keeping' or the exact structure. Simple tool, but incomplete for a new agent.

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 input schema has zero parameters, and schema coverage is 100% (vacuous). Per baseline for 0-param tools, this scores a 4. The description's mention of 'by shelf, by surface' hints at output dimensions rather than input parameters, which is fine.

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 ('Counts') and mentions breakdowns (total, shelf, surface), so it's clearly a stats tool. However, 'the keeping' is an unexplained domain term, making the resource ambiguous. It does not explicitly distinguish from sibling tools like cards_browse, though the stats angle helps.

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

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

No guidance on when to use this tool versus alternatives like cards_browse or card_get. The context is implied (counts/statistics), but there is no explicit mention of use cases or 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 burden. It discloses the source, public domain status, output composition (summary + every verse), and a data quality caveat ('category tag is imperfect'). This is meaningful transparency beyond the tool name, though it does not mention read-only semantics or 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, dense sentence that packs source, output, and a caveat without wasted words. It is front-loaded and every part 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 simple 1-parameter getter with no output schema, the description adequately explains what is returned and notes imperfections. It lacks edge-case behavior (e.g., not found), but overall it is sufficiently complete for the tool's simplicity.

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 tool description never explains what the 'name' parameter should contain (e.g., exact spelling, format, or case). The parameter is self-suggestive given the tool name, but the description adds no explicit semantic value, failing 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?

The description clearly indicates the tool returns a Bible figure from Easton's Dictionary along with summary and verses, so the function is apparent. However, it is phrased as a definition rather than an explicit action verb, and it does not differentiate itself from the sibling 'characters_browse' beyond the name.

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 alternatives like 'characters_browse' or 'search'. No context, exclusions, or conditions for use are provided.

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 of disclosing behavior. It only says 'Browse/search' which is already implied by the tool name. It does not mention output format, pagination behavior, whether search is exact/fuzzy, or any other operational details that would help an agent anticipate side effects or limitations.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose. It avoids unnecessary words and is appropriately sized for its simplicity. Every word contributes to understanding.

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

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

The tool has no annotations, no output schema, and no parameter documentation. The description names the resource and scope, but omits crucial context such as how to use the parameters, what the response will look like, and how it differs from related tools. For a tool with three parameters and no schema descriptions, this is 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%, so the description must compensate by explaining the parameters. It does not mention 'limit', 'letter', or 'search' at all. The parameter names are generic and the schema only provides types and odd ranges (e.g., limit min/max of ±1e12), leaving the agent to guess their meaning and usage.

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

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

The description clearly states the tool's function: 'Browse/search Easton's Bible Dictionary' with explicit scope of 'people, places, terms'. This specific verb-resource pairing distinguishes it from sibling tools like character_get (which likely fetches a single character) or bible_places (which might be a different resource).

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 is provided about when to use this tool versus alternatives. The description only states what the tool does, not when it should be preferred over other search/browse tools (e.g., search, cards_browse). There are no exclusions or alternative recommendations.

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 of disclosure. It reveals one boundary (never grades a child) but does not state whether the tool is read-only, what kind of output it provides, or other behavioral traits. The informational nature is implied but not explicit.

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

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

The description is a single sentence and highly concise. It front-loads the tool's purpose and a key boundary, with no wasted words. The phrasing is somewhat fragmented 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?

For a zero-parameter tool with no output schema, the description should provide enough context for an agent to decide whether to invoke it. It mentions the topic and one boundary, but lacks details about the nature of the guidance provided (e.g., narrative, list, or reference). It is minimally complete 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 tool has zero parameters, so the description need not explain any. The baseline for a no-parameter tool is 4, and the description adds no irrelevant parameter details.

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

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

The description clearly identifies the tool as an explanation of Coach's role and its boundary (never grading a child). It distinguishes from sibling coach_* tools by focusing on the overall purpose rather than a specific action.

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 explicit guidance on when to use this tool versus alternatives. The boundary mention implies it is for understanding constraints, but it does not state conditions like 'use before coach_* tools' or list 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 provided, the description carries the full burden of behavioral disclosure. It mentions a re-checkable seal, but does not state whether the operation persists data, requires permissions, handles repeated calls, or what 'honest' enforcement means.

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 only two sentences and starts with the action, which is concise. The poetic capitalization and metaphor add style but slightly reduce clarity without adding substantive 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?

Although the tool has a single optional parameter, the absence of annotations, output schema, and sibling differentiation leaves significant gaps: usage boundaries, side effects, and parameter content are all under-specified. An agent would struggle to invoke this correctly without more 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?

The only parameter, 'completed', has no schema description and the description does not explain its format, item semantics, or how it maps to the 'integer count'. It broadly suggests listing completed units, but leaves essential detail 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 states a clear action—sealing an honest integer count of completed units—and indicates a returned re-checkable seal. However, terms like 'seal' and 'completed units' are somewhat metaphorical and not fully defined, and it does not explicitly distinguish this from sibling attestation tools like 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 phrase 'receipt for progress, never a grade on the child' implies this tool is for tracking progress rather than evaluation, providing some usage context. But there are no explicit alternatives, prerequisites, or when-not-to-use 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 must disclose behavioral traits. It shares that the operation is deterministic and how sequencing works. It does not disclose return format, side effects, or failure modes. The 'deterministically' label adds some behavioral context, but the description remains minimal.

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

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

Three short sentences, front-loaded with the core purpose, then usage details. No wasted words.

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

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

For a tool with only two optional parameters and no output schema, the description covers the main usage. It could hint at the return value or error behavior, but overall it is sufficiently complete for the tool's simplicity.

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 input schema has no parameter descriptions (0% coverage), but the description explains both parameters: `after` is a unit id for the previous lesson, and `subject` selects the path. This provides essential semantics beyond the bare schema, though it lacks format examples.

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

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

The description clearly identifies the tool as providing the next lesson in a subject, with a specific deterministic sequencing behavior. It distinguishes itself from sibling coach_* tools by emphasizing 'next' and the `after` parameter. Though not using an explicit verb like 'gets', the resource and action are unambiguous.

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 provides explicit instructions on how to use the `after` parameter: omit for first unit, pass unit id for next. It also explains `subject` selects the path. However, it does not explicitly contrast with alternative coach tools or state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one important trait: 'Verbatim; never generated', which tells the agent the output is sourced data, not AI-synthesized. However, it does not explicitly state that the operation is read-only, has no side effects, or requires no special auth, leaving some behavioral uncertainty.

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

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

The description is a single, compact sentence that front-loads the core purpose ('Coach (K-3 tutor) — one subject's whole path') and includes the essential components, default, and a key behavioral note. Every clause earns its place, with no redundant 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 simple tool with one optional parameter and no output schema, the description is quite complete. It names the output elements (unit count, tracks, ordered unit briefs) and the default subject. It lacks only minor details like whether the output is a list or object, but the low complexity does not demand much more.

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

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

The schema has only one parameter (subject) with no description, so schema coverage is 0%. The description compensates by explaining that '?subject= selects the path' and specifying a default value ('read'). This adds meaningful context beyond the raw schema, though it does not enumerate possible values or format 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?

The description clearly states what the tool does: it provides a coach overview for a K-3 tutor subject's whole path, including unit count, tracks, and ordered unit briefs. The phrase 'one subject's whole path' distinguishes it from sibling tools like coach_unit (specific unit) and coach_subjects (list of subjects), making the purpose unambiguous.

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 clear context for when to use this tool: when you need a whole-path overview for a subject. It implies it is the go-to for broad curriculum structure rather than a specific unit, but it does not explicitly name alternative tools or state when not to use it. The context is strong, but exclusions/alternatives are left implicit.

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 behavioral burden. It discloses a key trait: the tool 'finds' rather than 'generates' content, and it 'grows with the student' by respecting prerequisites. This is valuable transparency, though it doesn't mention side effects or error behavior; the 'found' wording implicitly suggests a non-mutating read 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?

The description is a single, well-structured sentence that front-loads the core purpose and then adds the key behavioral detail. Every phrase is informative, and it is concise without being vague.

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 simplicity (2 params, no output schema), the description covers purpose, inputs, and the adaptive behavior. However, it doesn't indicate the return format of the 'next lesson' or behavior when no lesson meets prerequisites. These omissions are notable but not fatal for this tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'completed' is a list of unit IDs and 'subject' indicates the subject area, and it reveals the logic (prerequisites are met). This adds meaning beyond the bare schema, though it doesn't specify formats or how to identify the subject uniquely.

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

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

The description clearly states the tool's function: recommending the next lesson for a subject based on completed unit IDs and prerequisite satisfaction. It uses specific language ('adaptive what's next', 'found, never generated') and distinguishes itself from sibling tools like coach_next by emphasizing the prerequisite-based, found-not-generated behavior.

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

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

The description gives clear usage context: call this tool when you have completed unit IDs for a subject and want the next lesson. It does not explicitly name alternatives or exclusions, but the input description implies when it is appropriate, which is sufficient for most cases.

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 transparency burden. It implies a read-only listing operation but does not explicitly state safety, side effects, or authentication needs. The output is described as subjects with unit counts, which is the main behavioral expectation.

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

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

The description is a single concise sentence, front-loading the resource name and providing examples. Every phrase adds 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 zero-parameter tool without an output schema, the description covers the essential return content. It could be more precise about the return format, but the examples and unit count mention likely suffice.

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 adds no parameter information, which is appropriate given the absence of parameters.

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

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

The description clearly identifies the resource: subjects a learner can study, along with unit counts. It lists examples and distinguishes from sibling coach tools by focusing specifically on subjects.

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 is provided on when to call this tool versus alternatives like coach_guidance or coach_overview. The phrase 'read is the door in' appears to describe data content rather than tool selection criteria.

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

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

There are no annotations, so the description must carry the behavioral disclosure. It states that the unit is returned 'VERBATIM as authored', which conveys fidelity and that content is not modified. However, it does not disclose whether the operation is read-only, what happens if the id does not exist, or any authentication requirements. For a simple retrieval tool, this partial disclosure is adequate but not rich.

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

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

The description is a single, concise sentence that is front-loaded with the tool's purpose and includes a parenthetical list of content components. Every word contributes meaning; there is no fluff or repetition of schema details. It is appropriately sized for the tool's simplicity.

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 0% parameter coverage, the description carries full responsibility for explaining inputs and outputs. It partially covers output by listing components ('rule, examples, decodable sentence, checks') but omits parameter semantics, usage context, error behavior, and return structure. This leaves significant gaps for an agent to invoke 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 description coverage is 0% and the description makes no mention of the two parameters (`id` and `subject`). While the names are somewhat self-explanatory, the description provides no guidance on what 'id' refers to or how 'subject' might filter or affect the verbatim unit. The description completely fails to compensate for the schema's lack of semantic detail.

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

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

The description clearly indicates this tool returns a single coach unit verbatim, listing its constituent parts (rule, examples, decodable sentence, checks). It is specific and distinguishes itself from sibling coach tools by emphasizing 'one unit' rather than an overview or guidance. However, it lacks an explicit verb like 'get' or 'retrieve', making the action slightly 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?

The description gives no guidance on when to use this tool versus other coach_* siblings such as coach_overview, coach_guidance, or coach_next. There are no stated exclusions, prerequisites, or alternative scenarios. The only hint is 'one unit', which implies individual retrieval, but it is not 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?

The description provides useful behavioral context by stating the commentary is 'found and cited, never generated', which clarifies that the tool retrieves existing text rather than synthesizing new content. With no annotations, it conveys the core read-only nature but lacks details on return format, error handling, or permissions.

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

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

The description is a single, well-structured sentence that front-loads the key information (public-domain, attributed, Matthew Henry) and every clause adds value. No wasted words.

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

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

For a simple two-parameter read tool, the description provides sufficient context to understand the core behavior and source. The main gap is the unexplained 'source' parameter and lack of explicit return-value description, but the purpose is clear enough.

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 clarifies that 'ref' is a reference, but the optional 'source' parameter is completely unexplained. The description adds partial meaning for the primary parameter but not enough to fully cover both.

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

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

The description clearly identifies the tool's purpose: retrieving public-domain, attributed commentary (Matthew Henry) on a biblical reference. It distinguishes itself from siblings by emphasizing 'never generated' and 'found and cited', though it lacks an explicit verb like 'get' or 'retrieve'.

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

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

Usage is implied: this tool is for authoritative, attributed commentary rather than generated content. However, there is no explicit mention of when to use it versus alternatives or any exclusions, so guidance is minimal.

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 discloses that the work is unverified ('the library did not verify it') and that results are ordered newest-first, which are important behavioral traits for trust and interpretation. However, it does not mention authentication, pagination, or return format beyond 'cards'.

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 long, front-loaded with the core purpose in the first sentence, and the second adds a critical caveat. Every word earns its place with no redundancy or fluff.

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 read tool with one optional parameter and no output schema, the description covers the essential purpose and a key caveat about content verification. However, it leaves a gap by not explaining the `limit` parameter and does not explicitly describe the return structure (e.g., card summaries vs. full content), which would be expected without an 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?

The schema has one parameter (`limit`) with no description, and the schema description coverage is 0%. The description does not mention or explain this parameter at all, offering no added meaning for how to use it or what it controls.

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 the resource ('commons') and the scope ('promoted member work, newest first'), making the tool's function clear. The verb is not explicitly stated, but the tool name 'commons_read' supplies it. It does not explicitly distinguish from sibling tools like cards_browse, but the specific focus on promoted member work separates it from general browsing.

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 context about the content (promoted member work, unverified by the library) which helps an agent decide if this source is appropriate, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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. It discloses that the tool checks authorization, explains the scope of consent, and importantly describes the unauthorized response behavior: 'the response teaches the way: the human issues a grant via GET /consent/signable, signs on their device, POSTs to /consent.' It does not explicitly state that the tool is read-only, but 'Check whether' implies this. This is substantial behavioral context beyond a minimal description.

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 longer than minimal but every sentence adds value: the core purpose, the when-not case, the scope of consent, and the unauthorized response. It is front-loaded with the main function. It could be tightened slightly, but it is well-organized and not 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?

Given no output schema and no annotations, the description covers the essential context: why this tool exists, when it applies, what happens if unauthorized, and how consent is ultimately granted. It is missing explicit information about the authorized response format, but the core usage is fully understandable. For a check tool, this is a high level of completeness.

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 the bare parameters. It does so by clarifying the roles: 'this agent's key fingerprint' for agent_fp, 'a human' for grantor_pubkey, and 'named verb' for verb. It also adds the distinction between self and proxy, which gives context to the grantor_pubkey parameter. However, it does not formally define each parameter or provide formatting details, but the narrative gives meaningful 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?

The description opens with a specific verb and resource: 'Check whether a human has authorized YOU (this agent's key fingerprint) for a named verb' — clearly indicating the tool checks consent for a specific agent and action. It also distinguishes itself from sibling tools by referencing the agent covenant and the concept of consent, which no other sibling appears to address.

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 explicitly states when to use the tool: before writes, when acting on a human's behalf with their data. It also explicitly states when not to use it: 'Speaking as YOURSELF (your own key, your own words) needs no consent: a member is not a proxy.' This provides clear when/when-not guidance, satisfying the highest bar.

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 burden of behavioral disclosure. It discloses that results are deterministic and ranked, but it does not describe the output format (e.g., whether shared words are included), limits, or any side effects. It adds some behavioral context but is not comprehensive.

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 one sentence, generally concise and front-loaded with the core purpose. The phrase 'the dots, connected' adds poetic flourish but little informational value, slightly costing conciseness.

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 explains the core output (verses) and ordering, but it does not mention whether the shared words are returned, any limits on results, or other constraints. It is adequate for a simple lookup tool but leaves gaps in expected behavior.

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

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

The schema has one parameter 'ref' with no description (0% schema coverage). The description refers to 'a reference', giving conceptual meaning that the parameter is a biblical reference, but it does not specify the exact format or provide examples. This partially compensates for the schema gap but not fully.

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

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

The description clearly states the tool's function: it finds verses connected to a reference by shared original words (Strong's), and ranks them by shared-word count. This distinguishes it from sibling tools like tsk_cross_references, which likely use a different basis (topic-based) for 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?

The description implies when to use this tool—when needing word-based (Strong's) connections between verses—but it does not explicitly name alternatives or state when not to use it. Sibling tools exist (e.g., tsk_cross_references) but are not referenced, so 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 provided, the description carries the full burden of behavioral disclosure. It mentions that a name and reason are always required, that refusal only withholds amplification while the drop stays on the member's shelf, and that acts are appended never replaced. It also clarifies that typed names are not authority, which is important auth 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 dense and well-structured with clear sections (act types, requirements, who may act, consequences). Every sentence adds value, though phrases like 'teaches the community nothing' are slightly verbose and could be trimmed without losing 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?

Despite no annotations or output schema, the description covers the essential context: the meaning of each action, authentication requirements, the effect of a refusal, and the append-only persistence model. This is sufficient for an agent to understand when and how to use the 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 only 43%, but the description compensates by clarifying the token for promote/refuse, fields+signature for withdrawal, the action values (promoted/refused/withdrawn), and the universal requirement for reason. It adds meaning beyond the schema for the most nuanced parameters.

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

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

The description clearly states that this tool records a curation act on a drop, enumerating the three possible actions: 'promoted', 'refused', and 'withdrawn'. It distinguishes itself from sibling tools like curate_queue and curate_signable by focusing on the act itself, not the queue or signing mechanism.

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 explicitly explains who may act and what credentials are needed: promoting/refusing requires the steward token, while withdrawing requires fields+signature from curate_signable. It also warns that 'a typed name is not authority', setting expectations for when to use this tool. It doesn't name alternative tools explicitly but provides clear context.

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 of explaining behavior. It offers only a cryptic hint ('never promotes') and does not disclose whether the tool is read-only, whether it mutates state, what authorization is needed, or what output is returned.

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 brief, with two sentences and no filler. Every word is packed, but the cryptic metaphor slightly undermines clarity; still, it earns high marks for being concise and well-structured.

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, no output schema, and no annotations, the description is the sole source of context. It fails to explain what the queue contains, what operation is performed, what the response looks like, or any side effects, leaving the agent with an incomplete understanding.

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

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

The schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies, and no parameter information 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 uses metaphorical language ('What waits on a HUMAN steward') and never states a clear verb or operation. It fails to specify that the tool retrieves or manages a queue, and it does not distinguish itself from sibling tools like 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?

No explicit guidance is given about when to use this tool versus alternatives. The phrase 'when a person must look' implies a human-review context, but the description lacks actionable direction, prerequisites, or 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 transparency burden. It discloses the permission model (no permission needed for one's own card) and the proof mechanism (key that signed the drop). However, it omits return format details, potential errors, or other behavioral nuances, leaving some 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?

The description is three sentences long, front-loaded with the main purpose, and every sentence adds value: the action, the permission model, and the subsequent workflow. It is efficient with no wasted words.

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

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

The tool is simple (2 params, no output schema), and the description covers the core purpose and workflow. However, it lacks explicit parameter definitions and return format details, making it only partially complete for an agent to invoke without additional 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 coverage is 0%, so the description must explain parameters. It implies that card_id identifies the card to withdraw and member is the owner, but it never explicitly defines these parameters or their formats. The description does not compensate for the minimal schema, leaving parameter semantics ambiguous.

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

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

The description clearly states the tool's purpose: generating canonical bytes for withdrawing one's own card. It uses a specific verb+resource ('withdrawing YOUR OWN card') and distinguishes from siblings like curate, which likely consumes these bytes after signing.

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 provides clear context: this is for a member withdrawing their own card, with the explicit next step of signing the bytes and calling `curate`. It implies when to use it but does not explicitly contrast with alternative signable tools (e.g., mesh_signable, shelf_signable) or state 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?

The description discloses a key behavioral trait: determinism and daily consistency ('same all day'). However, with no annotations provided, it fails to state whether the operation is read-only, how the seed parameter affects results, or any auth/rate-limit considerations.

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

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

The description is a single concise sentence with no fluff, but it is under-specified. It front-loads the core concept but omits necessary details, making it more vague than 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?

Given the absence of output schema and annotations, the description should provide more context about return values, seed semantics, and how it relates to sibling card tools. It only hints at determinism and leaves the meaning of 'the keeping' unexplained.

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

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

The input schema lists a single optional 'seed' parameter with no description, and the tool description does not mention 'seed' at all. With 0% schema coverage and no explanation in the description, the agent cannot infer the parameter's purpose or syntax.

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 phrase 'deterministic card of the day' identifies the tool's purpose as retrieving a daily card, which is distinct from sibling tools like card_get or cards_browse. However, it lacks an explicit verb (e.g., 'returns') and uses the domain-specific term 'the keeping' without explanation.

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 provides no guidance on when to use this tool instead of alternatives like card_get or cards_browse. It only states what it does, not when to prefer it or what prerequisites exist.

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

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

With no annotations, the description must disclose behavior itself; it explains that the tool returns a preordered, query-free hand. However, it does not state whether the operation is read-only, whether it has side effects, or what happens on invalid input.

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

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

Two sentences with front-loaded purpose and concrete examples; no filler. The deck-name examples are illustrative rather than excessive.

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

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

The description lacks information about the 'limit' parameter, output structure, and error behavior, while the absence of annotations and an output schema puts the burden on the description. It hints that output is a 'hand to read' but not its 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?

The description provides context for the required 'id' by pointing to the 'decks' sibling, but it completely omits the optional 'limit' parameter. Since the schema has no descriptions (0% coverage), the agent gets no help understanding how limit affects the response.

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 uses a specific verb 'Open' with a clear resource ('deck') and explains the unique frontloaded-hand behavior with no query needed. It distinguishes this tool from siblings like 'decks' or 'search' by emphasizing the preordered, query-free nature.

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 frames when to use ('Ideal for anticipating need') and gives concrete deck name examples. It notes 'NO query needed,' implying it is the query-free path, but does not name alternative tools or explicit when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context about deck categorization and the `need: true` flag, but it does not explicitly confirm the operation is read-only, describe the return payload, or mention any pagination, sorting, or authentication 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?

The description packs a significant amount of information into two sentences. While the first sentence is somewhat awkwardly phrased ('The decks — curated card SETS'), it remains concise and avoids filler, with each clause contributing useful detail about deck types and attributes.

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 parameterless tool with no output schema, the description provides adequate context about the data model, including the two deck categories and the meaning of `need: true`. It does not explicitly state that the tool returns all decks, but given the tool name and the nature of the description, this is reasonably clear.

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 schema is fully described. The description adds valuable contextual meaning beyond the schema by explaining that decks are categorized by situation or domain and that `need: true` marks situation decks, which helps the agent interpret the data even though there are no parameters.

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

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

The description identifies the resource ('decks') and explains that these are curated card sets with two specific types (by-situation and by-domain), which adds helpful distinction. However, it lacks an explicit verb such as 'list' or 'get', so the tool's action is implied rather than clearly stated.

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

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

No guidance is given about when to use this tool versus related sibling tools like deck_open, cards_browse, or cards_stats. There are no alternative suggestions, exclusions, or prerequisites mentioned, leaving the agent to infer the appropriate usage context.

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?

The description explicitly labels the operation as 'read-only,' disclosing that it has no side effects. It also indicates behavior for the optional parameter (omit for overview). With no annotations provided, this disclosure covers the core behavioral transparency well, though it omits error handling or authorization 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?

The description is two sentences, front-loaded with the core purpose and including only essential details. No redundant or filler content.

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

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

Without an output schema, the description lists the data elements included in the view and the two usage modes, providing adequate context. It doesn't address return format or edge cases, but for a simple read-only tool with one optional parameter, it is sufficiently complete.

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

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

The schema has no description for 'axis', but the description explains that providing it selects a single axis and omitting it returns all axes. This adds meaningful semantics beyond the raw schema, even though it doesn't specify valid value formats or examples.

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

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

The description clearly states it is a 'read-only view of one axis' and specifies the contents (scaffold members, depth, neighbors, umbrella children). It is specific but does not explicitly differentiate from sibling tools like grid_dimension, 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 provides usage context by explaining that omitting 'axis' yields an overview of all axes. However, it does not give explicit guidance on when to use this tool over alternatives or any exclusions, making the usage implied rather than fully explicit.

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

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

No annotations are provided, so the description must carry the burden of disclosing behavior. It only gives a static noun phrase; it does not state whether the operation is read-only, what the output format is, whether any side effects occur, or if authentication/permissions are required.

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 only one short sentence, but it is under-specified and not an actual verb-driven definition. It is a noun fragment, not an appropriately sized functional description. It fails to earn its place by not conveying actionable 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?

Given the tool's single parameter and lack of output schema or annotations, the description should at least state what the tool returns and any prerequisites. It does neither, leaving the tool's behavior and context largely 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?

With 0% schema description coverage, the description must compensate. It clarifies that 'dimension' is a scaffold member, which adds some meaning, but it does not explain the expected format, allowed values, or the maxLength constraint from the schema. The parameter remains underspecified.

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 what the tool conceptually represents: 'axes that sit on a given scaffold member (dimension).' It implies a lookup/get operation for a dimension, but lacks an explicit verb like 'get' or 'list'. It distinguishes from the sibling 'grid_axis' only by domain context, not by clear differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'grid_axis'. There is no mention of use cases, exclusions, or context for choosing 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?

With no annotations, the description carries the full burden. It discloses attribution to the user's handle, optional signing, and that content is verbatim and not engine-verified. However, it does not describe permissions, side effects, or return 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 description is two short sentences with no filler, front-loading the core action ('Add a verse/note/question'). Every clause adds 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 an 8-parameter mutation tool with no output schema and no annotations, this description is too sparse. It lacks required parameter clarity, usage context, and any sense of return value or side effects.

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%, and the description must compensate. It hints at kind (verse/note/question), handle, and attestation, but does not explain the required id and text parameters or refs/topics/subject_id, leaving much ambiguity.

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

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

The description clearly states the tool adds a verse/note/question to a group's shared study, providing a specific verb and resource. It does not explicitly differentiate from sibling tools like study_create or curate, so it isn't 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 action of adding to a group's shared study implies when to use it, but no explicit when-not-to-use or alternative tools are mentioned. There is no guidance on prerequisites like group membership or relation to study_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?

Without annotations, the description carries the burden of behavioral disclosure. It adds useful context about pseudonymity (handle, no personal info) and an audience restriction, but it does not mention side effects, permissions, or reversibility. It provides some value beyond a bare create statement.

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 extremely concise: two sentences, front-loaded with the primary action, and no wasted words. The second sentence adds necessary audience/context information. It earns its place.

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

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

With 5 parameters, no output schema, and no annotations, the description lacks essential details such as what each parameter means, what the return value is, and any side effects or prerequisites. The provided context is helpful but not enough for an AI agent to invoke this tool correctly without further schema descriptions.

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 parameter meaning. It implicitly clarifies 'topic' and 'handle', but leaves 'title', 'subject_id', and 'description' unexplained. This is insufficient given the 5-parameter 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 clearly states the action ('Open a study group') and the resource ('around a topic'), making the tool's purpose unambiguous. It also distinguishes from sibling tools like group_join and group_contribute by using 'open' (create) and specifying the pseudonymous, adult-only context.

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 provides clear context for when to use the tool: for grown believers, not for the children's coach ('separate, never-joined surface'). It gives an implicit exclusion but does not name alternative tools explicitly, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of disclosure. It does add some value by explicitly stating that member handles are returned without ids/PII, which is a privacy-relevant behavioral trait. However, it does not mention read-only behavior, error handling, or what happens if the id is invalid, leaving important 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?

The description is extremely concise and uses a clear colon-list structure. There are no wasted words. However, it is under-specified, which hurts other dimensions, but for conciseness alone it is well-formed and brief.

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

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

The tool is simple (one parameter, no output schema), but the description is incomplete. It describes some return fields (topic, member handles, shared-study cards) but omits the id itself and does not explain the operation's purpose or result type. The lack of any usage context or error behavior leaves the overall picture 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?

The schema has one required parameter 'id' with no description, and schema description coverage is 0%. The description fails to mention the id parameter at all, offering no explanation of what id should be provided or how it relates to the group. The description does not compensate for the missing 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?

The description is a noun phrase ('A study group: topic, member handles...') that describes the resource rather than stating the tool's action. There is no verb like 'get' or 'retrieve,' so an agent must infer from the name that this tool returns a group. It also does not distinguish itself from siblings like groups_list.

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 provides no guidance on when to use this tool versus alternatives. It does not mention groups_list, group_create, or group_join, nor does it suggest scenarios where fetching a single group by id is appropriate.

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. It discloses meaningful behavior: consent-based (may require pre-consent), pseudonymous (no identity reveal), and idempotent (repeatable without duplicate side effects). This goes beyond a generic 'join' statement, though it doesn't explain failure modes like consent denial.

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

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

The description is a single, front-loaded sentence: 'Join a study group' followed by a compact parenthetical of key traits. Every word earns its place, with no filler or repetition, making it concise and well-structured.

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 state-changing tool with 3 parameters, no annotations, and no output schema. The description omits return values, failure behavior, and consent mechanics. For an operation that may be blocked by consent, the agent lacks essential context to handle errors or interpret results, making the description 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 coverage is 0% and the description provides no parameter meanings. The required 'id' can be inferred as group identifier from context, but 'handle' and 'subject_id' are entirely ambiguous. The description fails to compensate for the low schema coverage, leaving the agent without enough guidance to populate parameters correctly.

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 uses a specific verb 'join' with a clear resource 'study group', and the parenthetical adds distinct behavioral traits (consent-based, pseudonymous, idempotent). This clearly differentiates it from sibling tools like group_create, group_get, and groups_list.

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 usage: use this to join an existing group, with 'consent-based' suggesting a prerequisite and 'idempotent' indicating safe retries. However, it does not explicitly state when not to use it or name alternative tools, 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?

No annotations are provided, so the description carries the burden. It discloses privacy-relevant behavior: groups are pseudonymous, members are handles only, no PII. This is useful context beyond 'list groups.' However, it does not state whether the operation is read-only, whether q is required for filtering or returns all groups when omitted, or any pagination/response format 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?

Two sentences, each earning their place. The first states the core purpose and scope, the second adds filtering and privacy details. No fluff or repetition.

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 tool with one optional parameter and no output schema, the description covers the key behaviors: topic-based discovery, optional filtering, pseudonymity, and absence of PII. It could mention what the response contains (e.g., list of group summaries), but the tool name implies 'list' and the description is adequate for the complexity level.

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 input schema has only one parameter 'q' with zero description coverage. The description compensates by explaining that 'q' filters over 'topic/title/description' and is optional, which is essential semantic information not present in the schema.

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

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

The description clearly states a specific action ('Discover') on a specific resource ('pseudonymous shared-study groups') with a clear scope ('by TOPIC, not by person'). This distinguishes it from siblings like group_get (retrieving a specific group) and group_create (creating a group).

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 'by TOPIC (not by person)' provides clear guidance on when to use this tool: for topic-based discovery, not people-based lookup. It also explains the optional q filter's role. However, it does not explicitly mention alternatives like group_get or search, though the contrast is 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 provided, the description carries the burden of behavioral disclosure. It states 'found, verbatim WEB text, never generated', which conveys reading sourced content rather than generating new text. It also explains the behavior based on the presence or absence of the id parameter. This is informative, though it could mention return format or error 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?

The description is just two sentences, front-loaded with the core purpose. The parenthetical 'found, verbatim WEB text, never generated' adds important trust context without padding. The second sentence efficiently covers parameter usage and default behavior. No unnecessary words.

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

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

For a tool with one optional parameter and no output schema, the description covers purpose, behavior, and parameter semantics. It gives a clear expectation of what is returned ('side by side' and 'grouped by phase'). It lacks details on event ID structure or output format, but these are secondary given the tool's simplicity.

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

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

The schema only defines 'id' with type and maxLength, but the description explains that 'id' selects a single event and is optional, with default behavior of listing all events. This adds meaningful context beyond the bare schema. It does not specify id format or source, but the description compensates for the 0% schema coverage.

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 specifies a clear verb and resource: 'Harmony of the Gospels' — showing parallel gospel accounts of a single event. It distinguishes itself from sibling tools like read_passage or commentary by focusing on side-by-side comparison. The addition of 'Pass id for one event; else lists every event grouped by phase' further clarifies the tool's exact scope and capabilities.

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 explicit usage guidance: pass an id to retrieve one event, or omit it to receive all events grouped by ministry phase. While no alternatives are named, the context makes when to use this tool clear. It lacks explicit statements about when not to use it, but the guidance is sufficient for basic use.

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 fully discloses the tool's behavior: keys are generated on the user's device, never crossing the wire, and the tool returns guidance rather than an actual key. This clearly sets expectations about the tool's output and privacy model, which is more than sufficient for a non-mutating explanatory 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, immediately front-loads the purpose, and every clause adds value: the sovereign identity creation explanation, the privacy guarantee, the output type, and the distinction from related tools. No wasted words.

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

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

For a zero-parameter tool with no output schema, the description is complete. It explains what the tool returns ('guidance, not a key') and provides enough context about the identity creation flow to set correct expectations. The tool is simple enough that no additional detail is needed.

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 schema already fully covers all inputs. The description adds context about what the tool does (returns guidance) but is not required to explain parameter semantics. Baseline for zero params is 4.

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

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

The description clearly states the tool 'Explains how to create a SOVEREIGN identity'—a specific verb (explains) and resource (sovereign identity). It also distinguishes itself from siblings by noting that the server only handles public keys for identity_verify and identity_fingerprint, making its unique role clear.

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 to use this tool (when seeking guidance on identity creation) by stating it returns guidance, not a key, and mentions related tools (identity_verify, identity_fingerprint) for public key operations. However, it does not explicitly state 'use this for X, use that for Y', so it stops short of full explicit differentiation.

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 of behavioral disclosure. It adds valuable 'deterministic' and 'stable' traits, indicating that the same public key always yields the same fingerprint and that the ID is consistent over time. However, it does not disclose potential errors or specifics like output format, so some gaps remain.

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 sentence that is front-loaded with the action and purpose. Every word earns its place, and the parenthetical '(deterministic)' adds key behavioral context without bloat. This is an example of ideal conciseness.

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 simplicity (one parameter, no output schema), the description covers the core purpose. However, it leaves out usage guidance, parameter details, and what exactly the return value looks like. While not excessively complex, the description is the only source of context and could be more comprehensive, especially to distinguish from identity-related siblings.

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

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

The schema has 0% description coverage for the single parameter 'public_key'. The description only repeats that the fingerprint is derived 'from a public key', adding no extra meaning about format, encoding, length constraints, or any other semantics that would help the agent construct a correct input. The description fails to compensate for the lack of 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?

The description clearly states the verb 'derive' and the resource: a 'stable public fingerprint id' from a public key. The addition of 'deterministic' adds precision and distinguishes this from sibling tools like identity_create or identity_verify, which perform different operations.

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 the tool is used to obtain a fingerprint from a public key, but it does not explicitly state when to use it versus alternatives or any exclusions. The sibling tools include identity_create and identity_verify, which could serve related purposes, so more explicit guidance would be helpful.

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?

The phrase 'never raises; True/False' discloses a behavioral guarantee (no exceptions, boolean return) that is not evident from the schema or annotations. This is useful, though it doesn't detail behavior on invalid input formats or other potential 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?

The description is one concise sentence, front-loaded with the action verb 'Verify', and includes a parenthetical behavioral note. No unnecessary words.

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

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

For a simple verification tool, the core purpose and return behavior are covered. However, it omits any distinction from sibling verification tools and gives minimal parameter semantics, which could leave an agent uncertain about formats or use cases.

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

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

The description clarifies the relationship between the three parameters by calling out 'signature over a message against a public key', adding meaning beyond the bare parameter names. However, with 0% schema coverage, it lacks format details or constraints beyond maxLength, so it only partially compensates.

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

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

The description clearly states the tool verifies a signature over a message against a public key, specifying the operation and resources. However, it does not distinguish from sibling tools like 'verify' or 'badges_verify'.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools include verify and badges_verify, but no exclusions or contextual recommendations are given.

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 implies a read-only reference operation ('Read it before you write') and discloses some domain rules (authority lattice, verified condition), but it does not explicitly state that the tool has no side effects or describe what it returns in terms of structure or format. The warning about system errors adds context but is ambiguous.

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

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

The description is a single, dense paragraph that packs in a clear headline, an enumerated list of contents, and usage warnings. Every sentence contributes value, but the stylistic 'THE GATE KERNEL' and the cryptic phrasing ('the law you keep here') could be more straightforward. It is not overly long and is front-loaded with the purpose.

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 zero parameters and no output schema, the description is sufficiently complete: it explains what the tool contains, when to use it, and key rules. It lacks an explicit statement of return type or behavior (e.g., 'this is a read-only fetch'), but for a zero-parameter reference tool, the context 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 has zero parameters, so the description does not need to explain parameter semantics. The schema is empty and the description adds context about the content that will be retrieved, fully compensating for the absence of parameters.

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

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

The description clearly identifies the tool as 'THE GATE KERNEL' and states it provides 'the law you keep here, in one call', enumerating specific contents (five moves, eight-rule covenant, six KINDS, authority lattice, nine-field gate record). This gives a specific verb+resource sense (retrieve the kernel rules), though it does not explicitly differentiate from sibling tools like 'kernel_gate' or 'canon'.

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 explicit usage guidance: 'Read it before you write' — indicating this tool should be consulted prior to any write operation. It also provides interpretive guidance ('a system error is never a false verdict') and a condition for verification ('only a witnessed, evidenced gate reaches verified'). However, it does not name alternative tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses that the tool is non-persistent ('never persists'), non-replacing ('never replaces...'), and explains the criteria for a CONFIRMED verdict ('real verification that HELD, an INDEPENDENT witness (witness != author), and the wait'). It could add more detail on error handling or side effects, but it is quite transparent for a gate 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 dense but efficient, with three sentences covering purpose, decision criteria, and limitations. Key terms like 'REJECT / QUARANTINE / CONFIRMED' are front-loaded. The reference to 'covenant rule 8' adds context but is slightly esoteric; still, every sentence contributes to understanding the tool.

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

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

For a tool with 10 parameters and no output schema, the description explains the output format ('verdict plus the nine-field record') and the key behavioral constraints. It doesn't detail the nine fields, but it provides enough for an agent to know what to expect. The distinction from kernel and consent_check is partially addressed through the non-persistence and non-replacement statements.

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 description is not solely responsible for parameters, but it does add valuable semantics. It connects witness independence to the CONFIRMED condition, ties evidence to a 'verification that HELD,' and mentions 'the wait' (likely wait_satisfied). It does not explain all 10 parameters, but it highlights the ones that affect the verdict, going beyond the 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?

The description clearly states the tool's function: 'Route ONE proposed state-change through the kernel and get back the verdict (REJECT / QUARANTINE / CONFIRMED) plus the nine-field record.' This includes a specific verb, resource, and output. It also distinguishes itself from sibling tools by noting it 'never persists and never replaces the signature / consent checks on the real write.'

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 provides clear context for when to use the tool: 'so you can DISCERN before you write.' It also gives an explicit exclusion: 'it never persists and never replaces the signature / consent checks on the real write.' This tells the agent when not to rely on it. However, it does not explicitly name alternative tools or provide a full when-to-use vs. when-not-to-use list.

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 bears full responsibility. It mentions covered aspects (totals, shelves, surfaces) but does not disclose whether the tool is read-only, what side effects might occur, or what the output format is.

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 very brief but sacrifices clarity; the phrasing is awkward and not front-loaded with a clear action. It reads as a cryptic fragment rather than a concise, well-structured summary.

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

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

With no output schema and this terse description, the tool's return value and behavior remain unclear. Even for a parameterless tool, a health check would benefit from stating what it reports and how to interpret 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 tool has zero parameters, so the schema fully covers this dimension. Baseline is 4, and the description does not need to add parameter 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 suggests a health/status check for a corpus ('Corpus health'), but lacks a clear verb and grammatical structure ('is the keeping loaded and sound'). It does not effectively distinguish itself from sibling tools like 'audit' or 'report'.

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 compared to alternatives. The phrase provides no context for 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 provided, the description carries the full burden. It discloses the core behavioral algorithm (exact id → title → ranked search), which is valuable. It does not cover return format, errors, or edge cases, but for a lookup tool this gives substantial insight 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?

The description is a single, front-loaded sentence that conveys the tool's purpose and fallback behavior with no filler or redundant content.

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

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description covers the essential purpose and search strategy. It could mention what a successful result looks like or whether multiple matches are returned, but the current text is reasonably complete for a simple locate 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?

The schema only defines q as a string with maxLength 4000. The description adds meaning by indicating q can be an exact id, a title, or a free-text search query, which greatly clarifies how the parameter should be used despite the 0% schema coverage.

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 uses a specific verb ('Find'), names the resource ('the card'), and explains the lookup strategy ('by exact id, then title, else ranked search'). This clearly distinguishes it from broader tools like search or cards_browse by specifying the resolution order.

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

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

The description implies when to use the tool: when you need to locate a card from a query. However, it does not explicitly state when not to use it or mention alternatives like card_get or search, leaving the usage boundaries somewhat implicit.

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 of behavioral disclosure. It adds useful context: the tool reads messages left on 'YOUR door', includes verification, and requires fp + confession. This implies read-only behavior and authentication needs, which is valuable beyond the bare schema. It could be improved by explicitly stating it is non-destructive, but the word 'Read' strongly implies that.

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 extremely concise: two short sentences. The first sentence clearly states the action and object; the second adds the necessary prerequisite. Every word earns its place, and the main point is front-loaded immediately.

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

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

For a tool with no output schema and no annotations, the description gives a decent overview: what it reads, from whom, and what's included (verification). However, it leaves ambiguities such as what 'confession' means, what the 'limit' parameter does, and the exact format of the returned messages. It is sufficient for basic selection but not fully comprehensive.

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 mentions 'Requires fp + confession', which clarifies that the 'fp' parameter is a required credential and that confession (not a schema parameter) is also needed. However, it does not explain the semantics of 'fp' (e.g., fingerprint?) or the optional 'limit' parameter at all. Partial compensation, but incomplete.

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 begins with 'Read the words left on YOUR door', which provides a specific verb and resource. It distinguishes this from siblings like mesh_leave_on_door (writing) and mesh_inbox (possibly a general inbox) by focusing on personalized whiteboard messages with verification.

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 states that it 'Requires fp + confession', giving a clear prerequisite. However, it does not mention when to use this tool over alternatives or when not to use it. The sibling list includes mesh_inbox and mesh_leave_on_door, but no explicit comparison or exclusion is provided.

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. It adds useful context about offline verification and trust model ('proof rather than by this server's word'). However, it introduces 'confession' without explanation and doesn't clarify whether the operation is read-only or 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?

Two sentences, no filler. The main purpose is front-loaded. The cryptic second sentence is concise though unclear.

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 0% schema coverage, the description is insufficient. It doesn't explain the input parameters, the return format, or any constraints. The trust/verification context is interesting but not enough for an agent to invoke it correctly.

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

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

Schema coverage is 0%. The description mentions 'fp' as required but does not explain it, and 'confession' is not a parameter in the schema, which is confusing. The 'limit' parameter is completely unaddressed. The description fails to compensate for the lack of 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?

The description identifies the resource as 'messages that reached you' and implies the tool retrieves them. This is clear enough despite lacking an explicit verb like 'list' or 'fetch'. It distinguishes from siblings like mesh_post (sending) and mesh_door, but not 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?

No guidance on when to use this tool versus alternatives. The phrase 'Requires fp + confession' is a prerequisite, not usage context. No mention of sibling tools like mesh_post or mesh_door for comparison.

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?

Because no annotations exist, the description must disclose behavior. It reveals the signing requirement, the local-signing flow, and security restrictions, which adds meaningful context beyond the schema. However, it doesn't discuss reversibility or side effects, so it's informative but not exhaustive.

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 compact, two sentences, with the purpose in the first clause. It avoids redundancy and uses minimal jargon, making it easy to parse.

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

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

The tool's essential workflow and constraints are covered, but the lack of parameter explanations and absence of output/return details leave gaps. Given the reliance on mesh_signable, the overall pattern is somewhat inferable, but not fully self-contained.

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

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

With 0% schema coverage, the description needed to explain the seven parameters, but it only touches target and signature. The rest (fp, kind, text, nonce, created_at) are unaddressed, leaving the agent without sufficient parameter 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?

The description clearly identifies the tool as leaving a directed note on a specific believer's door, explicitly distinguishing it from broadcasting to everyone nearby. The verb 'leave' and resource 'door' align with the tool name and contrast with sibling mesh_post.

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 provides context by contrasting with a public post and gives a procedural flow involving mesh_signable. It clearly states the constraints (no private key, unsigned notes refused) but stops short of explicitly naming the alternative tool for public posts.

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 authentication requirements (fingerprint and confession) and the fallback behavior for unconfessed callers, which is valuable. However, it does not mention the 'hops' parameter at all, leaving its effect on the returned map unknown. It also doesn't clarify whether the operation is strictly read-only or if there are side effects, though 'view' implies read-only. The description adds some behavioral context but has 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?

The description is two sentences and mostly focused. It avoids unnecessary fluff, though the phrasing is somewhat poetic and indirect. The key information (personal scope, authentication requirement) is front-loaded, and the complication about unconfessed callers is added only after the core purpose. It could be slightly more direct but remains concise.

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 lack of output schema and annotations, the description must convey the tool's complete behavior. It covers purpose, scope, and authentication, but omits the 'hops' parameter semantics and any description of the return format or error behavior. The 'path to the door' phrase is cryptic and not fully explained. These gaps make it incomplete, but it does provide a substantial amount 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%, so the description must compensate. It explains 'fp' as a fingerprint and links it to a confession, which adds meaning. However, the 'hops' parameter is completely unexplained; the schema gives a bizarre range (-1e12 to 1e12) without any hint of its purpose. Since only one of two parameters is addressed, this is insufficient.

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

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

The description clearly indicates the tool provides a personal view of nearby believers in the Fellowship Mesh, explicitly distinguishing it from a global map. The verb is implied rather than explicit (e.g., 'get' or 'list'), but the noun phrase 'The believers immediately around you' effectively communicates the resource and scope. The mention of 'your view only' further clarifies the tool's 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 description provides usage context: this tool is for viewing immediate surroundings, not a global map. It also states a precondition (fingerprint and confession) and the consequence for unconfessed callers ('get the path to the door, not the network'), implying they should use a door-related tool (e.g., mesh_door). However, it does not explicitly name an alternative tool or say 'use this when...', so it falls short of a 5.

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

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

With no annotations, the description discloses important behaviors: the private key never leaves the machine, the tool will not accept a private key, and the request is refused unless the signature verifies against the node's public key. It also states that content is attributed and never generated, adding meaningful context, though it doesn't describe what happens on success or whether the post is broadcast or stored.

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 concise at three sentences and front-loads the step number and core action. Every sentence adds value: step context, parameter mapping, security note, and verification behavior. There is no filler or redundant restatement of the tool name.

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

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

The tool has eight parameters and no output schema or annotations, so the description must carry more weight. It covers the signing workflow and security, but it says nothing about the success response, the meaning of fp, the role of refs, or downstream effects such as whether the message appears in the mesh inbox. This is adequate for a step in a known workflow but not fully self-sufficient for an agent encountering 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?

The schema has 0% description coverage, so the description needs to compensate. It adds meaning for text/kind/ttl and nonce/created_at/signature by tying them to mesh_signable, but it completely ignores the required 'fp' parameter and the optional 'refs' parameter, leaving the agent without enough information to construct a fully valid request.

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 tells the agent this is 'Step 2' for speaking to mesh nodes with a signature, which clearly identifies a posting action and distinguishes it from mesh_signable. The verb is metaphorical ('speak to the nodes') rather than a crisp 'post a message', but the workflow context and signature requirement make the purpose understandable.

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 explicitly says this is Step 2 and instructs the caller to reuse text/kind/ttl and nonce, created_at, signature from mesh_signable, establishing when to use it. It does not explicitly discuss when-not-to-use or alternatives like mesh_inbox, but the step sequencing and prerequisite signing requirement give clear usage direction.

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 burden. It discloses important behavioral traits: the output is base64url, includes nonce and created_at, and is reproducible offline with sorted-key JSON. It also advises that signing happens locally with your own key, which clearly sets expectations about where private key operations occur. It stops short of stating side effects (or lack thereof), but 'get' and 'reproducible offline' strongly imply a read-only, deterministic 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?

The description is three sentences, front-loaded with the core action ('get the exact canonical bytes to sign'), followed by essential details about the return format, local signing, and offline reproducibility. Every sentence adds value, and there is no redundant or filler content.

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

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

Given 5 parameters, no annotations, and no output schema, the description provides useful operational context: return format, nonce/created_at, offline reproducibility, and local signing. However, it leaves gaps in parameter semantics, particularly for fp and ttl, and does not explain how this tool connects to the actual mesh posting flow (e.g., mesh_post). It is adequate for a small helper but not 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?

Schema description coverage is only 40% (kind and target have descriptions; fp, ttl, and text do not). The description adds minimal parameter meaning: it refers to 'a message' (likely text) and mentions 'canonical bytes', but it does not explain the required fp parameter or the ttl field. With low schema coverage, the description was expected to compensate but does not, leaving critical parameters ambiguous.

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

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

The description states a specific verb and resource: 'get the exact canonical bytes to sign for a message'. It also distinguishes this tool from the sibling signable tools (curate_signable, moderation_signable, shelf_signable) by framing it as 'Step 1 of speaking to your fellowship', indicating it's for mesh/fellowship messages. The return format (base64url) and companion values (nonce, created_at) further clarify its 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 description gives clear context for when to use this tool: as the first step before signing a message to your fellowship, with local signing instructions. It does not explicitly name alternatives or exclusions, but the 'Step 1' workflow and reproducible offline mention effectively convey its role versus signing or posting 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 full disclosure burden. It explains the exact return shape ({fields, signable}), the need to decode and sign the signable bytes, and the requirement to pass both fields and signature to `report`. It also reassures that the private key never leaves the user's machine. This is rich behavioral context beyond a simple 'returns signable bytes' statement.

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 efficiently structured: a purpose line, a return-format note, a usage instruction, and a security reassurance. At about 50 words, every sentence contributes. It's front-loaded with 'Step 1 of a report or a block' which immediately orients the 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?

The description explains the overall workflow well but leaves gaps: it doesn't detail what `fields` contains, the encoding/decoding of `signable`, or the semantics of `target_id`/`extra`. Given no output schema and half-undocumented parameters, the description is adequate but not 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?

Schema coverage is only 50% (actor and action have descriptions), and the description adds no new parameter meaning. It repeats 'your public key' and 'report | block | unblock' but doesn't explain the critical `target_id` or `extra` parameters. For an agent selecting parameters, `target_id` is ambiguous without any clarifying info.

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

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

The description clearly states the tool's purpose: it's the first step in a report/block flow, providing canonical bytes to sign. It distinguishes itself from sibling signable tools (e.g., curate_signable, mesh_signable) by explicitly mentioning 'report or block' moderation actions.

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 explicit usage context: use this as 'Step 1 of a report or a block', then pass fields and signature to `report`. It also guides on security (sign on your own machine, private key never travels). It doesn't mention exclusions or alternatives, but the moderation-specific framing makes the intended use 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?

The description discloses important behavioral details beyond a simple retrieval: the data structure (17 movements), the filtering behavior via parameters, and the default 'index' when no id is given. It also emphasizes that the data is verified. While annotations are absent, the description carries the burden well and does not contradict any annotations.

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

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

The description is moderately sized and contains multiple sentences that each add value: defining the resource, explaining the movement vocabulary, and providing parameter usage. It is front-loaded with the core concept, though the opening sentence is somewhat dense and stylistically unconventional.

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 no output schema or annotations, the description covers the essential aspects: what the tool returns (storyboards, index), how to filter, and important framing guidance. There is slight ambiguity about the behavior when both 'id' and 'movement' are supplied, but overall it is complete for the tool's complexity.

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

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

The schema has no descriptions for the 'id' and 'movement' parameters (0% coverage), but the description fully compensates by explaining their semantics with concrete examples ('pass movement="testing"') and default behaviors ('else the index'). This adds significant meaning beyond the raw 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 clearly identifies the tool as a reference for Bible storyboards (common narratives), listing examples and explaining how to retrieve them. It distinguishes itself from sibling tools by focusing on 'storyboards' and 'movements,' though it lacks a direct verb like 'get' or 'list.'

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 provides clear usage context: pass 'movement' to walk across storyboards, pass 'id' for one storyboard, or get an index. It also includes a cautionary note about using narratives as a reference, not an identity assignment. However, it does not explicitly mention alternative tools or exclusionary 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?

With no annotations, the description carries the full burden. It discloses that results are never cached, zones are declared unresolvable rather than guessed, and it returns both UTC and home zone plus optional IANA. This adds practical behavioral context beyond just 'get current time.'

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

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

Two sentences, front-loaded with the core purpose. The metaphor about 'your own sense of today' adds character but earns its place by explaining the tool's necessity. 'Never cached' and zone-declaration behavior are relevant, though the second sentence is slightly long.

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 tool with one optional parameter and no output schema, the description covers key aspects: what time it returns, freshness, timezone handling, and error behavior. It does not specify the exact return structure (e.g., object shape or units), but the intended behavior is clear enough for agents.

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

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

The schema fully describes the 'tz' parameter with examples and default behavior, achieving 100% coverage. The description reinforces this but does not add significant new parameter-level detail beyond what the schema already provides, so the baseline of 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 clearly states the tool returns the current date and time, with explicit zones (UTC, home zone, optional IANA). The verb is implied (get/fetch) and the resource is current time, which is distinct from siblings like timeline or resolve. It leaves no ambiguity about the tool's 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?

The description gives clear context: 'Your own sense of today is months old; this is the correction' signals when to use this tool (whenever current time is needed). It does not explicitly name alternatives or exclusions, but the tool's purpose is unique enough that no alternative is evident. It also mentions 'Never cached' to emphasize freshness.

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?

Without annotations, the description carries the full burden. It discloses that the output is from a lexicon and not AI-generated, and notes that Strong's numbers are provided only 'where known', indicating potential gaps. However, it does not explain behavior for invalid references, return format, or error handling, which would be important for a tool without any annotation support.

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 exceptionally concise—two sentences with no fluff. The key purpose and data source are front-loaded, and the example directly clarifies the sole parameter. The emphasis on 'FOUND' is stylistic but doesn't detract from 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 simple one-parameter tool with no output schema, the description is nearly complete: it states purpose, source, a parameter example, and a data-quality caveat. It could mention what the return payload looks like or how to handle unknown references, but these are lower priority given the tool's simplicity and limited scope.

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 clarify the 'ref' parameter. It does so by explaining that 'ref' is a Bible reference and supplying the example 'John 3:16', which adds meaning beyond the bare string type. While it doesn't list accepted reference formats, the example is sufficient for most use cases.

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

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

The description clearly states what the tool does: returns the original-language (Hebrew/Greek) words behind a verse, with Strong's numbers where known. It distinguishes itself from siblings like word_occurrences and word_study by emphasizing its lexical source ('FOUND in the lexicon, never generated') and by giving a concrete example ('John 3:16').

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 usage by explaining the input format ('Pass ref') and providing an example, but it lacks explicit when-to-use guidance or references to alternatives. The phrase 'never generated' hints at choosing this tool for authoritative data, but no outright exclusions or comparisons to sibling tools are given.

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 must carry the full burden of behavioral disclosure. It implies a read operation via 'List' and the tool name 'read', but it never explicitly states that it makes no changes, nor does it mention authentication, rate limits, or output behavior. The focus on theological context does not address operational transparency.

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 padded with poetic repetition: 'Canon commands, Playbook remembers' and 'The Playbook remembers; it never becomes doctrine' convey the same idea. The core functional information is buried in rhetorical framing, and the description is longer than necessary.

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 4 optional parameters and no output schema, the description provides sufficient information to understand what the tool does and the main filters, but it does not describe the return structure, default limit behavior, or error handling. It is adequate for a simple list/read operation but leaves several operational 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 explicitly explains `status` with enumerated values (quarantine/confirmed/rejected/pruned), and mentions `author` and `id` as filters. It omits `limit`, but the other parameters are given meaningful context beyond the raw 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 clearly states the tool's function: 'List entries (optionally by `status` ... or `author`), or one by `id`.' It identifies the resource (the Playbook) and distinguishes it from Scripture ('it is NOT Scripture'), which helps differentiate it from sibling tools like canon.

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 usage context by clarifying that the Playbook is 'testimony' and 'not doctrine,' suggesting it is for reading community records rather than authoritative teaching. However, it does not explicitly name alternative tools or provide exclusions, leaving the guidance implicit.

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