Loading ToolBench
MCP server for Mock Fleet - provides tools to manage WireMock mock configurations, lifecycle operations, stub management, request handling, and mock testing
Mock Fleet MCP demonstrates solid foundational quality with 32 well-named, documented tools operating on WireMock and Kubernetes Fleet APIs. All tools follow consistent verb_noun naming conventions (list_*, get_*, create_*, update_*, delete_*, start_*, stop_*) and include descriptions. Input schemas are present with types and descriptions for all parameters. However, several gaps prevent a higher score: (1) Output schemas are not documented in the provided source, response structures are inferred but not formally specified, making downstream tool composition harder for LLMs. (2) Parameter descriptions, while present, are often terse (10-30 chars) and lack actionable constraints, e.g., 'limit' is described as 'Page size' without stating the valid range (1-100?). (3) Error handling details are absent from the definitions; no guidance on retryability, recovery steps, or what happens on concurrency conflicts (resourceVersion mismatches). (4) Tool composition could be stronger, tools like import_mock_configs require understanding of Kubernetes resourceVersion patterns, which is not documented for LLMs unfamiliar with optimistic concurrency control. (5) No per-tool risk annotations in the source code (only inferred from tool names and input params).
Count logged requests in a running mock pod matching request criteria (WireMock tool).
Create a new stub in a running mock pod (WireMock tool).
Delete a binary body file from a running mock pod (WireMock tool).
Atomically delete a saved mock configuration using optimistic concurrency control.
Delete a stub from a running mock pod (WireMock tool).
Export saved mock overrides as a reusable configuration array; omit mockId to export all. Does not include inherited defaults or start pods.
Find logged requests in a running mock pod matching request criteria (WireMock tool).
Output schemas not documented in tool definitions. Response structures for all 32 tools are inferred from API behavior but not formally specified. This breaks downstream tool composition, LLMs cannot plan multi-step workflows when they don't know what fields a tool returns.
Parameter descriptions are terse and lack actionable constraints. 'limit' is described as 'Page size' without specifying valid range (1 - 100? 1 - 1000?). 'cursor' is 'Opaque continuation cursor', too vague. Constraints like min/max, allowed enum values, and format requirements must be in the description text for LLM consumption (they cannot parse JSON Schema fields).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2025-06-18+ | v2 |
Get a binary body file from a running mock pod (WireMock tool).
Get one mock's configuration and Fleet routing metadata.
Get near-miss request/stub pairings from a running mock pod (WireMock tool).
Get recording status in a running mock pod (WireMock tool).
Get one stub's configuration from a running mock pod (WireMock tool).
Atomically create or replace saved mock overrides from a configuration array using optimistic concurrency. Preserves other mocks and applies to future pods only.
List binary body files stored in a running mock pod (WireMock tool).
List configured and active Mock Fleet mocks without starting any mock pod.
List the public option catalog for an optional exact WireMock 3.x version.
List state machine scenarios configured in a running mock pod (WireMock tool).
List stubs configured in a running mock pod (WireMock tool).
List requests that did not match any stub in a running mock pod (WireMock tool).
Save a stub to disk in a running mock pod (WireMock tool).
Store or replace a binary body file in a running mock pod (WireMock tool).
Clear the request journal in a running mock pod (WireMock tool).
Reset all state machine scenarios in a running mock pod (WireMock tool).
Send a test request to a running mock pod and receive the response (WireMock tool).
Save recorded requests as JSON stubs in a running mock pod (WireMock tool).
Start a mock pod for a configured mock if not already running.
Start request recording in a running mock pod (WireMock tool).
Stop a running mock pod.
Stop request recording in a running mock pod and show candidate stubs (WireMock tool).
Remove a stub from disk in a running mock pod (WireMock tool).
Atomically create, replace, or partially update one saved mock configuration using optimistic concurrency control.
Update an existing stub in a running mock pod (WireMock tool).
Optimistic concurrency control (resourceVersion) is undocumented for LLM use. Tools update_mock_config, delete_mock_config, and import_mock_configs require a 'resourceVersion' parameter from get_mock_config responses, but this Kubernetes pattern is not explained. LLMs will not understand why these calls fail with 409 Conflict or how to recover. Needs explicit recovery guidance: 'If you get a concurrency conflict, call get_mock_config to fetch the latest resourceVersion and retry.'
No documented error handling or recovery paths. Tool descriptions do not explain failure modes (e.g., 'Mock not found', 'WireMock pod unreachable', 'ConfigMap conflict') or what LLMs should do next (retry? lookup? ask user?). Errors returned by the server must include actionable next steps.
Tool composition gaps. Import/export tools require understanding of array format and resourceVersion. Stub operations require 'mockId' and 'stubId', but there is no guidance on obtaining a stubId if only a request path is known. Tools should explicitly document lookup sequences: 'To update a stub by path, call list_stubs first to find its UUID.'
Create/update distinction not clarified. update_mock_config creates or updates based on whether the mock exists, but this overloading is not documented. Parameter 'baseline' is 'optional for update', when is it required? When should LLMs provide it? Adds ambiguity.
Risk annotations present in input but not in source code. Mock ID and stubId are string types with no validation hints. LLMs cannot verify format (UUID? kebab-case? arbitrary string?) before calling tools. Descriptions should state: 'Mock ID: lowercase alphanumeric and hyphens, 1-63 chars' or similar.
No documented prerequisites or state dependencies. send_request, for example, silently fails if the mock pod is not running, but the description does not warn LLMs. Similarly, snapshot_requests requires that recording was active. Tools should state: 'Requires mock to be running (call start_mock first if needed).'