DEV Community: LUIS GUSTAVO PEIL DE OLIVEIRA

MCP is finally here: stop building REST boilerplate and start shipping

LUIS GUSTAVO PEIL DE OLIVEIRA — Sat, 27 Jun 2026 08:22:28 +0000

TL;DR: BugiaData MCP is live. Point Cursor, Claude, or Windsurf at a hosted SSE server, paste one config block, and ask your agent for relational fake data with valid foreign keys—no custom REST glue in your repo.

If you build with AI agents, you already know the loop:

You need realistic test data.
You wire up an HTTP client, auth headers, error handling, and JSON parsing.
You repeat that for every new tool, every new environment, every new IDE.

The Model Context Protocol was supposed to fix the integration tax. In practice, a lot of “MCP-ready” products still feel like REST APIs wearing a badge—same docs maze, same “here’s your API key, good luck.”

I built BugiaData to skip that layer for one job: generating fake data that actually behaves like a database—locales, multiple tables, foreign keys intact—directly from the chat in your editor.

What shipped

BugiaData now exposes a hosted remote MCP server (SSE) with four tools:

Tool	What it does
`ping`	Health check + tier hint
`whoami`	Quota and account info for your API key
`generate_data`	Single Faker-type batch (names, emails, etc.)
`generate_relational_data`	Multi-table JSON with `foreign_key` columns wired correctly

Same API key and monthly quota as the REST API and Studio. Free tier: 10,000 tokens/month.

Works today in Cursor, Claude Desktop, Claude Code, and Windsurf.

Why MCP beats another REST wrapper (for this use case)

REST is fine for humans. For agents, every endpoint is another chance to hallucinate paths, forget headers, or invent query params.

With MCP:

Your client discovers tools, not OpenAPI specs.
The agent maps natural language to structured arguments once.
You stay in the editor—no context switch to Postman or a seed script.

BugiaData’s differentiator isn’t “fake data exists.” It’s relational consistency: users and orders where orders.user_id actually references users.id, in pl_PL or pt_BR if you ask for it.

Flat Faker lists are easy. Graph-shaped test data is where projects stall. That’s the wedge.

Replace “call my REST API” with this (≈5 minutes)

1. Get an API key

2. Add the server to your client

Cursor — .cursor/mcp.json (project or global):

{
  "mcpServers": {
    "bugiadata": {
      "url": "https://mcp.bugiadata.com/sse",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Claude Desktop / Claude Code / Windsurf — same mcpServers block in your client config (claude_desktop_config.json, ~/.claude/mcp.json, or Windsurf MCP config).

Restart the client after saving.

3. Ask for data in plain language

Try something concrete:

Using BugiaData, generate 20 users and their orders. Orders must reference users.id. Use locale pt_BR.

Or a single-type batch:

Generate 10 company names and emails with locale en_US via BugiaData.

The agent should call generate_relational_data or generate_data and return JSON in chat—no shell scripts, no hand-rolled fetch.

See it before you sign up

The MCP landing page includes a live demo (rate-limited ping / sample generation) so you can watch JSON come back before creating an account:

👉 bugiadata.com/mcp

Full docs (REST + schema shape): bugiadata.com/docs

Listings (if you’re browsing, not building)

cursor.store: cursor.store/mcp/lgpoliveira/bugiadata-mcp
MCP Registry: io.github.lgpoliveira/bugiadata-mcp — search
Install snippets repo: github.com/lgpoliveira/bugiadata-mcp

What I’d love feedback on

If you’re already on MCP in production:

What would make you default to MCP over a one-off REST call for data tools?
Is relational schema generation the missing piece, or still overkill for your tests?

Drop a comment or open an issue on the docs repo. I’m especially interested in real agent prompts that broke—or surprised you—in a good way.

Links

Why I’m killing "Blank Canvas Syndrome" in Database Seeding

LUIS GUSTAVO PEIL DE OLIVEIRA — Fri, 01 May 2026 20:20:30 +0000

Most dev tools hide behind "Contact Sales" buttons. I’m doing the opposite.

With the Conversion Catalyst update, I’ve made BugiaData the most transparent way to handle relational test data. As a solo builder, I wanted to focus on the human element of dev-ops:

Instant ROI: I built a calculator to help you justify the shift from manual scripts to synthetic data.
Relational Templates: I added a feature to load full schemas for Social Media or Fintech apps in a single click.

The Road to AI-Native
While I’ve spent time perfecting the Studio for humans, my next move is the MCP Server. I am building the infrastructure at mcp.bugiadata.com to ensure BugiaData lives where you code.

Check out the new templates I’ve built: https://bugiadata.com

webdev #database #productivity #buildinpublic

How Relational Fake Data Speeds Up Your Testing Workflow

LUIS GUSTAVO PEIL DE OLIVEIRA — Fri, 13 Mar 2026 09:24:32 +0000

Every developer has been there: you’re trying to test a new dashboard feature, but your local database is empty. You spend the next thirty minutes writing a "quick script" to generate 50 users, 100 orders, and 200 line items.

By the time you’ve mapped the user_ids to the customer_ids and handled the date-time logic, you’ve lost your flow.

This is the hidden cost of Manual Data Stitching.

The Problem: "Foreign Key Hell"

Most mock APIs or libraries provide "flat" data. You get a list of names or a list of addresses. But modern applications are relational. If you are testing a Fintech app, a "User" without a "Transaction" is useless.

Testing relational integrity usually requires:

Generating Parent records (Users).
Capturing their IDs.
Injecting those IDs into Child records (Orders).
Repeating for every nested relationship.

The Solution: Relational Seeding in One Request

The most efficient way to speed up this process is moving the relational logic to the API level. Instead of making five calls, you define the schema and let the generator handle the mapping.

Here is a conceptual example of a single-request schema that generates a User and their related Posts while maintaining integrity:

{
  "tables": [
    {
      "name": "users",
      "count": 5,
      "columns": [
        {"name": "id", "type": "uuid", "primary_key": true},
        {"name": "username", "type": "username", "locale": "en_US"}
      ]
    },
    {
      "name": "posts",
      "count": 20,
      "columns": [
        {"name": "id", "type": "uuid", "primary_key": true},
        {"name": "author_id", "type": "foreign_key", "references": "users.id"},
        {"name": "title", "type": "sentence"},
        {"name": "content", "type": "paragraph"}
      ]
    }
  ]
}

Why this changes the game:

Consistency: Every author_id in the posts table is guaranteed to exist in the users table.
Localization: You can test how a German address affects your UI layout while ensuring the user's name matches the region.
Speed: You eliminate the "middle-man" scripts in your CI/CD pipeline.

Building a "Trustable Lie"

I’ve been building a tool called BugiaData to solve this exact bottleneck. It’s a developer-first REST API specifically designed to handle these complex, multi-table datasets in a single call.
The goal was to create a "trustable lie"—synthetic data that is so high-fidelity and relationally sound that your application can't tell the difference between a seed and a real production database.
If you’re tired of manually stitching JSON files or writing seeding scripts that break every time your schema changes, give it a look. There is a Free Tier available for testing, and you can get up and running without even adding a credit card.

Check it out here: https://bugiadata.com

How are you handling complex data seeding in your current stack? Let's discuss in the comments!