{"id":50797266,"url":"https://github.com/mcpland/mock-mcp","last_synced_at":"2026-06-12T15:32:02.445Z","repository":{"id":323899028,"uuid":"1089738499","full_name":"mcpland/mock-mcp","owner":"mcpland","description":"Mock MCP Server - AI-driven mock data orchestration with OpenAPI JSON Schema for testing","archived":false,"fork":false,"pushed_at":"2026-03-08T18:03:15.000Z","size":320,"stargazers_count":5,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-03-08T22:10:16.174Z","etag":null,"topics":["mcp-server","mock","mock-data","openapi","openapi-spec"],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mcpland.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-11-04T18:40:03.000Z","updated_at":"2026-03-08T18:03:18.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/mcpland/mock-mcp","commit_stats":null,"previous_names":["mcpland/mock-mcp"],"tags_count":9,"template":false,"template_full_name":null,"purl":"pkg:github/mcpland/mock-mcp","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mcpland%2Fmock-mcp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mcpland%2Fmock-mcp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mcpland%2Fmock-mcp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mcpland%2Fmock-mcp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mcpland","download_url":"https://codeload.github.com/mcpland/mock-mcp/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mcpland%2Fmock-mcp/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34251774,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-12T02:00:06.859Z","response_time":109,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["mcp-server","mock","mock-data","openapi","openapi-spec"],"created_at":"2026-06-12T15:32:01.823Z","updated_at":"2026-06-12T15:32:02.438Z","avatar_url":"https://github.com/mcpland.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# mock-mcp\n\n![Node CI](https://github.com/mcpland/mock-mcp/workflows/Node%20CI/badge.svg)\n[![npm](https://img.shields.io/npm/v/mock-mcp.svg)](https://www.npmjs.com/package/mock-mcp)\n![license](https://img.shields.io/npm/l/mock-mcp)\n\nMock MCP Server - AI-generated mock data based on your **OpenAPI JSON Schema** definitions. The project uses a **Daemon + Adapter** architecture that enables multiple MCP clients (Cursor, Claude Desktop, etc.) to run simultaneously without port conflicts, while providing robust claim-based concurrency control for mock batch processing.\n\n## Table of Contents\n\n- [Quick Start](#quick-start)\n- [Why Mock MCP](#why-mock-mcp)\n- [What Mock MCP Does](#what-mock-mcp-does)\n- [Architecture](#architecture)\n- [Configure MCP Server](#configure-mcp-server)\n- [Connect From Tests](#connect-from-tests)\n- [Describe Requests with Metadata](#describe-requests-with-metadata)\n- [MCP Tools](#mcp-tools)\n- [CLI Commands](#cli-commands)\n- [Available APIs](#available-apis)\n- [Environment Variables](#environment-variables)\n- [How It Works](#how-it-works)\n- [Use the development scripts](#use-the-development-scripts)\n- [License](#license)\n\n## Quick Start\n\n1. **Install the package.** Add mock-mcp as a dev dependency inside your project.\n\n```bash\nnpm install -D mock-mcp\n# or\nyarn add -D mock-mcp\n# or\npnpm add -D mock-mcp\n```\n\n2. **Configure the Model Context Protocol server.** Add mock-mcp to your MCP client configuration (Cursor, Claude Desktop, etc.):\n\n```json\n{\n  \"mcpServers\": {\n    \"mock-mcp\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mock-mcp@latest\", \"adapter\"]\n    }\n  }\n}\n```\n\n\u003e **Note:** The `adapter` command connects to a shared daemon process that is automatically started when needed. This eliminates port conflicts when running multiple MCP clients simultaneously.\n\n3. **Connect from your tests.** Use `connect` to retrieve a mock client and request data for intercepted calls.\n\n```ts\nimport { render, screen, fireEvent } from \"@testing-library/react\";\nimport { connect } from \"mock-mcp\";\n\nconst userSchema = {\n  summary: \"Fetch the current user\",\n  response: {\n    type: \"object\",\n    required: [\"id\", \"name\"],\n    properties: {\n      id: { type: \"number\" },\n      name: { type: \"string\" },\n    },\n  },\n};\n\nit(\"example\", async () =\u003e {\n  const mockClient = await connect();\n  const metadata = {\n    schemaUrl: \"https://example.com/openapi.json#/paths/~1user/get\",\n    schema: userSchema,\n    instructions: \"Respond with a single user described by the schema.\",\n  };\n\n  fetchMock.get(\"/user\", async () =\u003e {\n    const response = await mockClient.requestMock(\"/user\", \"GET\", { metadata }) // add mock via mock-mcp\n    return response.data\n  });\n\n  const result = await fetch(\"/user\");\n  const data = await result.json();\n  expect(data).toEqual({ id: 1, name: \"Jane\" });\n}, 10 * 60 * 1000); // 10 minute timeout for AI interaction\n```\n\n4. **Run with MCP enabled.** Prompt your AI client to run the persistent test command and provide mocks through the tools.\n\n```\nPlease run the persistent test: `MOCK_MCP=true npm test test/example.test.tsx` and mock fetch data with mock-mcp\n```\n\n## Why Mock MCP\n\n### The Problem with Traditional Mock Approaches\n\nTesting modern web applications often feels like preparing for a battle—you need the right weapons (test cases), ammunition (mock data), and strategy (test logic). But creating mock data has always been the most tedious part:\n\n```typescript\n// Traditional approach: Manual fixture hell\nconst mockUsers = [\n  { id: 1, name: \"Alice\", email: \"alice@example.com\", role: \"admin\", ... },\n  { id: 2, name: \"Bob\", email: \"bob@example.com\", role: \"user\", ... },\n  // ... 50 more lines of boring manual data entry\n];\n```\n\n**Common Pain Points:**\n\n| Challenge                   | Traditional Solutions           | Limitations                                 |\n| --------------------------- | ------------------------------- | ------------------------------------------- |\n| **Creating Realistic Data** | Manual JSON files or faker.js   | ❌ Time-consuming, lacks business logic     |\n| **Complex Scenarios**       | Hardcoded edge cases            | ❌ Difficult to maintain, brittle           |\n| **Evolving Requirements**   | Update fixtures manually        | ❌ High maintenance cost                    |\n| **Learning Curve**          | New team members write fixtures | ❌ Steep learning curve for complex domains |\n| **CI/CD Integration**       | Static fixtures only            | ❌ Can't adapt to new scenarios             |\n\n### The Mock MCP Innovation\n\nMock MCP introduces a **paradigm shift**: instead of treating mock data as static artifacts, it makes them **AI-generated, interactive, and evolvable**.\n\n```\nTraditional:  Write Test → Create Fixtures → Run Test → Maintain Fixtures\n                                ↑                          ↓\n                                └──────── Pain Loop ───────┘\n\nMock MCP:     Write Test → AI Generates Data (Schema-Compliant) → Run Test → Solidify Code\n                             ↑                                    ↓\n                             └───────────── Evolution ────────────┘\n```\n\n### Schema-Driven Accuracy\n\nUnlike \"hallucinated\" mocks, Mock MCP uses your actual **OpenAPI JSON Schema** definitions to ground the AI. This ensures that generated data not only looks real but strictly adheres to your API contracts, catching integration issues early.\n\n## What Mock MCP Does\n\nMock MCP uses a **Daemon + Adapter** architecture to move intercepted requests from tests to AI helpers and back again.\n\n- **Schema-aware generation** uses your provided metadata (OpenAPI JSON Schema) to ensure mocks match production behavior.\n- **Batch-aware test client** collects every network interception inside a single macrotask and waits for the full response set.\n- **Claim-based concurrency** prevents multiple AI clients from racing on the same batch through lease-based locking.\n- **Multi-run isolation** supports concurrent test processes with distinct run IDs.\n- **IPC-based communication** uses Unix Domain Sockets (macOS/Linux) or Named Pipes (Windows) instead of TCP ports, eliminating port conflicts.\n- **Timeouts, TTLs, and cleanup** guard the test runner from stale batches or disconnected clients.\n\n## Architecture\n\nThe v0.4.0 release introduces a new **Daemon + Adapter** architecture that fundamentally solves the \"multiple MCP clients\" problem:\n\n```\n┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐\n│   Test Process  │     │     Daemon      │     │    Adapter      │\n│  (your tests)   │────▶│  (per-project)  │◀────│  (per MCP client)│\n└─────────────────┘     └─────────────────┘     └─────────────────┘\n        │                       │                       │\n        │  WebSocket/IPC        │  JSON-RPC/IPC         │  MCP stdio\n        │                       │                       │\n        ▼                       ▼                       ▼\n   BatchMockCollector     Mock Bridge Daemon      MCP Tools\n   - Auto-discovers       - Manages runs/batches  - claim_next_batch\n   - Sends batches        - Claim/lease control   - provide_batch_mock_data\n   - Receives mocks       - Multi-client safe     - get_status, list_runs\n```\n\n**Key Benefits:**\n\n- Single daemon per project (no per-client server instances)\n- IPC communication\n- Full multi-client support\n- Claim-based concurrency (no race conditions)\n- Auto-discovery (no manual configuration)\n\n## Configure MCP Server\n\nAdd mock-mcp to your MCP client configuration. The adapter automatically discovers or starts the daemon for your project:\n\n```json\n{\n  \"mcpServers\": {\n    \"mock-mcp\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mock-mcp\", \"adapter\"]\n    }\n  }\n}\n```\n\n**That's it!** The daemon uses IPC (Unix Domain Sockets on macOS/Linux, Named Pipes on Windows) which:\n\n- Eliminates port conflicts between multiple MCP clients\n- Automatically shares state between all adapters in the same project\n- Requires no manual coordination or environment variables\n\nRestart your MCP client and confirm that the `mock-mcp` server exposes the tools (`get_status`, `claim_next_batch`, `provide_batch_mock_data`, etc.).\n\n## Connect From Tests\n\nTests call `connect` to spin up a `BatchMockCollector` that automatically discovers and connects to the daemon:\n\n```ts\n// tests/mocks.ts\nimport { connect } from \"mock-mcp\";\n\n// Auto-discovers daemon via IPC\nconst mockClient = await connect({\n  timeout: 60000,\n});\n\nawait page.route(\"**/api/users\", async (route) =\u003e {\n  const url = new URL(route.request().url());\n  const { data } = await mockClient.requestMock(\n    url.pathname,\n    route.request().method()\n  );\n\n  await route.fulfill({\n    status: 200,\n    contentType: \"application/json\",\n    body: JSON.stringify(data),\n  });\n});\n```\n\nBatch behaviour stays automatic: additional `requestMock` calls issued in the same macrotask are grouped, forwarded, and resolved together.\n\nNeed to pause the test until everything in-flight resolves? Call `waitForPendingRequests` to block on the current set of pending requests (anything started after the call is not included):\n\n```ts\n// After routing a few requests\nawait mockClient.waitForPendingRequests();\n// Safe to assert on the results produced by the mocked responses\n```\n\n**Multiple test processes** can run concurrently - each gets a unique `runId` and their batches are isolated from each other.\n\n## Describe Requests with Metadata\n\n`requestMock` accepts an optional third argument (`RequestMockOptions`) that is forwarded without modification to the MCP server. The most important field in that object is `metadata`, which lets the test process describe each request with the exact OpenAPI JSON Schema fragment, sample payloads, or test context that the AI client needs to build a response.\n\nWhen an MCP client calls `get_pending_batches`, every `requests[].metadata` entry from the test run is included in the response. That is the channel the LLM uses to understand the requested endpoint before supplying data through `provide_batch_mock_data`. Metadata is also persisted when batch logging is enabled, so you can audit what was sent to the model.\n\n```ts\nconst listProductsSchema = {\n  summary: \"List products by popularity\",\n  response: {\n    type: \"array\",\n    items: {\n      type: \"object\",\n      required: [\"id\", \"name\", \"price\"],\n      properties: {\n        id: { type: \"string\" },\n        name: { type: \"string\" },\n        price: { type: \"number\" },\n      },\n    },\n  },\n};\n\nawait mockClient.requestMock(\"/api/products\", \"GET\", {\n  metadata: {\n    // Link or embed the authoritative contract for the AI to follow.\n    schemaUrl:\n      \"https://shop.example.com/openapi.json#/paths/~1api~1products/get\",\n    schema: listProductsSchema,\n    instructions:\n      \"Return 3 popular products with stable ids so the UI can snapshot them.\",\n    testFile: expect.getState().testPath,\n  },\n});\n```\n\n**Tips for useful metadata**\n\n- Embed the OpenAPI/JSON Schema snippet (or a reference URL) that describes the response structure for the intercepted endpoint.\n- Include contextual hints such as the test name, scenario, user role, or seed data so the model can mirror your expected fixtures.\n- Keep the metadata JSON-serializable and deterministic; large binary blobs or class instances will be dropped.\n- Reuse helper functions to centralize schema definitions so each test only supplies the endpoint-specific instructions.\n\n## MCP Tools\n\nThe new architecture provides a richer set of tools with claim-based concurrency control:\n\n| Tool                      | Purpose                                         | Input                                      |\n| ------------------------- | ----------------------------------------------- | ------------------------------------------ |\n| `get_status`              | Get daemon status (runs, pending, claimed)      | None                                       |\n| `list_runs`               | List all active test runs                       | None                                       |\n| `claim_next_batch`        | Claim the next pending batch (with lease)       | `{ runId?, leaseMs? }`                     |\n| `get_batch`               | Get details of a specific batch (read-only)     | `{ batchId }`                              |\n| `provide_batch_mock_data` | Provide mock data for a claimed batch           | `{ batchId, claimToken, mocks }`           |\n| `release_batch`           | Release a claimed batch without providing mocks | `{ batchId, claimToken, reason? }`         |\n\n### Workflow\n\nThe new workflow uses **claim → provide** to prevent race conditions:\n\n1. **Claim a batch** - Call `claim_next_batch` to acquire a lease on a pending batch\n2. **Receive batch details** - Get `batchId`, `claimToken`, and `requests` array\n3. **Generate mocks** - Create mock responses for each request\n4. **Provide mocks** - Call `provide_batch_mock_data` with the claim token\n\n```jsonc\n// Step 1: Claim\n{\n  \"name\": \"claim_next_batch\",\n  \"arguments\": { \"leaseMs\": 30000 }\n}\n// Returns: { \"batchId\": \"batch:abc:1\", \"claimToken\": \"xyz\", \"requests\": [...] }\n\n// Step 2: Provide\n{\n  \"name\": \"provide_batch_mock_data\",\n  \"arguments\": {\n    \"batchId\": \"batch:abc:1\",\n    \"claimToken\": \"xyz\",\n    \"mocks\": [\n      { \"requestId\": \"req-1\", \"data\": { \"id\": 1, \"name\": \"Alice\" } }\n    ]\n  }\n}\n```\n\n**Lease expiration**: If you don't provide mocks within the lease time (default 30s), the batch is automatically released for another adapter to claim.\n\n## CLI Commands\n\n| Command             | Description                                           |\n| ------------------- | ----------------------------------------------------- |\n| `mock-mcp adapter`  | Start the MCP adapter (default, for MCP clients)      |\n| `mock-mcp daemon`   | Start the daemon process (usually auto-started)       |\n| `mock-mcp status`   | Show daemon status for current project                |\n| `mock-mcp stop`     | Stop the daemon for current project                   |\n| `mock-mcp help`     | Show help                                             |\n| `mock-mcp version`  | Show version                                          |\n\nExample usage:\n\n```bash\n# Check if daemon is running\nmock-mcp status\n\n# Manually stop daemon\nmock-mcp stop\n```\n\n## Available APIs\n\nThe library exports primitives so you can embed the workflow inside bespoke runners or scripts:\n\n### Client APIs\n\n- `connect(options?)` - Creates a `BatchMockCollector` and waits for daemon connection.\n- `BatchMockCollector` - Low-level batching client for test environments.\n- `BatchMockCollector.requestMock(endpoint, method, options?)` - Request mock data for an endpoint.\n- `BatchMockCollector.waitForPendingRequests()` - Wait for pending requests to settle.\n- `BatchMockCollector.getRunId()` - Get the unique run ID for this collector.\n\n### Server APIs\n\n- `MockMcpDaemon` - The daemon process that manages runs and batches.\n- `runAdapter()` - Start the MCP adapter (stdio transport).\n- `DaemonClient` - JSON-RPC client for communicating with the daemon.\n\n### Discovery APIs\n\n- `ensureDaemonRunning(options?)` - Ensure daemon is running, start if needed.\n- `resolveProjectRoot(startDir?)` - Find project root by searching for `.git` or `package.json`.\n- `computeProjectId(projectRoot)` - Compute stable project ID from path.\n\nEach class accepts logger overrides, timeout tweaks, and other ergonomics.\n\n## Environment Variables\n\n| Variable             | Description                                                              | Default            |\n| -------------------- | ------------------------------------------------------------------------ | ------------------ |\n| `MOCK_MCP`           | Enables the test runner hook so intercepted requests are routed to mock-mcp. | unset              |\n| `MOCK_MCP_CACHE_DIR` | Override the cache directory for daemon files (registry, socket, lock). | `~/.cache/mock-mcp`|\n\n## How It Works\n\nThe new **Daemon + Adapter** architecture uses four collaborating processes:\n\n| Process          | Responsibility                                        | Technology                               | Communication                   |\n| ---------------- | ----------------------------------------------------- | ---------------------------------------- | ------------------------------- |\n| **Test Process** | Executes test cases and intercepts HTTP requests      | Playwright/Puppeteer + BatchMockCollector| WebSocket over IPC → Daemon     |\n| **Daemon**       | Manages runs, batches, claims with lease control      | Node.js + HTTP/WS on Unix socket         | IPC ↔ Test \u0026 Adapter            |\n| **Adapter**      | Bridges MCP protocol to daemon RPC                    | Node.js + MCP SDK (stdio)                | stdio ↔ MCP Client, RPC → Daemon|\n| **MCP Client**   | Uses AI to produce mock data via MCP tools            | Cursor / Claude Desktop / custom clients | MCP protocol → Adapter          |\n\n### Data flow sequence with claim-based concurrency\n\n```\n┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐\n│  Test Process    │      │     Daemon       │      │     Adapter      │      │   MCP Client     │\n│  (Browser Test)  │      │  (per-project)   │      │ (per MCP client) │      │      (AI)        │\n└────────┬─────────┘      └────────┬─────────┘      └────────┬─────────┘      └────────┬─────────┘\n         │                         │                         │                         │\n         │  1. Connect via IPC     │                         │                         │\n         │     HELLO_TEST          │                         │                         │\n         ├════════════════════════►│                         │                         │\n         │                         │                         │                         │\n         │  2. HELLO_ACK           │                         │                         │\n         │◄════════════════════════┤                         │                         │\n         │                         │                         │                         │\n         │  3. BATCH_MOCK_REQUEST  │                         │                         │\n         │     [req-1, req-2, ...] │                         │                         │\n         ├════════════════════════►│                         │                         │\n         │                         │                         │                         │\n         │     Test paused...      │  4. Store in pending    │                         │\n         │       Awaiting mocks    │     queue               │                         │\n         │                         │                         │                         │\n         │                         │                         │◄────────────────────────┤\n         │                         │                         │  5. claim_next_batch    │\n         │                         │                         │                         │\n         │                         │◄────────────────────────┤                         │\n         │                         │  6. RPC: claimNextBatch │                         │\n         │                         │                         │                         │\n         │                         ├────────────────────────►│                         │\n         │                         │  7. {batch, claimToken} │                         │\n         │                         │                         │                         │\n         │                         │                         ├────────────────────────►│\n         │                         │                         │  8. Return batch info   │\n         │                         │                         │                         │\n         │                         │                         │        9. AI generates  │\n         │                         │                         │           mock data     │\n         │                         │                         │                         │\n         │                         │                         │◄────────────────────────┤\n         │                         │                         │  10. provide_batch_     │\n         │                         │                         │      mock_data          │\n         │                         │                         │                         │\n         │                         │◄────────────────────────┤                         │\n         │                         │  11. RPC: provideBatch  │                         │\n         │                         │      + claimToken       │                         │\n         │                         │                         │                         │\n         │  12. BATCH_MOCK_RESULT  │                         │                         │\n         │      [mock-1, mock-2]   │                         │                         │\n         │◄════════════════════════┤                         │                         │\n         │                         │                         │                         │\n         │  13. Resolve promises   │                         │                         │\n         │      Test continues     │                         │                         │\n         ▼                         ▼                         ▼                         ▼\n\nProtocol Summary:\n─────────────────\n- Test Process ←→ Daemon: WebSocket over IPC (Unix socket / Named pipe)\n  Message types: HELLO_TEST, BATCH_MOCK_REQUEST, BATCH_MOCK_RESULT\n\n- Adapter ←→ Daemon: HTTP JSON-RPC over IPC\n  Methods: claimNextBatch, provideBatch, getStatus, listRuns\n\n- MCP Client ←→ Adapter: MCP protocol (stdio)\n  Tools: claim_next_batch, provide_batch_mock_data, get_status, list_runs\n\nKey Features:\n──────────────\n✓ uses IPC instead of TCP - No port conflicts\n✓ Multi-client support - multiple MCP clients can run simultaneously\n✓ Claim-based concurrency - prevents race conditions on batches\n✓ Lease expiration - auto-recovery if adapter crashes\n✓ Multi-run isolation - concurrent test processes are isolated\n✓ Auto-discovery - no manual configuration needed\n```\n\n## Use the development scripts\n\n```bash\nyarn test              # runs Vitest suites\nyarn test:concurrency  # runs concurrency tests specifically\nyarn dev               # tsx watch mode for the CLI\nyarn dev:adapter       # tsx watch mode for adapter\nyarn lint              # eslint --ext .ts\nyarn build             # compile TypeScript\n```\n\nTests create isolated daemon instances with temporary cache directories, so they can run safely without affecting your development environment.\n\n## License\n\nMIT\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmcpland%2Fmock-mcp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmcpland%2Fmock-mcp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmcpland%2Fmock-mcp/lists"}