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 meaningful content traits — platform-tagged rules, web HTML/CSS guidance, and official Apple source links — which helps the agent anticipate the return. It says nothing about error behavior for unknown ids or rate limits, but read-only behavior is clear from the verb.

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

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

Three short sentences, front-loaded with the action and content type. The middle sentence about Apple creating the guidance is borderline filler but is brief and establishes attribution, so it does not seriously hurt readability.

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 does the work of describing what comes back: platform-tagged rules, web HTML/CSS guidance, and official source links. For a single-card lookup with a fully documented schema, this is nearly complete; only failure modes for invalid ids are unaddressed.

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

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

Schema coverage is 100%, with the id example values and the platform enum already documented in the schema. The description's mention of 'platform-tagged rules' and 'web HTML/CSS guidance' loosely corroborates the platform parameter but adds no syntax or format detail 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 (Return) and resource (community implementation notes inspired by Apple's HIG), and clarifies the content type. However, it never distinguishes itself from siblings like get_topic or search_hig, which likely return overlapping design guidance, so an agent cannot tell which one to pick from the purpose alone.

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

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

There is no when-to-use guidance, no exclusions, and no alternatives named. The description implies retrieval of a single reference card by id but never says when this is preferable to search_hig, get_topic, or list_topics.

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 disclosure burden and does deliver the output shape (Markdown plus canonical Apple URL) and the narrowing effect of section/platform. It says nothing about error behavior for an invalid slug, network/rate-limit characteristics, or how large an article may be, which are the gaps a caller would want.

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

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

Three short sentences, front-loaded with the verb, resource, and return format, then the accepted input forms, then the two filters. No filler and nothing repeated from the schema verbatim.

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 no annotations, so the description must carry return semantics — it does (Markdown body plus canonical URL). Input flexibility and both optional filters are covered; only failure modes and remote-access constraints are absent, which is a minor gap for a read-only fetch 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 already 100%, so the baseline is 3. The description goes slightly beyond the schema by explaining the filter effect — 'section to keep one heading' and 'platform to drop other platforms' notes' — which clarifies that platform is a subtractive filter rather than just a target selector.

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 specific verb and resource — 'Fetch one Human Interface Guidelines article as Markdown, with the canonical Apple URL' — and the word 'one' plus the output format distinguish it from list_topics and search_hig. It never names those siblings explicitly, so an agent must infer the routing rather than being told.

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?

'Accepts a slug, path, or developer.apple.com URL' and the note about section/platform tell the agent how to call it, but not when to choose it over search_hig (to discover a topic) or get_design_reference. Usage is implied by the input flexibility rather than stated with conditions or 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the shape of the return payload (notes + checklist + topics), which is genuinely useful since there is no output schema. It stops short of stating that it produces guidance rather than code/files, or any limits on repeated calls or platform defaults.

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 input precondition ('Given a UI task and platform') precedes the payoff. It is dense but every clause earns its place.

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

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

For a two-parameter, annotation-free tool with no output schema, the description adequately covers inputs and return contents. The only meaningful gap is behavior when the optional platform is omitted, which is left 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 100% and both parameters (task, platform) are documented in the schema itself, including the enum and the 'use web for websites' note. The description merely references 'a UI task and platform' without adding format or syntax detail, 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?

The description names a specific verb (return) and enumerates the exact artifacts produced: community implementation notes, a short checklist, and two or three Apple topics. That is far more informative than a restatement of the title, though it never contrasts itself with siblings like search_hig or get_design_reference.

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 'before writing the interface' implies the intended workflow position, giving implicit usage guidance. However, it never states when to prefer this over search_hig, list_topics, or get_design_reference, nor any exclusions, so an agent must infer the routing.

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 and no output schema, the description carries the full behavioral burden, yet it only says it 'shows' help. It does not disclose the return format, whether the output is static or topic-dependent, or any read-only nature. For a no-annotation tool this is a notable gap.

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

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

A single efficient, front-loaded sentence with no waste. It is terse but appropriate to a simple help command, though it leaves room for a short clause about scope.

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

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

For a zero-parameter help tool with no output schema and no annotations, the description is minimally adequate but incomplete: it never mentions what the help content covers, whether HIG-specific guidance differs from sibling tools, or what the agent receives back.

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 baseline is 4; there are no parameter semantics to document or compensate for.

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 ('Show how to use the HIG design commands and tools'), making it clear this is the general help entry point. It distinguishes itself implicitly from the functional siblings (search_hig, get_topic, guide_interface) by being the help/orientation tool, though it never names those alternatives.

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

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

There is no guidance on when to invoke help versus the five sibling tools, nor any prerequisite or trigger condition. An agent must infer that this is a general orientation command rather than something tied to a specific query.

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 it does disclose a key trait: the output contains titles and official URLs, not article text. It says nothing about pagination, the effect of the limit parameter, or whether filters combine with AND semantics, so the read-only list behavior is only partially covered.

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, zero filler. Purpose comes first, filtering second, and the output-shape caveat last, which is exactly the right order.

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 compensates by describing the return contents (titles and URLs, not body text). What remains missing is limit/default behavior and whether multiple filters are combined, both of which an agent would want for a 4-parameter 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 75%, so the schema already documents group, section, and platform with examples and 2 enums. The description restates the same three filter dimensions without adding format, default, or combination semantics, and never mentions the limit 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?

States a specific verb and resource ("List Apple Human Interface Guidelines topics") and implicitly separates itself from get_topic by noting it returns titles and URLs rather than article text. However, it never names search_hig, the nearest sibling, so the list-vs-search distinction is only inferable.

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?

"Filter by section, component group, or platform" describes how to narrow results, which implies the browsing use case, but gives no explicit when-to-use or when-not-to-use guidance relative to search_hig. No prerequisites or exclusions are stated.

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

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

No annotations are supplied, so the description carries the disclosure burden on its own. It usefully states what comes back (matching topics and official URLs, not full content), but says nothing about auth needs, rate limits, ranking behavior, or pagination.

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 and ending with the routing caveat. Every clause carries information and nothing is padded.

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

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

For a 4-param search tool with no output schema, it covers the return shape at a high level and routes to get_topic, but never mentions the platform or limit parameters and gives no sense of result volume or ordering. Adequate but leaves gaps an agent must resolve by reading 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 75%, so the schema already documents query, section, and platform. The description echoes title/section/alias matching and adds alias examples, but adds no syntax or behavior beyond the structured fields, matching the baseline for well-covered schemas.

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 HIG catalog) plus what the query matches against (title, section, aliases). It also frames the boundary with get_topic, so an agent can tell it apart from a sibling even without opening schemas.

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

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

Explicitly states the negative case (does not return full articles) and names the alternative (call get_topic for those), which is real routing guidance. It stops short of clarifying search vs list_topics or get_design_reference, so it is clear but incomplete.

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