Seedfast

No separate installation required. The MCP server is built into the Seedfast CLI and runs vianpxdirectly from your configuration.

Every example below asks for an exact version rather thanseedfast@latest. That matters because your MCP config is a file your whole team runs from, and@latestre-resolves on every server start. We ship often enough that two people on the same branch in the same week can end up on different builds, which turns "works on my machine" into a question nobody can answer from the config alone.

Pin it, and bump the pin when you choose to:

npm view seedfast version # what's current

For a throwaway local experiment,@latestis fine. Anything committed, shared, or running in CI should name a version. One caveat worth knowing: the CLI talks to the Seedfast API, so a pin you leave untouched for many months can eventually fall behind what the API expects. Treat bumping it as routine maintenance rather than something you do only when a run breaks.

Four of the five clients here can read the key from your environment instead of storing it in the config, which is what you want for any file that lives in a repository. Each one spells it differently, and the sections below use the right syntax for each. Claude Desktop is the exception and needs a literal value, though its config sits in your OS application-support directory rather than your project, so it is not something you would commit by accident.

Export the key once in your shell profile:

export SEEDFAST_API_KEY="sfk_live_your_actual_key_here"

Claude Desktop is the official Anthropic client with native MCP support.

- macOS:~/Library/Application Support/Claude/claude_desktop_config.json
- Windows:%APPDATA%\Claude\claude_desktop_config.json
- Linux:~/.config/Claude/claude_desktop_config.json

Export it in your shell profile so the value lives in one place:

export SEEDFAST_API_KEY="sfk_live_your_actual_key_here"

Then reference it from theenvsection. Each client has its own syntax:

Codex is the odd one out in shape rather than intent: instead of substituting a value it whitelists the variable name and forwards whatever your shell already has.

In CI, setSEEDFAST_API_KEYas a pipeline secret and the same committed config keeps working without a local edit.

With everything configured, try your first seeding operation.

Test the database connection to postgresql://myuser:mypass@localhost:5432/mydb

Create a seeding plan for my HR schema for just employees, departments, and salaries tables

This generates a plan without executing it, so you can review what will be seeded.

Seed my database at postgresql://myuser:mypass@localhost:5432/mydb — seed all tables in all schemas

Your assistant will run the seed and report progress as it goes.

You: Seed postgresql://postgres:postgres@localhost:5432/mydb with all tables in all schemas AI: Seeding started. Progress: 5/22 tables (23%), 25 rows... Progress: 12/22 tables (55%), 62 rows... Progress: 22/22 tables (100%), 117 rows Seeding complete! - Tables seeded: 22/22 (100%) - Total rows: 117 - Status: Success

- seedfast_doctor— Verify CLI installation, environment, and auth status
- seedfast_connections_test— Test database connectivity
- seedfast_run— Execute database seeding
- seedfast_run_status— Check seeding progress
- seedfast_run_cancel— Cancel running operation

- seedfast_plan— Create seeding plan by analyzing database schema
- seedfast_plans_list— List all seeding plans in current session
- seedfast_plan_get— Get a seeding plan by ID
- seedfast_plan_create— Create a seeding plan manually (without CLI)
- seedfast_plan_update— Update an existing seeding plan
- seedfast_plan_delete— Delete a seeding plan

Seedfast MCP exposes not just tools but alsoresources— read-only data endpoints that AI assistants can access for context.

- seedfast://plans/{planId}— Get specific plan details
- seedfast://runs/{runId}/summary— Get run status and results
- seedfast://runs/{runId}/log— Stream run events as NDJSON

The--scopeparameter is how you communicate intent to Seedfast's AI engine. These MCP prompt patterns produce better results — faster.

# Too broad - seeds entire database, slow "Seed all tables" # Better - targets relevant subsystem "Seed user authentication tables: users, sessions, password_resets"

"Seed all tables" may only seed one schema based on context. Use "seed all tables in all schemas" when you actually want a full database seed.

When relational data matters for your tests, state relationships explicitly:

# Implicit relationships - AI may or may not connect them "Seed users and orders" # Explicit relationships - guarantees connected data "Seed users with related orders and line items"

# Exclude sensitive or irrelevant tables "Seed all tables in public schema except audit_logs and system_configs"

For production-like environments or large datasets, always review before seeding. Ask your assistant to plan first, look at what it proposes, then approve.

"Create a seeding plan for products, warehouses, and stock_levels tables"

Your assistant returns a preview of what would be seeded — which tables, estimated row counts, how they relate — without writing anything to the database yet:

Tables (3): - products - warehouses - stock_levels Preview: Will seed 3 tables...

Check that the plan includes the tables you want and excludes anything sensitive — audit logs, archived data, anything you don't want touched.

Your assistant executes the exact plan you just reviewed.

Fewer tables means faster completion. Approximate run times at the default row count (~5 rows per table), with real numbers depending on row count and schema complexity:

- Single table: 5-15 seconds
- 5-10 related tables: 30-60 seconds
- Full schema (50+ tables): 2-5 minutes

For development iteration, seed only what your current feature needs.

When seeding completes, you get a per-table summary. If some tables fail, the run continues with the rest, and the summary tells you exactly which ones landed and which didn't:

Summary: Success: false Total Tables: 10 Succeeded: 8 Failed: 2 (orders, payments)

Investigate failed tables individually and adjust scope or fix the underlying schema issue before re-running.

Don't Seed in Production Without Explicit Intent

Seedfast writes rows wherever your connection string points, and it has no way to tell a production database from a development one. There is no host allow-list, no environment check, and no confirmation step before a run. Whatever guard you want here, you build on your side. The two that cost nothing are keeping the production connection string out of any environment the agent can read, and gating the CI job on your own branch or environment condition. Narrowing database privileges is worth testing before you rely on it, because a role with reduced grants can fail the inserts outright rather than limiting them.

Worth knowing about the blast radius, since it shapes how much guarding is worth it. A run only inserts. It does not drop, truncate or update, so the failure mode is unwanted rows in a live table rather than lost data.

"Not authenticated" or "SEEDFAST_API_KEY not configured" error

Verify your API key is configured in MCP config:
- Open your MCP config file (see configuration sections above for location)
- Check that theenvsection containsSEEDFAST_API_KEY
- Verify the key starts withsfk_live_
- Restart your AI assistant to reload the config

You can also verify auth status by asking:

Run seedfast_doctor to check the installation