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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds substantial value beyond that by disclosing the return shape: matched use case(s), up to 8 standards ranked by fit/maturity/adoption with reasons, do_this_first prerequisites, deprecated standards to avoid, and also_consider contents.

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 and examples are front-loaded in the first clause, and the remainder packs input and output detail without redundancy. It reads as a dense single block rather than cleanly separated sentences, which is slightly harder to scan but still earns its length.

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

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

There is no output schema, so the description must explain returns, and it does so thoroughly (ranked standards, reasons, prerequisites, deprecated items, related items). Inputs are covered at a high level; only the finer per-parameter constraints are left to the schema.

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

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

Schema description coverage is 0%, so the description must carry the param burden. It does characterize question as free-form plain words with examples and flags use_case as one of 15 schema ids plus audience, but it adds no constraint detail (e.g. the 200-char limit) and defers the enum values to the schema, so compensation is only partial.

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

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

The description states a specific verb+resource: ask a plain-language question about what to implement for a goal, with concrete examples ('let agents pay per request'). It is clearly a recommendation/guidance tool distinct from data-oriented siblings like get/search/changes, but it never explicitly names or contrasts a sibling, so it stops short of a 5.

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

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

Usage is implied through example questions ('stop AI training crawls', 'let ChatGPT call my API') and the note that use_case/audience are optional, which conveys how to invoke it. However, there is no explicit when-to-use vs when-not-to-use guidance against siblings such as search, define, or template, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description usefully goes beyond them by spelling out the exact shape of each returned row (record, kind, field, old/new value, claim, evidence URL, data commit) and the timestamp normalisation rule. It omits ordering and pagination behavior, which keeps it short of a 5.

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

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

Two tight sentences, front-loaded with the purpose, then inputs, then outputs – no filler. It is dense but readable, and every clause carries information. The compressed 'Input:'/'Returns:' phrasing is efficient rather than padded.

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

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

With no output schema, the description rightly documents the returned row, and it covers the required argument's format. But for a 4-parameter tool it leaves step, record_id and limit semantically undefined and says nothing about result ordering, truncation, or how far back it scans, which are the questions an agent still has before calling it.

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

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

Schema description coverage is only 25% – solely 'since' is documented in the schema – so the description is expected to compensate but mostly does not. It restates 'since' as an ISO date (slightly at odds with the schema's 'offset is applied, then the UTC date is used') and merely names step, record_id and limit without explaining what each filters or how limit bounds results (schema caps it at 200 but the description doesn't say it truncates).

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 opening sentence names a concrete resource and action ('what changed on the map since a date'), which is far clearer than the bare tool name 'changes'. It also enumerates the returned row fields, reinforcing what the tool produces. It does not, however, distinguish itself from near-neighbors like 'stale' or 'search', which an agent may reasonably confuse it with.

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

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

Usage is only implied by the purpose sentence; there is no explicit statement of when to pick this over 'stale', 'search', or 'get', and no prerequisites or exclusions. The optional filters (step, record_id, limit) are listed but never framed as selection criteria for a scenario.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context beyond that: plural inputs are tolerated, the return includes related protocol ids, and standards names return a summary instead of an error rather than failing.

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, front-loaded with the core action, then input format, then the non-obvious edge-case behavior. No filler and every sentence adds 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?

There is no output schema, so the description takes on the burden and delivers: it names what is returned (the definition and related protocol ids) and describes the alternate return for standards. For a single-parameter read tool this is fully adequate.

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

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

Schema description coverage is 0% and there is a single parameter, so the description must carry the load. It does meaningfully: it specifies that 'term' accepts an id, name, or alias, and that plurals are tolerated — details absent from the schema (which only gives type and length bounds).

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 ('a glossary term of the agentic web'), and the special-case behavior for standards makes the scope unambiguous. An agent can distinguish this from siblings like get, search, or ask 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?

