What Is aimock? We Tested CopilotKit's Mock Server for Your Entire AI Stack aimock is an open source mock server from CopilotKit that lets you test AI applications without calling real APIs: it mocks LLM providers, MCP servers, A2A agents, AG UI streams, vector databases and multimedia endpoints from a single npm package on a single local port. It's MIT licensed, written in TypeScript with zero runtime dependencies, and it exists to solve a problem every AI team hits eventually: test suites that are slow, flaky and expensive because they talk to live model APIs. We installed it and ran it before writing this, and we'll tell you exactly what worked, what surprised us, and the three gotchas that cost us real debugging time. Testing for this article was run in a sandboxed Linux environment with Claude as part of our editorial workflow, and every command and output below is reproducible. Why does testing AI apps need a special mock server? A single agent request in 2026 can touch six or seven services before it returns: the LLM, an MCP tool server, a vector database for RAG, a web search API, a reranker, a moderation layer, maybe a sub agent over A2A. Most teams mock one of those and leave the rest live, which means CI burns tokens on every run and fails randomly when a provider hiccups. aimock's answer is to mock the whole chain deterministically. You define fixtures, which are match criteria plus a canned response, and the mock serves them over real HTTP on a real port. That last detail matters: unlike interceptor based tools such as MSW, it works across processes, so your app under test doesn't need any special test harness. It just points its base URL at localhost. The project started as LLMock, CopilotKit's LLM only mock, and was renamed to aimock at version 1.7.0 of the package when coverage expanded to the rest of the agentic stack. It's used in the test suites of TanStack, Mastra, OpenClaw and the AG UI protocol itself, according to the official README and CopilotKit's launch post. What happened when we installed it? The install is genuinely as small as advertised. finished in about 5 seconds, added exactly one package to , and took 8.4 MB on disk. The zero dependencies claim is literally true, everything is built on Node.js builtins. We tested version 1.38.0. Getting a mocked LLM response took four lines and one environment variable. This is the actual code we ran, using the real OpenAI SDK, not a fake client: The first response came back in 63 milliseconds, in correct OpenAI wire format, with a fake API key. Tool call fixtures also came back properly shaped, with generated IDs the SDK parsed without complaint. For a class exercise or a CI pipeline, that's the whole point: no keys, no network, no cost, no flakiness. Does aimock really mock MCP servers? Yes, and this is the part most coverage of aimock skips, so we went deepest here. runs a local MCP server speaking full JSON RPC 2.0 with session management. You register tools with , attach behavior with , and any MCP client can run the complete handshake against it: , session ID negotiation, , , with correct MCP error codes for unknown tools. What surprised us is how strict it is, in a good way. When our hand rolled test client skipped the notification after , every subsequent call failed with . That's the correct behavior per the MCP spec, and it means aimock will catch sloppy MCP clients that happen to work against more forgiving servers. If you're learning to build MCP clients or agents, that strictness is free protocol tutoring. One more detail we haven't seen mentioned anywhere: the npm package ships its own agent skill file at , a document written for AI coding agents that teaches them the fixture syntax, match fields and common patterns. If you use Claude Code or a similar agent to write your tests, it can read that file and generate correct fixtures on the first try. A testing library shipping documentation for machines as a first class artifact tells you a lot about where dev tooling is heading. What gotchas did we hit? Three, all reproducible on version 1.38.0, all cheap to avoid once you know them: 1. returns the URL; there is no property. exposes after starting, so we assumed did too. It doesn't, is and our first client crashed with . Capture the return value: . 2. Tool handlers go in , not in . We passed a function inside the definition. The tool registered fine, listed fine, and returned empty content on every call, silently, with no error. The schema belongs in ; the behavior belongs in a separate call. 3. Fixtures can't be passed as a constructor array. doesn't error, it just serves 404s for everything. Use after construction, or load them from a directory with the CLI's flag. We also verified the chaos testing works as documented. A fixture with made the OpenAI SDK throw a real with status 500, and on a streaming fixture killed the stream with an . If your agent claims to handle provider outages gracefully, this is how you prove it in