Pauhu EU Data

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavior beyond that: binary blobs answer binary:true, non-UTF-8 refusal, diff_too_large >100000 lines, response_too_large for oversized single lines, hunk splitting at line boundaries, page sizing (~1MB, 1000 items, truncated:true), and a pauhu-library-receipt/2 on every response including errors.

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

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

Front-loaded with the core compare/repo-vs-package statement, and nearly every sentence carries distinct operational information (modes, binary, size limits, paging, receipts). It is extremely dense and reads as one monolithic paragraph, which hurts scanability, but waste is minimal.

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

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

For a 7-parameter, no-output-schema, high-complexity read tool, the description covers mode selection, error conditions, refusal cases, pagination, and the receipt contract an agent must know to consume or verify results. Nothing needed to invoke or interpret the call is missing.

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

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

Schema coverage is high (86%, baseline 3), but the description adds mode-specific semantics the schema lacks: path returns a unified diff of one file with Myers algorithm and minimal:false large-change handling, and limit means files-per-page in summary mode vs hunks-per-page in path mode. This meaningfully extends the terse schema descriptions.

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

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

States a specific verb (compares) and resource (two exact identities of the same public GitHub repo or npm package, base/head resolved to shas/tarballs). It also articulates the two operating modes (summary vs single-file unified diff), so an agent can tell this apart from code_read/code_grep siblings without opening the schema.

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

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

The description cleanly distinguishes the two modes via 'Without path' vs 'With path', which is genuine usage guidance, but it never says when to choose code_diff over code_read, code_grep, or source_fetch_fragment, nor any prerequisites. Usage is implied rather than routed to alternatives.

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

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

Goes far beyond the readOnlyHint/openWorldHint annotations: it guarantees nothing is silently omitted by reporting counts of scanned files, binary files (defined as NUL byte or invalid UTF-8, never searched as text) and oversized files, and it documents the truncation contract (1000 matches / ~1 MB per page, truncated:true, next_offset). It also explains that every response, including errors, carries a receipt in structuredContent and as a trailing text line, and that library_verify validates it.

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 block but front-loaded correctly: the literal-match purpose comes first, followed by return shape, omission accounting, pagination, and receipt. Every sentence carries information, though bullets or line breaks would make the pagination and receipt clauses easier to scan.

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 10 parameters, the description carries the return-format burden well: it names the match fields (path, line number, line text, blob id), explains pagination and truncation, and describes the receipt envelope. For a read-only search tool this is complete enough for an agent to call correctly, with the remaining gaps (auth, rate limits, repo-vs-package precedence) minor.

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 80%, so the baseline is 3, and the description adds meaning on top: it explains the page-size defaults and hard cap (default 200, at most 1000), the 1 MB byte bound that can end a page early, and the role of next_offset. That said, it says nothing extra about ref resolution, path/extensions filtering, or repo-vs-package precedence beyond what the schema already documents.

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

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

States a precise verb and resource: 'Finds a literal string ... in the text files of a public GitHub repository at a commit sha or an npm package version.' The parenthetical '(no regular expressions)' clearly differentiates it from a regex/semantic searcher, but it does not name sibling tools such as source_search or code_read to complete the disambiguation.

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

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

Usage is implied rather than stated: the literal-match constraint and repo/package targeting tell the agent the kind of query this tool answers, but there is no explicit when-to-use, when-not-to-use, or preferred-alternative guidance relative to source_search or source_fetch_fragment.

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

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

Annotations only declare readOnly/openWorld, but the description adds substantial behavior beyond them: paging semantics with offset/limit, a 1000-entry and ~1 MB per-page bound, the truncated:true signal, total/next_offset fields, and the fact that every response including errors carries a pauhu-library-receipt/2 receivable by library_verify. That is exactly the extra context annotations cannot provide.

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

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

Front-loaded with the core capability and information-dense with no filler, but the single long paragraph with stacked parentheticals is harder to parse than it needs to be for pagination and receipt details.

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 required parameters, the description takes on the burden and does it: it explains the per-file return shape, pagination fields and bound conditions, and the receipt envelope including error responses. An agent has enough to call and 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?

