Allows GitHub Copilot to create and manage Mockoon mock APIs through natural language.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mockoon-mcp create a new environment for a pet store API"
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.
An MCP server that lets AI assistants (Claude, GitHub Copilot, Cursor, etc.) create and manage Mockoon mock APIs through natural language.
Node.js 18+
Mockoon Desktop — for managing environment files via the UI
Mockoon CLI (optional) — required only if you want to use the start_server / stop_server tools to start mock servers programmatically (npm install -g @mockoon/cli)
Related MCP server: Mock Server AI MCP
No installation needed. Configure your AI client using npx:
Create .vscode/mcp.json in your workspace:
{
"servers": {
"mockoon": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mockoon-mcp@latest"]
}
}
}Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"mockoon": {
"command": "npx",
"args": ["-y", "mockoon-mcp@latest"]
}
}
}Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project:
{
"mcpServers": {
"mockoon": {
"command": "npx",
"args": ["-y", "mockoon-mcp@latest"]
}
}
}Variable | Description |
| Override the primary storage directory (default: Mockoon Desktop's storage folder) |
| Semicolon-separated list of additional directories to search for environment files |
Default storage path:
Windows: %APPDATA%\mockoon\storage
macOS/Linux: ~/.config/mockoon/storage
Example:
"env": {
"MOCKOON_DATA_DIRS": "/path/to/dir1;/path/to/dir2"
}Tool | Description |
| List all environments with file path and port |
| Create a new environment |
| Permanently delete an environment file |
Tool | Description |
| List all routes in an environment (UUID, method, endpoint, response count) |
| Inspect a single route with all responses, rules, headers and body |
| Create a route with a single default response |
| Create a route + N responses (default + conditionals) in one call |
| Create N routes in one call — ideal for scaffolding an entire API |
| Update method, endpoint, documentation and/or default response fields |
| Clone a route (all responses included) with new UUIDs |
| Delete a route and all its responses |
| Add a conditional/alternative response to an existing route |
| Change which response is marked as default |
| Return the current default response (quick inspect) |
Tool | Description |
| List all databuckets in an environment |
| Create a new databucket |
| Update the content of a databucket |
| Delete a databucket |
Tool | Description |
| Start a mock server for an environment |
| Stop a running mock server |
| List all currently running mock servers |
Note:
start_serverandstop_serverrequire Mockoon CLI to be installed globally (npm install -g @mockoon/cli). If you only use Mockoon Desktop, these tools will not work — but all other tools (environments, routes, databuckets) work without CLI.
Here are some example phrases you can say to your AI assistant to interact with Mockoon via this MCP server:
Exploring environments and routes
"List all available Mockoon environments."
"Show me all the routes in the Taccuino environment."
"Get the full detail of route GET /users/:id, including all responses and rules."
Creating routes
"Create a GET /products route in the Demo API environment that returns a JSON array of 3 products with status 200."
"Add a POST /auth/login route with two responses: 200 with a token body and 401 Unauthorized."
"Scaffold a full CRUD API for a Task resource under /tasks in the Demo environment."
Updating and managing routes
"Change the default response of GET /users to return status 204 with an empty body."
"Duplicate the GET /orders route."
"Delete the DELETE /legacy/endpoint route from the environment."
"Add a conditional 403 response to POST /documents that triggers when the X-Role header equals guest."
Databuckets
"Create a databucket called UserList in the Demo API with a JSON array of 5 fake users."
"Update the ProductCatalog databucket with a new list of items."
Server management
"Start the mock server for the Taccuino environment."
"Stop all running mock servers."
"Which Mockoon environments are currently running?"
The server communicates via stdio (JSON-RPC 2.0). It reads and writes Mockoon's environment JSON files directly, no REST API involved.
Changes made by the MCP server are reflected in Mockoon Desktop automatically if the Environment file watcher is enabled. Go to Application → Settings and set it to Auto for silent reloads.
MIT — see LICENSE.
Add a new conditional or alternative response to an existing route. Use rules to define when this response is activated.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | Route UUID | |
| statusCode | No | HTTP status code | |
| body | No | Response body (plain text or JSON string) | |
| label | No | Label for this response (optional) | |
| contentType | No | Content-Type header value | application/json |
| headers | No | Additional headers (excluding Content-Type) | |
| rules | No | Activation rules for this response | |
| rulesOperator | No | Logical operator between rules | OR |
| isDefault | No | Mark this response as the default (demotes all others) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic action (add) and mention of rules, but does not disclose side effects (e.g., overriding existing responses, handling of isDefault) or authorization needs.
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 concise, front-loaded sentences with no wasted words. Efficient and clear.
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?
With 10 parameters and no output schema or annotations, the description is minimal. It does not cover return values, side effects, or prerequisites like route existence, leaving gaps for a complex 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 description coverage is 100%, so parameters are documented. The description adds context for 'rules' but does not provide additional meaning for other parameters beyond what schema already offers. Baseline 3 is appropriate.
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?
Clearly states 'Add a new conditional or alternative response to an existing route', which identifies the action and resource. However, it could better differentiate from similar tools like set_default_response or create_route_with_responses.
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 guidance to 'Use rules to define when this response is activated', but lacks explicit when-to-use vs alternatives and does not mention prerequisites (e.g., route must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple routes at once. Each item in the array follows the same structure as create_route_with_responses. Ideal for scaffolding an entire API in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routes | Yes | List of routes to create |
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 does not mention important traits such as atomicity, partial failure handling, idempotency, authentication requirements, or rate limits, which are critical for a bulk operation.
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 extremely concise: two sentences that are front-loaded with the action and purpose. Every word earns its place 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?
Given the tool's complexity (nested array, many subfields) and absence of an output schema, the description is too minimal. It does not address response behavior, limitations, or error handling, leaving gaps for an AI agent to safely invoke this bulk operation.
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 the schema already documents parameters. The description adds value by stating that each item follows the structure of create_route_with_responses, linking to a known sibling tool and providing contextual understanding beyond the raw 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 creates multiple routes at once, referencing the sibling tool create_route_with_responses, and distinguishes itself from single-route tools by emphasizing bulk creation and scaffolding use case.
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 identifies an ideal use case ('scaffolding an entire API in one call'), implying when to use this tool over individual route creation. However, it lacks explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Mockoon environment
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Environment name | |
| port | Yes | Port for the mock server |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only indicates a creation action but omits details like whether creation is idempotent, if duplicate names are allowed, or if conflicts (e.g., port already in use) are handled. This leaves the agent uncertain about 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose. Every word is meaningful, with no unnecessary information. It is front-loaded and earns its place.
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 creation tool with no output schema or annotations, the description lacks completeness. It does not explain what the tool returns (e.g., created environment object), potential errors, or integration with sibling tools (e.g., listing or starting the environment). This leaves gaps for the agent to infer.
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 already covers both parameters (name, port) with descriptions, achieving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate. No additional constraints or formatting hints are provided.
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 'Create a new Mockoon environment' clearly states the verb 'create' and the resource 'environment', making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like delete_environment, list_environments, etc., by specifying creation.
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 no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., need to create environment before routes) or context (e.g., if environment creation is a prerequisite for starting a server). This absence of usage context reduces utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new HTTP route with a single default response. Use create_route_with_responses to add multiple responses in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| method | Yes | HTTP method | |
| endpoint | Yes | Route path without leading slash (e.g. users/:id) | |
| documentation | No | Optional documentation / description for the route | |
| statusCode | No | HTTP status code | |
| body | No | Response body (plain text or JSON string) | |
| contentType | No | Content-Type header value | application/json |
| headers | No | Additional response headers (excluding Content-Type) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates a creation operation but does not disclose potential side effects, error conditions, or permissions needed. It is adequate but not thorough.
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 main purpose, and no extraneous information. Highly concise.
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?
The tool has no output schema and does not explain return values (e.g., created route object) or potential errors. The description omits what happens upon success, leaving the agent uncertain about the result.
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 description adds minimal additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 'Create a new HTTP route with a single default response', specifying the verb and resource, and distinguishes itself from the sibling tool create_route_with_responses.
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 directs users to create_route_with_responses for adding multiple responses, providing clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new HTTP route together with all its responses (default + conditionals) in a single call. The first response in the list is treated as the default unless one has isDefault=true.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| method | Yes | HTTP method | |
| endpoint | Yes | Route path without leading slash (e.g. users/:id) | |
| documentation | No | Optional route description | |
| responses | Yes | Array of responses. First one becomes default unless isDefault is set on another. |
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 only mentions the default response selection logic but lacks disclosure of other behavioral traits such as side effects (e.g., whether existing routes are overwritten), error states, idempotency, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a helpful note. It is extremely concise with no unnecessary words or repetition.
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 (5 parameters, nested responses array), the description is too brief. It does not cover prerequisites (e.g., environment existence), workflow, or return values (no output schema). Important context is missing.
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 the baseline is 3. The description adds a small nuance about default response selection, but otherwise the schema already describes the parameters adequately. The added value is minimal.
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 a new HTTP route together with all its responses (default + conditionals) in a single call.' This distinguishes it from siblings like create_route (which likely creates a route without responses) and add_route_response (adds responses individually).
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 mentions that 'The first response in the list is treated as the default unless one has isDefault=true,' which gives a usage hint. However, it does not explicitly state when to use this tool versus alternatives (e.g., create_route followed by add_route_response), nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new databucket (data template) in a Mockoon environment
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| name | Yes | Databucket name | |
| value | Yes | JSON content or Handlebars template for the databucket |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only states 'Create' implying a write operation, but lacks disclosure of side effects, permissions, idempotency, or failure 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 a single sentence with no unnecessary information, making it concise. However, it could be slightly restructured to front-load key information.
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?
With 3 required parameters, no annotations, and no output schema, the description lacks context about the databucket purpose, value parameter format, or expected outcome. It is insufficient for an agent to fully understand the tool's usage.
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% with descriptions for all three parameters. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 'Create' and the resource 'databucket (data template)' within a Mockoon environment, which is specific. However, it does not explicitly differentiate from sibling tools like create_route or create_environment, though the resource type is distinct.
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 no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. The agent receives no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Mockoon environment by UUID. The environment file will be permanently removed from disk.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | UUID of the environment to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the file is permanently removed from disk, which discloses irreversibility. However, it does not mention any side effects, such as whether a running server is stopped or if authorization is needed, which would be useful for an agent. The irreversibility is a key behavioral trait.
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 extremely concise with two sentences, conveying all necessary information without any wasted words. It is front-loaded with the action and identifier.
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 simple delete operation with one parameter and no output schema, the description is nearly complete. It covers the core behavior (permanent deletion). However, it could mention implications for running servers or permissions, which are not covered. Given the simplicity, it is sufficient for most use cases.
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 parameter is fully described in the schema. The description adds no additional semantics beyond the schema, aligning with the baseline score 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 action (delete a Mockoon environment by UUID) and specifies the resource (environment file). It distinguishes from siblings like create_environment or delete_route by focusing on environment deletion.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies a straightforward delete operation but does not mention prerequisites, such as stopping a running server before deletion, nor does it provide alternatives. This is a basic delete operation, so lack of guidelines is acceptable but not exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a route and all its responses from a Mockoon environment.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | UUID of the route to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explicitly states the destructive cascading nature ('all its responses'). However, it does not mention irreversibility, required permissions, or error conditions.
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?
A single sentence that front-loads the verb and clearly states the operation. No extraneous words.
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 simple delete operation, the description is adequate. It names the parameters and the effect. However, it could mention what happens on success (e.g., no content response) or error cases.
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% with descriptions for both parameters, so the baseline is 3. The tool description does not add additional context beyond the 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 action ('Delete') and the specific resources ('route and all its responses') within a 'Mockoon environment'. This distinguishes it from siblings like 'create_route' or 'duplicate_route'.
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?
No guidance on when to use this tool versus alternatives like 'update_route' or 'bulk_create_routes'. There is no mention of prerequisites or scenarios where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a databucket from a Mockoon environment
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| templateId | Yes | UUID of the databucket to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states a destructive action ('Delete') but does not mention irreversibility, side effects (e.g., cascade deletion of associated data), or whether the environment or databucket must exist. This is insufficient for a deletion operation.
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 a single sentence of eight words, with no filler or redundant information. It is highly concise and front-loaded, earning its place without any waste.
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 simple delete tool with two parameters and no output schema, the description is minimal but adequate. It does not specify return behavior, error conditions, or consequences of deletion, which a more complete description would include. However, given the tool's simplicity, it meets a baseline level of 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?
Schema description coverage is 100%, with each parameter having a basic description (e.g., 'Environment UUID'). The description adds minimal value beyond the schema by indicating the operation's context, but it does not clarify parameter semantics further. Baseline 3 is appropriate.
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 'Delete a databucket from a Mockoon environment' uses a specific verb (Delete) and resource (databucket), clearly distinguishing from sibling tools like delete_environment and delete_route which operate on different resources. The tool name 'delete_template' aligns with the description despite the synonym 'databucket', making the purpose 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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or conditions for deletion. It lacks explicit when-to-use or when-not-to-use context, leaving the agent to infer that it should only be used when intending to delete a databucket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone an existing route (with all its responses) into the same environment. All UUIDs are regenerated. The copy gets '(copy)' appended to its documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | UUID of the route to duplicate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It mentions UUID regeneration and appending '(copy)', indicating it's a write operation, but does not disclose permissions needed, whether the original is modified, or the return 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?
Two sentences, front-loaded with the main action, no redundant words. Every sentence provides essential information.
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 simple clone operation with no output schema, the description is fairly complete. It explains what is cloned, UUID regeneration, and naming. However, it could mention that the original route is unchanged and what the tool returns.
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 the schema already documents both parameters. The description adds no additional parameter details beyond what is in the schema, so it meets 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 clones an existing route with all responses into the same environment, and distinguishes it from sibling tools like create_route by noting it duplicates an existing route rather than creating from scratch.
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 does not provide explicit guidance on when to use this tool over alternatives like create_route or create_route_with_responses. It does not mention prerequisites (e.g., the route must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current default response of a route (status code, headers, body). Use get_route for full details including all responses.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | Route UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the return values (status code, headers, body) but does not mention error behavior (e.g., when route does not exist) or authorization requirements. Slight gap, but overall clear for a read operation.
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 efficient sentences with no wasted words. The key information (purpose and usage guidance) is front-loaded.
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?
No output schema exists, so the description must clarify return values. It does list the components (status code, headers, body), which is adequate. Could be more detailed on format, but sufficient for a simple read 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 description coverage is 100%, with meaningful descriptions for both parameters. The tool description adds no additional information beyond the schema, so baseline score of 3 is appropriate.
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?
Clearly states the tool returns the default response of a route, specifying components (status code, headers, body). Distinguishes from sibling tool get_route by noting that tool provides full details.
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?
Explicitly advises using get_route for full details including all responses, providing clear guidance on when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full details of a single route including all responses (status codes, labels, rules, headers, body).
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | Route UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states that the tool returns details including responses, which is sufficient for a read operation. It doesn't mention error handling or auth, but the core behavior is transparent.
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?
A single, well-structured sentence that is front-loaded with the action and resource, and concisely lists the included details. No unnecessary words.
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 absence of an output schema, the description enumerates the return categories (status codes, labels, rules, headers, body). This provides adequate context for a get operation, though error conditions are not covered.
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 the parameters are already well-described. The tool description does not add further meaning beyond what the schema provides, earning a baseline score 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 uses a specific verb ('Return') and resource ('full details of a single route'), and clearly distinguishes from sibling tools like list_routes (which returns a list) and add_route_response (which adds a response).
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?
No explicit when-to-use or when-not-to-use guidance is provided. It's implied that this tool is used to retrieve a specific route's details, but there is no mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all local Mockoon environment files. Returns the file path for each environment, which can be passed to start_mock. Searches the default storage directory and any extra directories set via MOCKOON_DATA_DIRS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses it searches directories, returns file paths, and is a read-only list operation. It doesn't mention error handling or permissions, but for a simple list tool this is adequate.
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 purpose, no wasted words. Efficient and clear.
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?
Covers what, where, and output format. Missing details on absolute/relative paths, but sufficient for an agent to use correctly alongside sibling tools.
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?
No parameters in schema, so description adds meaning by explaining the search scope and return value, which is valuable beyond the empty 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?
Description clearly states it lists all local Mockoon environment files and returns file paths. The verb 'list' and resource 'environment files' are specific, and the mention of passing to 'start_mock' distinguishes it from sibling tools like create_environment or start_server.
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 context on where it searches (default directory and MOCKOON_DATA_DIRS), implying when to use it. No explicit when-not or alternatives, but sibling differentiation is clear through naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all routes in a Mockoon environment with their UUIDs, method, endpoint and number of responses.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It correctly implies a read-only operation by stating it 'lists' routes, but it does not disclose any potential side effects, authentication requirements, or whether the list is paginated. The transparency is adequate but not enriched beyond the obvious.
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 a single, concise sentence that contains all essential information without any fluff. It is front-loaded with the verb and resource, and every phrase earns its place.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description covers the main points: what is listed and the included attributes. It could potentially mention if there is pagination or limits, but for a basic list operation, it is sufficiently 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?
Schema coverage is 100% (environmentId is described as 'Environment UUID'). The description does not add additional meaning to the parameter beyond what the schema already provides. The parameter is straightforward, and the schema handles the semantics adequately.
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 'list', the resource 'routes', the scope 'all routes in a Mockoon environment', and the specific attributes returned (UUIDs, method, endpoint, number of responses). This distinguishes it from sibling tools like 'get_route' (single route) and 'create_route'.
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 does not explicitly state when to use this tool versus alternatives, such as using 'get_route' for a specific route. Usage is implied by the listing purpose, but no exclusions or contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the UUIDs of all Mockoon environments currently running as mock servers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly describes a read-only operation that returns UUIDs of running servers, with no side effects. Adding an explicit statement of non-destructiveness would strengthen it, but the behavior is clear.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose.
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 simple list tool with no parameters and no output schema, the description is sufficient. It specifies what is listed (UUIDs of running environments). A minor addition about the format (e.g., list of strings) could improve completeness, but it is already effective.
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 tool has zero parameters, and the schema coverage is 100% (empty). The description adds no parameter information, which is appropriate. Following the guideline, a baseline of 4 is given.
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 'List' and the resource 'UUIDs of all Mockoon environments currently running as mock servers.' It distinguishes from sibling tools like 'list_environments' (which likely lists all environments) and 'start_server'/'stop_server'.
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 implies usage when you need to know which environments are currently running, but it does not explicitly state when to use this tool versus alternatives like 'list_environments' or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databuckets (data templates) in a Mockoon environment
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states it lists templates, without mentioning side effects, authentication needs, rate limits, or return format. This is insufficient for a read operation.
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 a single sentence with no unnecessary words, efficiently conveying the core purpose.
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 simple list tool with one parameter, the description is adequate but lacks details on output, pagination, or any behavioral nuances. It meets minimum viability but has clear 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?
Schema coverage is 100% with the environmentId parameter described as 'Environment UUID'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'List', the resource 'databuckets (data templates)', and the scope 'in a Mockoon environment', distinguishing it from sibling tools like list_environments and list_routes.
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?
No explicit guidance on when to use this tool versus alternatives. It only implies listing templates given an environmentId, but fails to mention conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set an existing response as the default for a route (demotes all other responses). Use get_route to list response UUIDs.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | Route UUID | |
| responseId | Yes | UUID of the response to make default |
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 the behavioral effect of demoting all other responses. However, it does not mention whether the operation is reversible or any authentication requirements.
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, no fluff. The most important information is front-loaded: the action and its side effect. The second sentence provides a useful pointer. Every word earns its place.
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 simple tool with 3 required parameters and no output schema, the description is clear and actionable. It could mention what happens if the response is already default or if the route doesn't exist, but it is adequate for typical 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% and each parameter is clearly described in the schema. The description adds context about obtaining responseId via get_route, but this is not specific to parameter semantics. The additional value is marginal, so baseline 3 is appropriate.
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 'Set' and the resource 'an existing response as the default for a route', with the side effect 'demotes all other responses'. It distinguishes from sibling tools like get_default_response and add_route_response.
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 instructs to use get_route to list response UUIDs, providing necessary prerequisite. It implicitly differentiates from reading (get_default_response) and adding (add_route_response) but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Mockoon mock server from a local environment JSON file. Use list_environments to find available file paths. Returns immediately with an error if the server is already running.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | UUID of the environment to start | |
| port | No | Override port (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool starts a server from a file and returns an error if the server is already running. However, it does not specify what happens on success (e.g., returns the port or status), nor does it mention required permissions or asynchronous 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 extremely concise, consisting of two short sentences that convey essential information. It is front-loaded with the action, and every word serves a purpose.
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 tool is simple, the description lacks details about the successful outcome (e.g., what the response contains, such as the started server's port or status). Since there is no output schema, the description should compensate, but it only mentions the error case.
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 the two parameters (environmentId and port). The description adds no additional semantic detail beyond the schema, so the baseline of 3 is appropriate.
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 action ('Start a Mockoon mock server') and the resource ('from a local environment JSON file'). It also references a sibling tool (list_environments) to find the file paths, distinguishing it from stop_server and list_running_servers.
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 tells the agent to use list_environments to find available file paths and warns that calling start_server when the server is already running will return an error immediately. This provides clear guidance on when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running Mockoon mock server. Returns an error message if no server is running for the given environment.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | UUID of the environment to stop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the transparency burden. It mentions an error case but does not disclose side effects, permissions, or what happens on success.
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, each essential, with no redundancy or wasted words.
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 simple single-parameter tool without output schema, the description covers the main functionality and an error condition, though success behavior is implied rather than stated.
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 the description does not need to add much. It repeats the parameter's purpose but does not provide additional meaning beyond the 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 uses a specific verb ('stop') and resource ('Mockoon mock server'), and distinguishes from sibling tools like start_server and list_running_servers.
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 clearly states the context ('running... server') and implies when to use it, but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a route's method, endpoint, documentation and/or its default response (body, status code, headers). Only provided fields are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| routeId | Yes | Route UUID | |
| method | No | New HTTP method (optional) | |
| endpoint | No | New route path (optional) | |
| documentation | No | New documentation string (optional) | |
| body | No | New body for the default response (optional) | |
| statusCode | No | New status code for the default response (optional) | |
| headers | No | New full header list for the default response — replaces existing headers (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions that only provided fields are changed (partial update), but does not disclose side effects, authorization needs, or what happens on validation failure. More depth is needed for a mutation tool.
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 long, front-loaded with the main action, and every word is purposeful. It is highly concise with no filler.
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?
The description covers the core purpose but lacks information about the return value (no output schema). It does not differentiate from sibling tools like add_route_response or set_default_response. For a tool with 8 parameters, the description is sufficient but could be more 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?
Schema description coverage is 100%, so the baseline is 3. The description reaffirms which fields are updatable and notes the partial update nature, but does not add significant new meaning beyond what the schema already provides (e.g., schema already says headers replaces existing headers).
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 'update', the resource 'route', and lists the specific attributes that can be updated (method, endpoint, documentation, default response components). It also clarifies that it's a partial update ('Only provided fields are changed'), which distinguishes it from siblings like create_route and delete_route.
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 no explicit guidance on when to use this tool versus alternatives (e.g., add_route_response, set_default_response). It does not mention prerequisites such as the route existing or environment being valid, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the content of an existing databucket
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment UUID | |
| templateId | Yes | Databucket UUID | |
| value | Yes | New databucket value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'Update the content' without specifying whether it's a full replacement, partial update, any side effects, permissions needed, or response format. Almost completely opaque.
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?
Single sentence is concise but sacrifices structure. Missing key details that would make it more useful without being overly long.
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 mutation tool with no output schema and no annotations, the description is severely incomplete. It does not explain what 'content' means, the nature of the update (merge or replace), or what happens after the update.
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 minimal descriptions. The tool description adds no additional semantics beyond what the schema already provides. Baseline 3 is appropriate per guidelines.
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?
Description states 'Update the content of an existing databucket,' but the tool name is 'update_template', creating confusion about whether it operates on templates or databuckets. This mismatch undermines clarity for an AI agent selecting the tool.
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?
No guidance on when to use this tool versus alternatives like create_template or update_route. The description does not explain prerequisites or contexts where the tool is appropriate.
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.
v1.0.2add_route_responsebulk_create_routescreate_environmentcreate_routecreate_route_with_responsescreate_templatedelete_environmentdelete_routedelete_templateduplicate_routeget_default_responseget_routelist_environmentslist_routeslist_running_serverslist_templatesset_default_responsestart_serverstop_serverupdate_routeupdate_templateEach tool targets a specific operation on a distinct resource (environments, routes, responses, templates, servers). Tools like get_route and get_default_response are clearly differentiated by scope. No two tools have overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_environment, list_routes, set_default_response). No mixed conventions or irregular names.
21 tools is well-scoped for an API mocking server. It covers environment, route, response, template, and server lifecycle without excess. Each tool serves a clear purpose.
The tool set covers CRUD for routes, environments, and templates, plus server start/stop and response management. A notable gap is the lack of an update_environment tool, but overall the surface is comprehensive for typical mocking workflows.
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.
Build, validate, and manage API simulations in WireMock Cloud from MCP-compatible AI agents.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Albenzoo/Mockoon-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server