Agentic Web Wiki — standards reference, probe, validate, template

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuine value by disclosing the response shape and the ranking rule ('ranked by tier and adoption'). It does not say what happens when no filters are supplied, how many standards are returned, or what an empty result looks like.

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 front-loaded sentences with no filler: capability, return shape, then disambiguation. The parenthetical in sentence one is slightly crammed, but every clause carries information an agent needs.

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 100% schema coverage, full annotations, and the return fields spelled out in lieu of an output schema, an agent has what it needs. The one gap is behavior with zero arguments, since all four parameters are optional and required count is 0.

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 baseline is 3. The description goes further by noting `q`/`question` are alternates ('pass question/q and/or use_case + audience filters') and by tying the number of named standards in the query to mode selection — semantics not encoded 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?

States a specific verb and resource ('Recommend and rank standards') plus a second, clearly bounded mode ('compare named protocols head-to-head when the query names 2+ standards'). The final sentence separates it from `search` and `get` by function, so an agent can pick it without opening a schema.

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

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

Explicit routing: 'Use ask for architecture and stack decisions; use search for keyword lookup or get for one standard's record.' It also gives the trigger condition for comparison mode (2+ named standards), leaving nothing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context on top: newest-first ordering, default 50 / max 200 caps, and the option to narrow by lifecycle step or record_id. It stops short of noting pagination beyond the limit or any rate behavior.

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

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

Three sentences, front-loaded with the core action and scope, then return shape, then sibling routing. Nothing is redundant and no sentence could be dropped without losing an agent-relevant fact.

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 spelling out the exact response shape (since, count, entries with date/record_id/field/old/new/source). Combined with filters, ordering, and limits, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, with descriptions and an enum already on every property, so the schema carries the parameter burden. The description restates the since format and the limit bounds rather than adding new meaning; only the mention of combining filters is marginal added value.

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

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

The description opens with a specific verb and resource — 'List machine-verified specification changes' — plus the ordering and default page size. It explicitly distinguishes itself from siblings by naming stale and digest as the tools for different questions.

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 routing rule: 'Use changes for field-level spec diffs; use stale to audit unverified records or digest for daily ecosystem news.' Both alternatives are named with the condition that selects them, leaving nothing 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 readOnly, idempotent, openWorld=false, but the description adds value beyond them: the exact return shape ({ kind, id, name, definition_md, related_protocols, url }) and the error behavior (nearest-term hints on unknown-term). With no output schema, this disclosure is genuinely useful; only minor gaps (e.g. whether hints always accompany not-found) 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?

Three sentences, zero waste: purpose first, then return shape and error fallback, then sibling routing. Front-loaded and appropriately sized.

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

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

No output schema exists, and the description compensates by enumerating the returned fields and describing the unknown-term error behavior. Combined with annotations covering the safety profile, nothing essential is missing for a one-parameter read 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 coverage is 100% and the single 'term' parameter already documents id/name/alias with examples; the description largely restates that. Per the rule, a 3 baseline is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (define) and resource (glossary term or standard) with accepted lookup keys, and contrasts directly with the get and search siblings. An agent can distinguish it from 'get' and 'search' 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?

Explicitly routes: use define for concept definitions, get for a standard's full specification record, search for keyword discovery. All three alternatives and their selecting conditions are named.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavior: the default-to-latest fallback, the exact return shape keys, and the mode toggles. It stops short of describing pagination, size limits, or what happens for an unpublished date, which keeps it off a 5.

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

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

Three dense sentences, purpose first, then return shape, then modes, then sibling routing. No filler or restated name/title; every clause carries operational 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?

No output schema exists, and the description compensates by enumerating the return keys { date, headline, highlights, new_instances, spec_changes, stats }. Defaults, alternate modes, and sibling routing are all covered; only edge-case behavior (unknown date, empty digest) is 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%, so the baseline is 3. The description earns above baseline by documenting the alias relationship (compact is an alias for include_stats: false) and the default-latest semantics of `date`, neither of which the bare schema fields spell out.

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 ("Fetch the curated daily agentic-web news and adoption digest") plus the date keying and default-latest behavior. It also explicitly distinguishes itself from the sibling tool `changes`, so an agent can choose between them without opening either schema.

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

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

