ComponentPilot MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TINYFISH_API_KEY | Yes | Your TinyFish API key, required for live use. Set it in your MCP client or shell. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_componentsA | Dynamically discover verified component types from a configured public catalogue. Use this first to translate a user's natural-language frontend intent (for example, horizontally browsable products) into returned catalog component name(s); do not guess a component name. Returns source citations. |
| get_component_examplesB | Return one offset-based page of implementations linked by the source component page. Pagination metadata describes the full normalized source-derived result set. Does not invent or crawl external implementation URLs. |
| find_design_systemsC | Search design-system names with query and, optionally, filter by a source-published technology tag. Existing query-only technology calls are supported as a documented fallback. |
| get_accessibility_guidanceC | Return bounded, cited guidance published in an Accessibility section or relevant published markup/keyboard sections. Returns status not_published when none is available. |
| compare_implementationsC | Compare distinct implementation references linked by a component page without crawling third-party sites. |
| inspect_component_demoA | Queue a bounded Agent inspection and immediately return its TinyFish run_id; it does not wait for browser execution. Select a source-linked implementation using implementation_name, implementation_url, or both when they identify the same record. If neither selector is supplied, the response lists source-backed implementation names; set selection_mode to auto only when the user explicitly asks ComponentPilot to choose the first source-backed implementation. Arbitrary URLs, credentials, logins, paywall bypasses, and destructive actions are prohibited. Use get_component_demo_run with the returned run_id for status and the final validated result; it retrieves the existing run and never queues, retries, or bills another Agent execution. |
| get_component_demo_runA | Retrieve status or the completed result for an Agent inspection already queued by this ComponentPilot process. This never queues, retries, or bills a second Agent execution. The result-validation context is in memory and unavailable after a server restart. |
| health_checkB | Report MCP-server health, bounded source reachability, cached-data freshness, and the latest successful source refresh. A lightweight TinyFish Fetch probe runs only when due; it never queues a paid Agent run. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools have clearly distinct purposes: discovery (find_components, find_design_systems), content retrieval (get_component_examples, get_accessibility_guidance), comparison, demo inspection, and health. The closest overlap is between get_component_examples, compare_implementations, and inspect_component_demo, since all deal with source-linked implementations, but descriptions and the explicit queue/poll pairing of inspect_component_demo and get_component_demo_run keep boundaries reasonably clear.
The set overwhelmingly follows a consistent verb_noun snake_case pattern (find_components, get_component_examples, compare_implementations, inspect_component_demo, get_component_demo_run). The only minor deviation is health_check, a conventional noun-first name, but it is immediately readable and does not disrupt the pattern.
Eight tools is well-scoped for a component discovery and demo-inspection server. Each tool maps to a distinct workflow step: discovery, examples, design systems, accessibility, comparison, demo queueing, demo retrieval, and health.
The surface covers the main lifecycle from component discovery through examples, comparison, and bounded demo inspection, plus design-system search and accessibility guidance. Minor gaps remain: there is no direct tool for retrieving a single component's metadata/details, and design-system search lacks a corresponding detail/retrieval operation.