Github Search Prefab Components

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

With no annotations, the description carries full burden and does an excellent job: it explains the OR-matching behavior, the automatic detail/compact mode based on match count (≤5), and how the 'detail' parameter overrides this. It also discloses the limit behavior difference between modes. These are precisely the behavioral traits an agent needs to predict the tool's response.

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 well-organized and front-loaded with the main purpose, then presents usage context, matching behavior, parameters, and a workflow reference. While it's longer than necessary, every sentence contributes meaning and the structure supports quick scanning. It could be tightened, but it's not 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?

The description covers the core search behavior, detail override, and limit semantics thoroughly, and mentions the workflow with github_get_skill. However, it omits the 'components' parameter entirely, leaving it unexplained. Given four parameters, one undocumented is a real gap that impacts an agent's ability to call the tool correctly in all cases. The output schema exists, so return format is covered, but the missing parameter drags completeness down.

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 schema already documents three parameters (query, detail, limit) with clear descriptions that largely match the text. The description adds little beyond the schema for these. More critically, the fourth parameter 'components' has no description in either the schema or the tool description, leaving it undefined. Since schema coverage is 75% (above the low threshold but not >80%), the description should have compensated but instead omits it entirely.

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 line 'Search the Prefab component library' states a clear verb and resource. It then distinguishes this tool from the sibling github_get_skill by specifying that the skill covers patterns/layout while this tool provides API details. The purpose is unambiguous and distinct from all sibling github 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?

The description explicitly states when to use this tool ('before writing component code') and contrasts it with the skill ('The skill covers patterns and layout; this tool has the API details'). It also names the specific alternative github_get_skill and references a workflow. This is direct and actionable usage guidance.

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