mockd is a versatile multi-protocol mock server for API simulation, testing, and development — with stateful data, chaos engineering, and AI-native tooling.
Multi-protocol Mocking: Create, retrieve, update, delete, list, and toggle mock endpoints for HTTP/HTTPS, gRPC, GraphQL, WebSocket, MQTT, SSE, SOAP, and OAuth — with request matching rules (path, method, headers, query params) and configurable responses.
Stateful Resource Management: Define and interact with CRUD collections (stateful tables) that persist data across requests — add items, list/get items, and reset to seed data.
Custom Operations: Register, list, retrieve, delete, and execute custom operations on stateful resources with defined steps and response logic.
Import/Export: Import mock definitions from OpenAPI specs, Postman collections, HAR files, WireMock stubs, cURL commands, or WSDL; export current mocks as YAML or JSON for backup or version control.
Chaos Engineering: Configure fault injection with latency, error rates, bandwidth throttling, and advanced stateful faults (circuit breakers, retry-after, progressive degradation, chunked dribble) — or apply named profiles like slow-api, flaky, or offline. Reset stats and manually trip/reset circuit breakers.
Request Logging & Verification: Capture and filter request/response logs, identify unmatched requests with near-miss analysis, verify mock invocation counts (exact, at-least, at-most), and reset verification data between test runs.
Workspace Management: Organize mocks into isolated environments, keeping configurations, state, and logs separate per project or scenario.
Server Administration: Get server health, active ports, statistics, and manage server contexts to communicate with different mockd instances.
Proxy Recording & Cloud Tunneling: Record live traffic for replay as mocks, and share local mocks publicly via secure cloud tunnels.
AI Integration (MCP): Acts as an AI-native server via the Model Context Protocol, exposing 18 tools so AI agents can create and manage mocks programmatically.
Web Dashboard: Visual interface for managing mocks and viewing request logs via a dedicated admin port.
Allows importing cURL commands to instantly generate mock API definitions.
Provides tools for mocking GraphQL APIs, including operation-specific matching and response definitions.
Provides a built-in MQTT broker for mocking messaging topics and payloads.
Enables importing Postman collections to automatically create functional mock servers.
Supports importing OpenAPI and Swagger 2.0 specifications to generate mock API structures.
Supports mocking XML-based protocols such as SOAP and defining XML response bodies.
Uses YAML for mock configuration, environment setup, and importing/exporting API definitions.
# Install
curl -sSL https://get.mockd.io | sh
# Start + create a stateful CRUD API in one command
mockd start
mockd add http --path /api/users --stateful users
# It works immediately
curl -X POST localhost:4280/api/users -d '{"name":"Alice","email":"alice@test.com"}'
# → {"id":"a1b2c3","name":"Alice","email":"alice@test.com"}
curl localhost:4280/api/users
# → {"data":[{"id":"a1b2c3","name":"Alice","email":"alice@test.com"}],"meta":{"total":1}}brew install getmockd/tap/mockd # Homebrew
docker run -p 4280:4280 -p 4290:4290 ghcr.io/getmockd/mockd:latest # Docker
go install github.com/getmockd/mockd/cmd/mockd@latest # GoPre-built binaries for Linux, macOS, and Windows on the Releases page.
Related MCP server: Mock MCP Server
Every other mock tool makes you choose: pick one protocol, install a runtime, bolt on extensions. mockd doesn't.
mockd | WireMock | Mockoon | Prism | MockServer | Beeceptor | json-server | |
Single binary, no runtime | ✅ | ❌ JVM | ❌ Electron | ✅ | ❌ JVM | ❌ SaaS | ❌ Node |
All 9 protocols built-in | ✅ | 🔌 Ext | Partial | HTTP only | HTTP only | Partial | REST only |
Chaos profiles + circuit breakers | ✅ | ⚠️ Cloud | ❌ | ❌ | ❌ | ❌ | ❌ |
MCP server | ✅ local | ⚠️ Cloud | ❌ | ❌ | ❌ | ⚠️ Cloud, Team+ | ❌ |
Free + self-hostable, unlimited | ✅ | ✅ | ✅ | ✅ | ✅ | 50 req/day | ✅ |
🔌 Ext = requires separate extension JAR • ⚠️ Cloud = only in paid/hosted tier
mockd | WireMock | Mockoon | Prism | MockServer | Beeceptor | json-server | |
Native single binary | ✅ Go | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Runtime required | none | JVM | Electron/Node | optional Node | JVM | n/a (SaaS) | Node |
Docker image | ✅ | ✅ | ✅ CLI | ✅ | ✅ | ⚠️ Enterprise | ❌ |
Managed SaaS offering | roadmap | WireMock Cloud | Mockoon Cloud | Stoplight | ❌ | ✅ | ❌ |
mockd | WireMock OSS | Mockoon | Prism | MockServer | Beeceptor | json-server | |
REST / HTTP | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
gRPC | ✅ | 🔌 Ext | ❌ | ❌ | ❌ | ✅ | ❌ |
GraphQL | ✅ | 🔌 Ext | ❌ | ❌ | ❌ | ✅ | ❌ |
WebSocket | ✅ | 🔌 Ext (beta) | ✅ | ❌ | ❌ | ❌ | ❌ |
MQTT | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
SSE | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
SOAP (WSDL) | ✅ | ❌ | Partial | ❌ | Partial | ✅ | ❌ |
mTLS | ✅ | ✅ | Partial | ❌ | ✅ | ✅ | ❌ |
OAuth flows | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
mockd | WireMock OSS | Mockoon | Prism | MockServer | Beeceptor | json-server | |
Stateful CRUD | ✅ | ❌ | ✅ | Partial | ❌ | ✅ | ✅ |
Multi-step stateful flows | ✅ | ✅ Scenarios | Partial | ❌ | Partial | ✅ | ❌ |
Fault injection (delay, errors) | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ |
Chaos profiles | ✅ | ⚠️ Cloud | ❌ | ❌ | ❌ | ❌ | ❌ |
Circuit breakers | ✅ | ⚠️ Cloud | ❌ | ❌ | ❌ | ❌ | ❌ |
Bandwidth throttling | ✅ | ❌ | ❌ | ❌ | ❌ | roadmap | ❌ |
Admin REST API | ✅ | ✅ | CLI only | ❌ | ✅ | ✅ | Partial |
Built-in web dashboard | ✅ | ⚠️ Cloud | ⚠️ Cloud | ❌ | ✅ read-only | ✅ | ❌ |
Native desktop GUI | ❌ | ❌ | ✅ Electron | ❌ | ❌ | ❌ | ❌ |
MCP server | ✅ local | ⚠️ Cloud | ❌ | ❌ | ❌ | ⚠️ Cloud Team+ | ❌ |
Cloud tunnel sharing | ✅ | ❌ | ⚠️ Cloud | ❌ | ❌ | ✅ | ❌ |
mockd | WireMock OSS | Mockoon | Prism | MockServer | Beeceptor | json-server | |
OpenAPI import | ✅ | ⚠️ Cloud | ✅ | ✅ | ✅ | ✅ | ❌ |
Postman import | ✅ | ⚠️ Cloud | ❌ | ✅ | ❌ | ❌ | ❌ |
HAR import | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
WSDL import | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
cURL import | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
WireMock format import | ✅ | native | ❌ | ❌ | ❌ | ❌ | ❌ |
Mockoon format import | ✅ | ❌ | native | ❌ | ❌ | ❌ | ❌ |
HAR export | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ |
Requests | Mock rules | Cost | |
mockd | unlimited | unlimited | free (Apache 2.0) |
WireMock OSS | unlimited | unlimited | free (Apache 2.0) |
Mockoon desktop / CLI | unlimited | unlimited | free (MIT) |
Prism | unlimited | unlimited | free (Apache 2.0) |
MockServer | unlimited | unlimited | free (Apache 2.0) |
Beeceptor free tier | 50 / day / endpoint | 3 | $10/mo+ for more |
json-server | unlimited | unlimited | free (MIT) |
Legend: ✅ built-in • 🔌 Ext = separate OSS extension • ⚠️ Cloud = only in paid / hosted tier • Partial = limited implementation • roadmap = on the project's stated roadmap, not yet shipped
Note on WireMock imports. The
⚠️ Cloudmarks on OpenAPI and Postman import reflect first-party WireMock features. Community converters exist (e.g.openapi-to-wiremock, OpenAPI Generator targets) but are not bundled with the OSS standalone JAR.
Import a real API spec, bind it to stateful tables, and get a mock that passes the real SDK:
# mockd.yaml — Stripe digital twin
version: "1.0"
imports:
- path: stripe-openapi.yaml
as: stripe
tables:
- name: customers
idStrategy: prefix
idPrefix: "cus_"
seedData:
- { id: "cus_1", name: "Acme Corp", email: "billing@acme.com" }
extend:
- { mock: stripe.GetCustomers, table: customers, action: list }
- { mock: stripe.PostCustomers, table: customers, action: create }
- { mock: stripe.GetCustomersCustomer, table: customers, action: get }
- { mock: stripe.PostCustomersCustomer, table: customers, action: update }
- { mock: stripe.DeleteCustomersCustomer, table: customers, action: delete }mockd start -c mockd.yaml --no-auth
curl -X POST localhost:4280/v1/customers -d "name=Test&email=test@corp.com"
# → {"id":"cus_a1b2c3","object":"customer","name":"Test","email":"test@corp.com"}Validated with real SDKs:
Stripe: 49/49 stripe-go SDK tests pass
Twilio: 13/13 twilio-go SDK tests pass
OpenAI: openai Python SDK verified (models, assistants, chat completions)
See mockd-samples for complete digital twin configs.
mockd includes a built-in Model Context Protocol server with 18 tools. AI agents can create mocks, manage state, import specs, and verify contracts without touching the CLI:
{
"mcpServers": {
"mockd": { "command": "mockd", "args": ["mcp"] }
}
}Works in Claude Desktop, Cursor, Windsurf, and any MCP-compatible editor. Tools cover mock CRUD, stateful resources, chaos injection, request logs, verification, workspaces, and import/export.
Protocol | Port | Example |
HTTP/HTTPS | 4280 |
|
gRPC | 50051 |
|
GraphQL | 4280 |
|
WebSocket | 4280 |
|
MQTT | 1883 |
|
SSE | 4280 |
|
SOAP | 4280 |
|
mockd import openapi.yaml # OpenAPI 3.x / Swagger 2.0
mockd import collection.json # Postman collections
mockd import recording.har # HAR files
mockd import wiremock-mapping.json # WireMock stubs
mockd import service.wsdl # WSDL → SOAP mocks
mockd import "curl -X GET https://api.example.com/users" # cURL commands
mockd export --format yaml > mocks.yamlmockd chaos apply flaky # 30% error rate
mockd chaos apply slow-api # 200-800ms latency
mockd chaos apply offline # 100% 503 errors
mockd chaos disablemockd tunnel
# → https://a1b2c3d4.tunnel.mockd.io → http://localhost:4280All 7 protocols multiplexed through a single secure connection on port 443. Works behind NAT and firewalls.
mockd workspace create -n "Payment API" --use
mockd import stripe-openapi.yaml
mockd workspace create -n "Comms API" --use
mockd import twilio-openapi.yaml
# Mocks, state, and logs are fully isolated per workspacemockd proxy start --port 8888
# Configure your app to use http://localhost:8888 as proxy
# Traffic is recorded, then replay with:
mockd import recordings/session.jsonRelease builds serve a web UI from the admin port (http://localhost:4290). VS Code-style editor, command palette, mock tree with folders, request log viewer, and near-miss debugging.
mockd works fully offline with no account required. For teams that want shared environments:
Persistent cloud mocks — deploy mock environments your whole team can hit
Team management — shared workspaces with access controls
Cloud tunnels — authenticated tunnels with custom domains
Coming soon. Join the waitlist.
Full guides, API reference, and config docs at docs.mockd.io.
Contributions welcome! See CONTRIBUTING.md for setup.
Apache License 2.0 — free for commercial use.
Permanently remove all captured request/response logs. Use this for test isolation between test runs. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context: it specifies the permanence of removal ('Permanently remove'), the scope ('all captured request/response logs'), and the irreversible nature ('cannot be undone'). This enhances understanding beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by usage context and warning, all in three concise sentences with zero wasted words. Each sentence earns its place by providing critical information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive, no parameters, no output schema), the description is complete: it covers purpose, usage guidelines, behavioral traits (permanence, irreversibility), and parameter implications. With annotations providing safety hints, no additional details are needed for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately explains that no inputs are needed, as it removes all logs by default, which aligns with the empty input schema and adds semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Permanently remove') and target resource ('all captured request/response logs'), distinguishing it from siblings like 'get_request_logs' (which retrieves logs) and 'reset_verification' (which resets verification state). The verb 'remove' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use this tool ('for test isolation between test runs') and when not to use it ('This action cannot be undone'), with clear alternatives implied (e.g., use 'get_request_logs' to view logs instead). This helps the agent choose appropriately between destructive and non-destructive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all current mocks as YAML or JSON configuration. Returns the full mock collection for backup, sharing, or version control.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format | yaml |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, but the description adds valuable context beyond this: it specifies that the export includes 'all current mocks' and returns 'the full mock collection,' clarifying scope. It doesn't mention rate limits, authentication needs, or side effects, but with annotations covering safety, this provides sufficient behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description is complete enough: it covers purpose, output format, and use cases. However, it could slightly improve by hinting at the output structure (e.g., 'collection' implies a list or object) or linking to sibling tools like 'import_mocks' for round-trip workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (including default, enum values, and description). The description mentions 'YAML or JSON' but doesn't add meaning beyond what the schema provides, such as format implications or usage tips, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export'), resource ('all current mocks'), and output format ('as YAML or JSON configuration'). It distinguishes from siblings like 'import_mocks' (which imports rather than exports) and 'manage_mock' (which manages individual mocks rather than exporting all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for backup, sharing, or version control'), which helps guide usage. However, it doesn't explicitly state when not to use it or mention specific alternatives among siblings (e.g., 'get_mock_invocations' for invocation data instead of configuration).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current chaos fault injection configuration including latency, error rate, and bandwidth throttle settings. Returns the active chaos config and injection statistics. Use this to check what chaos rules are active before modifying them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating it's a safe, repeatable read operation. The description adds value by specifying what is returned ('active chaos config and injection statistics'), which is useful context beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place with no wasted words, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only, no parameters) and lack of output schema, the description is mostly complete. It explains what is retrieved and when to use it, but could slightly improve by detailing the format of the returned config or statistics for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is high. The description compensates by explaining the return content ('active chaos config and injection statistics'), adding semantic meaning beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'current chaos fault injection configuration', specifying it includes latency, error rate, and bandwidth throttle settings. It distinguishes from sibling tools like 'set_chaos_config' (for modifying) and 'reset_chaos_stats' (for resetting statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this to check what chaos rules are active before modifying them.' This provides clear context for usage versus alternatives like 'set_chaos_config' for modification, making it highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all recorded invocations (request/response pairs) for a specific mock. Shows method, path, headers, body, and timestamp for each call. Use this to debug what requests actually hit a mock.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Mock ID | |
| limit | No | Max invocations to return (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent operations, which the description aligns with by implying safe retrieval. It adds value by specifying the tool's purpose for debugging and the types of data returned (request/response pairs), though it doesn't detail behavioral aspects like rate limits or pagination beyond the default limit in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a usage guideline. Both sentences are essential—the first defines the tool's function, and the second provides context—with no wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), annotations cover safety (read-only, idempotent), and the description explains purpose and usage. However, it lacks details on output format or error handling, which could be useful since there's no output schema, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents parameters (id and limit). The description does not add semantic details beyond the schema, such as explaining mock ID formats or limit implications, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all recorded invocations') and resource ('for a specific mock'), detailing what data is returned (method, path, headers, body, timestamp). It distinguishes from sibling tools like 'get_request_logs' by focusing on mock-specific invocations rather than general request logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use this to debug what requests actually hit a mock'), providing clear context for its application. This distinguishes it from alternatives like 'get_request_logs' or 'verify_mock' by specifying its debugging purpose for mock invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve captured request/response logs. Filter by method, path, mock ID, or protocol. Use this to verify that expected API calls were made to the mock server.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum logs to return | |
| method | No | Filter by HTTP method | |
| mockId | No | Filter by mock ID that handled the request | |
| offset | No | Logs to skip | |
| pathPrefix | No | Filter by path prefix | |
| protocol | No | Filter by protocol type | |
| unmatchedOnly | No | If true, only return unmatched requests with near-miss analysis showing which mocks almost matched and why they didn't |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable read operations. The description adds valuable context beyond this by mentioning 'captured' logs and the verification purpose, which helps the agent understand the tool's role in mock server testing. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first sentence states the purpose and key filtering options, and the second provides clear usage guidance. It's front-loaded with essential information and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema) and rich annotations (readOnlyHint, idempotentHint), the description is largely complete. It covers purpose, filtering, and usage context. However, it doesn't mention pagination behavior (implied by 'limit' and 'offset' parameters) or the 'unmatchedOnly' feature's near-miss analysis, which could be helpful for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself. The description mentions filtering by 'method, path, mock ID, or protocol,' which aligns with parameters like 'method,' 'pathPrefix,' 'mockId,' and 'protocol,' but doesn't add significant semantic detail beyond what the schema provides. The baseline score of 3 is appropriate given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('retrieve captured request/response logs') and resources ('logs'), and distinguishes it from siblings by specifying its filtering capabilities. It explicitly mentions verifying expected API calls to the mock server, which differentiates it from tools like 'clear_request_logs' or 'get_mock_invocations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'to verify that expected API calls were made to the mock server.' This directly addresses the tool's primary use case and distinguishes it from alternatives like 'get_mock_invocations' or 'verify_mock', which might serve different verification purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get server health, ports, and statistics. Use this FIRST when debugging connectivity or port issues. Combines health check, stats, and port information into a single response.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds valuable context about what information is returned (health, ports, statistics) and that it combines multiple data types into one response, which goes beyond the annotations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states what the tool does, and the second provides usage guidance. There's zero wasted language, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, good annotations (readOnly, idempotent), but no output schema, the description provides excellent context about what information is returned and when to use it. The main gap is the lack of output format details, but for a diagnostic tool with no parameters, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and it focuses on the tool's output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get server health, ports, and statistics') and distinguishes it from siblings by specifying it combines multiple types of information into a single response. It explicitly identifies the resource (server) and the scope of data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this FIRST when debugging connectivity or port issues') and distinguishes it from potential alternatives by noting it combines health check, stats, and port information into one response, suggesting it's a comprehensive diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the status of all stateful chaos fault instances: circuit breakers (state, trip count, request count), retry-after trackers (limited/passed counts), and progressive degradation (current delay, request count, error count). Use this to monitor active fault state machines after configuring advanced chaos rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable read operations. The description adds valuable context by specifying what data is retrieved (e.g., state, trip count, request count) and the purpose (monitoring after configuration), which goes beyond annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage guidance. Every sentence earns its place by adding specific details (e.g., components monitored) and context without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, annotations cover safety (read-only, idempotent), and no output schema exists, the description is mostly complete. It explains what data is retrieved and when to use it, but could briefly mention the return format (e.g., structured data) for better clarity, though not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied since no parameters exist, and the description adds value elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'status of all stateful chaos fault instances', specifying the exact components: circuit breakers, retry-after trackers, and progressive degradation. It distinguishes from siblings by focusing on monitoring active fault state machines, unlike tools like 'get_chaos_config' (configuration) or 'get_request_logs' (logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'to monitor active fault state machines after configuring advanced chaos rules.' This provides clear context and distinguishes it from alternatives like 'get_chaos_config' (for configuration) or 'reset_chaos_stats' (for resetting). No exclusions are mentioned, but the guidance is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import mocks from inline content or a file on the mockd server's filesystem. Supports OpenAPI, Postman, HAR, WireMock, cURL, and mockd YAML/JSON formats. Format is auto-detected if not specified. Use dryRun=true to preview without applying. Use the file parameter for large specs that are too large for inline content.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Mock definition content (YAML, JSON, OpenAPI spec, Postman collection, HAR, WireMock, or cURL) | |
| dryRun | No | Parse and validate without applying. Returns a summary of what would be imported. | |
| file | No | Path to a file on the mockd server's filesystem to import. Use this for large specs (OpenAPI, Postman, etc.) that are too large for inline content. Mutually exclusive with content. | |
| format | No | Format hint for parsing | auto |
| replace | No | Replace all existing mocks (true) or merge with existing (false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions dryRun preview and replace parameter, but does not fully disclose default behavior (e.g., merging by default), authentication needs, or side effects. Partial but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently convey purpose, supported formats, usage tips, and parameter hints. No unnecessary content, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers key aspects: input methods, formats, dryRun, and replace. It lacks details on return values or error handling but is fairly complete for an import tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds value beyond schema by explaining format auto-detection, dryRun for preview, and file for large specs. All parameters are well-addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Import mocks from inline content or a file on the mockd server's filesystem' and lists supported formats. It distinguishes from sibling tools like export_mocks and manage_mock by focusing on import functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use dryRun and file parameters, and notes format auto-detection. However, it does not explicitly state when not to use this tool or mention alternatives like manage_mock for individual mocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trip or reset a chaos circuit breaker by its state key. Circuit breaker keys follow the format "ruleIdx:faultIdx" (e.g., "0:0" for the first fault in the first rule). Use get_stateful_faults to discover active circuit breaker keys.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform on the circuit breaker | |
| key | Yes | Circuit breaker state key (e.g., "0:0") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the key format and discovery method, which is useful beyond the idempotentHint annotation. However, it does not disclose other behavioral traits like potential side effects, error conditions, or response format. With annotations covering idempotency, the description provides moderate additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and key format, and the second provides usage guidance. It is front-loaded with essential information and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, idempotentHint annotation, no output schema), the description is mostly complete. It covers purpose, usage, and key semantics, but lacks details on behavioral outcomes or error handling, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal semantics by explaining the key format with an example ('e.g., "0:0"') and linking to get_stateful_faults for key discovery, but does not provide extra details beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('manually trip or reset'), the resource ('a chaos circuit breaker'), and the mechanism ('by its state key'). It distinguishes from siblings by specifying the unique format of circuit breaker keys and referencing get_stateful_faults for discovery, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('to manually trip or reset a chaos circuit breaker') and provides a clear alternative ('Use get_stateful_faults to discover active circuit breaker keys'), ensuring the agent knows both the primary use case and how to obtain necessary inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View or switch the active admin server context. Use 'get' to see the current context and all available contexts. Use 'switch' to change which mockd server this session communicates with.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| name | No | Context name (required for switch) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the two operations and their effects, but doesn't mention permission requirements, whether changes persist across sessions, error conditions, or what 'mockd server' represents. It provides basic operational context but lacks deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly explain the tool's functionality. The first sentence states the overall purpose, and the second explains the two action modes. Every word serves a clear purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides adequate operational guidance but lacks important context. It doesn't explain what a 'context' represents, what 'mockd server' is, whether switching affects other operations, or what format the 'get' output returns. The description covers basic usage but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context about parameter usage: it explains that 'get' shows current and available contexts, while 'switch' requires a name parameter to change servers. With 100% schema description coverage, this supplemental guidance elevates the score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('view' and 'switch') and resource ('active admin server context'). It distinguishes this from sibling tools by focusing on context management rather than mock management, logging, or chaos configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each action: 'get' to see current and available contexts, and 'switch' to change the mockd server. It clearly differentiates the two modes of operation without needing to reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage custom operations on stateful resources. Use 'list' to see all operations, 'get' for details, 'register' to create new ones, 'delete' to remove, or 'execute' to run an operation with input data.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation action | |
| definition | No | Operation definition (required for register). Must include name, steps, and optionally consistency and response. | |
| input | No | Input data for execute action | |
| name | No | Operation name (required for get, delete, execute) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that operations are 'stateful' and describes actions, but fails to cover critical aspects like permissions required, whether changes are reversible, rate limits, error handling, or what the response looks like. For a multi-action tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in a single sentence that lists all actions and their purposes, with no wasted words. It is front-loaded with the main purpose and follows with specific actions, making it easy to scan. However, it could be slightly improved by breaking into bullet points for even clearer readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, stateful resources) and lack of annotations or output schema, the description is moderately complete. It covers the basic purpose and actions but misses details on behavioral traits, return values, and differentiation from siblings. It is adequate as a starting point but requires additional context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (action, definition, input, name) with descriptions. The description adds some context by linking actions to parameters (e.g., 'register' requires definition, 'execute' uses input), but does not provide additional meaning beyond what the schema specifies, such as format details or examples. Baseline 3 is appropriate when the schema handles most of the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing custom operations on stateful resources, specifying the five available actions (list, get, register, delete, execute). It uses specific verbs and identifies the resource (stateful resources), but does not explicitly differentiate from sibling tools like manage_state or manage_workspace, which might handle similar resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by listing the actions and their purposes (e.g., 'register' to create, 'execute' to run with input data), giving some context for when to use each action. However, it lacks explicit guidance on when to choose this tool over alternatives like manage_state or manage_workspace, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, retrieve, update, delete, list, or toggle mock endpoints. Use 'action' to specify the operation. For list, optionally filter by type or enabled status. For get/update/delete/toggle, provide the mock ID. For create, provide type and protocol-specific configuration.
Examples: List: {"action":"list","type":"http"} Get: {"action":"get","id":"http_060bff782a1de15f"} Create: {"action":"create","type":"http","http":{"matcher":{"method":"GET","path":"/api/hello"},"response":{"statusCode":200,"body":"{"msg":"hello"}"}}} Update: {"action":"update","id":"http_060bff782a1de15f","http":{"response":{"statusCode":201}}} Delete: {"action":"delete","id":"http_060bff782a1de15f"} Toggle: {"action":"toggle","id":"http_060bff782a1de15f","enabled":false}
Stateful binding examples (bind mocks to stateful resource tables for automatic CRUD): List: {"action":"create","type":"http","http":{"matcher":{"method":"GET","path":"/api/users"}},"extend":{"table":"users","action":"list"}} Create: {"action":"create","type":"http","http":{"matcher":{"method":"POST","path":"/api/users"}},"extend":{"table":"users","action":"create"}} Get: {"action":"create","type":"http","http":{"matcher":{"method":"GET","path":"/api/users/{id}"}},"extend":{"table":"users","action":"get"}} Update: {"action":"create","type":"http","http":{"matcher":{"method":"PUT","path":"/api/users/{id}"}},"extend":{"table":"users","action":"update"}} Delete: {"action":"create","type":"http","http":{"matcher":{"method":"DELETE","path":"/api/users/{id}"}},"extend":{"table":"users","action":"delete"}} Custom: {"action":"create","type":"http","http":{"matcher":{"method":"POST","path":"/api/users/{id}/verify"}},"extend":{"table":"users","action":"custom","operation":"VerifyUser"}}
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| enabled | No | For toggle: set specific state. For list: filter by enabled status. | |
| extend | No | Bind this mock to a stateful resource table for automatic CRUD. Create the table first with manage_state add_resource. Works with HTTP and SOAP mocks. | |
| graphql | No | GraphQL config (create/update) | |
| grpc | No | gRPC config (create/update) | |
| http | No | HTTP mock spec (required when type=http) | |
| id | No | Mock ID (required for get/update/delete/toggle) | |
| mqtt | No | MQTT config (create/update) | |
| name | No | Mock name (create/update) | |
| oauth | No | OAuth config (create/update) | |
| soap | No | SOAP config (create/update) | |
| type | No | Protocol type for create or list filter | |
| websocket | No | WebSocket config (create/update) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It covers the actions, parameters, and stateful binding behavior. However, it does not discuss side effects like idempotency (e.g., repeated create actions) or error handling, which would be beneficial for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, followed by action-specific examples and stateful binding examples. It is relatively long but appropriately detailed for a complex tool with 13 parameters and multiple actions. Could be slightly more concise, but the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, nested objects, no output schema), the description is comprehensive. It covers all actions, parameter requirements, stateful binding, and provides numerous examples. It lacks return value details but since no output schema exists, it's not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining which parameters are required for each action, showing concrete examples, and detailing stateful binding configuration. This helps the agent understand parameter relationships and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create, retrieve, update, delete, list, or toggle mock endpoints.' It specifies the actions and provides examples, distinguishing it from sibling tools like manage_state or manage_workspace, which handle state and workspace management respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each action (e.g., 'For get/update/delete/toggle, provide the mock ID. For create, provide type and protocol-specific configuration.') and includes examples for all actions and stateful binding. It does not explicitly mention when not to use an action or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage stateful mock resources — CRUD collections that persist data across requests. Use 'overview' to see all resources, 'add_resource' to create a new resource with full table configuration, 'list_items' to browse items in a resource, 'get_item' for a specific item, 'create_item' to add data, 'reset' to restore seed data, or 'delete_resource' to fully unregister a resource.
Examples: Overview: {"action":"overview"} Add resource:{"action":"add_resource","resource":"users"} Add resource:{"action":"add_resource","resource":"customers","id_strategy":"prefix","id_prefix":"cus_","seed_data":[{"name":"Alice"}]} List items: {"action":"list_items","resource":"users","limit":10} Get item: {"action":"get_item","resource":"users","item_id":"abc123"} Create item: {"action":"create_item","resource":"users","data":{"name":"Alice"}} Reset: {"action":"reset","resource":"users"} Delete resource: {"action":"delete_resource","resource":"users"}
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| data | No | Item data (required for create_item) | |
| id_field | No | Custom ID field name (default: 'id', for add_resource) | |
| id_prefix | No | Prefix for generated IDs when id_strategy is 'prefix' (e.g., 'cus_' for customer IDs) | |
| id_strategy | No | ID generation strategy for new items | |
| item_id | No | Item ID (required for get_item) | |
| limit | No | Max items for list_items | |
| max_items | No | Maximum number of items the resource can hold (0 = unlimited) | |
| offset | No | Pagination offset for list_items | |
| order | No | Sort order: asc or desc | desc |
| parent_field | No | Foreign key field name for nested/child resources | |
| relationships | No | Relationship definitions for ?expand[] support. Map of field name to {table, field} objects. | |
| resource | No | Resource name (required for add_resource/list_items/get_item/create_item/reset/delete_resource) | |
| response | No | Response transform configuration. Controls how list/get responses are shaped (envelope, pagination, field mapping). | |
| seed_data | No | Initial data items to populate the resource with. Each item is an object. | |
| sort | No | Sort field for list_items | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions persistence and lists destructive actions (reset, delete_resource), but lacks details on side effects, authorization, idempotency, or error handling, which are important for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, followed by a bulleted action list and well-structured JSON examples. It is somewhat lengthy but efficient given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers all actions and gives examples, it lacks output descriptions for each action (no output schema provided), and does not address error handling, edge cases, or data limits, leaving some gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the already comprehensive schema by providing concrete examples for each action, illustrating parameter usage, relationships, and transformations, which helps agents understand how parameters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage stateful mock resources — CRUD collections that persist data across requests,' uses specific verb 'manage' with resource 'stateful mock resources,' and distinguishes from siblings like manage_mock and manage_workspace by focusing on stateful persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (for CRUD on stateful mock resources) and provides examples for each action, but does not explicitly state exclusions or direct comparisons to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available workspaces or switch the active workspace. Workspaces isolate mock configurations. Use 'list' to see all workspaces, 'switch' to route subsequent operations to a specific workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| id | No | Workspace ID (required for switch) | |
| name | No | Workspace name (required for create, alternative to ID for switch) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that workspaces isolate mock configurations and that switching routes subsequent operations. However, it lacks details on side effects, permissions, or what the 'list' action returns. Basic transparency but significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a third listing uses. It front-loads the main purpose. While it could be more structured (e.g., separate sections for actions), it is not verbose and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema, the description does not explain what the 'list' action returns, lacks an example, and omits the 'create' action. Error cases and output format are not mentioned, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about workspaces isolating configurations and the actions' purposes, but does not add meaning beyond the schema's parameter descriptions, which already specify requirements for each action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or switches workspaces and explains that workspaces isolate mock configurations. It covers the 'list' and 'switch' actions explicitly, but omits the 'create' action that is present in the schema, making the purpose slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance for using 'list' and 'switch' actions, but does not address when to use this tool versus sibling tools, nor does it mention the 'create' action or when not to use this tool. The guidance is adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset chaos injection statistics counters to zero without changing the active chaos configuration. Use this to start fresh measurement after modifying chaos rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=true, which the description aligns with by describing a reset operation. The description adds value by clarifying that it resets counters without affecting configuration, enhancing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and purpose, with no wasted words. Every sentence earns its place by providing essential usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with annotations covering idempotency and destructiveness, the description is complete enough. It lacks output details, but since there's no output schema, this is a minor gap in an otherwise well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter details, which is acceptable since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('reset'), target resource ('chaos injection statistics counters'), and scope ('to zero without changing the active chaos configuration'), distinguishing it from sibling tools like 'get_chaos_config' or 'set_chaos_config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'to start fresh measurement after modifying chaos rules,' providing clear context and distinguishing it from alternatives like 'reset_verification' or other management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear verification data (invocation records and counters) for a specific mock or all mocks. Use this to reset counters before running a new test scenario.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Mock ID to reset. Omit to reset ALL mocks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies what gets cleared ('verification data (invocation records and counters)') and the test scenario use case. While annotations already indicate destructive and idempotent behavior, the description provides specific details about the data affected, earning a high score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences: the first states the purpose and scope, the second provides usage guidance. Every word earns its place with zero wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with one parameter) and the presence of annotations covering safety aspects, the description provides good contextual completeness. It explains what data is cleared and when to use it, though it doesn't mention output behavior (no output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Clear verification data') and resource ('for a specific mock or all mocks'), distinguishing it from siblings like 'clear_request_logs' (which clears logs) or 'reset_chaos_stats' (which resets chaos statistics). It provides precise scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'to reset counters before running a new test scenario.' This provides clear context for usage and distinguishes it from other reset/clear operations by focusing on verification data rather than logs or chaos stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure chaos fault injection rules. For simple chaos: set latency ranges, error rates, or bandwidth throttling. For advanced stateful faults: pass raw rules with fault types like circuit_breaker, retry_after, progressive_degradation, or chunked_dribble. Pass enabled=false to disable all chaos. For pre-built configurations, use named profiles like "slow-api" or "flaky".
| Name | Required | Description | Default |
|---|---|---|---|
| bandwidth_bytes_per_sec | No | Bandwidth throttle in bytes/sec | |
| enabled | Yes | Enable or disable chaos injection | |
| error_codes | No | HTTP status codes to return on error (e.g., [500, 502, 503]) | |
| error_rate | No | Error rate 0.0-1.0 (e.g., 0.2 = 20% of requests fail) | |
| latency_max_ms | No | Maximum random latency in milliseconds | |
| latency_min_ms | No | Minimum random latency in milliseconds | |
| latency_ms | No | Fixed latency in milliseconds | |
| profile | No | Named chaos profile | |
| rules | No | Raw chaos rules for advanced fault types. Each rule has probability (0-1), optional pathPattern, optional methods, and faults array. Fault types: latency, error, slow_body, corrupt_body, partial_response, connection_reset, circuit_breaker, retry_after, progressive_degradation, chunked_dribble. Each fault has type, probability (0-1), and config object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the idempotentHint annotation. It explains that 'enabled=false' disables all chaos, describes the distinction between simple and advanced fault types, and mentions pre-built profile options. While it doesn't cover rate limits, authentication needs, or side effects, it provides meaningful operational guidance that the annotation alone doesn't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that each earn their place: first establishes the core purpose, second distinguishes simple vs. advanced usage, third covers disabling and pre-built alternatives. No wasted words, front-loaded with the main function, and appropriately sized for a complex configuration tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, advanced fault types) and the absence of an output schema, the description provides good contextual coverage. It explains the tool's scope, different usage modes, and key behavioral aspects. However, it doesn't describe what happens after configuration (e.g., whether changes take effect immediately, what the response looks like, or error conditions), which would be helpful for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds some semantic context by grouping parameters into 'simple chaos' (latency ranges, error rates, bandwidth) and 'advanced stateful faults' (raw rules with specific fault types), and mentions the profile parameter's purpose. However, it doesn't provide additional syntax, format, or constraint details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure chaos fault injection rules.' It specifies both simple chaos (latency, error rates, bandwidth throttling) and advanced stateful faults (circuit_breaker, retry_after, etc.), distinguishing it from sibling tools like 'get_chaos_config' (which reads config) and 'reset_chaos_stats' (which resets statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for configuring chaos injection, with guidance on simple vs. advanced usage and disabling chaos. It explicitly mentions an alternative: 'For pre-built configurations, use named profiles...' However, it doesn't specify when NOT to use this tool versus other sibling tools like 'manage_circuit_breaker' or 'manage_stateful_faults' that might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a mock was called the expected number of times. Returns pass/fail status, actual call count, and invocation details. Optionally assert with expected_count, at_least, or at_most parameters. Use this to assert your application is making the right API calls.
| Name | Required | Description | Default |
|---|---|---|---|
| at_least | No | Minimum invocations expected | |
| at_most | No | Maximum invocations expected | |
| expected_count | No | Expected number of invocations (exact match) | |
| id | Yes | Mock ID to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent operations, which the description aligns with by describing a checking/assertion function. The description adds valuable behavioral context: it specifies the return format ('pass/fail status, actual call count, and invocation details') and explains the optional assertion parameters ('at_least, or at_most'), which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by return details and usage guidance. Each sentence adds value: the first defines the tool, the second specifies outputs, and the third provides context. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (verification with optional parameters), annotations cover safety (read-only, idempotent), and the description explains purpose, returns, and usage. However, there is no output schema, so the description partially compensates by mentioning return details, but it could be more explicit about output structure (e.g., format of 'invocation details').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters well. The description adds minimal semantics by mentioning 'Optionally assert with expected_count, at_least, or at_most parameters,' which reinforces but does not significantly expand beyond the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check whether a mock was called the expected number of times.' It specifies the verb ('Check'), resource ('mock'), and scope ('expected number of times'), distinguishing it from sibling tools like 'get_mock_invocations' (which likely lists calls) or 'reset_verification' (which resets counts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to assert your application is making the right API calls.' It implies this tool is for verification/assertion purposes, but it does not explicitly state when not to use it or name alternatives (e.g., 'get_mock_invocations' for non-assertive checking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.6.6import_mocks2 fields changedInput schema / properties / file{
"description": "Path to a file on the mockd server's filesystem to import. Use this for large specs (OpenAPI, Postman, etc.) that are too large for inline content. Mutually exclusive with content.",
"type": "string"
}Input schema / required[ "content" ]
manage_mock1 field changedInput schema / properties / extend{
"description": "Bind this mock to a stateful resource table for automatic CRUD. Create the table first with manage_state add_resource. Works with HTTP and SOAP mocks.",
"properties": {
"action": {
"description": "CRUD action to perform",
"enum": [
"list",
"get",
"create",
"update",
"delete",
"custom"
],
"type": "string"
},
"operation": {
"description": "Custom operation name (required when action is 'custom')",
"type": "string"
},
"table": {
"description": "Resource table name (must exist in state store)",
"type": "string"
}
},
"required": [
"table",
"action"
],
"type": "object"
}manage_state10 fields changedInput schema / properties / action / enum[ "overview", "add_resource", "list_items", "get_item", "create_item", "reset" ]
[ "overview", "add_resource", "list_items", "get_item", "create_item", "reset", "delete_resource" ]
Input schema / properties / id_prefix{
"description": "Prefix for generated IDs when id_strategy is 'prefix' (e.g., 'cus_' for customer IDs)",
"type": "string"
}Input schema / properties / id_strategy{
"description": "ID generation strategy for new items",
"enum": [
"uuid",
"prefix",
"ulid",
"sequence",
"short"
],
"type": "string"
}Input schema / properties / max_items{
"description": "Maximum number of items the resource can hold (0 = unlimited)",
"type": "integer"
}Input schema / properties / parent_field{
"description": "Foreign key field name for nested/child resources",
"type": "string"
}Input schema / properties / path{
"description": "URL base path for the resource (e.g., /api/users). Omit for bridge-only mode (for add_resource)",
"type": "string"
}Input schema / properties / relationships{
"description": "Relationship definitions for ?expand[] support. Map of field name to {table, field} objects.",
"type": "object"
}Input schema / properties / resource / description"Resource name (required for add_resource/list_items/get_item/create_item/reset)"
"Resource name (required for add_resource/list_items/get_item/create_item/reset/delete_resource)"
Input schema / properties / response{
"description": "Response transform configuration. Controls how list/get responses are shaped (envelope, pagination, field mapping).",
"type": "object"
}Input schema / properties / seed_data{
"description": "Initial data items to populate the resource with. Each item is an object.",
"items": {
"type": "object"
},
"type": "array"
}manage_workspace2 fields changedInput schema / properties / action / enum[ "list", "switch" ]
[ "list", "switch", "create" ]
Input schema / properties / name / description"Workspace name (for switch, alternative to ID)"
"Workspace name (required for create, alternative to ID for switch)"
v0.5.1clear_request_logsexport_mocksget_chaos_configget_mock_invocationsget_request_logsget_server_statusget_stateful_faultsimport_mocksmanage_circuit_breakermanage_contextmanage_custom_operationmanage_mockmanage_statemanage_workspacereset_chaos_statsreset_verificationset_chaos_configverify_mockMost tools have distinct purposes, but some overlap exists: get_mock_invocations and get_request_logs both retrieve request/response data, though they differ in scope (specific mock vs. general logs). Tools like manage_mock and manage_state cover different aspects (mock endpoints vs. stateful resources), but the 'manage_' prefix groups them in a way that could cause initial confusion. Overall, descriptions help clarify boundaries, but the set isn't perfectly distinct.
Naming follows a mostly consistent verb_noun pattern (e.g., clear_request_logs, export_mocks, get_chaos_config), with a few deviations like manage_mock and manage_state that use 'manage_' as a prefix for multi-action tools. The pattern is readable and predictable, though not perfectly uniform across all tools.
With 18 tools, the count is well-scoped for a mock server that handles mocks, chaos injection, stateful resources, and verification. Each tool serves a clear purpose in this domain, such as managing mocks, configuring chaos, or tracking invocations, without feeling excessive or thin.
The tool set provides comprehensive coverage for a mock server domain, including CRUD operations for mocks and stateful resources, chaos configuration and monitoring, verification, logging, and workspace management. There are no obvious gaps; tools like import_mocks and export_mocks handle configuration lifecycle, while manage_custom_operation and manage_context add flexibility.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/getmockd/mockd'
If you have feedback or need assistance with the MCP directory API, please join our Discord server