Inspo: a catalogue of real websites your coding agent can study over MCP

The pitch is that agents have tools but not taste

The project's argument is one sentence long and it is worth quoting, because it explains the whole architecture. Agents have tools but not taste, and the open web already holds every reference they need, so Inspo assembles, tags and addresses it.

The demonstration is a before and after. Same brief, same model, no design skill on either run, and the only difference is that the page on the right was built with Inspo MCP on the session. The description of the two outputs is telling in itself. The bare agent's page is a dark theme with a neon accent and a gradient app mock. The page built with Inspo is warm paper, editorial type and a detailed product mock.

The claim is not that the agent suddenly learned design. The claim is that the agent was given something to look at, and looked at it differently. That framing is the honest one for a reference archive, and it also sets the expectation: this is a source of examples, and the quality of the result depends on the agent's ability to use them and on the quality of what is in the archive.

The project description calls it real websites for your coding agent to learn design from, searchable over MCP, and the site is inspomcp.dev. The licence is MIT with copyright Together AI and contributors, and the repository has no GitHub releases, with the last push on 2026-10-01.

It is worth noting who built it. The repository is under the Nutlope organisation, and the licence line and the .env example both point at Together AI as the model provider behind the capture pipeline and the semantic search. This is a commercial company's open source tool, not a community project, which shows up in the code in the model choices and in the paywall policy at the end of the roadmap.

What is in the archive and how it was extracted

The contents section gives three specific numbers and one catalogue figure. There are 2,320 pages across 832 real sites, each captured on desktop and mobile, with traced palettes, real fonts, detected tech and a fold-by-fold autopsy on every page. There are 68 canonical reference components, being heroes, pricing sections, footers, navs and more, each demonstrating one named macrostructure with copy-pasteable JSX. And there is a DESIGN.md for every site, extracted from its DOM, containing semantic palette roles, a type ramp, a spacing scale, CSS variables and the container width.

That last item is the most useful thing in the archive for an agent. A screenshot tells a model what a page looks like, but a DESIGN.md gives it the tokens. Semantic palette roles means the colours are named for what they do rather than what they look like, so an agent generating a button does not have to guess which of six greys is the interactive one. A type ramp and a spacing scale are the two things a language model is worst at inventing, because they have to be internally consistent across a whole page, and a model without a scale produces a plausible-looking page where every margin is slightly wrong.

The capture pipeline is described in the tech stack section. A Playwright capture worker takes desktop and mobile shots and does palette, type ramp and CSS variable extraction, and runs tag and autopsy passes via Together AI. The autopsy is the fold-by-fold analysis, a per-screen breakdown rather than a single verdict on a whole page. The specific models are named in the environment example: a vision model for tagging, northstars and quality, and an embedding model for text.

The component layer is separate from the site layer. 68 canonical reference components each demonstrate one named macrostructure, and the README notes that the roadmap item to backfill component crops so that find_components returns a crop for every hit is still unchecked. So the component catalogue is currently uneven in exactly the way that roadmap entry describes.

Fifteen tools, and one call that composes them

The tool surface is described by its count rather than its detail. Fifteen tools expose all of it, and recommend(brief) composes most of them into one call. The full tool table lives in apps/mcp/README.md, which the README links rather than reproducing.

That single-call composition is the design decision that matters for adoption. An agent that has to chain eight tool calls to get a design direction will often not do it, and an agent with one call named after the thing a developer actually asks for, namely a brief, will. The other request patterns in the workflow reinforce the point. The gallery site and the curator dashboard are built with Next.js 16 and Tailwind v4, and the tool names in the roadmap and the security section give a sample of the surface: find_components, find_similar, and get_design_system.

The security section is unusually detailed and worth reading closely, because an MCP server that fetches URLs is exactly the shape of tool that introduces server side request forgery.

Every tool is read-only, and there is exactly one path that touches the outside world, which is get_design_system with live true. That call supplements thin captured tokens from the screen's own source, and it passes each URL and redirect through an SSRF guard: public named hosts only, ports 80 and 443, a byte-capped body, and no JavaScript execution. The no-JS rule matters because a headless fetch of a page that runs script can reach internal services.

The hosted endpoint logs the tool name, success and duration per call, and never logs IPs or query text. That is a short log schema, and it is also a specific claim about what the operator does not collect, which is the kind of thing to check rather than assume.

Installing it is one command, and the hosted endpoint needs no database

The cloning and running section gives four routes, in increasing order of effort.

The first is a single command that detects the client and writes the configuration:

npx -y inspo-mcp install