The description implies when this tool applies (looking up a term's definition) and clarifies that standards names are handled gracefully, but never explicitly contrasts it with sibling lookup tools such as get, search, or ask. Usage 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description goes further by disclosing provenance guarantees ('Every number in an item appears in a source it cites'), the VERIFIED/REPORTED trust labelling, that stats come from a fixed panel re-checked daily, and that methodology is included — real behavioral context beyond the annotations.

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

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

It is front-loaded with the one-line purpose, then input options, then the return contract, which is the right order. The enumeration of returned fields is long, but since there is no output schema it largely earns its place; the trailing human-URL aside is the only mildly expendable element.

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 full return-value burden and does so: it lists headline, lede, item fields, stats panels, and methodology. It stops short of covering edge cases such as what happens for an unpublished date, which keeps it from a 5.

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 already documented there, including the 'latest (default)' semantics and the list:true meaning. The description largely restates these ('date (YYYY-MM-DD, default latest)', 'list: true for the index of every published date'), adding only mild clarification, which lands at the baseline 3.

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

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

The first sentence names a specific resource ('agentic-web daily digest') and the form it takes ('structured data'), and the rest enumerates the exact payload shape an agent can expect. The purpose is unambiguous, though it never names or contrasts a sibling such as 'search' or 'get', which would have fully earned a 5.

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

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

Usage is only implied: the description explains that you pass a date or list:true, so an agent can infer 'call this to read the digest for a day'. There is no statement of when to prefer this over 'search', 'get', or the other siblings, nor any when-not condition or prerequisite.

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 bar is lower; the description still adds useful behavior: the id accepts aliases such as llms.txt or /.well-known/ard.json, and a miss returns the nearest ids rather than a bare error. It omits return format details and rate limits.

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

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

Two tight sentences: the returned-field inventory is front-loaded, then id semantics and miss behavior follow. No filler and every clause adds 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 no output schema, the description compensates by enumerating the record's components, and the sole parameter's accepted forms and error behavior are both covered. An agent has enough to call this correctly without opening anything else.

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

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

Schema coverage is 0% — the schema only says id is a 1-120 char string — so the description carries the burden and does so well, explaining that id may be the file or path the standard is known by and giving concrete alias examples. This is meaningfully more than the schema offers.

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 standard's full record by id') and enumerates exactly what the record contains (status, governance, version, spec URL, probe rule, evidence, disputes, summary, freshness). The emphasis on a single full record implicitly separates it from list/boolean siblings like search and has.

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 'by id' and the single-required-param schema, but the description never states when to reach for this tool versus siblings such as has (existence check) or search (discovery by attributes). No prerequisites or exclusions are given.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower. The description still adds genuinely useful behavior: the check is a live network fetch of a well-known path, and an apex redirecting to its www host is followed and reported as final_origin — non-obvious semantics an agent could not infer from 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?

Three short sentences, front-loaded with purpose then inputs then return shape, with zero filler. Every clause (live fetch, redirect following, final_origin) carries distinct 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 steps in to describe the return payload (found/absent plus URL, status, reason, final_origin). Combined with the disclosed network behavior, this is nearly complete; only the acquisition of valid standard ids is left unexplained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does define both params semantically — origin as hostname and id as standard id — but gives no format, syntax, or source guidance for obtaining a valid 'id', leaving a real gap for a 2-param tool.

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

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

States a specific verb+resource: 'Check one public origin for one standard by fetching its well-known path live.' The single-origin/single-standard scope is concrete. It does not, however, differentiate itself from the sibling 'probe', which sounds like an adjacent check operation.

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 'one public origin for one standard' implies this is a targeted, per-origin check rather than a bulk scan, which gives some implied usage context. But no explicit when-to-use, when-not-to-use, or named alternative (e.g., probe vs. this) is provided.

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

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

Goes well beyond the annotations: it discloses the credential-free scope, the ~30 GET rules, that skipped checks come with reasons, coverage by lifecycle step, and notably that an apex redirecting to its www host is followed and surfaced as final_origin. Annotations already cover the read-only/idempotent/open-world profile, and the description adds real operational context; only rate limits or timeouts are unmentioned.

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

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

Three tight sentences with the resource and scope front-loaded, then input, then return shape and redirect handling. No filler or repetition.

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

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

With no output schema, the description correctly explains the return structure (found, absent, skipped with reasons, coverage by lifecycle step, final_origin). Annotations carry the safety profile. The main gap is the undisclosed format of the single required parameter.

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

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

Schema description coverage is 0%, so the description should compensate, but 'Input: origin' merely restates the parameter name. It never clarifies the expected format (bare hostname vs. full URL with scheme) even though the apex/www redirect note hints at hostname semantics.

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

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

Clearly states a specific verb and resource: check one public origin for standards observable without credentials, quantified as ~30 GET rules. The scope is precise, though it does not differentiate itself from any of the similarly named siblings (get, has, search, validate_manifest).

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 credential-free, public-origin framing, but there is no explicit statement of when to use this rather than 'get', 'has', or 'validate_manifest'. No exclusions or prerequisites are given beyond the public/unauthenticated limitation.

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, and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: a hard cap of 10 results, a ranking rule favoring exact id/acronym matches, and the fact that ambiguous acronyms like ACP return all candidates.

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 return behavior and ranking — a sensible order with no filler sentences. Dense but every clause adds information; slightly compressed into one run-on paragraph.

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 correctly describes the return shape (up to 10 matches with id, step, status) and the ranking semantics. Combined with annotations covering safety, an agent has enough to call this correctly; only the parameter length constraints are 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 description coverage is 0%, so the description carries the burden for the single parameter, and it does explain q's accepted form (plain words, freely phrased) with examples. It omits the 2-200 character bounds, so it does not fully compensate for the coverage gap.

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

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

