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

Annotations already cover read-only and closed-world behavior, and the description adds real value on top by disclosing that the payload is a 'Full definition' with a default section set and that accessibility, CSS, sitePage and changelog are opt-in. It does not say what happens for an unrecognized or deprecated component name, which is the remaining behavioral 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?

Two sentences, front-loaded with the resource and payload scope, then the name-normalization rule. The parenthetical item lists are dense but each item carries information an agent cannot get from the schema, so little could be cut without loss.

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 shoulders the burden of explaining return values and does so thoroughly, including the opt-in sections. Missing only failure behavior (unknown component) and any note on payload size for 'all', which matters for a tool that can return CSS and changelog alongside types.

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, and the description beats it: it clarifies that 'name' accepts plain ('button'), prefixed ('evo-button'), angle-bracketed ('<evo-button>') and Marko 5 alias ('ebay-button') forms, which goes beyond the schema's own examples. The 'sections' parameter is not discussed in the description, but its enum and default are fully documented 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 ('Full definition of one evo-web Marko 6 component') and enumerates exactly what the definition contains (attributes, attribute tags, usage examples, TS types, optional accessibility/CSS/changelog). It never names a sibling such as list_components or search_docs, so the boundary with those tools is left to inference.

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

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

Usage is implied by the enumeration of return content, but there is no explicit when-to-use guidance, no exclusion against list_components (browse) or search_docs (free-text lookup), and no stated behavior when a name is unknown. The accepted-name sentence helps invocation but is not a routing guideline.

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 is covered; the description adds real context beyond that by disclosing the output format (Markdown) and the three accepted id forms. It omits failure behavior for a missing id and any note on large pages being truncated, which would matter for a fetch 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?

Two sentences, front-loaded with purpose and format, followed by accepted inputs and the optional narrowing parameter. Every clause carries information; nothing is redundant with 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 two-parameter read tool with full schema coverage and read-only annotations, this is nearly complete: input forms, output format, and section extraction are all covered, and no output schema exists to require return-value explanation. The only gap is error/not-found behavior and size limits on large pages.

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 meaning the schema does not: worked examples for all three id formats ('marko:reference/core-tag', a full URL, and a bare slug) and a clarification that `section` returns only that heading's content rather than filtering the whole page.

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 ('Read a Marko or evo-web documentation page') plus the return format ('as Markdown'). It also names the sibling tools that supply valid ids (search_docs/list_docs), so an agent can separate this fetch tool from the discovery tools 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?

