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

With no annotations, the description carries the full burden, and it only discloses that no third-party crawling occurs. It says nothing about whether the tool is read-only, where the data comes from (cached vs live), rate limits, or what the comparison output 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?

A single front-loaded sentence with no filler; the constraint is placed usefully at the end. It is concise to the point of under-specification, but nothing in it 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?

For a four-parameter tool with zero annotation and zero schema description coverage and no output schema, one sentence is far too thin. An agent lacks the information needed to supply source_id or implementation_names correctly or to know what the comparison returns.

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% across four parameters, so the description must compensate and it does not. None of 'component', 'source_id', 'max_results', or 'implementation_names' is explained — an agent cannot tell what source_id identifies or what implementation_names filters.

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 gives a verb ('compare') and an object ('distinct implementation references linked by a component page'), which tells an agent this is a comparison operation over referenced implementations. However, 'implementation references' is vague about what is actually returned, and the differentiator from siblings like get_component_examples or inspect_component_demo is only implicit.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no naming of alternatives. The only guidance is the negative constraint 'without crawling third-party sites', which hints at scope but doesn't tell an agent when to pick this over get_component_examples or inspect_component_demo.

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

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

With no annotations, the description carries the full burden. It discloses that results are verified and accompanied by source citations and that lookup is 'dynamic' against a configured catalogue, but says nothing about whether the call is read-only, what happens on zero matches, or any catalogue/auth preconditions.

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 directive front-loaded ('Use this first'), a useful concrete example, and a short return-value note. No filler or restatement of the tool name.

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

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

For a simple three-parameter discovery tool with no output schema, the description covers intent translation and return citations but omits result-count behavior (max_results default/ceiling), empty-result handling, and the meaning of source_id, leaving real gaps for an agent configuring the call.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'query' is natural-language frontend intent (with a concrete example), and 'configured public catalogue' loosely hints at source_id, but max_results and the length/range constraints on all three parameters are entirely undocumented.

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

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

The description uses a specific verb+resource pair ('discover verified component types') and scopes it to a 'configured public catalogue', which separates it from siblings like find_design_systems or get_component_examples. It does not name a sibling explicitly, but the resource is unambiguous.

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

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

It gives clear directive conditions: 'Use this first' establishes ordering relative to the other discovery tools, and 'do not guess a component name' states a negative case. It stops short of naming which sibling to call next (e.g. get_component_examples), so alternatives are only implied.

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

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

With no annotations, the description carries the full behavioral burden and does not say whether the tool is read-only, whether source_id is required to obtain technology tags, what the result list looks like, or how max_results interacts with filtering. The phrase "source-published technology tag" is the only behavioral hint, implying tag vocabularies originate from a catalog, but an agent still has to guess at the semantics of a fallback path.

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 compact sentences that lead with the core capability and place the caveat last. Nothing is redundant, though the second sentence's drafting ("Existing query-only technology calls are supported as a documented fallback") is dense and takes effort to parse for what is a simple backward-compatibility note.

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

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

For a tool with no annotations, no output schema, and zero parameter documentation, the description is too thin: it omits the role of source_id and max_results, the shape of returned matches, and any statement of read-only safety. The backward-compatibility note is documented but leaves the agent uncertain what the primary calling convention should be.

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% across four parameters, so the description must compensate and largely fails: 'query' is described as name search and 'technology' is loosely explained, but 'source_id' (which clearly scopes the technology vocabulary) and 'max_results' (bounded 1-20, default 10) are not addressed at all. The fallback sentence hints at an interaction between query and technology but never clarifies how the parameters combine.

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 and resource ("Search design-system names") and distinguishes the primary query path from the optional technology filter, which differentiates it from component-level siblings like find_components. It stops short of a crisp statement about what a design system record is, and the trailing fallback sentence muddies rather than sharpens the purpose.

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

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

No guidance on when to pick this tool over siblings such as find_components or compare_implementations; the only usage context is the note that query-only calls with a technology value are a "documented fallback," which signals legacy support but doesn't tell an agent which path to prefer or why. There are no exclusions, prerequisites, or example queries.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two useful traits: output is 'bounded' and 'cited', and a 'not_published' status is returned when nothing is found. However, it never states read-only nature, permission or scope requirements, how 'bounded' limits results, or pagination/truncation behavior for a lookup that could return large sections.

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 with the primary behavior front-loaded and the edge case second. No filler, though the phrase 'relevant published markup/keyboard sections' is compressed to the point of ambiguity.

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 annotations, no output schema, and 0% parameter documentation, the description should do more. It hints at return shape via 'cited' and 'not_published', but leaves parameter meaning, scope, and result size unexplained for a two-parameter lookup tool.

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

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

Schema description coverage is 0% across two parameters, so the description must compensate. It adds no meaning for either: 'component' is never explained (name? ID? path?) and 'source_id' is not mentioned at all, leaving the agent to guess constraints like the 120/60 character limits or whether source_id narrows the lookup.

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: returns published accessibility guidance, plus the fallback status 'not_published'. An agent can tell this is a documentation-lookup tool, though it never says what 'component' identifies or how it differs from siblings like get_component_examples.

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 mention of accessibility, markup and keyboard sections, and the 'not_published' fallback tells the agent what happens when nothing exists. There is no explicit when-to-use/when-not guidance and no routing to sibling tools such as find_components or get_component_examples.

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

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

