Synthbrew MCP Agent for AI Coding Workflows

TL;DR

The Synthbrew MCP agent lets AI coding tools use Synthbrew directly. Instead of opening the dashboard, manually creating a schema, generating a source, copying runtime docs, and pasting connection details back into your editor, you can ask your agent to do the workflow for you.

For example:

Can you generate a Synthbrew schema for a B2B SaaS analytics app with accounts, users, subscriptions, invoices, product events, and support tickets? Generate 100,000 rows, keep the relationships realistic, create the data source, and give me the connection credentials and runtime API docs.

The agent can draft the schema, validate it, create the Synthbrew resources, generate the data source, and return the details your app needs.

Start with the Synthbrew agent setup guide, or jump straight to the client-specific guides for Codex, Claude Code, Cursor, and Windsurf.

Why this belongs inside your coding agent

Frontend and product engineers increasingly work through AI coding agents. The agent can read your app, understand the components you are building, generate client code, and wire API calls. But until now, the data environment was still a separate chore.

That gap matters. A realistic UI needs more than a few rows of JSON. It needs related records, timestamps, edge cases, pagination, mutations, and enough volume to make charts and filters behave like they will in production.

Synthbrew already gives teams a way to go from schema to seeded relational data and a runtime CRUD API. The MCP agent brings that workflow into the same place you are already building the app.

Coding agent
  -> drafts schema from your product request
  -> validates schema with Synthbrew
  -> creates schema and source
  -> generates seeded relational data
  -> returns runtime API docs and connection details

That means you can ask for the backend surface your feature needs without switching contexts.

What is the Synthbrew MCP agent?

The Synthbrew MCP agent is an MCP server packaged as @synthbrew/agent. MCP, or Model Context Protocol, is a standard way for AI tools to call external tools through a structured interface. In practice, it means your coding agent gets a list of Synthbrew actions it can call safely and predictably.

The first version focuses on the workflow that matters most:

Validate a Synthbrew schema config
List or create projects
Create schemas and schema versions
Create and regenerate data sources
Inspect generation jobs and events
Create source API keys
Fetch runtime API docs for a generated source

The package does not ask Synthbrew’s own AI schema generator to design the schema. Your coding agent does that. Synthbrew provides validation, resource creation, deterministic generation, runtime API access, and source-level secrets.

That division is deliberate. The agent is good at understanding your app context. Synthbrew is good at turning a validated schema into a usable data source.

A better prompt than “make fake data”

The useful prompt is not “generate fake users.” That gives you a flat fixture.

A better prompt describes the product workflow you want to build:

Use Synthbrew to create a marketplace dataset with sellers, buyers, products, orders, order_items, payouts, reviews, and refunds. Generate enough data for a realistic admin dashboard, create the source, and return the API key plus example queries I can use in my app.

This gives the agent the domain, the important tables, the expected relationships, and the app outcome. The agent can then produce a schema that supports dashboard metrics, product detail pages, buyer histories, refund workflows, and seller payout views.

Another example:

Create a Synthbrew schema for a sales CRM with companies, contacts, deals, activities, notes, tasks, and pipeline stages. Generate 50,000 realistic records across the tables, create a Postgres source, and return everything needed to connect my app to it.

That is much closer to how product work actually happens. You are not asking for rows. You are asking for an environment your feature can use.

Replicate the schema your app already has

One of the most useful agent workflows is pointing Synthbrew at the schema files in your existing app. In Codex, Claude Code, Cursor, Windsurf, or any MCP-capable coding agent, the agent can inspect your models, translate them into a Synthbrew schema, validate the config, generate a populated source, and return the credentials your app needs.

For example:

Use Synthbrew MCP to replicate my database schema at /db/models and generate 100,000 rows. Give me the source database credentials and runtime API docs afterward.

This is especially useful when your frontend is already shaped around a real application schema, but you do not want to connect local development, demos, or QA runs to production-like customer data. The generated source keeps the same table shape and relationships your app expects, while Synthbrew fills it with safe, realistic sample rows at the volume you need.

What your agent can return

