Find up to 8 compact Basecoat UI component summaries by intent or query to locate building blocks for Astro or static HTML interfaces.
Find up to 8 compact component summaries by intent and/or query (either field may be omitted). No matches returns an empty list; no markup is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| intent | No |
Changes observed during successful MCP inspections.
v1.0.3Input schema / requiredRemoved value: -[
- "intent",
- "query"
-]v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds genuinely new behavioral facts beyond them: the hard cap of 8 results, empty-list-on-no-match, and that no markup is returned. It does not mention ranking or ordering of results, but the additions are real value.
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 compact sentence with the result cap and the empty-result behavior front-loaded, and no filler. It is perhaps overly terse given the undocumented param distinction, but nothing in it wastes space.
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 two-param search tool with rich annotations and no output schema, the description covers the essentials (cap, empty result, no markup). It stops short of defining the intent/query distinction or result ordering, which are the remaining gaps an agent would hit in practice.
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 carries the burden for both params. It clarifies that both are optional and combinable ('and/or'), but never explains what 'intent' means versus 'query' — the central semantic distinction an agent needs to fill them correctly. Partial compensation only.
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 (Find) and resource (component summaries), and scopes it with 'up to 8 compact' and 'by intent and/or query'. 'Compact summaries' implicitly distinguishes it from get_component_details, though it never names the sibling or explains the boundary explicitly.
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 parenthetical '(either field may be omitted)' tells the agent both params are optional, which is useful invocation guidance. However, there is no explicit when-to-use-this-vs-validate_composition/get_component_details routing, so usage must be inferred from 'compact summaries'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.