It implies the correct workflow by saying to pass an id 'from search_docs/list_docs', which tells the agent to discover first and fetch second. It also gives a concrete narrowing option ('Use `section` to return only one heading's content'). It does not say what to do when an id is unknown or when to prefer search_docs over a direct slug guess, so it stops short of 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral content beyond that: it discloses what the tool returns (upstream commits/versions and counts of components and docs), which matters because there is no output schema. It doesn't mention whether the counts are exact or how often the index is rebuilt, but the core disclosure 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?

A single sentence that front-loads the primary payload (source commits/versions) and then appends the secondary payload (counts). No filler, no restatement 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?

For a no-argument, read-only metadata tool with no output schema, the description covers what an agent needs: what the response contains and that it is static provenance data. It could go slightly further on freshness semantics (e.g., whether this reflects the currently deployed index), but overall it is complete for the complexity.

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

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

The tool takes zero parameters, so the schema-related baseline is 4. The description correctly presents this as an argument-free informational call, and no parameter meaning is left ambiguous.

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

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

The description pairs a specific verb ("Show") with a precise resource: the provenance of the bundled index (source commits/versions) plus component/doc counts. That is clearly distinct from the sibling retrieval tools like list_components, get_component, and search_docs. It stops short of naming a sibling to route against, which keeps it at 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?

There is no explicit when-to-use statement or exclusion. An agent can infer the use case (checking index freshness/version or gauging corpus size before searching), but nothing in the text says when this is preferable to querying components directly.

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 scope are covered upstream. The description adds genuinely useful non-annotation context: results are grouped by category and the underlying package/tag naming convention (<evo-*>), which shapes how an agent should interpret the output. It stops short of describing pagination or the per-item 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?

Two sentences with zero filler. The resource and scope come first, and the optional filtering guidance follows immediately, so an agent can act after the first sentence and refine after the second.

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 read-only, parameter-light listing tool with full schema coverage and no output schema, the description covers scope, naming convention, grouping, and filtering adequately. The only gap is any hint about result volume or item shape, which is minor given the annotations already settle the safety profile.

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 both the query and category parameters are already documented, including the category value list. The description only restates the same filters and adds examples that largely duplicate the schema's own example, so it does not meaningfully extend parameter meaning beyond the structured fields.

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 the eBay evo-web components") and pins the scope precisely: Marko 6, package @evo-web/marko, tags named <evo-*>. It is clearly distinguished from the singular get_component sibling by naming the resource as a plural listing with no single-target lookup.

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 states the optional filters (category or free-text query) and gives concrete query examples ('date picker', 'dropdown'), which tells an agent how to narrow the listing. It never explicitly routes the agent elsewhere — e.g. it does not say to use get_component for a single component's details or search_docs for prose — so there are no explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds returned fields (id, title, URL) and filter behavior, but omits ordering, pagination, or rate-limit details.

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

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

A single sentence, front-loaded with the purpose and return fields, with no wasted wording.

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

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

For a simple read-only list tool with one optional enum parameter and no output schema, the description covers purpose, return fields, and filtering. It could mention ordering or pagination, but those may not apply.

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 enum already defines all/marko/evo with a default of all. The description clarifies that marko and evo correspond to Marko docs and evo-web docs, adding minor semantic value 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 ('List') and resource ('documentation pages'), plus the returned fields and optional source filter. It does not explicitly name search_docs as the alternative, but the list-vs-search distinction is clear enough.

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 that results can optionally be limited to Marko docs or evo-web docs, which implies when to use the source filter. It does not state when to prefer search_docs or get_doc, nor any exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses the no-argument fallback (returns the entire mapping table), which the schema cannot express since the parameter is optional, but it says nothing about the size or pagination of that full table or the format of the changelog notes.

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

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

Two sentences, front-loaded with the primary lookup behavior and followed by the fallback case. Every clause carries information; nothing is redundant or repeated from the 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 read-only, single-optional-parameter tool with no output schema, the description does the essential work of describing what comes back (replacement tag plus API-difference notes). Minor gaps remain around the shape/size of the full-table response, but an agent can call it correctly from this description.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is 3. The description goes beyond it by adding a sample value and, more importantly, by defining the semantics of omission - no name yields the complete mapping table - which the schema alone does not convey.

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: given a Marko 5 '@ebay/ebayui-core' tag, return the Marko 6 '@evo-web/marko' replacement plus changelog notes. A concrete example input ('ebay-textbox') makes the resource domain unambiguous and clearly separates this migration-mapping tool from lookup siblings like get_component.

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 establishes the calling context (migrating ebayui-core tags to evo-web) and explains the two modes of use: pass a name for one mapping, omit it for the full table. It does not name alternatives or exclusions, e.g. whether list_components should be used to enumerate all tags instead of the no-arg fallback.

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, and the description reinforces the closed-world nature by enumerating the fixed corpora. It adds the return shape (ranked sections with ids) and the follow-up route, but says nothing about ranking behavior, pagination, or empty-result handling beyond the limit parameter documented in 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, no filler: the corpus scope is front-loaded, and the second sentence covers the return value and next step. Every clause carries information an agent needs to decide and call.

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 search tool with no output schema, the description covers input scope (corpora), output shape (ranked sections with ids), and the natural follow-up call. Nothing essential to correct invocation 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, but the description adds real meaning by spelling out what each source bucket actually contains (Marko docs vs evo-web site + components vs components only), which disambiguates the enum values. The query parameter is left to the schema, which already provides good examples.

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

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

The description names a specific verb (full-text search) and enumerates the exact corpus: Marko 6 docs, migration guides, evo-web component/accessibility docs, and component attributes/examples. It also distinguishes itself from retrieval siblings by stating that results are ranked sections with ids to pass to get_doc or get_component, so an agent knows this is the discovery step, not the fetch step.

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 clearly implied: search first, then fetch detail via get_doc or get_component, which cleanly separates this tool from the retrieval siblings. What is missing is explicit guidance against alternatives such as list_docs or list_components (i.e., use this when you don't already know the doc name), so it stops short of naming when-not-to-use.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-world read. The description adds that results include tag names and Marko 6 usage snippets, which is genuinely useful return-format context, but it says nothing about result ordering, pagination, or what an empty result means.

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

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

A single well-formed sentence that front-loads the action, the searchable corpus, and the return value with zero filler. It could be marginally improved by adding a short clause about the limit parameter, but nothing present 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?

This is a simple two-parameter read tool with annotations and no output schema, and the description covers the corpus and the response shape. The unexplained 'limit' parameter and the absence of any routing guidance leave it adequate but not fully complete.

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

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

Schema description coverage is 50%: 'query' is documented in the schema and the description reinforces it with concrete keyword examples including a size suffix. The 'limit' parameter (1-100) is not explained anywhere, which is the main semantic gap; at this coverage level a baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Search the evo-web icon set') and states what comes back ('tag names plus Marko 6 usage'), so the agent knows this is an icon lookup rather than a general doc search. It does not explicitly differentiate itself from siblings like search_docs or list_components, which is the only thing keeping it from a 5.

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

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

The example queries ('cart', 'chevron down', 'close 16') implicitly show the expected input style and that size tokens can be folded into the query, which guides usage. However, there is no explicit when-to-use or when-not-to-use guidance and no pointer to alternatives such as search_docs for broader lookups.

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