Fetch a minimal component template, dependencies, and composition tips for Astro or HTML. Build and validate Basecoat UI interfaces offline with curated design resources.
Get one minimal component template, dependencies, and composition tips for Astro or HTML. Response is bounded below 2000 UTF-8 bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| environment | Yes |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds a concrete behavioral constraint by stating the response is bounded to 2000 UTF-8 bytes, and discloses that the result contains a minimal template, dependencies, and composition tips. This adds value beyond the annotations, though the size-bound phrasing is slightly ambiguous.
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 two short, front-loaded sentences with no filler. The core retrieval statement comes first, and the response-size note is a useful addition. Every sentence 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 simple read-only lookup with two required parameters and no output schema, the description covers the main invocation facts: input language, single-component resource, and response contents and size limit. It does not mention response format or how to discover valid IDs, but the sibling search_components tool likely fills that gap. Overall it is sufficiently complete for a correct call, with minor discoverability gaps.
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 must compensate for missing parameter documentation. It maps the environment parameter to Astro or HTML and implies id selects a single component, but it never explicitly defines id as a component identifier or explains how valid ids are discovered. This is only partial compensation for the absent schema descriptions.
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 uses a specific verb, 'Get', and names a concrete resource: one minimal component template with dependencies and composition tips, scoped to Astro or HTML. This clearly differentiates it from search_components (searching) and validate_composition (validating), and 'one minimal' signals single-item retrieval rather than a list operation.
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?
No guidance is given about when to use this tool versus search_components or validate_composition. The description does not say to use search_components first to find an id, nor does it mention when validation would be more appropriate. Usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.