What can you do with this server?

This MCP server allows coding agents to manage a WireMock instance via its Admin API, including stub mapping CRUD, request journal inspection, and namespace-based multi-agent ownership controls. * Check WireMock status: wiremock_status verifies connectivity, health, and version. * Manage stub mappings: * List mappings (mock_list) with optional pagination. * Get a specific mapping by ID (mock_get). * Create new mappings preserving advanced WireMock structure (mock_create). * Update existing mappings by ID with namespace enforcement (mock_update). * Delete a mapping by ID with ownership checks (mock_delete). * Adopt unmanaged legacy mappings into the current namespace (mock_adopt). * Delete only mappings owned by the namespace (mock_delete_owned). * Reset all runtime mappings to backing-store defaults (mock_reset). * Inspect request journal: * List requests with optional limit and since filters (request_list). * Get a specific journal entry by ID (request_get). * Show unmatched requests (request_unmatched). * Count requests matching a pattern (request_count). * Clear the request journal without affecting mappings (request_clear). * Multi-agent namespace support: When configured with WIREMOCK_MCP_NAMESPACE, created mappings are tagged with ownership metadata; update and delete operations are restricted to owned mappings, while reads remain open. Destructive global operations (mock_reset, request_clear) are blocked by default but can be allowed. mock_adopt and mock_delete_owned help manage namespace-scoped cleanup.

How do I use wiremock-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., "@wiremock-mcp Create a mock for GET /api/users returning JSON" 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.

wiremock-mcp

by Erivelto47

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

wiremock-mcp

A lightweight MCP server that lets coding agents manage a local or remote WireMock instance through the WireMock Admin API.

The project is designed around a simple rule: WireMock remains the source of truth. The MCP server does not own or migrate your existing mappings; it connects to the WireMock instance you already use.

Package

@erivelto_muller/wiremock-mcp

The package is published to the public npm registry.

Related MCP server: @restforge-dev/mcp-server

MVP architecture

