My coding agent set up auth five times, five different ways. So I gave it my working version

Every new project starts the same way. I ask the agent to set up auth, and it writes it from scratch again. One time the session cookie is missing secure. Another time it uses an API from two major versions ago, or the middleware protects every route except the one that matters. Each version looks plausible, and I only find the problem after an hour of debugging or, worse, in review.

I already have an auth setup I trust: the config, the database schema, the middleware and the sign-in route, tested in production. It just lives in an old repo the agent can't see.

So I built Sniptide, a pastebin where I keep the setups I reuse, and gave it an MCP server so Claude Code, Codex and Cursor can search and read the same library. This post covers why the usual options didn't work for me, how the workflow looks, and a few decisions I'd make again.

Why not a template, a package or a skills folder?

I tried all three before building anything.

A template repo works for day one, but it's a whole repo. Auth is four files, and I don't want to start every project from someone's opinion about folder structure, linting and CI just to get them. Templates also go stale quietly, because nobody updates a repo they only clone.

A private npm package is the "correct" answer and the most work. Auth config isn't a library. It touches your schema, your routes and your env, so it ends up as a package full of options that still needs glue code in every project. Publishing a new version to change one line got old fast.

A skills folder in each repo is close to what I wanted, but it lives in one repo. The moment I start project number six, the agent can't see what I wrote for project number five.

What I wanted was simpler: the files I trust, in one place, with a link I control, readable by me and by my agent from any project.

The workflow

I save the four auth files as one paste, since a paste holds up to 10 files, and put it in a collection called building-blocks. Then I connect the agent once:

claude mcp add --transport http sniptide https://app.sniptide.com/api/mcp

After signing in through the browser with /mcp, I can ask in plain language:

Set up auth using the setup from my Sniptide building blocks.

The agent calls search_snippets, reads the matching paste with read_snippet, and adapts my working files to the new project instead of guessing. It keeps my cookie settings and my middleware, and only changes what the new project actually needs, like import paths or the database client.

The same works for the database setup, env validation or the button component my team agreed on. Over time the collection turns into a set of building blocks I trust, and a new project is mostly the agent assembling them.

Prompts for bigger jobs

Plain tool calls are fine for one snippet. For a whole setup, the server also ships MCP prompts:

• use_snippet takes a task, searches your snippets, reads the best match and adapts it to the project.
• apply_collection fetches every paste in a collection, lists the steps and waits for your go-ahead before applying them in order.
• save_snippet goes the other way. When the agent writes something worth keeping, it proposes a title, tags and paths, leaves secrets out and saves a private snippet after you confirm.

apply_collection is the one I use most. Starting a project with "apply building-blocks" and reviewing a numbered plan beats reviewing 400 lines the agent invented.

Three decisions that mattered

1. Stateless JSON over SSE. The MCP endpoint is a single POST route inside the Next.js app. It answers with plain JSON and keeps no session, so GET and DELETE just return 405. That means no long-lived connections to babysit, and it runs behind any reverse proxy or serverless host without special config.

2. Read-only by default. An agent signs in with OAuth, or with a personal API token for scripts and CI. Either way it gets read access unless you grant write access. Cookies are never accepted as MCP credentials, and browser requests from another origin are rejected. An agent only ever sees your own pastes, and revoking a token cuts it off immediately. Giving an agent your auth code is fine. Giving it the ability to quietly rewrite that code should be a choice you make.

3. Markdown for agents that just fetch links. Not every agent speaks MCP. If a client requests a paste link with Accept: text/markdown, it gets the files back as fenced code blocks without the page around them:

curl -H "Accept: text/markdown" https://app.sniptide.com/k3j9xq

Password-protected and burn-after-reading pastes return a short note asking the reader to open them in a browser, so the Markdown copy never leaks what the share page protects. It was the cheapest feature I built and one of the most useful.

If you'd rather keep it in the repo

The CLI can write a collection into your project as a skill:

sniptide skill building-blocks

That creates .claude/skills/building-blocks/ with a SKILL.md describing each paste and the files next to it, so the agent loads only what it needs. It's a local copy, so you rerun it with --force when the collection changes. I use this for projects where I want the setup pinned, and MCP everywhere else.

It's also just a pastebin

You don't have to use agents at all. A paste can be private, unlisted or public, password protected, set to expire or burn after reading, and you can invite people to view or edit it. Every edit records a revision you can compare and restore. There are also encrypted env groups for handing a project's .env to a teammate without pasting it into Slack.

Self-hosting

The app is AGPL-3.0 and runs on your own server with one command, which sets up Docker Compose, HTTPS and Postgres:

curl -fsSL https://sniptide.com/install.sh | sh

The MCP endpoint comes with every instance, so your agents only talk to your server. The self-hosting docs cover the manual Compose setup if you'd rather not pipe to sh.

What I'm unsure about

The part I keep going back and forth on is how much the agent should adapt. Sometimes I want my auth files copied exactly, and sometimes I want them rewritten for a different framework. Right now that's up to how you phrase the prompt, and I'm not sure that's good enough.

I'd love to hear how you handle this today. Do you keep reusable setups in gists, a template, a private package or a skills folder, or do you let the agent regenerate them every time? And if you try the MCP server, tell me where it gets in the way.

• Repo: https://github.com/Dino-Kupinic/sniptide
• Launch post: https://sniptide.com/blog/introducing-sniptide

I'm the developer of Sniptide.