Skip to content
Language
Test against reality.

The production layer for AI agents.

Every call your agent makes to a real system runs through Mockd. Simulated first, controlled always, recorded either way.

  • no login
  • no API keys
  • real tool schemas
Ask AI about Mockd

Built for the agents you already run

ClaudeOpenAICursorVS CodeLangChainVercel AI SDKn8nZedReplitClaudeOpenAICursorVS CodeLangChainVercel AI SDKn8nZedReplitClaudeOpenAICursorVS CodeLangChainVercel AI SDKn8nZedReplitClaudeOpenAICursorVS CodeLangChainVercel AI SDKn8nZedReplit

Your agent's path to production runs through here.

Your agentMockdHubSpotSalesforceSlackGitHubyour own APISoon
The path

From sandbox to production, one gate at a time

Production is the last gate, not the first test. One URL carries your agent the whole way, and each gate opens when you have seen enough. Never because a deadline said so.

  1. 01

    Point your agent at Mockd. One URL, no SDK, no code change.

    your endpoint
    mock.mock-d.com/hubspot/mcp
  2. 02

    It works against a realistic copy that remembers: records persist, failures strike on purpose.

    deal_998148 000
    written by
    crm.deals.create
    read back by
    crm.deals.get
  3. 03

    Every call is on record: what was sent, what came back, how long it took, and what it changed.

    1. crm.contacts.search142 ms
    2. crm.deals.create196 ms
    3. crm.notes.create429
    4. crm.notes.create110 ms
    0+0,8s
  4. 04

    Allow per system and per tool what the agent may do: read, write, or nothing at all.

    • crm.deals.getread
    • crm.notes.createwrite
    • crm.contacts.deleteblocked
  5. 05

    Calls reach the real system step by step. Reads first, writes when you are ready.

    Production

Control before production, the last two gates on this path.

Talk to us about early access
The problem

Know before you ship.

Your agent works. Then it touches production. It can pass every local test; the real risk starts where it uses tools and changes company data, and today the first honest test of that is production itself.

  1. It wrote to the real account

    Right tool, wrong argument. A record changes, an email goes out, a row is gone by morning. You hear about it from a customer, not from a log.

  2. When it breaks, there's no trace

    The agent messed something up. But what exactly? Which tool, which arguments, which response? Between the prompt and the side effect there's nothing to open. Debugging turns into guessing.

  3. One 429 kills ten minutes of work

    A rate limit lands mid-run. Does your agent back off and carry on, or retry the charge and pay twice? You find out in production, and never the same way twice.

  4. Four tools, none covers the path

    Tracing tools watch, but only after the fact, and without a mock. Classic API mocks don't speak MCP. Interactive MCP debuggers let you click, but keep nothing. And every step from test to live means wiring your agent up again.

Know before you ship. That takes a layer in between, a place where the agent proves it can before you hand over the keys.
FAQ

Questions, answered

Still curious? The docs go deeper on transports, scenarios and the trace API.

What exactly is a 'mock MCP server'?

It's a server that speaks the Model Context Protocol and exposes the same tools (same names, same descriptions, same schemas) as the real thing, but answers with synthetic, deterministic data instead of calling a live API. Your agent can't tell the difference; you get a safe copy and full visibility.

Do I have to change my agent's code?

No. You paste a connection config into whatever MCP client you already use: Claude, Cursor, the OpenAI Agents SDK, LangGraph, and so on. Mockd looks like any other MCP server to your agent.

How is this different from just logging tool calls myself?

Two things: the mock (you don't need the real service or its data) and the viewer (a structured, shareable trace of every call). Together they turn 'integrate, then hope' into 'test, observe, control, then go live'.

Can I test my own internal MCP server?

Not yet. Bring Your Own MCP is on the roadmap. Once it ships, you point Mockd at your server's URL and it renders the tool descriptions, proxies the calls, and records a full trace so you can tune prompts against your own tools.

Do I have to re-wire my agent to go from mock to real?

No. It's the same URL the whole way. The last two gates of the path do it in stages: Control sets what the agent may do per system and per tool, and Go live routes calls to the real server one step at a time, reads first, writes when you're ready. Both are on the roadmap.

Is the mocked data realistic?

Yes. Mocks return shaped, plausible records (real field names, IDs, relationships) so the model behaves the way it would in production, without any production data being involved.

What happens to my data?

There is nothing of yours to keep. The mocks answer from synthetic data, so a run needs no OAuth, no API key and no account. The run itself is on a clock: fifteen quiet minutes end it, two hours end it in any case, and a day after that the run and its share link are deleted.

Which servers can I mock today?

HubSpot is live now. Salesforce, Slack, Stripe, Notion, GitHub and more are next. Bring Your Own MCP is on the roadmap and will work with anything that speaks the protocol.

Agents meet reality.

Give yours a safe version of the real world, watch every call land, and decide when it is ready for the real one. No login, no API keys.