Gives an explicit routing rule: "Use digest for daily narrative summaries; use changes for raw field-level diffs." It also states the two alternate modes (list: true for dates, compact: true to omit stats) with the conditions that select them.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds value beyond them by disclosing the unknown-id failure mode (error with nearest matches) and enumerating the returned fields. It stops short of explaining what ambiguous fields like probe or adoption contain, so it is strong 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?

Three tight sentences: purpose first, return/error contract second, routing last. No filler and the most decision-relevant information is front-loaded.

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

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

With no output schema, the description carries the return-value burden and does so by listing the field set and the error behavior, which is enough to call it correctly. Minor gap: several field names are opaque and there is no note on record size or truncation.

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 id parameter already documents the accepted forms with examples (mcp, ard, llms.txt, RFC 9421). The description's mention of id/acronym/filename/RFC restates the schema rather than adding resolution rules or precedence when a value matches multiple standards, 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 and resource ("Fetch one standard's complete specification record") plus the accepted identifier forms, and explicitly names the sibling tools it is not (search, define). An agent can distinguish it from every sibling 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 explicit routing: use get when the id is known, use search to discover unknown ids, use define for glossary concepts. Both the when and the when-not are stated with the alternative named.

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

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

Goes beyond the annotations by disclosing a concrete rate limit (120/min) and the exact return field set, plus the scope limit that it does not grade the site. The annotations already cover readOnly/idempotent/openWorld, so this is additive; it stops short of explaining what fields like 'outcome' vs 'status' vs 'reason' actually mean, which matters since there is no output schema.

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

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

Three compact sentences, front-loaded with the core action and constraint, then the return contract, then the routing guidance. Every sentence carries distinct information with no repetition of the title or 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?

For a 2-parameter read-only check with full schema coverage and complete annotations, this covers nearly everything an agent needs, including the return shape that would otherwise be missing without an output schema. Minor gap: the returned fields are listed but not defined, and no guidance on error/not-found handling.

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 carry their own descriptions with examples (origin hostname, id such as ard/llms-txt/robots.txt). The description adds no parameter meaning beyond that, 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 and scope: check ONE public origin over HTTPS for a SINGLE standard or manifest, explicitly 'without grading the full site.' This cleanly separates it from probe (all 37 paths) and validate_manifest (A+–F grading) named in the same breath.

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

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

Explicit when-to-use plus two named alternatives with the condition that selects each: 'use has for a fast single-file check; use probe to scan all 37 paths at once, or validate_manifest for A+–F conformance grading.' Nothing 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?

Goes well beyond the readOnly/idempotent annotations by disclosing the 24h KV cache default, the 5-minute per-origin cooldown on fresh probes, and a 30/min rate limit — operational facts an agent cannot infer elsewhere. It also warns that verify:true performs an active MCP initialize/A2A handshake, which is meaningful behavioral context for a tool flagged readOnly.

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 scan scope, then caching/limits, then return shape, then sibling routing — a sensible order. It is dense with nested parentheticals, though virtually every clause carries information, so the cost is readability rather than waste.

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

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

With no output schema, the description enumerates the return keys ({ found_ids, found, absent, coverage, extracted, connect_recipe }) and the mode-dependent shape changes. Input is restricted to a public hostname, and the caching/cooldown/rate-limit constraints are all supplied, leaving nothing essential unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds output-shape consequences the schema does not spell out: brief reduces to found_ids + extracted endpoints, compact replaces absent/skipped maps with absent_ids[]. The 'e.g. ard, llms.txt' hint for id is marginal since the schema already gives that example.

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 ('Scan') and resource ('a public origin across 37 agent-facing paths and headers'), leaving no ambiguity about what the tool returns or covers. It explicitly differentiates itself from siblings has (single standard) and validate_manifest (conformance scoring).

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?

Ends with an explicit routing rule: 'Use probe for raw multi-path discovery; use has for one standard, or validate_manifest for A+–F conformance scoring.' It also gives conditional guidance for fresh, brief, compact and verify, so the agent knows when each mode applies.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. Beyond that, the description adds meaningful behavioral detail: top 10 ranking by title/alias/body match, returned fields, and nearest_ids hints when no results are found.

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 dense sentences with no filler. The core search scope and return behavior are front-loaded, and the sibling-routing guidance follows 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?

