How do I use mockserver-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mockserver-mcp Create a mock GET /api/users returning 200 with user list" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mockserver-mcp

by Akkshay10

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mockserver-mcp

An MCP (Model Context Protocol) server for interacting with James Bloom's MockServer. This enables AI assistants to create mock HTTP expectations, verify requests, clear state, and manage MockServer instances programmatically.

Prerequisites

You need a running MockServer instance:

# Using Docker (easiest)
docker run -d -p 1080:1080 mockserver/mockserver

Related MCP server: httptoolkit-mcp

Installation

Using npx (recommended)

npx mockserver-mcp

Global installation

npm install -g mockserver-mcp
mockserver-mcp

Configuration

Environment Variables

Variable	Description	Default
`MOCKSERVER_HOST`	MockServer hostname	`localhost`
`MOCKSERVER_PORT`	MockServer port	`1080`

MCP Client Configuration

Add to your MCP client configuration file (e.g., Claude Desktop, Kiro, Cursor):

{
  "mcpServers": {
    "mockserver": {
      "command": "npx",
      "args": ["-y", "mockserver-mcp"],
      "env": {
        "MOCKSERVER_HOST": "localhost",
        "MOCKSERVER_PORT": "1080"
      }
    }
  }
}

For shared team MockServer, change MOCKSERVER_HOST to your server's address.

Available Tools

mockserver_create_expectation

Create a mock HTTP expectation on MockServer.

Parameters:

httpRequest (required): Request matching criteria
- method: HTTP method (GET, POST, PUT, DELETE, etc.)
- path: URL path to match
- queryStringParameters: Query parameters to match
- headers: Headers to match
- body: Body matcher with type (STRING, JSON, REGEX, XPATH, JSON_PATH) and value
httpResponse: Response configuration
- statusCode: HTTP status code
- headers: Response headers
- body: Response body (string or object)
- delay: Response delay with timeUnit and value
times: How many times to match (remainingTimes, unlimited)
timeToLive: Expectation lifetime (timeUnit, timeToLive)

Example:

{
  "httpRequest": {
    "method": "GET",
    "path": "/api/users"
  },
  "httpResponse": {
    "statusCode": 200,
    "body": { "users": [] }
  }
}

mockserver_verify

Verify that requests matching criteria were received by MockServer.

Parameters:

httpRequest (required): Request matching criteria (same as create_expectation)
times: Expected request count
- atLeast: Minimum number of requests
- atMost: Maximum number of requests
- exactly: Exact number of requests

Example:

{
  "httpRequest": {
    "method": "POST",
    "path": "/api/orders"
  },
  "times": {
    "atLeast": 1
  }
}

mockserver_clear

Clear expectations and recorded requests from MockServer.

Parameters:

httpRequest (optional): Request matcher to clear specific expectations. If not provided, clears all.

Example:

{
  "httpRequest": {
    "path": "/api/users"
  }
}

mockserver_reset

Perform a full reset of MockServer, clearing all expectations and recorded requests.

Parameters: None

mockserver_retrieve_requests

Retrieve recorded requests from MockServer.

Parameters:

httpRequest (optional): Request matcher to filter recorded requests

Example:

{
  "httpRequest": {
    "method": "GET"
  }
}

mockserver_status

Get MockServer connection status and configuration.

Parameters: None

Why Mocking?

API mocking enables early testing — start building and testing your frontend or integrations before the backend is ready. No more waiting. Ship faster.

Requirements

Node.js >= 18.0.0
A running MockServer instance

License

MIT

Available Tools

6 tools

mockserver_clearA

Clear expectations and recorded requests from MockServer. Optionally filter by request matcher.

ParametersJSON Schema

Name	Required	Description	Default
`httpRequest`	No	Optional request matcher to clear specific expectations. If not provided, clears all.

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully carries the burden. It discloses the destructive nature (clear) and optional filtering. However, it does not specify irreversibility or side effects on active expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loading the action and resource, with an additional clause for optional filtering. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains input well but lacks mention of output (e.g., success indication). For a simple clear operation, this is adequate but could be marginally improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed property descriptions. The description adds no extra parameter meaning beyond noting the optionality, which is already implied by 'required: []'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Clear') and the resource ('expectations and recorded requests from MockServer'). It specifies optional filtering, distinguishing it from sibling tools like create_expectation or retrieve_requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like mockserver_reset, which might overlap in functionality. The description does not provide explicit context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mockserver_create_expectationB

Create a mock HTTP expectation on MockServer. Define request matching criteria and the response to return.

ParametersJSON Schema

Name	Required	Description
`id`	No	Optional expectation identifier
`times`	No	How many times this expectation should be matched
`timeToLive`	No	How long this expectation should remain active
`httpRequest`	Yes	Request matching criteria (method, path, headers, body, etc.)
`httpResponse`	No	Response configuration

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It does not disclose behavioral traits like persistence, ordering, or side effects beyond the generic 'create'. Lacks details on how expectations interact or are cleared.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource. No redundant information. Efficient and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description should explain return values or confirmation. It does not. For a tool with complex nested parameters, some usage guidance would improve completeness. The description is too brief.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no new meaning beyond the schema. The description mentions 'request matching criteria' and 'response', which mirrors the schema parameters but doesn't provide additional insight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a mock HTTP expectation on MockServer, specifying both request matching and response definition. It distinguishes from siblings which handle clearing, resetting, retrieving, status, and verifying.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives (e.g., when to create vs verify/clear). It does not mention prerequisites, limitations, or context of use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mockserver_resetA