Codex / Claude / Cursor / MCP client
                 |
                 | MCP stdio
                 v
       @erivelto_muller/wiremock-mcp
                 |
                 | HTTP
                 v
       WIREMOCK_URL/__admin/*
                 |
                 v
             WireMock 3.x

The MVP connects to one WireMock instance configured by WIREMOCK_URL.

Default:

http://localhost:8080

Requirements

Node.js 22 or newer
a running WireMock 3.x instance
an MCP client with stdio server support

Docker is optional. It is only needed if you want an easy way to start WireMock locally.

Quick start

1. Start WireMock if you do not already have one

Using the official WireMock Docker image:

docker run --rm -it \
  --name wiremock \
  -p 8080:8080 \
  wiremock/wiremock:3.13.2

Verify it:

curl http://localhost:8080/__admin/health

If you already have WireMock running with existing mappings, keep using it. You do not need to migrate them.

2. Configure the MCP server

Generic process-spawned MCP configuration:

{
  "mcpServers": {
    "wiremock": {
      "command": "npx",
      "args": ["-y", "@erivelto_muller/wiremock-mcp"],
      "env": {
        "WIREMOCK_URL": "http://localhost:8080"
      }
    }
  }
}

For an existing WireMock on another port:

{
  "mcpServers": {
    "wiremock": {
      "command": "npx",
      "args": ["-y", "@erivelto_muller/wiremock-mcp"],
      "env": {
        "WIREMOCK_URL": "http://localhost:9090"
      }
    }
  }
}

The server can also be started directly:

WIREMOCK_URL=http://localhost:9090 \
npx -y @erivelto_muller/wiremock-mcp

No repository clone is required for normal use.

Tools

The server exposes the following MCP tools:

Tool	Purpose
`wiremock_status`	Check connectivity, health and WireMock version
`mock_list`	List registered stub mappings
`mock_get`	Get one mapping by ID
`mock_create`	Create a WireMock mapping
`mock_update`	Update a mapping by ID, enforcing namespace ownership when configured
`mock_delete`	Delete a mapping by ID, enforcing namespace ownership when configured
`mock_adopt`	Explicitly adopt an unmanaged legacy mapping into the current namespace
`mock_delete_owned`	Delete only mappings owned by the current namespace
`mock_reset`	Reset runtime mappings to the backing-store defaults
`request_list`	List requests from the request journal
`request_get`	Get one journal request by ID
`request_unmatched`	List requests that matched no stub
`request_count`	Count journal requests matching a WireMock request pattern
`request_clear`	Clear the request journal without deleting mappings

The create/update/count tools intentionally preserve WireMock's advanced request/mapping structure instead of reducing WireMock to a small custom schema.

Namespace ownership

By default the server runs in unscoped compatibility mode. This keeps existing WireMock workflows working: mappings are not automatically tagged, and mock_update, mock_delete, mock_reset and request_clear behave globally.

For multi-agent use, run one MCP process per agent with a distinct namespace:

{
  "mcpServers": {
    "wiremock-agent-a": {
      "command": "npx",
      "args": ["-y", "@erivelto_muller/wiremock-mcp"],
      "env": {
        "WIREMOCK_URL": "http://localhost:8080",
        "WIREMOCK_MCP_NAMESPACE": "agent-a"
      }
    }
  }
}

When WIREMOCK_MCP_NAMESPACE is set, mappings created by this MCP process are tagged in WireMock metadata:

{
  "metadata": {
    "wiremockMcp": {
      "managed": true,
      "namespace": "agent-a"
    }
  }
}

The reserved key is metadata.wiremockMcp. Other metadata is preserved.

Ownership classifications:

Classification	Meaning
`OWNED`	Managed by this MCP process namespace
`FOREIGN`	Managed by another MCP namespace
`UNMANAGED`	No valid WireMock MCP ownership metadata
`UNSCOPED`	No namespace configured, compatibility mode

Reads are never blocked by ownership. Agents can still list and inspect foreign or unmanaged mappings for diagnosis.

Writes are guarded when namespace mode is active:

mock_update and mock_delete allow OWNED mappings;
FOREIGN mappings are always refused;
UNMANAGED mappings are refused by default;
pass allowUnmanaged: true to mock_update or mock_delete for an explicit opt-in operation on a legacy mapping.

allowUnmanaged does not adopt a mapping. To mark a legacy mapping as owned by the current namespace, use:

mock_adopt(id="...")

mock_adopt is idempotent for OWNED mappings, refuses FOREIGN mappings and preserves request/response fields plus non-reserved metadata.

To clean up only this namespace, use:

mock_delete_owned()

mock_delete_owned does not remove foreign or unmanaged mappings.

mock_reset and request_clear are global operations. When namespace mode is active, both are blocked by default. You can explicitly allow them for a process:

{
  "mcpServers": {
    "wiremock-agent-a": {
      "command": "npx",
      "args": ["-y", "@erivelto_muller/wiremock-mcp"],
      "env": {
        "WIREMOCK_URL": "http://localhost:8080",
        "WIREMOCK_MCP_NAMESPACE": "agent-a",
        "WIREMOCK_MCP_ALLOW_GLOBAL_DESTRUCTIVE": "true"
      }
    }
  }
}

Only enable this for isolated WireMock instances or when the agent is expected to affect every mapping/request journal entry in the configured WireMock. Request journal ownership is not tracked in this version.

Example agent requests

Once the MCP is configured, examples include:

Create a GET /products/123 mock returning HTTP 200 with this JSON body: ...

List the existing WireMock mappings and show me which one handles /payments.

Update this mapping so that it returns HTTP 503 with a 500 ms delay.

Show the requests received by WireMock that did not match any mock.

Check whether my application called POST /orders and how many times.

Existing WireMock environments

Using an existing instance is a primary use case.

For example, if your WireMock already runs at:

http://localhost:9090

with a collection of existing mappings, configure only:

WIREMOCK_URL=http://localhost:9090

The MCP operates on the mappings and request journal already present in that WireMock instance.

Safety

The configured MCP server has permission to modify the WireMock instance pointed to by WIREMOCK_URL.

Some tools are intentionally destructive:

mock_delete removes a mapping;
mock_delete_owned removes all mappings owned by the current namespace;
mock_reset resets runtime mappings;
request_clear clears the request journal.

Use a development/test WireMock instance unless you explicitly intend the agent to manage another environment.

The MVP does not expose WireMock shutdown operations.

The MVP does not implement authentication, credential storage, request redaction, multi-tenant authorization or environment allowlists. If your WireMock Admin API is reachable from this server, an MCP client can create, update and delete mappings and clear the request journal through the tools listed above. Prefer isolated development/test instances and avoid pointing WIREMOCK_URL at shared or production-like environments unless that access is intentional.

HTTPS URLs are accepted, but no custom CA, client certificate or authorization header configuration is included in the MVP.

Development

Clone the repository:

git clone https://github.com/Erivelto47/wiremock-mcp.git
cd wiremock-mcp

Install dependencies:

npm ci

Build:

npm run build

Run the server from a local build:

WIREMOCK_URL=http://localhost:8080 node dist/index.js

Run unit tests:

npm test

Run the real WireMock integration/E2E suite:

npm run test:integration

The integration suite starts an isolated WireMock Docker container on port 18080, exercises the MCP through stdio and cleans the container afterward.

Test the package before publishing

Inspect the files that would be included in the npm package:

npm pack --dry-run

A local tarball can also be generated with:

npm pack

This makes it possible to smoke-test the installable package before publishing it.

npm distribution

The primary distribution target is the public npm registry so users can run the MCP with npx and do not need to clone this repository.

Target package:

@erivelto_muller/wiremock-mcp

Releases are intended to be published by GitHub Actions from SemVer tags after Trusted Publishing is configured on npmjs.com.

Manual publishing, when needed, uses:

npm publish --access public

Publishing is a release-maintainer action and is not performed by normal development/test commands.

CI and releases

Continuous integration runs on pushes and pull requests to master:

npm ci
npm run typecheck
npm run build
npm test
npm run test:integration
npm pack --dry-run

The publish workflow runs only when a tag matching v* is pushed. Before publishing, it repeats the same gates and verifies that the tag version matches package.json exactly:

v0.2.0 -> package.json version 0.2.0

The workflow uses npm Trusted Publishing with GitHub Actions OIDC. It does not use long-lived npm publish tokens, publish secrets or OTP values.

After .github/workflows/publish.yml exists on the default branch, the maintainer must configure the npm package Trusted Publisher with:

Provider: GitHub Actions
GitHub user/org: Erivelto47
Repository: wiremock-mcp
Workflow filename: publish.yml
Allowed action: npm publish
Environment: empty

The workflow filename is publish.yml, not .github/workflows/publish.yml. Each npm package supports one Trusted Publisher at a time. Do not create a release tag until this npm package setting has been configured.

Roadmap

MVP — one external WireMock

TypeScript / Node.js
MCP over stdio
one WIREMOCK_URL
mapping CRUD
namespace ownership for concurrent agents
request-journal inspection
npm distribution
CI and Trusted Publishing workflow
real WireMock Docker E2E tests

Next functional step — multiple WireMock instances

A later release can support named instances while keeping the current single-URL configuration as the default.

Conceptually:

mock_list(instance="payments")
mock_create(instance="legacy", ...)

Possible configuration:

instances:
  payments: http://localhost:9091
  legacy: http://localhost:9092

This is intentionally outside the first MVP so the initial server stays small and predictable.

Future distribution — all-in-one Docker image

A later release can provide an OCI/Docker image that bundles:

MCP server + WireMock

for zero-config local onboarding.

That convenience image must not remove the ability to connect the MCP to an existing external WireMock instance.

Other possible extensions

Streamable HTTP transport
OpenAPI-assisted mock creation
recording/proxy workflows
richer request verification helpers
per-namespace request-journal isolation

These are not part of the MVP.

License

MIT. See LICENSE.

Available Tools

12 tools

mock_createB

Create a WireMock stub mapping, preserving advanced WireMock fields.

ParametersJSON Schema

Name	Required	Description	Default
`mapping`	Yes

TDQS

B3.1/5.0

Behavior2/5

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 mentions 'preserving advanced WireMock fields', which hints at a non-destructive handling of extra fields, but does not disclose important behaviors such as whether the tool overwrites existing mappings, requires authentication, or returns a specific response. The description is insufficient for a write operation.

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?

The description is a single, front-loaded sentence with no wasted words. It states the core action first and then adds a meaningful qualifier. This is concise and well-structured.

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 that there is no output schema, no annotations, and a complex nested parameter, the description is incomplete. It does not explain what the tool returns on success, how to handle errors, or how the created mapping interacts with other mock tools. The description is too minimal for a tool that creates rich WireMock stubs.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not compensate. The only parameter 'mapping' is described as a 'WireMock stub mapping', which gives a general idea but lacks details about its required structure (e.g., request matchers, response templates). The schema itself is generic (an object with additionalProperties), so the description offers only minimal semantic value.

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 uses a specific verb and resource: 'Create a WireMock stub mapping'. It clearly distinguishes this tool from siblings like mock_list and mock_delete by indicating it is a creation operation. The additional phrase 'preserving advanced WireMock fields' adds nuance, further clarifying the tool's focus.

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 versus alternatives. It does not mention scenarios where this tool is preferred over mock_update or mock_delete, nor does it state any prerequisites or exclusions. The agent is left to infer usage from the tool name and siblings.

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

mock_deleteB

Delete one WireMock stub mapping by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic delete action without explaining permanence, idempotency, error behavior, or any side effects. The agent is left unaware of what happens if the ID does not exist.

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?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's primary purpose.

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

Completeness3/5

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

For a simple one-parameter delete tool with no annotations or output schema, the description provides the essential action and parameter meaning. However, it lacks information on response status, error handling, and how the ID is obtained, which would be helpful for complete invocation context.

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?

The schema has no description for the 'id' parameter, so the description's 'by ID' clarifies that it refers to the stub mapping's identifier. However, it does not elaborate on the expected format or that the ID must correspond to an existing mapping, which is minimal compensation for the 0% schema coverage.

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 ('Delete'), the resource ('WireMock stub mapping'), and the scope ('by ID'). It effectively distinguishes this from sibling tools like mock_update or mock_reset.

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 is provided on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusion criteria, leaving the agent to infer usage solely from the name.

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

mock_getA

Get one WireMock stub mapping by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'Get', which is already evident from the tool name. It does not describe return format, error handling for missing IDs, or any side effects.

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 sentence that directly states the action and target. No unnecessary words or redundancy.

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

Completeness3/5

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

The tool is simple with one parameter and no output schema, but the description omits any information about return values, errors, or prerequisites. It is a minimal description that suffices for a basic get operation but lacks robustness.

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?

The input schema has one required id parameter with no description. The description's 'by ID' clarifies that id is the mapping identifier, adding basic semantics, but does not explain the ID format or how to obtain it. With 0% schema coverage, the description only minimally compensates.

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 uses a specific verb 'Get' with the resource 'WireMock stub mapping' and scope 'by ID', clearly distinguishing this from sibling tools like mock_list or mock_delete.

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?

The description implies usage when a specific mapping ID is known, but does not explicitly state when to prefer this over mock_list or other alternatives. No exclusions or alternative tool names are mentioned.

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

mock_listB

List WireMock stub mappings from the configured instance.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only listing operation, which is transparent, but it omits behavioral details such as pagination behavior, default limits, ordering, and response structure. The core action is clear but incomplete.

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?

The description is a single, front-loaded sentence that directly states the action and target. It contains no unnecessary words, fluff, or repetition of the tool name.

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?

The description is minimal and leaves out important context like return value format, pagination defaults, and how this relates to sibling tools. Given that there are optional pagination parameters and no output schema, more detail is needed for an agent to invoke the tool with confidence.

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

Parameters2/5

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

The input schema has 0% description coverage, and the description does not mention limit or offset at all. While the parameter names hint at pagination, no defaults, maximums, or behavior are explained. The description fails to compensate for the lack of schema descriptions.

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 uses the specific verb 'List' with the resource 'WireMock stub mappings' and identifies the source as 'the configured instance.' This clearly distinguishes it from siblings like mock_get (single mapping), request_list (HTTP requests), and mutation tools.

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 is provided about when to use this tool versus alternatives. There is no explicit mention of mock_get for retrieving a single mapping or request_list for requests, and no exclusions or prerequisites. Usage is only implied by the verb 'List.'

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

mock_resetA

Destructively reset runtime mappings to the configured WireMock backing-store defaults.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly uses the adverb 'destructively' to warn about irreversible effects, and specifies that it resets to backing-store defaults. This provides key transparency about the operation's impact, though it does not detail side effects beyond mappings.

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?

The description is a single sentence, front-loaded with the critical word 'destructively'. Every word contributes meaning: it identifies the action, scope, and target defaults. There is no fluff or redundancy.

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

Completeness5/5

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

For a tool with no parameters, no output schema, and no annotations, the description fully covers the essential context: it resets runtime mappings, and it is destructive. The sibling tools (mock_create, mock_delete, request_clear) provide additional context, but the description itself is self-sufficient for this simple operation.

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 the input schema is an empty object with 100% coverage. No parameter explanations are needed, and the description correctly omits them. Per rubric, a 0-parameter tool with full schema coverage earns a baseline of 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 states a specific verb ('reset') and resource ('runtime mappings'), and clarifies the target state ('configured WireMock backing-store defaults'). It clearly distinguishes this from sibling tools like mock_create, mock_update, and mock_delete, as it performs a bulk reset to defaults.

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?

The description implies the tool is used to restore all runtime mappings to defaults, but it does not explicitly state when to use it instead of alternatives (e.g., deleting individual mappings) or provide any exclusions. The usage is implied rather than explicitly guided.

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

mock_updateA

Update a WireMock stub mapping by ID, preserving advanced WireMock fields.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`mapping`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It reveals one useful behavior—preserving advanced WireMock fields—but omits essential details like failure behavior, prerequisites, idempotency, or response format. For a mutation tool, this is insufficient.

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?

The description is a single, concise sentence that front-loads the verb and resource. There is no redundancy or unnecessary detail—every phrase contributes meaning.

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 the absence of annotations and an output schema, and the presence of a complex nested 'mapping' object, this description is too sparse. It fails to cover return values, error scenarios, or detailed mapping requirements, leaving the agent to rely on inference.

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 description coverage is 0%, so the description must compensate. It does mention the 'id' parameter (by ID) and 'mapping' (the fields to update), and 'preserving' hints at partial update semantics. However, it does not explain the mapping object's structure or the nature of the update operation in detail.

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 uses the specific verb 'Update' with the resource 'WireMock stub mapping by ID', clearly distinguishing it from sibling tools like mock_create, mock_get, and mock_delete. The clause 'preserving advanced WireMock fields' further clarifies the tool's scope.

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

Usage Guidelines4/5

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

The description clearly implies this tool is for modifying an existing stub mapping identified by ID, which is a distinct context from creating or deleting. However, it does not explicitly mention alternatives or state when not to use it, so it falls short of a 5.

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

request_clearA

Clear the entire WireMock request journal without deleting mappings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses that the journal is cleared entirely and that mappings are preserved, which is useful. However, it does not mention reversibility, persistence, or side effects on in-flight requests, leaving some behavioral ambiguity for a destructive action.

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?

The description is a single, concise sentence that conveys all essential information: the action, the target, the scope, and the critical non-destructive exception. No filler or redundancy, every word earns its place.

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

Completeness5/5

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

Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool does and what it avoids. It is sufficient for an agent to understand the tool's scope and impact, and the sibling context around journal clearing is accounted for.

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 takes zero parameters, so there are no parameter semantics to clarify. The schema coverage is trivially 100%, and the description adds nothing about parameters, which is appropriate and complete for a no-argument operation.

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 uses a specific verb 'Clear' with a resource 'WireMock request journal' and scope 'entire', immediately clarifying the operation. The qualifier 'without deleting mappings' distinguishes it from related tools like mock_reset and mock_delete, making its purpose unambiguous.

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

Usage Guidelines4/5

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

The description implies the intended use case: when you want to wipe the request journal but keep mappings intact. It contrasts with mock_reset behavior implicitly, though it does not explicitly name alternatives or exclude other tools. This gives clear context without formal when-to-use statements.

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

request_countC

Count request journal entries matching a WireMock request pattern.

ParametersJSON Schema

Name	Required	Description	Default
`criteria`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior, but it only restates that matching entries are counted. It does not explain whether matching is exact, fuzzy, or based on WireMock request patterns, nor what happens when no matches are found.

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 with no redundant wording. It is well-structured and front-loaded, though the conciseness sacrifices necessary detail.

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 the nested criteria object, lack of annotations, and no output schema, the description provides insufficient context. It fails to explain the return value, criteria format, or how this tool fits into the broader request journal workflow.

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

Parameters1/5

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

Schema coverage is 0% and the description provides no explanation of the 'criteria' parameter. The schema shows an object but gives no hint about its structure or how it relates to a WireMock request pattern, leaving the agent to guess.

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 uses a specific verb ('Count') and resource ('request journal entries') and clearly distinguishes from sibling tools like request_list and request_get by focusing on counting rather than retrieving entries.

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 is provided on when to use this tool versus alternatives like request_list or request_unmatched. There is no mention of criteria semantics, prerequisites, or scenarios where counting is preferred.

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

request_getA

Get one WireMock request journal entry by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses it is a read operation ('Get'), but does not describe behavior for missing IDs, return format, pagination, auth, or rate limits. For a simple get, this is minimal but still lacking context.

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?

The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place, with zero fluff or redundancy.

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

Completeness3/5

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

Given the tool's simplicity, the description is mostly adequate, but with no output schema and no annotations, it fails to state what the returned journal entry looks like or error/edge behavior. The sibling tool context provides some inference, but the description alone is incomplete for an agent to fully anticipate the response.

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 0% for the only parameter, so the description must compensate. It adds the meaning that 'id' is a journal entry ID, which is useful, but it does not provide the ID format or how to obtain it. With a single parameter, this partial compensation earns a mid-score.

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 uses a specific verb ('Get') and resource ('WireMock request journal entry'), with a clear scope ('by ID'). It distinguishes from siblings like request_list (which likely lists all entries) by focusing on a single entry retrieval.

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?

The description implies usage when an ID is available, but does not explicitly state when to use this over alternatives like request_list, nor does it provide exclusions or alternatives. It relies on the parameter name to convey intent, so guidance is only implicit.

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

request_listC

List requests from the WireMock request journal.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`since`	No

TDQS

C2.6/5.0

Behavior2/5

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 only states the basic operation and gives no details about return format, pagination, default limit, ordering, or potential side effects. The phrase 'request journal' adds slight context but insufficiently discloses behavior.

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, front-loaded sentence with no wasteful words. It is appropriately concise for a simple listing operation, though it could be enriched with parameter context without becoming bloated.

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?

The tool has no output schema and optional parameters, so the description should explain return values, parameter effects, and any limits. It does none of this, leaving significant gaps for an agent to safely and effectively invoke the tool.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it doesn't mention 'limit' or 'since' at all. The parameter names are somewhat suggestive, but 'since' remains ambiguous (e.g., timestamp vs. sequence ID), and no details are provided.

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?

The description clearly states the action ('List') and the resource ('requests from the WireMock request journal'), making the tool's purpose unambiguous. It distinguishes from siblings like request_get or request_count by specifying a list operation, though it doesn't explicitly name alternatives.

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 is given about when to use this tool versus other request-related tools. It doesn't mention prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage context solely from the tool name and sibling names.

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

request_unmatchedA

List request journal entries that matched no WireMock stub.

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 are provided, so the description carries full burden. 'List' implies a read-only operation, but it does not explicitly state side effects, auth requirements, or lack of mutation. The absence of parameters and the simple verb provide limited transparency beyond the operation itself.

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?

The description is a single, concise sentence with no redundant words. It provides exactly the needed information in a front-loaded manner.

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 the tool's simplicity (no params, no output schema), the description is nearly complete. It states the core behavior clearly, though it doesn't specify the exact fields returned or behavior when no entries exist. Sibling tool names add some context but are not referenced in the description.

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% (trivially). The baseline for zero parameters is 4, and the description does not need to add parameter semantics. It correctly implies no input 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 uses a specific verb 'List' with a clear resource 'request journal entries' and a distinct qualifier 'matched no WireMock stub'. This clearly distinguishes it from sibling tools like request_list or request_count.

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?

The description implies usage for listing unmatched entries but provides no explicit when-to-use vs alternatives. It does not name sibling tools or explain when this should be chosen over request_list or request_get.

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

wiremock_statusA

Check the configured WireMock Admin API health and version.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden for behavioral disclosure. It states what is checked (health and version), but does not mention response format, potential errors, or whether any state is changed. Since it's likely a read-only health check, the description is adequate but lacks depth.

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?

The description is one short sentence that is front-loaded with the key verb and resource. Every word earns its place, with no redundancy or filler.

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 the tool's simplicity (no params, no output schema, no sibling overlap), the description is sufficiently complete. It explains the purpose and scope, though it could optionally mention what the returned health/version information looks like.

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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter details, but none are needed because the tool takes no inputs.

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 uses a specific verb ('Check') and clearly identifies the resource ('WireMock Admin API') and the scope ('health and version'). It distinguishes this tool from siblings like mock_list and request_get, which serve different purposes.

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

Usage Guidelines4/5

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

The description implies clear usage context: use this tool to check the WireMock Admin API status. It does not explicitly name exclusions or alternatives, but the sibling tools are obviously for mocks/requests, so the usage scenario is evident.

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.

12 tool updatesv0.1.0Aug 11, 2026
- First observedmock_create
- First observedmock_delete
- First observedmock_get
- First observedmock_list
- First observedmock_reset
- First observedmock_update
- First observedrequest_clear
- First observedrequest_count
- First observedrequest_get
- First observedrequest_list
- First observedrequest_unmatched
- First observedwiremock_status

Install Server

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

TDQS

A3.5/5.0

Scored 2026-08-11 16:35 across 12 tools

Disambiguation5/5

Each tool has a distinctly different purpose: status, mock CRUD, and request journal operations. There is no ambiguity between listing, getting, creating, updating, deleting mocks, or between request list/get/unmatched/count/clear.

Naming Consistency4/5

Most tools follow a clear resource_action pattern (mock_list, request_get, etc.). The only deviation is wiremock_status, which uses a noun phrase instead of an action verb, but it is still understandable and consistent with the resource-based naming.

Tool Count5/5

12 tools is well-scoped for a WireMock admin server, covering status, mock lifecycle management, and request journal operations without excessive overlap or unnecessary additions.

Completeness4/5

The tool surface provides full CRUD for stub mappings and a robust set of request journal operations. Minor gaps exist (e.g., no tool for managing global settings or scenarios), but the core WireMock workflows are effectively covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

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

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
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
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
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

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
@restforge-dev/mcp-serverofficial
Developer Tools API Testing
restforge
A
license
A
quality
C
maintenance
MCP server that exposes RESTForge capabilities to AI agents, enabling them to set up, configure, generate code, and manage RESTForge projects through natural language.
Updated 4 months ago (2026-05-08 01:14 UTC)
29
44
MIT
forge-mcp
Coding Agents Agent Orchestration Developer Tools
amigo-ai
A
license
B
quality
C
maintenance
Prototype MCP server enabling coding agents to manage Amigo Agent Forge operations, including org credentials, entity configurations, conversation simulations, and version sets.
Updated 2 months ago (2026-07-12 02:42 UTC)
37
28
ISC
mockserver-mcp
API Testing Testing & QA Tools
Akkshay10
A
license
A
quality
B
maintenance
An MCP server for interacting with MockServer, enabling AI assistants to create mock HTTP expectations, verify requests, clear state, and manage MockServer instances programmatically.
Updated 9 months ago (2025-12-17 04:27 UTC)
6
81
1
MIT

wiremock-mcp

Package

MVP architecture

Requirements

Quick start

1. Start WireMock if you do not already have one

2. Configure the MCP server

Tools

Namespace ownership

Example agent requests

Existing WireMock environments

Safety

Development

Test the package before publishing

npm distribution

CI and releases

Roadmap

MVP — one external WireMock

Next functional step — multiple WireMock instances

Future distribution — all-in-one Docker image

Other possible extensions

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@restforge-dev/mcp-serverofficial