Search encode-ui components

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

Beyond the annotations (readOnlyHint=true, openWorldHint=false), the description reveals key behavioral traits: it's a 'plain substring filter' over an index, drops single characters and splits on punctuation, and clarifies that 'score' is rank-derived and not calibrated while 'cosine' is always null. This adds significant context about matching limitations and output semantics, fully earning a high score.

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 longer than average, but every sentence serves a purpose: purpose, engine mechanics, query quirks, alternative discovery method, install-command note, and absence limitation. It is front-loaded with the core purpose and then expands logically. However, some phrasing could be tightened (e.g., the 'Web engine' sentence packs many ideas), so it's not maximally concise.

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?

Given the tool's complexity (6 params, output schema, multiple siblings), the description is remarkably complete. It covers what the tool does, how it works, its limitations, when to use alternatives, and even advises reading a catalog resource for better judgment. The output schema exists, so no need to detail return values; the description handles all critical context.

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. The description adds meaning beyond the schema by explaining behavior of the query parameter: 'Terms split on punctuation and single characters are dropped, so "toast?" and "a dialog." behave like the bare words.' It also notes that 'exact names and aliases... work best,' which directly aids parameter usage. Other parameters are already well-described in the schema, so the description provides a modest but valuable increment.

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+resource+scope: 'Find React components in the encode-ui registry by name, alias, or keyword.' This clearly distinguishes it from siblings like list_components (which lists everything) and get_component (which fetches a single component). The mention of alternatives in the latter half further reinforces differentiation.

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 explicit guidance on when to use this tool vs. alternatives: 'For discovery and planning, read the catalog resource... once and judge the descriptions yourself' and 'A filter cannot prove absence: for "find ALL X" or "does the registry have X?" use list_groups + list_components.' It also warns about exact-name matching versus loose behavior phrasing, giving clear context for effective use.

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