Click on "Deploy 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., "@whistle-mcp 帮我创建一个Mock，请求 api.example.com/user/info 时返回张三的信息"
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.
MCP (Model Context Protocol) Server for whistle - 让 AI 直接操作 whistle 的 Mock 数据。
# 全局安装（推荐）
npm install -g whistle-mcp
# 或直接用 npx，无需安装
npx whistle-mcpRelated MCP server: Whissle MCP Server
编辑 Cursor 的 MCP 配置文件（~/.cursor/mcp.json）：
{
"mcpServers": {
"whistle": {
"command": "npx",
"args": ["-y", "whistle-mcp"],
"env": {
"WHISTLE_BASE_URL": "http://127.0.0.1:8899",
"WHISTLE_USERNAME": "",
"WHISTLE_PASSWORD": ""
}
}
}
}全局安装后也可以写成：
{
"mcpServers": {
"whistle": {
"command": "whistle-mcp",
"env": {
"WHISTLE_BASE_URL": "http://127.0.0.1:8899"
}
}
}
}编辑 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：
{
"mcpServers": {
"whistle": {
"command": "npx",
"args": ["-y", "whistle-mcp"],
"env": {
"WHISTLE_BASE_URL": "http://127.0.0.1:8899",
"WHISTLE_USERNAME": "",
"WHISTLE_PASSWORD": ""
}
}
}
}如果 whistle 启用了鉴权（
w2 start -u admin -p 123456），请填写WHISTLE_USERNAME和WHISTLE_PASSWORD。
任何支持 stdio 传输的 MCP 客户端都可以使用：
WHISTLE_BASE_URL=http://127.0.0.1:8899 \
WHISTLE_USERNAME=admin \
WHISTLE_PASSWORD=123456 \
npx -y whistle-mcpwhistle_rule_list - 获取所有规则列表
whistle_rule_get - 获取规则内容
whistle_rule_set - 创建/更新规则
whistle_rule_remove - 删除规则
whistle_rule_enable / whistle_rule_disable - 启用/禁用规则
whistle_value_list - 获取所有 Values
whistle_value_get - 获取 Value 内容
whistle_value_set - 创建/更新 Value
whistle_value_remove - 删除 Value
whistle_mock_create - 一键创建完整 Mock 方案（规则 + Values）
whistle_mock_apply - 启用/禁用 Mock 规则
whistle_sessions_list - 获取最近抓包的 session 列表，可按 URL / HTTP 方法过滤
whistle_session_get - 获取单个请求的完整详情，自动解析 Query 参数、POST 参数和响应 JSON 字段树
whistle_sessions_search - 按请求参数名（query/POST body）或响应 JSON 字段名搜索抓包，例如"哪些请求带了 token 参数"、"哪些接口返回了 address 字段"
whistle_status - 检查 whistle 服务状态
whistle_server_info - 获取服务器信息
变量 | 默认值 | 说明 |
| 自动探测 | whistle Web UI 地址。不设置时会自动读取 |
| `` | whistle 鉴权用户名（可选） |
| `` | whistle 鉴权密码（可选） |
MCP Server 启动时会自动检测运行中的 whistle 实例（不管用什么端口启动），优先级：
环境变量 WHISTLE_BASE_URL（显式指定，最高优先级）
whistle 状态文件 ~/.startingAppData/（自动探测）
默认 http://127.0.0.1:8899（fallback）
所以即使你 w2 start -p 8888 用别的端口启动，也能自动识别，无需改配置。
AI 指令：
帮我创建一个 Mock，当请求
api.example.com/user/info时返回用户数据
AI 会调用：
{
"tool": "whistle_mock_create",
"arguments": {
"pattern": "api.example.com/user/info",
"response": {
"code": 200,
"data": {
"id": 12345,
"name": "张三",
"email": "zhangsan@example.com"
}
},
"statusCode": 200,
"delay": 100
}
}AI 指令：
列出所有 whistle 规则
AI 会调用：
{
"tool": "whistle_rule_list"
}AI 指令：
把用户 Mock 数据里的邮箱改成 lisi@example.com
AI 会调用：
{
"tool": "whistle_value_set",
"arguments": {
"name": "mock_value_1234567890",
"content": "{\"statusCode\":200,\"headers\":{\"Content-Type\":\"application/json\"},\"body\":{\"code\":200,\"data\":{\"id\":12345,\"name\":\"张三\",\"email\":\"lisi@example.com\"}}}"
}
}AI 指令：
帮我看看最近有没有抓到 api.vip.com 的请求
AI 会调用：
{
"tool": "whistle_sessions_list",
"arguments": {
"urlFilter": "api.vip.com",
"count": 10
}
}AI 指令：
查看最后一个请求的完整响应数据
AI 会调用：
{
"tool": "whistle_session_get",
"arguments": {
"id": "abc123-def456"
}
}AI 指令：
查一下最近有没有请求带了 userId 参数
AI 会调用：
{
"tool": "whistle_sessions_search",
"arguments": {
"param": "userId",
"count": 50
}
}AI 指令：
看看最近 POST 到 api.vip.com 的接口，返回的数据里有没有 address 字段
AI 会调用：
{
"tool": "whistle_sessions_search",
"arguments": {
"urlFilter": "api.vip.com",
"method": "POST",
"field": "address",
"count": 50
}
}whistle 已安装并运行：
npm i -g whistle
w2 start确认 whistle Web UI 可访问：
curl http://127.0.0.1:8899/cgi-bin/status┌─────────────┐ MCP (stdio) ┌──────────────────┐ HTTP ┌─────────────┐
│ AI Client │ ◄──────────────────► │ whistle-mcp-server│ ◄─────────────► │ whistle │
│ (Claude/ │ │ (Node.js) │ │ (127.0.0.1 │
│ Cursor) │ │ │ │ :8899) │
└─────────────┘ └──────────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ ~/.whistle/ │
│ rules/ │
│ values/ │
└─────────────┘# 启动 whistle
w2 start
# 启动 MCP Server（开发模式）
npm run dev
# 测试 MCP 协议
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node src/index.js查看 whistle Web UI 的 CGI 接口：
# 规则列表
curl http://127.0.0.1:8899/cgi-bin/rules/list
# Values 列表
curl http://127.0.0.1:8899/cgi-bin/values/listMIT
启用或禁用指定的 Mock 规则
| Name | Required | Description | Default |
|---|---|---|---|
| enable | No | true=启用，false=禁用 | |
| ruleName | Yes | 规则名称 |
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 mentions the enable/disable action but does not disclose side effects, error behavior (e.g., what happens if the rule does not exist), persistence, or whether the operation is reversible. This is a significant gap for a mutating 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 a single, efficient sentence that immediately conveys the core purpose. It is appropriately sized, though it does omit usage and behavioral details, but this does not detract from conciseness.
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 annotations, no output schema, and the existence of closely related sibling tools, the description is incomplete. It does not explain return values, error conditions, or how this tool fits alongside the separate enable/disable tools, leaving the agent without enough context for reliable invocation.
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 provides full descriptions for both parameters (enable with true=enable, false=disable; ruleName as the rule name). Since schema description coverage is 100%, the description does not need to add parameter details. The tool description itself adds no extra semantic nuance 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 '启用或禁用指定的 Mock 规则' clearly states the tool enables or disables a specified mock rule, providing a specific verb and resource. However, it does not distinguish this tool from sibling tools like whistle_rule_enable and whistle_rule_disable, which appear to offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as whistle_rule_enable or whistle_rule_disable. The description only states what the tool does, not the contextual use cases or exclusions, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
一键创建完整 Mock 方案：自动生成 Value（存储响应数据）+ 规则（匹配 URL），并立即启用
| Name | Required | Description | Default |
|---|---|---|---|
| delay | No | 响应延迟（毫秒） | |
| headers | No | 自定义响应头 | |
| pattern | Yes | URL 匹配模式，如 api.example.com/user 或 */api/user | |
| response | Yes | Mock 响应的 JSON 数据 | |
| ruleName | No | 自定义规则名称（可选，默认自动生成） | |
| statusCode | No | HTTP 状态码 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure burden. It clearly states two key side effects: automatically generating a Value (storing response data) and a Rule (matching URL), and immediately enabling the rule. This goes beyond a simple 'creates a mock' statement. However, it does not mention potential overwriting behavior, failure modes, or 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?
The description is a single concise sentence, front-loaded with the main action, and contains no redundant or filler content. Every part adds value: one-click creation, auto-generation of value and rule, and immediate enabling.
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 moderate complexity with 6 parameters and nested objects, and no output schema. The description covers the core behavior but does not explain what is returned (e.g., generated rule/value names), or how the tool behaves if the pattern already exists. Given the lack of annotations and output schema, the description is adequate but not fully 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 adds minimal parameter semantics—it implies that 'pattern' is used for URL matching and 'response' is the stored data, but this is already stated in the schema parameter descriptions. No additional parameter meaning is 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?
Description clearly states a specific verb+resource: '一键创建完整 Mock 方案' (one-click create complete Mock solution), and explains it auto-generates a Value and a Rule. This distinguishes it from sibling tools that handle rules or values separately, such as whistle_rule_set and whistle_value_set.
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?
Usage is implied: the description says it creates a complete mock solution in one click, suggesting it should be used when both a value and a rule are needed and immediately enabled. However, it does not explicitly state when not to use it or mention alternative tools like whistle_rule_set or whistle_value_set for granular control.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
禁用指定规则
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 规则名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'disable specified rule.' It does not disclose side effects, reversibility, persistence, or whether the rule must exist or what happens on failure. For a mutation tool, this is a significant gap.
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 short phrase, front-loaded with the action and target. It contains no unnecessary words or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one fully documented parameter, no output schema), the description is minimally adequate. However, it lacks behavioral context such as idempotency, error handling, or the effect of disabling a non-existent rule, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'name' with description '规则名称' (rule name). The description's reference to 'specified rule' only echoes the schema without adding new semantic detail, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '禁用指定规则' clearly states the action (disable) and the target (specified rule), distinguishing it from siblings like enable, list, get, set, and remove. The verb-resource pair is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose disable over remove or enable, nor any prerequisites or contexts that would warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
启用指定规则
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 规则名称 |
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 states 'enable' with no disclosure of side effects, permission requirements, idempotency, or failure behavior. This is insufficient for a state-changing 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 a single concise sentence, front-loads the verb, and contains 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?
Despite the simple schema, the description lacks any behavioral details such as success/failure output, prerequisites, or consequences of enabling a rule. With no output schema or annotations, this is a meaningful gap for a mutation 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?
The single parameter 'name' is fully described in the schema with '规则名称' (rule name), giving 100% coverage. The description adds no additional parameter semantics 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 '启用指定规则' (Enable specified rule) clearly states a verb and resource, distinguishing it from siblings like disable, list, get, set, and remove. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as whistle_rule_disable or whistle_rule_set. There are no usage conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定规则的详细内容
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 规则名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action without mentioning error handling, permissions, or response format. While '获取' implies a read operation, no further behavioral traits are disclosed.
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 short sentence with no redundancy or wasted words. It is appropriately sized for a simple get operation.
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 one-parameter get tool, the description is minimally adequate but does not mention return value structure or error cases. Since there is no output schema, a bit more detail would be helpful, but the low complexity keeps it at a moderate score.
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 schema already describes the single parameter 'name' with 100% coverage, so the description adds no additional meaning beyond what is in the schema. The baseline of 3 is appropriate as the schema does the heavy lifting.
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 (get), resource (specified rule), and scope (detailed content), distinguishing it from list and mutation siblings. It doesn't explicitly mention alternatives but the verb and specific object make the purpose clear.
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?
There is no guidance on when to use this tool versus whistle_rule_list or other rule tools. The description implies a 'get detail' use case but provides no explicit context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 whistle 中所有规则列表
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It states the operation is to 'get all rule list', implying a read-only retrieval without side effects. However, it does not explicitly confirm there are no mutations, nor does it disclose any potential limitations like pagination or return format. This is adequate for a simple list but lacks explicit safety guarantees.
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 in Chinese that directly states the tool's purpose. It is front-loaded with the verb and resource, with no filler or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with zero parameters and no output schema, the description adequately covers what the tool does: retrieves all whistle rules. It does not explain return format or edge cases, but given the tool's simplicity and the sibling context, this is nearly complete. A slightly more explicit mention of output structure could push it to 5.
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 zero parameters, so the schema provides complete coverage (100%). Per the rubric, the baseline for 0 params is 4. There is nothing else for the description to add about parameter meanings.
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 '获取 whistle 中所有规则列表' clearly identifies the action (retrieve all) and the resource (whistle rules). It distinguishes itself from sibling tools like whistle_rule_get (single rule retrieval) and whistle_rule_set (modification) by indicating a list operation covering all rules.
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. It does not mention conditions like 'use this to enumerate all rules' or contrast with whistle_rule_get, leaving the agent to infer usage solely from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除指定规则
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 规则名称 |
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 says 'delete specified rule' with no information about irreversibility, side effects, permissions, or what happens to dependent data. This is a significant transparency gap for a destructive 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 and to the point, with no unnecessary words. It is effective in stating the core purpose, though it lacks additional context that could be included without bloating it.
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 (one parameter, no output schema, no annotations), the description is under-specified. It does not explain the effect of deletion, whether it is permanent, or how it interacts with other rule-related tools. The description is minimally adequate but leaves important context 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 description coverage is 100% (the 'name' parameter is described as '规则名称'). The description adds no additional meaning beyond the schema, but per the baseline for high schema coverage, a 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?
The description '删除指定规则' explicitly states the action (delete/remove) and the resource (specified rule), clearly distinguishing it from sibling tools like whistle_rule_set, whistle_rule_enable, and whistle_rule_disable. It is a specific verb+resource statement.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The description provides no usage context beyond the bare action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建或更新规则。规则内容使用 whistle 规则语法，如：pattern resBody://{valueName}
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 规则名称（唯一标识） | |
| enable | No | 是否立即启用该规则 | |
| content | Yes | 规则内容，如：api.example.com/user resBody://{mock_data} |
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 that it creates or updates rules, but does not mention side effects (e.g., overwriting existing rules), required permissions, idempotency, or response behavior. The example given shows syntax but does not clarify what happens on conflict or failure.
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 immediately states the purpose and gives a representative example. It is front-loaded with the action and resource, and every word contributes to understanding. No unnecessary filler or repetition exists.
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 annotations and no output schema, the description is quite thin. It fails to explain behavior on update (e.g., whether it replaces existing rules), validation rules for content, or what the tool returns after creation/update. Given the absence of additional structured metadata, the description leaves significant gaps for an agent to safely invoke the 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 the baseline for this dimension is 3. The description adds an example of content syntax ('pattern resBody://{valueName}'), but this is nearly redundant with the schema's own example for the content parameter. No additional semantic meaning is provided for name or enable parameters beyond what the schema already describes.
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 function with a specific verb-resource pair: '创建或更新规则' (create or update rules). It distinguishes itself from sibling tools like whistle_rule_list, whistle_rule_get, whistle_rule_remove, and whistle_rule_enable/disable by indicating that this tool handles the create/update action.
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. It does not mention that this should be used for new rule creation or modifying existing rules, nor does it reference sibling tools like list/get/remove for other operations. Usage context is only implicitly inferred from the verb 'create or update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 whistle 服务器信息（端口、版本、网络等）
| 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 transparency burden. It discloses the returned categories (port, version, network) and the verb '获取/get' implies a read-only operation, but it does not explicitly state safety, required server state, or response format. Some behavioral context is present but not fully developed.
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, front-loaded with the verb and resource, and contains no filler or redundant information. It is maximally concise while communicating 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 parameterless info tool, the description is mostly adequate, but it lacks differentiation from whistle_status and does not describe what the returned data looks like. Since there is no output schema, a bit more detail about return content or scope would improve 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?
The tool has zero parameters, so parameter semantics are trivial. Per the rubric, zero-parameter tools receive a baseline of 4; the description does not need to add parameter-level details.
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 a 'get' operation on Whistle server information, enumerating port, version, and network details. However, it does not explicitly differentiate itself from the sibling tool whistle_status, which could overlap in purpose.
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 usage guidance is provided. The description only says what the tool does, not when to use it over alternatives such as whistle_status or other related tools. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取单个请求的完整详情（请求头、请求体、响应头、响应体、耗时、规则等），自动解析 query 参数、POST 参数和响应 JSON 字段树
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | session id（从 whistle_sessions_list 结果中获取） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via the verb '获取' (get) and details the returned content, but it does not explicitly state side-effect-free behavior, error conditions, or authorization requirements. The description adds useful context about auto-parsing but leaves some behavioral aspects unspecified.
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, dense sentence that front-loads the core purpose. It lists many included fields and behaviors, but each element adds value and there is no fluff or repetition. Slightly over-stuffed but still concise for the amount of information conveyed.
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 simplicity (one parameter, no output schema), the description provides a solid outline of what the tool returns and its parsing behavior. It does not describe the output format or error handling, but for a simple retrieval tool with clear schema coverage, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the single 'id' parameter, and the description adds valuable provenance by noting the id comes from whistle_sessions_list. This covers the parameter semantics well beyond just the schema's basic type definition.
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 gets full details of a single request, enumerating specific content categories (headers, body, response, timing, rules) and auto-parsing behavior. This distinct verb+resource combination differentiates it from sibling tools like whistle_sessions_list, which presumably provides a list of sessions.
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 parameter description explicitly instructs that the session id comes from whistle_sessions_list, implying a clear workflow (first list, then get details). While it doesn't explicitly mention when not to use this tool or alternative tools, the workflow guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取最近抓包的 session 列表，可按 URL 或 HTTP 方法过滤
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 获取数量，默认 200 | |
| method | No | 按 HTTP 方法过滤（GET / POST / PUT / DELETE） | |
| urlFilter | No | URL 过滤关键词（正则，如 "api.user"） |
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 only states the list and filtering capability, but does not disclose behavioral details such as whether sessions are returned in descending time order, what fields are included, or whether filters are case-sensitive. The "recent" qualifier is helpful but insufficient.
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 that efficiently conveys the core purpose and primary filters. There is no redundant or filler content, and it is appropriately 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?
For a simple list tool with three parameters and no output schema, the description gives the essential purpose and filters. However, it omits details about the return format, ordering, and limit behavior, which would be needed for a fully complete understanding without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with full descriptions, so the baseline is 3. The description adds minimal value by mentioning URL and HTTP method filtering, which aligns with urlFilter and method. However, the 'count' parameter is not mentioned in the description, but the schema covers it 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 a specific action—'获取最近抓包的 session 列表' (get recent captured session list)—and specifies filtering by URL or HTTP method. This distinguishes it from sibling tools like whistle_session_get (single session) and whistle_sessions_search (search), which suggests a different scope.
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 phrase '最近抓包' (recently captured) provides a clear context for when to use this tool: to retrieve recent sessions. It does not exclude alternatives or explicitly mention the sibling search tool, but it gives enough context for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索抓包数据：按请求参数名（query/POST body）或响应 JSON 字段名过滤。例如：查找哪些请求带了 token 参数、哪些接口返回了 address 字段
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 扫描最近多少条记录，默认 200 | |
| field | No | 响应 JSON 字段名（部分匹配字段路径，如 "address" 可匹配到 "data.address"） | |
| param | No | 请求参数名（匹配 URL query 参数和 POST body 参数，部分匹配，如 "token"、"userId"） | |
| method | No | 按 HTTP 方法过滤（GET / POST / PUT / DELETE） | |
| urlFilter | No | URL 过滤关键词（正则，如 "api.user"） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the filtering logic (by query/POST body params and response JSON fields) with examples, but does not describe what the output looks like (e.g., whether it returns full session data or just matches) or any side effects. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a colon and an illustrative example, front-loaded with the main verb and resource. Every word contributes to understanding the tool's purpose, making it highly concise with no 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?
Given there are 5 optional parameters and no output schema, the description covers the tool's purpose and filtering dimensions but leaves gaps: it does not explain how multiple filters combine (AND/OR) or what the return data contains. This is acceptable but not fully complete for an agent to invoke correctly without further guidance.
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 provides thorough descriptions for all 5 parameters (100% coverage), including details like partial path matching. The description adds contextual examples but not new parameter semantics beyond what the schema already documents, so a 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?
The description clearly states the tool searches captured data using request parameter names or response JSON fields, with concrete examples. This distinguishes it from sibling tools like whistle_sessions_list (listing sessions) and whistle_session_get (fetching a specific session), establishing a specific verb+resource+scope.
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 when to use it—when you need to find requests carrying a specific parameter (e.g., token) or responses containing a certain field (e.g., address). It does not explicitly mention alternatives or exclusion criteria, but the context is clear enough for an AI agent to infer its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查 whistle 服务运行状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavior. It only says 'check status' with no indication of what the check entails, whether it performs any side effects, or what the response format looks like. It doesn't disclose whether the tool is read-only or what 'running status' means in practice.
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 short sentence that is perfectly concise and front-loaded. Every word contributes to conveying the tool's purpose with no unnecessary 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?
Given the tool's low complexity, the description is minimally adequate but lacks details about the return value or expected output format. Since there is no output schema, the description should explain what the agent will receive (e.g., a boolean, a string, or a status object) to fully leverage the tool's result. This gap makes it less than fully 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?
The tool has zero parameters and the schema is effectively empty, so the baseline for parameter semantics is 4. The description adds no parameter details, but none are needed since no parameters exist.
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 '检查 whistle 服务运行状态' clearly states the tool's purpose: checking the running status of the whistle service. It uses a specific verb (检查/check) and resource (whistle service status), and it's distinct from sibling tools that deal with rules, values, mocks, sessions, or server info.
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?
There is no explicit guidance on when to use this tool versus alternatives like whistle_server_info or other status-related tools. The intended use is only implied by the name and description, not stated with clear context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定 Value 的内容
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Value 名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the basic 'get' action without mentioning read-only safety, what happens if the Value does not exist, auth requirements, or return format. For a tool with no annotations, this is a notable gap.
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, highly concise and front-loaded. It communicates the essential purpose without any fluff, earning a high score for efficiency, though it could potentially add a tiny bit of context without becoming verbose.
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 low complexity (one parameter, no nested objects, no output schema), the description is minimally sufficient. However, it leaves the agent guessing about the response format and error behavior. Since there is no output schema to fill that gap, a complete description would benefit from a brief mention of the return value or not-found handling.
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 schema describes the single parameter 'name' with 'Value 名称' (Value name), giving 100% schema coverage. The description adds no extra meaning beyond that, so the baseline score of 3 applies.
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 gets the content of a specified Value, using a specific verb ('获取' = get) and resource ('Value'). It naturally distinguishes from sibling tools like whistle_value_list (which lists all values) and whistle_value_set/remove (which modify values), 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. It does not mention that it should be used for retrieving a single known Value by name, nor does it reference sibling tools or any exclusions. The agent must infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 whistle 中所有 Values（键值对）列表
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It does disclose that the tool returns a list of all Values and defines them as key-value pairs, which is useful. However, it does not mention any caveats such as return format, ordering, or performance implications, leaving some behavioral details unclear.
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 is front-loaded with the key action ('get') and resource ('all Values list'). No wasted words; it earns its place entirely.
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 zero-parameter listing tool, the description adequately conveys the purpose and the nature of the returned data (key-value pairs). While there is no output schema, the description's mention of 'list' gives the basic shape. It could be slightly more specific about the return structure, but overall it is sufficient for this simple 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?
The input schema is empty (0 parameters), so the baseline is 4 per the rubric. The description adds context by specifying the scope ('all Values') and that they are key-value pairs, which helps clarify what the tool operates on without needing parameter details.
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 fetches all Values (key-value pairs) in whistle. It uses a specific verb (获取/get) and resource (all Values), distinguishing it from sibling tools like whistle_value_get, whistle_value_set, and whistle_value_remove.
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 offers no explicit guidance on when to use this tool versus alternatives. While the purpose implies it is for listing all values, there is no mention of when to choose whistle_value_get for a specific value or whistle_value_set for modifications, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除指定 Value
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Value 名称 |
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 only says 'delete specified Value' without mentioning that deletion is destructive, possibly irreversible, or whether it affects other resources. This is a significant gap 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 a single, short sentence with no filler or redundancy. It is front-loaded and easy to parse, though its brevity borders on under-specification. It earns a 4 for being appropriately 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 description is incomplete for a delete operation. It omits important context about irreversibility, effects on related data, and any preconditions. With no output schema and no annotations, the agent cannot assess consequences or expected behavior.
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 describes the 'name' parameter as 'Value 名称', and the tool description adds no further semantic detail. Since schema coverage is 100%, the baseline score of 3 is appropriate even though the description adds no parameter context.
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 resource ('指定 Value' / specified Value), making the tool's purpose obvious. It does not explicitly differentiate from sibling value tools, but the remove verb is distinct enough from get and set.
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 usage guidance is provided. The description gives no indication of when to use this tool versus alternatives (e.g., value_set or value_remove for rules), no prerequisites (such as the value existing), and no mention of side effects or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建或更新 Value。Value 用于存储 Mock 数据、模板等
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Value 名称 | |
| content | Yes | Value 内容（通常是 JSON 字符串） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'create or update' without mentioning idempotency, overwrite behavior, authentication requirements, or consequences of updating an existing Value. This is insufficient 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 a single, front-loaded sentence that communicates the verb, resource, and use case without unnecessary words. It is concise 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?
The tool has a simple signature (2 params, full schema coverage) and no output schema. The description explains the resource's purpose but lacks behavioral details and explicit usage guidance. It is adequate but not complete, leaving room for improvement.
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%: both 'name' and 'content' have descriptions. The tool description adds that Values are for Mock data/templates, which provides context for the parameters, but does not add any syntactic or format details 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 tool's function: '创建或更新 Value' (create or update Value), with the specific resource type (Value) and its purpose (storing Mock data, templates). This distinguishes it from siblings like whistle_value_list, whistle_value_get, and whistle_value_remove.
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 when to use this tool (for managing Values that store Mock data/templates) but does not explicitly contrast it with alternatives like whistle_mock_create or whistle_rule_set. No when-not or exclusion criteria are given.
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.
v1.0.0whistle_mock_applywhistle_mock_createwhistle_rule_disablewhistle_rule_enablewhistle_rule_getwhistle_rule_listwhistle_rule_removewhistle_rule_setwhistle_server_infowhistle_session_getwhistle_sessions_listwhistle_sessions_searchwhistle_statuswhistle_value_getwhistle_value_listwhistle_value_removewhistle_value_setScored across 17 tools
The tool set is organized by resource (rules, values, mocks, sessions, server), with clear distinctions between CRUD operations and enabling/disabling. The main ambiguity is whistle_mock_apply overlapping with whistle_rule_enable/disable, but the descriptions clarify the mock-specific scope. Overall, agents should be able to select the right tool.
Names follow a consistent whistle_<resource>_<action> pattern, with minor deviations: sessions_list (plural) vs session_get (singular), and the separate whistle_status and whistle_server_info break the pattern. These are small inconsistencies but the overall convention is clear and predictable.
With 17 tools, the server is slightly above the ideal range, but each tool serves a distinct need in managing Whistle's rules, values, mock setups, and session inspection. The count is justified by the breadth of functionality and does not feel excessive.
The rule and value tools provide full CRUD plus enable/disable, and session tools cover list/get/search. Mock creation automates the composition of values and rules, though there is no dedicated mock delete/update tool, requiring manual composition of rule/value operations. This is a minor gap that agents can work around.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
Build, validate, and manage API simulations in WireMock Cloud from MCP-compatible AI agents.
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