Schema coverage is already 86%, but the description adds meaning: ref is resolved to a commit sha before the read, version is checked against the registry's sha512 tarball integrity, and repo/package are mutually exclusive. It competes with a strong schema rather than duplicating it, though per-parameter detail is mostly left to the schema.

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

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

States a specific verb and resource: listing files under a path of a public GitHub repo at a commit sha, or an npm package at a verified version. It also names what the listing returns (type, size, git blob id), which cleanly separates it from code_read and code_grep without opening their schemas.

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

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

Clear context for when this is the right tool: directory-level enumeration of a repo/package pinned to an exact identity, with the repo/package mutual exclusivity spelled out in the parameters. It never names a sibling as an alternative (e.g. code_read for a single file), so there is no explicit when-not 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that refs are resolved to a commit sha, that npm tarballs are checked against the registry sha512, the exact binary-detection rule (NUL byte in first 8000 bytes or invalid UTF-8), the binary:true answer shape, and that every response carries a pauhu-library-receipt/2. Nothing here is duplicated from the annotations.

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

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

Front-loaded with the core action and the identity guarantee, and each subsequent sentence covers a distinct behavior (paging, binary handling, receipts). It is dense but slightly long; the receipt sentence is necessary but the most expendable.

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

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

With no output schema, the description still describes the return payload (requested lines, commit/version and integrity, path, blob id, source URL) and the error case (receipt on every answer, binary:true with reason/size/blob id). An agent has everything needed to call and 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?

Schema description coverage is already 100%, so the baseline is 3; the description adds how ref resolution and npm integrity verification actually behave and clarifies that next_start_line drives the next page. It stops short of giving format examples beyond what the schema already supplies.

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

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

States a specific verb and resource ('Reads one file of a public GitHub repository or npm package') with the exact identity constraint that distinguishes it from code_list, code_grep and source_fetch_fragment. An agent can tell this is the single-file, commit-pinned read tool without opening the schema.

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

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

Explains when the tool applies (need one file at an exact commit/version), how to page (start_line/end_line, next_start_line), and routes receipt-checking to the library_verify sibling. It does not explicitly contrast itself against code_grep or source_fetch_fragment, so no exclusions are stated.

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

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

Annotations only declare readOnlyHint=true and openWorldHint=false. The description adds rich behavioral semantics beyond that: a uniform facet list, the three align verdicts (exact, frontier, unresolved), the distinction between transient outage and 'no edge', and when an IRI accompanies an exact identifier facet.

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 front-loads the core cross-reference action, then tightly specifies the emitted facets and verdict semantics. Despite domain jargon, every sentence contributes necessary detail, especially since there is no output schema.

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

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

With no output schema, the description adequately covers the return format and verdict meanings, while annotations cover the safety profile. It omits operational constraints and any usage guidance, so it is strong but not fully complete for every decision an agent must make.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description adds no syntax or format details beyond 'one concept' and does not clarify the optional lang default or its effect on rendering literals.

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 ('Cross-reference') and resource ('one concept across EU and global authority id-spaces') and explains the output as aligned facets. It does not explicitly differentiate the tool from any sibling, and no sibling names are referenced, so a 4 rather than 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?

No when-to-use, prerequisites, or alternatives are given. The description explains what happens after invocation but not under what circumstances an agent should choose this tool over, for example, source_verify_bearing or library_verify.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, and the description confirms 'Read-only; takes no input'. It adds value beyond the annotations by disclosing the receipt format (pauhu-library-receipt/2), the fact that every code_* answer carries one, and the fields each catalogue entry exposes. It does not describe ordering or pagination, but for a static read-only listing this is solid.

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 compact sentences that front-load the catalogue contents before the receipt/verification aside. Nothing is redundant, though the phrase 'what the code tools answer' costs a beat of clarity for no real gain.

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

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

With no output schema, the description carries the burden of describing the return payload, and it does list the entry fields (id@version, tool, input). Combined with the receipt explanation and the zero-parameter, read-only nature of the tool, an agent has what it needs, though the exact entry structure remains loosely specified.

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

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