States a specific verb (Search) and resource (the standards), plus the fields searched (name, acronym, alias, question, use case). This clearly separates it from siblings like get, has, define, and ask without needing to open 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 concrete query-phrasing guidance with example inputs ('A2A vs MCP', 'pay per request'), which tells the agent this is a free-text lookup rather than an exact-key retrieval. It stops short of naming when to prefer get or has instead, so no explicit alternatives or exclusions are provided.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description adds real behavioral detail: the 30-day default threshold and the guarantee that total_standards, cutoff, oldest_verified and newest_verified are always returned so an empty result is still informative.

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

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

Two sentences, with the core filter and default front-loaded before the return-value detail. The return enumeration is long, but since no output schema exists that content is justified rather than filler.

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

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

With no output schema, the description correctly documents the returned fields and the always-present summary values; annotations handle safety. The only shortfall is incomplete coverage of the two parameters' constraints, which neither schema nor description supplies.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden and largely does: 'days' is explained as a threshold with a default of 30, and 'step' as an optional lifecycle-step filter. It omits the 1-3650 range on days and any hint of valid step values (maxLength 40), leaving a small gap.

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

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

The description states a specific resource and predicate: records whose last verification is older than N days. That is concrete enough to distinguish it from generic siblings like get or search, though it never names or contrasts those siblings 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?

The filter condition ('last verification older than N days') implies the audit/cleanup use case, and the optional lifecycle-step scoping narrows it further. There is no explicit when-to-use, when-not-to-use, or alternative named (e.g., search for text-based queries), so guidance stays implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the concrete return fields (target_path, content_type, recommended_headers, contents, fields to edit, notes, validate_manifest call), but does not explain behavior like whether the boilerplate is static or templated from the supplied inputs, or how missing optional fields are handled.

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 long enumeration of ten spec IDs plus an eight-item return-field list makes the description dense and somewhat hard to scan. Information is front-loaded reasonably (purpose first, then inputs, then returns), but the run-on structure could be tightened without losing meaning.

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

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

With no output schema, the description compensates by enumerating the return fields and noting the follow-up validate_manifest call. For a read-only, idempotent boilerplate tool the coverage is strong; the only gap is behavior when optional inputs are omitted or how template filling works.

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 75% and descriptions exist for id, domain, api_url, contact, mcp_url, agent_url. The description lists the parameters by name (id required; domain, name, description, mcp_url, api_url, agent_url, contact optional) but adds little semantic detail beyond the schema. It does clarify that name/description are optional, but the heavy lifting is already 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 resource: spec-compliant boilerplate for an agent-facing file, listing the supported spec IDs explicitly. The verb is less crisp (does it generate, return, or scaffold the file?), but the resource and enumeration are clear enough to distinguish it from siblings like validate_manifest or get.

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

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

The description implies use when you need starter content for one of the listed specs, and it explicitly notes running validate_manifest once live. However, it does not state when NOT to use it or contrast with siblings, so guidance remains implied rather than explicit.

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

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

Annotations already cover read-only, idempotent, open-world, non-destructive behavior, and the description adds substantial return-shape detail that annotations can't: grade range A+ to F, rubric, per-manifest errors vs warnings, steps covered, callable capabilities, and next steps. It also notes the externally visible report page and badge URL, extra context beyond structured fields.

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, input, and output; dense but well ordered. The final sentence about the /check/ page and /badge/ SVG is somewhat tangential to invoking the tool, though it does hint at side effects/stability of the report.

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

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

No output schema exists, so the description carries the return burden and does so thoroughly — grade, rubric, errors, warnings, coverage, callable capabilities, and next steps. Combined with the input explanation, an agent has everything needed to call it and interpret results.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it does: origin is framed as a public origin/domain, and id is explicitly optional and scoped to a single manifest. It enumerates the same ids as the schema enum without explaining each manifest type, leaving minor ambiguity.

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

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

The description opens with a specific verb and resource ("Validate a public origin's agent-facing manifests") plus an outcome ("grade its agentic-web readiness"), which cleanly separates it from generic siblings like get, probe, or search. An agent can identify the task 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?

It explains the required input (origin) and clarifies the optional id's role — "to check one manifest only" — rather than all manifests. It doesn't name alternative sibling tools or state exclusions, but usage context is clear enough to select the tool confidently.

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