Perform a full reset of MockServer, clearing all expectations and recorded requests.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses destructive behavior ('clearing all expectations and recorded requests'), but lacks details on side effects, authorization needs, or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, well-formed sentence with no extraneous words. The key action and effect are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description adequately conveys the tool's purpose. However, it could explicitly mention that this resets the entire MockServer state versus partial operations available via siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema description coverage is 100%. The description correctly adds no extra parameter info since none are needed. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Perform a full reset of MockServer, clearing all expectations and recorded requests.' It uses a specific verb ('reset') and resource ('MockServer'), and distinguishes from siblings like mockserver_clear by specifying 'full reset'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While 'full reset' implies a comprehensive operation, the description does not contrast with siblings like mockserver_clear or provide when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mockserver_retrieve_requestsB

Retrieve recorded requests from MockServer. Optionally filter by request matcher.

ParametersJSON Schema

Name	Required	Description	Default
`httpRequest`	No	Optional request matcher to filter recorded requests

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only describes the basic action without disclosing whether it is read-only, any permissions needed, or behavioral implications like pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence. While efficient, it omits important details, making it slightly under-specified but not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a nested parameter and no output schema, the description fails to explain return format, default behavior (e.g., all requests returned), or any constraints. Incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal value by mentioning optional filtering, but does not explain usage details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 'recorded requests from MockServer'. It is distinct from sibling tools which handle clearing, creating expectations, resetting, status, and verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like mockserver_clear or mockserver_verify. No context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mockserver_statusA

Get MockServer connection status and configuration. Returns host, port, and reachability.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses return values but omits behavioral traits like idempotency, error conditions, or authentication requirements. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single clear sentence with no redundancy. All information is front-loaded and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with no parameters and no output schema. Description covers the core purpose and output fields. Lacks error handling or usage notes, but sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so baseline is high (4). Description adds meaning by specifying what the response includes (host, port, reachability), which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get MockServer connection status and configuration' with specific return fields (host, port, reachability). This distinguishes it from sibling tools that perform mutations or retrievals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives guidance. While the purpose is clear, the description does not help an agent decide between this and sibling tools like mockserver_verify or mockserver_retrieve_requests.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mockserver_verifyC

Verify that requests matching criteria were received by MockServer. Returns verification result with match count.

ParametersJSON Schema

Name	Required	Description	Default
`times`	No	Expected number of matching requests
`httpRequest`	Yes	Request matching criteria

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states basic result info ('returns verification result with match count'). Missing behavioral traits like whether it throws on mismatch, side effects, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with verb and resource. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with nested parameters and no output schema, missing details on times parameter semantics, success/failure indication, and result structure. Description is insufficient for full situational understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond what schema provides, meeting baseline but not exceeding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'verify', resource 'requests matching criteria', and result 'returns verification result with match count'. It distinguishes from sibling tools that manage expectations or retrieve requests, though not explicitly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like mockserver_retrieve_requests or mockserver_create_expectation. Usage context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.2Jul 17, 2026
- First observedmockserver_clear
- First observedmockserver_create_expectation
- First observedmockserver_reset
- First observedmockserver_retrieve_requests
- First observedmockserver_status
- First observedmockserver_verify

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a unique purpose: creating expectations, clearing/resetting (partial vs full), retrieving requests, checking status, and verifying requests. No ambiguity.

Naming Consistency5/5

All tools follow the pattern 'mockserver_verb' or 'mockserver_verb_noun', using snake_case consistently.

Tool Count5/5

Six tools cover the essential operations for a mock server (create, clear, reset, retrieve, status, verify) without being excessive.

Completeness4/5

Core functionality is covered, but a tool to list current expectations would provide more complete lifecycle management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

simceptorOAuth
io.github.ayda212
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
API Testing Testing & QA Tools
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
WireMock CloudOAuth
io.wiremock
Build, validate, and manage API simulations in WireMock Cloud from MCP-compatible AI agents.
API Testing Testing & QA Tools Developer Tools
1
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

Mock MCP Server
Developer Tools Testing & QA Tools
DiscreteTom
A
license
B
quality
D
maintenance
A mock MCP server for testing MCP client implementations and development workflows. Supports tools, prompts, and resources across multiple transport protocols (stdio, HTTP, SSE).
Updated 9 months ago (2025-12-12 06:43 UTC)
1
MIT
httptoolkit-mcp
Testing & QA Tools API Testing Developer Tools
fdciabdul
A
license
A
quality
F
maintenance
An MCP server that enables AI assistants to control HTTP Toolkit for intercepting, inspecting, and debugging HTTP(S) traffic from browsers, mobile devices, and Docker containers. It provides tools for server management, interceptor activation, and sending HTTP requests through natural language commands.
Updated 6 months ago (2026-03-20 08:49 UTC)
23
108
1
MIT
Mockzillaofficial
API Testing Developer Tools Testing & QA Tools
mockzilla
A
license
A
quality
D
maintenance
MCP server for mockzilla. Lets coding agents (Claude Desktop, Cursor, etc.) install the mockzilla CLI, stand up API mocks from an OpenAPI spec or a single endpoint, and — with an account — deploy hosted mocks on mockzilla.org.
Updated 3 months ago (2026-05-23 17:47 UTC)
14
62
5
MIT
MCP HTTP Client Server
API Testing Developer Tools
ferPrieto
A
license
Not graded
quality
C
maintenance
A powerful MCP server for making HTTP requests, GraphQL queries, and TCP/Telnet connections from AI assistants.
Updated 8 months ago (2025-12-28 10:22 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Akkshay10/MCPClientMock'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mockserver-mcp

Prerequisites

Installation

Using npx (recommended)

Global installation

Configuration

Environment Variables

MCP Client Configuration

Available Tools

mockserver_create_expectation

mockserver_verify

mockserver_clear

mockserver_reset

mockserver_retrieve_requests

mockserver_status

Why Mocking?

Requirements

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Mockzillaofficial

Latest Blog Posts

MCP directory API