Agent workflow
A practical sequence for coding agents that select, retrieve and integrate catalogue components into a Svelte project.
This guide is written for coding agents and the people who direct them. It applies whether the agent uses the MCP server, the public API or the website. To connect an agent, follow the setup steps; the tools are specified in the MCP reference.
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). 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-requiredcomponent 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.