The documentation says it detects Claude Code, Cursor, Codex, VS Code, Windsurf, Zed and Claude Desktop, and that a --dry-run flag shows the plan before anything is written. That detail is worth having, because an installer that edits your editor configuration without showing you what it will do is an installer you run in a sandbox first.

The second route is pointing a client at the hosted endpoint yourself:

claude mcp add --transport http inspo https://inspomcp.dev/api/mcp

The third is cloning the repository, and the fourth and fifth are the gallery and the dev loop:

git clone https://github.com/Nutlope/inspo.git && cd inspo && pnpm install

pnpm dev

pnpm --filter @inspo/mcp test

After pnpm dev you open localhost:3000 for the gallery, and the dev loop test command runs the MCP package's tests.

The architecture detail that matters for self hosting is in the tech stack: the MCP server has two transports, stdio via npm and Streamable HTTP served by the site's own Vercel deployment, and there is no database at query time because the catalogue ships as a static seed. The environment example confirms this, since the database section is marked optional and says the catalogue ships from a static seed file, so the gallery and the MCP work fully without a database, and a Neon connection string is only needed for the live Neon-backed path.

That is a genuinely useful property for a self hosted install. A team running this on its own infrastructure does not need to stand up Postgres to give an agent a reference library.

The parts of the stack you do not need if you only want the catalogue

The environment example is a good map of the full pipeline, and it shows how much of the machinery exists only to create the archive rather than to serve it.

The Together AI key powers the capture worker's enrichment: vision tagging, northstars and quality on one side, and text embeddings on the other, using a 1024 dimension embedding model. The embedding model is what backs the semantic search and the find_similar tool, which means the search path is a network call to an external model provider at query time, not a local index.

The Vercel Blob read and write token holds the captured PNG, AVIF and WebP assets. The token is written by the capture worker and read back by the MCP server, so the screenshots are an external storage dependency rather than something in the repository.

The auth variables are for the web application and are explicitly optional, since they are only needed if you enable the authenticated web routes. The environment file is unusually well commented about this, noting that in production both the secret and the URL are required and that the application throws on boot if they are unset when NODE_ENV is production, so that it cannot silently sign sessions with the development fallback. Generating the secret is a single openssl command.

So the minimum viable self hosted setup is the MCP server with its static seed and, if you want search, a Together AI key. The database, the blob store and the auth secret are all optional for a read-only catalogue, and the root package manifest reflects that structure, with the database commands scoped to their own workspace package through the db prefixed scripts and the capture commands scoped to the worker package.

An archive of other people's work, and what that obliges

The security section closes with a paragraph that is short and legally meaningful. The screenshots remain the work of their designers, every screen credits and links its source, and takedowns are honoured at a dedicated page. The MIT licence covers the code, and the copyright line names Together AI and contributors.

That is the right way to do it, and it also sets a limit on what the archive can be. The screenshots are being redistributed for the purpose of being studied, and the credit-and-takedown policy is what keeps that defensible. It is worth knowing as a user that the archive is a courtesy arrangement, not a permanent guarantee, and that a site can be removed from it.

The roadmap contains one line that is a policy rather than a feature: accounts and paywalls are skipped on purpose, because the archive is more useful free. That is a real constraint on coverage. The sites in the archive are the publicly reachable ones, which means the design references available to the agent are the ones anyone could see. A logged-in dashboard, a paywalled report or a member-only checkout will not be in there.

The rest of the roadmap is ordinary maintenance, and two items are worth noting because they describe current behaviour. The plan is to show the desktop and mobile capture side by side on every screen page, and to re-shoot the mobile set at retina scale, which means the mobile captures are currently not at retina resolution. Another item is to paginate the list tools instead of capping them, so the list tools currently return a capped number of results rather than everything, which is a detail that matters if you are trying to enumerate the archive.

Contributing is simple: append a site to the seed urls file and open a pull request, with the bar stated as whether it makes the archive better for someone building a website.

Editorial conclusion

Inspo fits a team whose coding agent produces generic interfaces, especially one working on marketing or landing pages where a reference matters more than a component library, and it fits a designer who wants to hand the agent a specific set of extracted tokens rather than a screenshot. It is the wrong choice if your problem is accessibility or component behaviour rather than visual taste, because the archive is static imagery and traced tokens, not tested interactive code, and it is the wrong choice if you need the catalogue offline, since the search path depends on Together AI embeddings. Before adopting it, read the tool table in apps/mcp/README.md to see which of the fifteen tools your host actually exposes, and check the SSRF guard behaviour of get_design_system with live true before pointing it at pages behind authentication.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Nutlope/inspo on GitHub
4. Project website
5. README