---
name: mockito
description: Create mock APIs from TypeScript interfaces, OpenAPI specs, or natural language descriptions using Mockito. Use this skill when building frontend apps before the backend exists, or when you need to test against realistic API responses.
---

# Mockito - Mock API Creation

Create mock APIs instantly while developing applications. This skill helps you mock backend APIs before they exist, enabling frontend-first development.

## When to Use This Skill

- Building a frontend before the backend is ready
- Need to test against realistic API responses
- Want to simulate third-party APIs
- Converting TypeScript types to working mock endpoints
- Prototyping API designs quickly

## Prerequisites

The Mockito MCP server must be configured. Add this to your Claude Code MCP settings:

```json
{
  "inputs": [
    {
      "type": "promptString",
      "id": "mockito-api-key",
      "description": "Enter your Mockito API Key (get one at dotmock.com/settings/api-keys)",
      "password": true
    }
  ],
  "mcpServers": {
    "mockito": {
      "type": "sse",
      "url": "https://mcp.dotmock.com/sse",
      "headers": {
        "X-API-Key": "${input:mockito-api-key}"
      }
    }
  }
}
```

## Workflow

### Step 1: Analyze the Codebase

First, search for API-related code:

1. **TypeScript interfaces/types** - Data models that represent API responses
2. **OpenAPI/Swagger specs** - Existing API documentation (*.yaml, *.yml, *.json)
3. **API client code** - Fetch calls, axios requests, or API client files

### Step 2: Generate or Validate OpenAPI Spec

Based on what you find:

**If TypeScript interfaces exist:**
Use the `analyze_typescript` MCP tool to convert them to OpenAPI schemas with CRUD endpoints.

**If OpenAPI spec exists:**
Use the `analyze_openapi` MCP tool to validate and analyze it.

**If neither exists:**
Use the `generate_api` MCP tool with a natural language description.

### Step 3: Create the Mock API

Use the `create_api` MCP tool with the OpenAPI specification to create the mock.

### Step 4: Update Application Config

Help update the application to use the mock URL:
- Set environment variables (e.g., `NEXT_PUBLIC_API_URL`)
- Update API client base URL
- Add development/production conditional logic if needed

## Available MCP Tools

| Tool | Purpose |
|------|---------|
| `create_api` | Create a mock API with OpenAPI spec |
| `list_apis` | List all mock APIs for the team |
| `get_api` | Get details of a specific API |
| `update_api` | Update API configuration |
| `delete_api` | Delete a mock API |
| `configure_endpoint` | Configure custom endpoint responses |
| `list_endpoints` | List all endpoints for an API |
| `get_endpoint` | Get endpoint configuration |
| `generate_api` | AI-generate OpenAPI from description |
| `analyze_typescript` | Convert TypeScript to OpenAPI |
| `analyze_openapi` | Validate existing OpenAPI spec |
| `get_traffic_logs` | Get request logs for debugging |
| `get_api_stats` | Get usage statistics |

## Examples

### Example 1: Create Mock from TypeScript Interfaces

**User request:** "Create a mock API for my User and Product types"

**Workflow:**
1. Search for TypeScript files with interface/type definitions
2. Read the relevant files (e.g., `src/types/user.ts`, `src/types/product.ts`)
3. Call `analyze_typescript` with the code content
4. Call `create_api` with the generated OpenAPI spec
5. Return the mock URL (e.g., `https://my-api-abc123.mock.rest`)

### Example 2: Create Mock from OpenAPI File

**User request:** "Create a mock from our api-spec.yaml"

**Workflow:**
1. Read the OpenAPI specification file
2. Call `analyze_openapi` to validate and extract info
3. Call `create_api` with the spec
4. Return the mock URL

### Example 3: Create Mock from Description

**User request:** "I need a mock API for a todo app with tasks and users"

**Workflow:**
1. Call `generate_api` with the description
2. Review the generated spec with the user
3. Call `create_api` with the spec
4. Return the mock URL

### Example 4: Configure Custom Response

**User request:** "Make the GET /users endpoint return an error for testing"

**Workflow:**
1. Call `list_apis` to find the API
2. Call `configure_endpoint` with custom error response:
   ```json
   {
     "apiId": "...",
     "method": "GET",
     "path": "/users",
     "config": {
       "statusCode": 500,
       "body": { "error": "Internal server error" }
     }
   }
   ```

## TypeScript to OpenAPI Conversion

When analyzing TypeScript, follow these conversion rules:

| TypeScript | OpenAPI Schema |
|------------|----------------|
| `string` | `{ type: "string" }` |
| `number` | `{ type: "number" }` |
| `boolean` | `{ type: "boolean" }` |
| `Date` | `{ type: "string", format: "date-time" }` |
| `Array<T>` / `T[]` | `{ type: "array", items: <T> }` |
| `T \| null` | Add `nullable: true` |
| `prop?: T` | Not in `required` array |
| `enum { A, B }` | `{ enum: ["A", "B"] }` |
| `Record<string, T>` | `{ type: "object", additionalProperties: <T> }` |

### Generated Endpoints

For each entity type (e.g., `User`), generate:

| Endpoint | Method | Description |
|----------|--------|-------------|
| `/users` | GET | List all users |
| `/users` | POST | Create a user |
| `/users/{id}` | GET | Get user by ID |
| `/users/{id}` | PUT | Update user |
| `/users/{id}` | DELETE | Delete user |

## Mock Data Templates

Mockito supports dynamic mock data using template functions:

| Template | Output |
|----------|--------|
| `{{uuid()}}` | Random UUID |
| `{{randomEmail()}}` | Random email address |
| `{{randomName()}}` | Random full name |
| `{{randomInt(1, 100)}}` | Random integer in range |
| `{{now()}}` | Current ISO timestamp |
| `{{now("iso")}}` | Current ISO timestamp |
| `{{lorem(5)}}` | 5 words of lorem ipsum |
| `{{randomPhone()}}` | Random phone number |

Example response body:
```json
{
  "id": "{{uuid()}}",
  "email": "{{randomEmail()}}",
  "name": "{{randomName()}}",
  "createdAt": "{{now()}}"
}
```

## Best Practices

1. **Prefer existing code** - Always analyze TypeScript/OpenAPI files before generating from scratch
2. **Match naming conventions** - Use the project's existing naming style for endpoints
3. **Include error responses** - Add 400, 401, 404, 500 responses for realistic testing
4. **Use realistic data** - Leverage template functions for dynamic mock data
5. **Keep specs focused** - Only include endpoints needed for current development

## Troubleshooting

**"API key required" error:**
Ensure the MCP server is configured with a valid API key from dotmock.com/settings/api-keys

**"Plan limit exceeded" error:**
The team has reached their plan's API limit. Check `get_plan_info` for current usage.

**Mock not returning expected data:**
Use `get_endpoint` to check the current configuration, then `configure_endpoint` to update it.