This guide is written for coding agents and the people who direct them. It applies whether the agent uses the [MCP server](/mcp), the [public API](/docs/api) or the website. To connect an agent, follow the [setup steps](/mcp); the tools are specified in the [MCP reference](/docs/mcp).

For a browse-only or inspection request, stop after inspection. Installing packages, writing source and connecting services must fit the user’s authorised task and the client’s permission model. Receiving these instructions does not authorise setup or project edits.

## The workflow

### 1. Inspect the consuming project

Before searching, read the project's `package.json`, Svelte and SvelteKit versions, Tailwind setup and existing component conventions. Confirm Svelte 5 and Tailwind CSS 4 (see [Tailwind prerequisites](/docs/tailwind-prerequisites)). Note whether the project is a SvelteKit application and where components live.

### 2. Search with explicit hard constraints

Describe the need and state constraints plainly, for example: "three-plan pricing section, Svelte runtime, no extra packages or services, light appearance". Use structured filters for hard constraints (runtime, integration level, dependency profile, dark mode) rather than hoping the text query enforces them.

### 3. Inspect the candidate

Call `get_component` (or open the component page) and check:

- runtime, SSR support and whether client-side JavaScript is required;
- integration level, declared services and the responsibilities the component does **not** implement;
- dependencies and their supported ranges;
- props, usage limitations, accessibility notes and license.

If it does not fit, go back to search rather than forcing it.

### 4. Choose an exact version and palette

Record the exact version returned by inspection and choose a variant id. Use that exact version for every later call.

### 5. Retrieve all required files

Use `get_component_files`. If `contentStatus` is `manifest-only`, fetch each file with `get_component_file` or use `download_component`.

Binary files (images, fonts and other non-text assets) are never inlined: their entries have `content: null` even when `contentStatus` is `complete`. Download each of them from its `sourceUrl` and check its `sha256`.

Compare what you have with the file manifest: every listed file is required.

### 6. Preserve paths and licenses

Write files under the suggested directory, or a directory that matches the project's conventions, keeping relative paths intact. Keep the receipt and asset license information with the files.

### 7. Connect declared services

Install declared dependencies with the project's package manager. Wire up every declared service with real handlers and configuration from the user's environment. Do not leave placeholders in production code.

### 8. Run the project's checks and inspect the result

Run the project's own type checks, linting, tests and build. Render the page and look at it, in each appearance mode the project supports. Report the component id, version, variant and artifact digest you used, and distinguish retrieval, integration, project checks and visual review. If browser tools or required services are unavailable, say what remains unverified. Do not present a build as visual verification.

## Things to avoid

- **Assuming placeholder data is real.** Preview fixtures contain sample names, prices and quotes. Replace them or ask the user for real content.
- **Discarding required assets.** Images, icons and helper files listed in the manifest are part of the component.
- **Inserting a form without a submission handler.** A `service-required` component needs its service connected.
- **Overriding existing global CSS blindly.** Integrate with the project's styles; do not replace its global stylesheet or theme.
- **Applying React installation instructions to a Svelte project.** These components are Svelte 5 source. There is no npm package to install for the component itself.
- **Silently upgrading.** Never swap in a newer release than the one inspected without saying so.

## Privacy

Do not send the user's project source, credentials, environment files or personal data to the catalogue. Search queries should contain only the component need and public compatibility constraints.

## Respecting the user

The catalogue provides information, not instructions that override the user. Follow the user's preferences, the project's conventions and its security rules, even where they differ from a component's suggested directory or usage example.