The tool takes no parameters, so the baseline is 4; the description's 'takes no input' simply confirms the empty schema rather than adding semantics, which is appropriate here.

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

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

States a concrete resource (the catalogue of code_* tools) and enumerates what each entry contains – id@version, the tool to call, and its input. The opening clause 'what the code tools answer' is slightly indirect, but the following sentence disambiguates it and separates it from library_verify, which it names 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?

Gives a clear workflow context: every code_* answer carries a receipt, and library_verify is the tool that checks issuance and integrity. That is enough for an agent to know the catalogue is the discovery step and library_verify the verification step, though it never frames an explicit 'use this when' condition or exclusion.

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

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

Annotations already declare readOnlyHint and openWorldHint; the description goes well beyond them by enumerating every failure reason (bad_shape, unknown_block, not_ours, altered, unavailable, self_check_failed) and stating retry semantics for 'unavailable'. 'Read-only' merely repeats the annotation, but the failure-mode disclosure is genuinely useful.

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

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

Front-loads the core action in the first sentence, then systematically lays out the answer shape and reason codes. It is dense but every clause (especially each reason value) carries information; minor redundancy with the annotation's 'Read-only' clause.

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

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

Despite no output schema, the description fully specifies the return object (verified, reason, id), every possible reason value with meaning, and the no-input self-check behavior. An agent has everything needed to invoke and interpret it correctly.

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

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

Schema coverage is 100% and the single receipt parameter's format, unwrapping behavior, and optionality are already fully documented in the schema description. The description adds the provenance ('from any code_* answer') but largely mirrors what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource: verify a receipt from any code_* answer, and specifies exactly what it determines (issued by this service, unchanged). An agent can distinguish it from code_* and source_verify_bearing siblings without opening the schema.

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

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