With no annotations, the description carries the full burden and does add real behavioral value: it declares the call is non-mutating in effect (no queueing, no retries, no second billing) and warns that result-validation context is in-memory and lost on server restart, which is a non-obvious and consequential constraint. It leaves unexplained whether the call blocks until completion or returns a pending status, and how a missing/expired run_id is reported.

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, each carrying distinct information: what is returned, what side effects do not occur, and a durability caveat. The identifying scope ("already queued") is front-loaded with no 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?

For a single-parameter read tool with no output schema, the description covers the essentials: it names the two return states (status vs. completed result), rules out side effects, and flags the restart limitation. Minor gaps are the enumeration of status values and the not-found case, which matter little given the tool's simplicity.

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

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

Schema description coverage is 0% for the single run_id parameter, so the description must compensate; it does imply the id is a handle issued by this process's earlier queueing call, but gives no format, expected pattern, or behavior for stale ids. That is partial compensation for a required, undocumented parameter.

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?

Uses a specific verb+resource pair ("Retrieve status or the completed result for an Agent inspection") and scopes it with "already queued by this ComponentPilot process," which implicitly separates it from the queueing sibling inspect_component_demo. It stops short of naming that sibling, so the distinction requires an inference from the word "already queued."

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?

"already queued" plus "never queues, retries, or bills a second Agent execution" tells the agent this is a follow-up/polling call, not a way to start work. However, no alternative is named explicitly and there is no statement of what to do when run_id is unknown or expired, so usage is implied rather than prescribed.

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

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

With no annotations, the description carries the full burden and does disclose useful behavior: results are offset-paged, pagination metadata reflects the whole normalized source-derived set rather than just the page, and no external crawling occurs. It leaves unstated what happens with an unknown component, whether results are cached, or how the data is sourced/authored, so gaps remain for a read tool with zero annotation coverage.

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

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

Three short sentences, front-loaded with the core action, followed by the pagination contract and a scope exclusion. Every sentence carries information, though the final negative sentence reads slightly awkwardly.

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 4-parameter read tool with no output schema and no annotations, the description establishes the pagination contract well but omits what an 'implementation' record contains, how component relates to source_id, and how page size is controlled. Adequate as a minimum viable definition, but not self-sufficient.

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 clarify all four parameters and only partially does: 'offset-based page' explains offset, and 'source component page' loosely ties to component. It never mentions source_id or the max_results page size, and gives no hint about accepted component identifier format or the 1-30 cap.

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: returns one page of implementations linked by a source component page. An agent can distinguish it from find_components (discovery) and compare_implementations (comparison), though the name/description mismatch between 'examples' and 'implementations' forces a small 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?

No explicit when-to-use guidance and no named alternatives among siblings like find_components or inspect_component_demo. The only scoping statement, 'Does not invent or crawl external implementation URLs,' constrains the data source rather than telling the agent when this tool is the right choice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that a lightweight TinyFish Fetch probe runs only when due and never queues a paid Agent run, but it does not state permissions, rate limits, or whether the operation is strictly read-only.

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

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

Two sentences, front-loaded with the reporting scope and followed by the key probe-cost behavior. There is no redundant or filler 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 low-complexity health-check tool with one optional parameter and no output schema, the description adequately lists what is reported and clarifies the probe's cost behavior. The main gap is the unexplained source_id 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?

The single optional source_id parameter has 0% schema description coverage, and the description does not explain what source_id means, how it scopes results, or what happens when it is omitted. The mention of "source reachability" only loosely hints at the parameter.

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, "Report," and names the concrete health dimensions: server health, source reachability, cached-data freshness, and latest successful refresh. It is clear what the tool does, though it does not explicitly differentiate itself from siblings, which are unrelated design/component tools.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. Usage is only implied by the name and the reporting scope.

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

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

With no annotations, the description carries the full burden and does well: it discloses asynchronous queueing, the fact that no execution wait occurs, the prohibition on arbitrary URLs, credentials, and destructive actions, and that retrieval never retries or bills another execution. It stops short of stating permission requirements, rate limits, or what happens when both selectors conflict beyond 'same record'.

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 most decision-relevant fact (queues and returns immediately) and ends with the sibling routing sentence, so structure is sound. The middle selector/auto-mode sentence is dense and slightly run-on, but every clause carries operational meaning.

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

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

For a 6-parameter tool with no annotations and no output schema, the description covers the essential workflow: what is produced (run_id), what is forbidden, and where to get results next. The main gap is the unaddressed required parameters component and requested_checks, leaving an agent to infer their meaning from the schema names.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does. It clarifies implementation_name/implementation_url pairing and selection_mode semantics, but says nothing about component, source_id, or the requested_checks enum values (tab_click, accordion_toggle, etc.), which remain unexplained from the schema alone.

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

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

Names a specific verb and resource ('Queue a bounded Agent inspection') and states the immediate return value (TinyFish run_id) plus the key negative ('does not wait for browser execution'). This clearly separates it from get_component_demo_run, which is described as retrieving an existing run rather than queuing one.

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 the agent: use this to queue, use get_component_demo_run with the returned run_id for status and results. It also gives conditional rules for selector usage and restricts selection_mode=auto to the case where the user explicitly asks ComponentPilot to choose.

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