Skip to content
Mockd
Mockd
Start free
Language
Roadmap

What's live, what we're building, and what comes after

This page lists no dates. It lists the order and the honest status: what you can use today at the top, what's being worked on below it.

  • Live
  • Being built
  • Next up
  • Later

Live

Usable today, no account.

  1. A mock sandbox with no account

    One line of config and your agent is talking to a mocked MCP server. No signup, no API key, no SDK. Your agent code stays as it is.

  2. Live trace viewer

    Every tool call visible at once: tool, arguments, response, latency and status. You see what your agent did, not what it was supposed to do.

  3. Failure and latency injection

    Rate limit, timeout, empty result or extra latency on demand: the same trace shows whether your agent recovers.

  4. Faithful tool surfaces

    Names, descriptions and schemas are exactly those of the real server, not a rebuild. That text is exactly what your model decides on.

  5. State that sticks

    What your agent creates, it finds again later. A reset restores exactly the same starting state, so the second run competes fairly with the first.

Being built

Started, not shipped.

  1. Replay and comparing two runs

    Replay a run and put two traces side by side — prompt diffing. Only then can you answer whether a changed tool description really changes behaviour.

  2. Accounts and persistent sessions

    Sign in and keep your runs instead of losing them to their expiry. Login arrives as a way to keep things, not as a gate at the door.

  3. A command line for coding agents

    So an agent in CI or in your editor can start a session, test, and read the trace itself — without going through the website.

Next up

Committed, not started.

  1. Targeted failure injection

    Not one failure mode for a whole session, but a specific tool on its third call. That's what makes scenarios resemble real outages.

  2. Automatic run checks

    Right tool picked? Dangerous one avoided? Order and arguments plausible? So "nothing broke" becomes something you can check rather than feel.

  3. More mock servers

    The catalog grows past HubSpot. Which ones land first is decided by what people ask for.

  4. Trace export to OpenTelemetry

    Traces should fit the observability stack you already run, instead of living only in the viewer.

  5. Connecting your own MCP server

    Connect your real server without changing your agent config — every call recorded, just like against a mock. In stages: observe first, then review, then allow.

Later

The bigger bets. Once the demand is there.

  1. Several servers on one endpoint

    Instead of maintaining a separate connection per service, everything runs through one observed place.

  2. Server composer

    Pick per server which tools your agent gets to see at all — mocked or real, per project.

  3. Turning an API into an MCP server

    For when there's no MCP server yet, just an API you already have.

  4. Finer release rules

    Decide which actions are allowed when — the part that matters once real data flows.

Missing something?

Tell us which mock or which feature you need. What gets asked for often moves up.

Email us