Although there is no output schema, the description explains the response shape, ranking behavior, and empty-result fallback. For a search tool, this is complete 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 100%, so q and query are already documented, including their alias relationship and 2–200 character bounds. The description reinforces that either q or its alias query should be passed, but adds little beyond the schema.

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

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

States a specific verb and resource set: search 132 standards and 52 glossary terms. It also names the supported query modes (keyword, acronym, alias, 'A vs B' pair) and distinguishes the tool from get and ask.

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

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

Explicitly says to use search for keyword discovery, get for an exact id, and ask for stack recommendations. This directly routes the agent among siblings with clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the default threshold of 30 days, the oldest-first ordering, and the exact return envelope. It does not mention result caps or pagination, which is a minor omission for a list 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?

Three dense sentences: selection rule first, return shape second, disambiguation third. Nothing is wasted, and the most decision-relevant information is front-loaded.

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

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

There is no output schema, and the description compensates by spelling out the returned fields (threshold_days, count, records with id/name/step/last_verified/days_since_verified). Combined with the annotations and full schema coverage, 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 coverage is 100%, and both parameters are documented in-schema including the enum values and the default of 30. The description largely restates 'older than N days' and 'optionally filtered by lifecycle step' without adding syntax or edge-case semantics, 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 and resource ('List standards') plus the precise selection criterion (last_verified older than N days), default, and sort order (oldest first). It also names the sibling it is not ('changes'), so the agent can distinguish it without opening either schema.

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

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

Explicit routing: 'Use stale to audit verification freshness; use changes to inspect actual specification edits since a date.' This gives both the when-to-use and the competing alternative with the condition that selects between them.

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 beyond the annotations by disclosing the no-disk-write guarantee, the exact return shape ({ id, path, content_type, contents, validate_with }), and the fact that from_live triggers an HTTPS probe of the public origin — a side effect the read-only/idempotent hints do not convey. It stops short of describing probe failure behavior, timeouts, or latency for that network path, which would be the remaining useful detail.

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, then scope, then return shape, then the alternative — a sensible ordering. The 12-id enumeration is long and duplicates the schema's id field verbatim, which is the one block that does not fully earn 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 9-parameter tool with one required param and no output schema, the description supplies the action, the optional network behavior, the return object's keys, and the sibling routing rule. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by tying from_live to the domain parameter and naming which discovered fields (MCP, OpenAPI, A2A, contact URLs) get pre-filled. The enumerated id list, however, merely repeats the schema's enum-like id description.

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

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

States a specific verb+resource ("Generate in-memory starter boilerplate") with the full set of supported manifest ids and the explicit constraint "without writing to disk." The final sentence separates it from validate_manifest, so an agent can route between the two 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?

Explicitly prescribes when to use this tool ("to author a new manifest") and names the alternative with its own condition ("use validate_manifest to lint existing content"). It also gives the trigger for the optional live-probe path ("when from_live: true is passed with domain"), leaving nothing 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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description nonetheless adds genuinely useful operational context the annotations cannot: 24h KV cache, 5-minute per-origin cooldown on fresh, 30/min rate limit, and that verify withholds credit for dead endpoints. Return shape is also enumerated (grade, score, subscores, conformance_summary, connect_recipe, permissions, manifests), which is valuable given no output schema exists.

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

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

Front-loaded with the primary action and appropriately sized for a 10-parameter tool; nearly every clause carries information. It is, however, a single run-on sentence with stacked parentheticals, which makes it denser to parse than it needs to be.

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?

Covers both invocation modes, the key modifiers, caching/cooldown/rate-limit constraints, and the return payload — enough to call it correctly with no output schema available. The only soft spot is that the interaction between diff and a prior snapshot baseline is stated but not fully defined (where the baseline originates).

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 every parameter is already documented; baseline is 3. The description does add mode-combination guidance (verify, bridge, diff, brief/compact) and the rate/cooldown consequences of fresh that the schema only hints at, but it does not add syntax or format detail beyond the schema text.

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

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

Names a specific verb+resource (audit an origin's manifests, grade it) and covers the second mode (in-memory local validation) in the same breath. It explicitly contrasts with siblings probe and template, so an agent can choose without opening any schema.

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

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

The final sentence states the routing rule directly: conformance grading and local linting here, ungraded discovery via probe, starter scaffolding via template. The two invocation modes are also gated by concrete conditions (pass origin to fetch; pass id + content to avoid network).

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