Once the workflow finishes, your agent can hand back the things developers need:

The schema it created
The source ID and generation status
Runtime API base details
Source API key instructions
Example fetch calls using x-api-key
Table names and route patterns
Optional read-only Postgres connection details when your plan supports direct DB access

For a frontend app, that is usually enough to start replacing local fixtures with real API calls.

const response = await fetch(`${SYNTHBREW_RUNTIME_URL}/customers?limit=50`, {
  headers: {
    "x-api-key": process.env.SYNTHBREW_SOURCE_API_KEY
  }
});

const { data } = await response.json();

The runtime details come from the generated source, so the agent can adapt examples to the exact tables it created.

How to install it

Most MCP clients can launch the package with npx:

npx -y @synthbrew/agent

Configure a Synthbrew public API key and the API base URL in your MCP client:

SYNTHBREW_API_KEY=sb_api_...
SYNTHBREW_API_URL=https://api.synthbrew.com/api
# Optional for local/self-hosted app links
SYNTHBREW_APP_URL=https://app.synthbrew.com

The generic MCP configuration looks like this:

{
  "mcpServers": {
    "synthbrew": {
      "command": "npx",
      "args": ["-y", "@synthbrew/agent"],
      "env": {
        "SYNTHBREW_API_KEY": "sb_api_...",
        "SYNTHBREW_API_URL": "https://api.synthbrew.com/api",
        "SYNTHBREW_APP_URL": "https://app.synthbrew.com"
      }
    }
  }
}

After a source is created or regenerated, the agent returns a source settings link. Users can ask the agent to issue runtime credentials in chat, but opening Synthbrew to create API keys and database passwords is the recommended path.

Each agent has its own config location and reload behavior. Use the setup guide for your tool:

If you want the lower-level API details behind the agent, see the Public API reference and the runtime API reference.

When this is better than static mocks

Static mocks still make sense for small components and early layout work. The Synthbrew MCP workflow becomes more useful when your UI depends on system behavior:

Tables with filtering, search, sorting, and pagination
Detail pages with related records
Dashboards with time-series data
CRUD flows that need persistent state
QA environments that need repeatable seeded data
Demo apps that need realistic volume and edge cases

If the feature needs joins, mutations, history, or realistic distributions, an agent-managed Synthbrew source gives you a stronger foundation than hand-written JSON.

What to ask your agent first

After setup, start with a focused prompt:

Use Synthbrew to create a schema for an ecommerce admin dashboard with customers, products, orders, order_items, payments, and refunds. Validate the schema first, create a populated source, and return the runtime API docs and connection details.

That single request shows the core product loop: schema, validation, source generation, runtime access, and integration help.

If your app already has database models, point the agent at them:

Use Synthbrew MCP to replicate my database schema at /db/models and generate 100,000 rows. Give me the source database credentials and runtime API docs afterward.

That lets the agent create a safe development dataset that matches the schema your app already uses, without hand-copying table definitions into Synthbrew.

If you are building a SaaS dashboard, try:

Use Synthbrew to create a SaaS metrics backend with accounts, users, subscriptions, invoices, product events, and support tickets. Generate 100,000 rows and give me the connection details I need to wire this app to the generated API.

If you are building a CRM, try:

Use Synthbrew to create a CRM dataset with companies, contacts, deals, activities, notes, tasks, and pipeline stages. Generate 50,000 records, create a source, and show me example API calls for list, detail, create, and update flows.

The bigger shift

The point is not just that agents can call another API. The point is that agents can now create the data environment that matches the feature they are building.

That changes the development loop. Instead of building UI against weak fixtures and replacing them later, you can ask for a realistic backend surface at the same time you ask for the frontend code. The schema, data, and runtime API become part of the agent workflow.

For teams building dashboards, internal tools, SaaS admin panels, and customer portals, that is the difference between a pretty prototype and a flow you can actually test.

Get started with the Synthbrew MCP agent docs, then connect it to Codex, Claude Code, Cursor, or Windsurf.

Introducing the Synthbrew MCP Agent for AI Coding Workflows