get_component_reference

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It conveys that the response includes multiple sections and that theming class-name maps are optional via the include parameter. However, it does not describe response structure, error conditions, or potential payload size, leaving notable gaps for an unannotated 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?

The description is exceptionally concise, consisting of two sentences that directly convey the tool's function and legacy context. Every word earns its place, with no redundancy or padding.

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?

The description lists the response contents and the schema provides valid parameter values, making it sufficiently complete for selecting and invoking the tool. It lacks explicit comparison to current sibling tools, but the purpose and capabilities are clearly communicated, so it remains effective.

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%, with both parameters already detailed including default include sections and PascalCase component names. The description itself adds only generic tool-level information and no additional parameter-specific semantics, so the baseline score of 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 clearly states the tool returns a full component reference with enumerated sections (description, examples, composition hints, props, theming maps). It uses the specific phrase 'Full component reference in one call' and explicitly distinguishes itself as replacing older v2.x tools, clarifying its consolidated role.

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 provides clear context as a replacement for get_component_docs and get_usage_example, signaling it is the unified way to fetch comprehensive component info. However, it does not explicitly contrast with current sibling tools like get_component_props or get_composition_hints, leaving some ambiguity about when to choose a more granular tool.

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