Clearly says to pass a receipt from any code_* answer, and explains the alternative no-input mode ('With no input, runs the code tools' self-check'). No explicit when-not guidance or named competing tool, but the usage context is unambiguous.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that with the tenant-scoping rule ('you can only delete your own'), but omits what happens when the id doesn't exist, whether deletion is permanent, and any permission 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?

A single front-loaded sentence with zero filler; the action and scope constraint come first. It is appropriately sized for a one-parameter tool, though it could have spent one more clause on behavior without bloat.

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 destructive mutation the annotations carry the safety burden, and the description adds the tenant boundary. However, with no output schema and an undocumented id parameter, an agent still lacks error/not-found behavior and confirmation that the operation is irreversible, leaving a modest gap.

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

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

Schema description coverage is 0% and the single 'id' parameter carries only a minLength constraint, so the description must compensate. 'By id' and the tenant-scoping note confirm the id is a connector identifier scoped to the caller, but give no format, source, or retrieval hint (e.g., from monitor_list_connectors).

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 ('Delete a registered connector by id') plus the tenant-scoping constraint, so the agent knows exactly what operation this performs. It doesn't explicitly contrast with monitor_register_connector or monitor_list_connectors, but the action is unambiguous from the name and text.

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 versus monitor_list_connectors or monitor_register_connector, nor any preconditions (e.g., must the connector be unregistered first?). The only contextual hint is the tenant-scoping note, which constrains scope but does not route the agent between alternatives.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered by structured data. The description adds the genuinely useful constraint that the operation is tenant-scoped, but it omits whether deletion is permanent or recoverable and what happens if the id does not exist.

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

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

A single front-loaded sentence with zero filler: verb, resource, identifier, and scope in one clause. Nothing is redundant or buried.

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

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

For a destructive mutation with no output schema and an undocumented required parameter, the description should say more: irreversibility, error behavior for unknown ids, and how ids are obtained. As written it leaves an agent guessing about the consequences of the call.

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

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

Schema description coverage is 0% for the single required parameter, so the description must carry the burden. It only says the template is identified "by id" and is tenant-scoped; it gives no format, source, or resolution guidance, leaving the parameter effectively undocumented.

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

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

The description pairs a specific verb ("Delete") with a specific resource ("a registered interest template") and adds the tenant-scoping qualifier, so an agent knows exactly what is being removed. It does not explicitly name sibling tools (e.g. monitor_list_templates or monitor_register_template), but the delete verb makes it distinguishable enough to act on.

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, no prerequisite (e.g. how to obtain a valid template id), and no warning that deletion is permanent. The only implicit usage signal is the tool name itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, non-mutating, account-scoped read. The description adds the ownership scoping detail but says nothing about result volume, ordering, or pagination, which are the behaviors an agent would still wonder about.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately sized for a trivial read tool, though it is short enough that it could have carried one more useful clause (e.g. what the list contains) at no cost.

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, non-destructive list operation with annotations covering the safety profile, the description is minimal but workable. Since there is no output schema, a brief indication of what a connector entry contains would have closed the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is reported at 100% for an empty object, so no compensating text is required.

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

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

States a specific verb (list) and resource (connectors) with an ownership scope ('under your account'), which is enough to distinguish it from monitor_register_connector and monitor_delete_connector. It does not, however, explicitly contrast itself with the near-miss sibling monitor_list_templates.

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

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

Usage is implied by the verb list — you call this when you need the registered connectors. There is no explicit when-to-use/when-not statement and no mention that registering or deleting requires the sibling tools, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the account-scoping qualifier; it says nothing about result size, pagination, or what fields a template contains, and there is no output schema to fill that gap.

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

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

A single front-loaded sentence with no filler; the resource and scope arrive 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 zero-parameter read tool this is close to sufficient, but 'interest template' is unexplained domain jargon and, with no output schema, the description leaves the shape and volume of the returned list entirely unstated.

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

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

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb (List) and resource (interest templates) plus the scope 'registered under your account'. It is distinguishable from monitor_list_connectors by resource name, though it never explains what a 'template' is relative to a 'connector', so sibling differentiation is implicit rather than explicit.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as monitor_list_connectors. The agent must infer that this is a discovery step preceding monitor_register_template or monitor_delete_template.

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

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, so the safety profile is covered. The description adds two genuine behavioral facts: the tool returns the registered connector, and monitor runs over connectors carry no per-run token charge. It does not disclose what happens on a duplicate id (a real concern given idempotentHint=false) or what errors/validation occur.

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

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

Purpose is front-loaded in the first clause, and the rest is a compact enumeration of inputs plus two closing facts. The single long run-on 'Inputs: ...' sentence is dense but every element carries information and nothing is padded.

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

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

For an 8-parameter mutation tool with no output schema, the description covers inputs, enum semantics, auth expectations, the return value, and a billing note. The remaining gap is failure behavior (duplicate id, invalid endpoint), which an agent would need to anticipate.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by explaining the 'kind' enum far more richly than the schema (e.g. 'https_json' answers JSON with url plus text, paragraph_text or title; 'pauhu_sources' covers your plan's sources) and by tying auth_kind='bearer' to a stored token reference. The mcp_tool_name default and poll_fallback_secs description largely duplicate 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 states a specific verb and resource ('Register one of your APIs or MCP servers as a connector') and frames the purpose ('so your sourced monitors can watch it'), which clearly distinguishes it from monitor_list_connectors and monitor_delete_connector by role. It stops short of explicitly naming any sibling as an alternative or complement.

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 only implied: 'so your sourced monitors can watch it' suggests you register before monitors can poll your own sources. There is no explicit when-to-use, no exclusion, and notably no routing between this and monitor_register_template, which is a plausible point of confusion among the siblings.

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

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

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower, yet the description still adds real value: it describes the shape of delivered matches (source URL, paragraph text, verification status) and the delivery semantics of each push kind. It does not state whether re-registering the same id updates or errors, which is the notable remaining gap for a non-idempotent tool.

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

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

Front-loaded with purpose and return shape, then a compact inventory of inputs. The second sentence is a long run-on parameter dump, but almost every clause carries information an agent needs, and nothing is wasted.

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

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

With no output schema, the description usefully describes what a match delivery contains and how it is pushed, which is the main completeness requirement here. The remaining gap is lifecycle behavior on duplicate ids and whether registration is persistent across sessions, minor against otherwise rich coverage.

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

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

Schema description coverage is only 50%, so the description has to compensate, and it largely does: it names id, connector_ids, query, jurisdiction, language, the three threshold kinds with a count for delta_at_least, the webhook URL with optional secret reference, and sse. It adds meaning beyond the enum values themselves, though it never explains what id represents or how it is used for later lookups.

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

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

Specific verb+resource ('Register a sourced monitor') with an explicit statement of what comes back (the registered template). It is clearly distinguishable from siblings like monitor_list_templates, monitor_delete_template and monitor_register_connector, which the description implicitly contrasts by focusing on creating a watch plus a push.

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

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

Usage is implied rather than stated: calling connector_ids 'your registered connectors to watch' hints that monitor_register_connector must run first, and the push-mode options imply when to pick webhook vs sse. But there is no explicit when-to-use / when-not guidance, no note on what happens if the id already exists, and no routing to monitor_list_templates or monitor_delete_template.

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

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

Beyond the readOnlyHint, the description discloses genuinely non-obvious behavior: `entitled: true` does not mean a product is sellable or served, `live_row_count` is a fast estimate rather than the filtered slice, and it explains the billing model (bulk annual plan, no per-call charges, search never billed). These are real traps an agent would otherwise fall into, which is exactly the value annotations cannot provide.

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

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

The core list purpose and the product_id detail mode are front-loaded, and the caveats are marked with IMPORTANT. It is a dense wall of text in one paragraph, and the pricing/billing sentences are somewhat tangential to invocation, but overall most sentences earn their place.

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

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

With no output schema, the description carries the burden of describing returns and does so reasonably: launch state, coverage state, entitled flag, live_row_count, row_count_basis/row_count_note, corpus_state. It names the key fields and their caveats, though it does not exhaustively enumerate the full row shape, leaving a small gap for a list tool.

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

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

Schema description coverage is 100% and only one optional param exists, so the baseline is 3. The description adds meaning beyond the schema by enumerating what the single-product mode returns (unit_definition, provenance, sectoral_ds, licence, cadence, limitations), which tells the agent why to pass product_id at all.

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

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

The description states a specific verb and resource: listing all 14 Pauhu sectoral products with their launch/coverage/access state, plus an optional single-product detail mode. It is clearly a catalogue/state tool, distinct from the search/translate siblings, though it never names a sibling to route against. Purpose is unambiguous even without that 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?

It gives an explicit usage context ('Customer's AI client calls this once at session start to learn product and access state') and a clear conditional for the parameter ('Pass product_id for one product's full served row'). It stops short of naming alternatives (e.g. pauhu_search or library_catalogue) or stating when not to call it, so it lands at a solid 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile and closed-corpus scoping are covered. The description adds genuine context beyond that: results are sourced with per-match snippets, answers trace to a source, and a no-match case is stated explicitly rather than silently returning empty. It stops short of describing pagination or limits, but that is covered by 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?

Two sentences, purpose front-loaded, with the return-behavior detail trailing. The second sentence is slightly run-on but every clause carries information (sourced passages, snippets, source-tracing, explicit no-match).

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it names claimed passages, per-match snippets, source tracing, and the explicit no-match message. What remains missing is corpus scope/limitations and result volume behavior, but annotation coverage handles the safety and world-boundary dimensions.

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

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

Schema description coverage is 100%, so both parameters (q, limit) are already documented in the schema. The description adds no syntax, format, or matching semantics beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Search) and resource (Pauhu's curated, sourced corpus), and the second sentence clarifies what comes back (sourced passages, per-match snippets). However, it never distinguishes itself from the many neighboring search tools (source_search, library_catalogue, source_fetch_fragment), so an agent cannot tell which corpus-retrieval tool to pick from the name alone.

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

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

No when-to-use, when-not-to-use, or named alternative is given. With siblings like source_search and library_catalogue in the same namespace, the absence of any routing guidance is a real gap; usage must be inferred from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety behavior is covered. The description adds valuable behavioral detail beyond annotations: it explains fuzzy/exact matching, a gamma score range of 0.0-1.0, returned EU terminology, and that each match traces to a real paragraph URL. It does not cover no-match behavior or limits, so not a 5.

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

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

Four sentences that are front-loaded: lookup, return contents, source traceability, then CAT integration context. The final sentence partly restates the input/output pattern, but it adds the 'sourced CAT assist' framing and the description remains efficient overall.

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

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

With no output schema, the description carries the return-value burden and does so well: it names the match, gamma score, EU terminology, and source URL. It also states read-only/open-world annotations context. It is nearly complete, though it omits edge cases such as no-match handling and language fallback behavior.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description says 'pass a segment' and mentions terminology, but adds no syntax, format, language-code, or domain-hint guidance beyond what the schema provides. Baseline 3 is appropriate when the schema does the parameter work.

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

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

States a specific verb and resource: 'Look up a text segment in Pauhu TM', and defines the resource as 'aligned human-translated paragraphs from primary EU law sources'. It clearly describes the return (best exact or fuzzy match, gamma score, EU terminology) but does not explicitly distinguish this from sibling tools such as pauhu_search or pauhu_translate.

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

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

Provides clear context for intended use: 'Designed for CAT tool integration: pass a segment, receive the TM match + terms as a sourced CAT assist.' However, it gives no explicit when-not conditions or alternatives to sibling tools, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and dataset-boundary questions are answered. The description adds real value beyond that: the returned fields (authoritative term, domain, reliability rating, equivalents), and the fact that the source is the EU's own authoritative record, which is consistent with the closed-world annotation.

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

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

Front-loaded and readable, but padded: 'authoritative' appears repeatedly and the final sentence ('Used for professional translation and interpretation, using domain terminology sourced from the EU's own authoritative record') largely restates the opening sentence rather than adding information, so not every sentence earns its place.

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

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

For a three-parameter read-only lookup with no output schema, the description covers what the tool does, the input forms accepted, and what is returned (term, domain, reliability rating, target-language equivalents). Only the routing relative to sibling terminology tools and any result-count/pagination behavior are unaddressed.

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

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

Schema description coverage is 100% and both enums are fully specified, so the schema carries the parameter burden and the baseline is 3. The description adds only a small increment ('Accepts single terms or multi-word phrases') about the term parameter's input shape.

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

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

States a specific verb and resource ('Look up EU-canonical terms ... in the EU's authoritative terminology record') and scopes it to 24 official EU languages, so an agent knows exactly what it does. However, it never distinguishes itself from the terminology-adjacent siblings (pauhu_tm, pauhu_search, concept_crosswalk), so an agent cannot route confidently on purpose alone.

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

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

The phrase 'Used for professional translation and interpretation' implies the use context but gives no when-to-use/when-not and names no alternative tool. With pauhu_tm (translation memory) and pauhu_search as obvious alternatives, the absence of any routing guidance leaves the agent to infer.

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

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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description goes well beyond that by disclosing the staleness behavior, the caller_verifies verification obligation, the bearing proof-token handoff, and an epistemic caveat that a citation is not evidence the claim is true. With no output schema, this is exactly the behavioral context the agent needs before acting on the text.

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

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

The purpose and required inputs are front-loaded in the first sentence, and each clause carries information. The closing epistemic caveat is somewhat tangential to invocation mechanics, but it is short and relevant to how the returned text should be treated.

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

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

With no output schema, the description fully covers the return contract (source_url, text_fragment_url, caller_verifies, bearing/null), the stale-result failure mode, and the follow-up tool. Nothing an agent needs to invoke this correctly or interpret its response is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the 'exact query string' and 'exact limit' semantics. The description restates the q/limit/id coupling but adds no format, boundary, or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get one cited result from source_search') and scopes it to a single fragment, which cleanly separates it from the sibling source_search that produces the result set. The relationship to source_verify_bearing (bearing token) is also named, so an agent can place the tool in the workflow without opening any schema.

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

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

Gives a hard prerequisite (reuse the exact q and limit from the originating source_search plus a result id) and a recovery path ('If the results have changed since your search, the call says so; run source_search again'). It also tells the agent what to do when caller_verifies is true. There is no explicit when-not-to-use or alternative-tool comparison beyond the implied dependency on source_search.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the caller_verifies status and the meaning of 'when true, open the cited text before relying on it', plus the warning that a citation is provenance, not truth or currency. That interpretive layer is exactly what annotations cannot express.

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

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

Front-loaded with the purpose, then input, then output, then the follow-up routing and the caveat — a sensible order with no filler. The closing caveat is dense but each clause carries distinct meaning, so it earns its space.

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

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

There is no output schema, and the description compensates by naming the returned fields (answer, results with id/title/url, caller_verifies) and explaining the one non-obvious field's contract. Combined with the explicit follow-up routing, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so q and limit are fully documented in the schema and the description only restates them ('Input: q (query) and limit'). No added syntax, format, or interaction detail for the parameters; baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb and resource ('Search Pauhu's sourced index') plus the return shape ('cited results as JSON'). The final sentence explicitly routes to the sibling source_fetch_fragment, so an agent can distinguish it from the other source_* tools without opening a schema.

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

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

Gives a clear trigger for the follow-up tool ('For one result's citation link, call source_fetch_fragment with the same q and limit and the result id'), which is unusually actionable. It does not distinguish this from siblings like pauhu_search or source_verify_bearing, so it stops short of the full when-not coverage a 5 requires.

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

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

With annotations covering the safety profile (readOnlyHint=true, openWorldHint=false), the description goes further by disclosing the return contract: { ok, status } with the enumerated states ok/degraded/unavailable. That is genuinely useful since there is no output schema. It does not explain what causes a degraded status or any rate/caching 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?

Two short sentences, front-loaded with the purpose and immediately followed by the return shape. Every clause carries information and nothing is padded.

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

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

For a zero-parameter read tool with no output schema, the description supplies everything an agent needs to call it and interpret the result. It stops short of explaining how to react to a 'degraded' status or what 'this resource' resolves to from the caller's perspective.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. No parameter-level gaps exist.

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

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

States a specific verb+resource ('liveness check for this resource') and calls out that it is lightweight, which cleanly separates it from heavier siblings like source_verify_bearing and source_fetch_fragment. It does not name a sibling explicitly, so the differentiation is inferred rather than stated.

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

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

The word 'lightweight' implies this is the cheap check to run before committing to a full verification or fetch, but no when-to-use, when-not-to-use, or named alternative is given. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds that this is a pure boolean check, that the bearing must be passed through untouched, and that the id is echoed back. It does not say whether an invalid or tampered bearing yields verified=false versus an error, which is the one behavioral detail an agent would want.

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 action, then inputs, then return values. Every sentence carries information; no filler or repetition of the title.

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

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

Two parameters, full schema coverage, and no output schema — yet the description explicitly enumerates the return shape (verified and id), which compensates. The only gap is the error/false distinction, minor for a read-only checker.

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

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

Schema coverage is 100% and both parameter descriptions already state 'from source_fetch_fragment, unchanged' and 'echoed back', so the description largely restates the schema. The emphasis on pass-through is useful reinforcement but adds no new syntax, format, or failure semantics. Baseline 3 applies when the schema carries the 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?

States a specific verb (checks/verifies) applied to a specific resource (the bearing from source_fetch_fragment), and names the outcome (verified true/false). An agent can distinguish it from source_fetch_fragment, which produces the bearing rather than checking it. It stops short of saying what the check actually validates (integrity? cryptographic proof? citation match), so 'checks' stays slightly opaque.

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

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

The sentence 'Checks the bearing returned by source_fetch_fragment' establishes the prerequisite and the fetch-then-verify sequence, and 'exactly as source_fetch_fragment returned it' warns against reconstructing the value. There is no explicit when-not guidance, but no sibling overlaps meaningfully in scope, so context is adequate.

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