Which integrations are available for this server?

Acts as a security proxy for GitHub MCP servers, intercepting high-risk repository management actions and requiring explicit human authorization via a one-time password (OTP) before execution. Provides a circuit breaker for PostgreSQL MCP servers, blocking destructive database operations such as dropping or truncating tables until they are confirmed by a user through an OTP flow. Intercepts potentially dangerous Stripe tool calls, such as refunds or charges, and requires human approval via a 4-digit code before the firewall allows the action to proceed to the target Stripe server.

How do I use MCP Action Firewall?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Action Firewall authorize the pending action with code 9942" 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 Action Firewall

by starskrime

Overview Schema Source Related Servers Discussions Admin

Python

Remote

🔥 MCP Action Firewall

Python 3.12+ License: MIT MCP Compatible

Works with any MCP-compatible agent

A transparent MCP proxy that intercepts dangerous tool calls and requires OTP-based human approval before execution. Acts as a circuit breaker between your AI agent and any MCP server.

How It Works

┌──────────┐    stdin/stdout    ┌──────────────────┐    stdin/stdout    ┌──────────────────┐
│ AI Agent │ ◄────────────────► │   MCP Action     │ ◄────────────────► │ Target MCP Server│
│ (Claude) │                    │   Firewall       │                    │ (e.g. Stripe)    │
└──────────┘                    └──────────────────┘                    └──────────────────┘
                                        │
                                   Policy Engine
                                  ┌───────────────┐
                                  │ Allow? Block? │
                                  │ Generate OTP  │
                                  └───────────────┘

MCP servers don't run like web servers — there's no background process on a port. Instead, your AI agent (Claude, Cursor, etc.) spawns the MCP server as a subprocess and talks to it over stdin/stdout. When the chat ends, the process dies.

The firewall inserts itself into that chain:

Without firewall:
  Claude ──spawns──► mcp-server-stripe

With firewall:
  Claude ──spawns──► mcp-action-firewall ──spawns──► mcp-server-stripe

So you just replace the server command in your MCP client config with the firewall, and tell the firewall what the original command was:

Before (direct):

{ "command": "uvx", "args": ["mcp-server-stripe", "--api-key", "sk_test_..."] }

After (wrapped with firewall):

{ "command": "uv", "args": ["run", "mcp-action-firewall", "--target", "mcp-server-stripe --api-key sk_test_..."] }

Then the firewall applies your security policy:

✅ Safe calls (e.g. get_balance) → forwarded immediately
🛑 Dangerous calls (e.g. delete_user) → blocked, OTP generated
🔑 Agent asks user for the code → user replies → agent calls firewall_confirm → original action executes

Related MCP server: sovr-mcp-proxy

Installation

pip install mcp-action-firewall
# or
uvx mcp-action-firewall --help

Quick Start — MCP Client Configuration

Add the firewall as a wrapper around any MCP server in your client config:

{
  "mcpServers": {
    "stripe": {
      "command": "uv",
      "args": ["run", "mcp-action-firewall", "--target", "mcp-server-stripe --api-key sk_test_abc123"]
    }
  }
}

That's it. Everything after --target is the full shell command to launch the real MCP server — including its own flags like --api-key. The firewall doesn't touch those args, it just spawns the target and sits in front of it.

More Examples

{
  "mcpServers": {
    "stripe": {
      "command": "uv",
      "args": [
        "run", "mcp-action-firewall",
        "--target", "uvx mcp-server-stripe --api-key sk_test_...",
        "--name", "stripe"
      ]
    },
    "database": {
      "command": "uv",
      "args": [
        "run", "mcp-action-firewall",
        "--target", "uvx mcp-server-postgres --connection-string postgresql://...",
        "--name", "database",
        "--config", "/path/to/my/firewall_config.json"
      ]
    }
  }
}

{
  "mcpServers": {
    "github": {
      "command": "uvx",
      "args": [
        "mcp-action-firewall",
        "--target", "npx @modelcontextprotocol/server-github"
      ]
    }
  }
}

The OTP Flow

When the agent tries to call a blocked tool, the firewall returns a structured response:

{
  "status": "PAUSED_FOR_APPROVAL",
  "message": "⚠️ The action 'delete_user' is HIGH RISK and has been locked by the Action Firewall.",
  "action": {
    "tool": "delete_user",
    "arguments": { "id": 42 }
  },
  "instruction": "To unlock this action, you MUST ask the user for authorization.\n\n1. Show the user the following and ask for approval:\n   Tool: **delete_user**\n   Arguments:\n{\"id\": 42}\n\n2. Tell the user: 'Please reply with approval code: **9942**' to allow this action, or say no to cancel.\n3. STOP and wait for their reply.\n4. When they reply with '9942', call the 'firewall_confirm' tool with that code.\n5. If they say no or give a different code, do NOT retry."
}

Argument visibility guarantee: The arguments shown to the user are frozen at interception time — they are taken from the original blocked call, not from what the agent passes to firewall_confirm. The agent cannot change the arguments after the OTP is issued.

The firewall_confirm tool is automatically injected into the server's tool list:

{
  "name": "firewall_confirm",
  "description": "Call this tool ONLY when the user provides the correct 4-digit approval code to confirm a paused action.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "otp": {
        "type": "string",
        "description": "The 4-digit code provided by the user."
      }
    },
    "required": ["otp"]
  }
}

Configuration

The firewall ships with sensible defaults. Override with --config:

{
  "global": {
    "allow_prefixes": ["get_", "list_", "read_", "fetch_"],
    "block_keywords": ["delete", "update", "create", "pay", "send", "transfer", "drop", "remove", "refund"],
    "default_action": "block",
    "otp_attempt_count": 1
  },
  "servers": {
    "stripe": {
      "allow_prefixes": [],
      "block_keywords": ["refund", "charge"],
      "default_action": "block"
    },
    "database": {
      "allow_prefixes": ["select_"],
      "block_keywords": ["drop", "truncate", "alter"],
      "default_action": "block"
    }
  }
}

Rule evaluation order:

Tool name starts with an allow prefix → ALLOW
Tool name contains a block keyword → BLOCK (OTP required)
No match → fallback to default_action

otp_attempt_count — maximum number of failed OTP attempts before the pending action is permanently locked out. Defaults to 1 (any wrong code cancels the request). Increase for more forgiving UX, keep at 1 for maximum security.

Per-server rules extend (not replace) the global rules. Use --name stripe to activate server-specific overrides.

CLI Reference

`--target` (required)

The full command to launch the real MCP server. This is the server you want to protect:

mcp-action-firewall --target "mcp-server-stripe --api-key sk_test_abc123"
mcp-action-firewall --target "npx @modelcontextprotocol/server-github"
mcp-action-firewall --target "uvx mcp-server-postgres --connection-string postgresql://localhost/mydb"

`--name` (optional)

Activates per-server rules from your config. Without it, only global rules apply:

mcp-action-firewall --target "mcp-server-stripe" --name stripe

`--config` (optional)

Custom config file path. Without it, uses firewall_config.json in your current directory, or the bundled defaults:

mcp-action-firewall --target "mcp-server-stripe" --config /path/to/my_rules.json

`-v` / `--verbose` (optional)

Turns on debug logging (written to stderr, won't interfere with MCP traffic):

mcp-action-firewall --target "mcp-server-stripe" -v

Project Structure

src/mcp_action_firewall/
├── __init__.py          # Package version
├── __main__.py          # python -m support
├── server.py            # CLI entry point
├── proxy.py             # JSON-RPC stdio proxy
├── policy.py            # Allow/block rule engine
├── state.py             # OTP store with TTL
└── default_config.json  # Bundled default rules

Try It — Interactive Demo

See the firewall in action without any setup:

git clone https://github.com/starskrime/mcp-action-firewall.git
cd mcp-action-firewall
uv sync
uv run python demo.py

The demo simulates an AI agent and walks you through the full OTP flow:

✅ Safe call (get_balance) → passes through instantly
🛑 Dangerous call (delete_user) → blocked, OTP generated
🔑 You enter the code → action executes after approval

Known Limitations

Argument Inspection

The firewall matches on tool names only, not argument values. This means a tool like get_data({"sql": "DROP TABLE users"}) would pass if get_ is in your allow list, because the policy engine only sees get_data.

Workaround: Use explicit tool names in your allow/block lists and set "default_action": "block" so unrecognized tools require approval.

🚧 Roadmap: Argument-level inspection (scanning argument values against block_keywords) is planned for a future release.

Development

# Install dev dependencies
uv sync

# Run tests
uv run pytest tests/ -v

# Run the firewall locally
uv run mcp-action-firewall --target "your-server-command" -v

License

MIT

Available Tools

14 tools

echoEcho ToolB

Echoes back the input string

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Message to echo

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description only says 'echoes back the input string'. Lacks details on side effects, error handling, or return format. For a simple tool, minimal disclosure.

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

Conciseness5/5

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

Single sentence, front-loaded with essential information. No wasted words.

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

Completeness4/5

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

For a simple echo tool with one required parameter, description is mostly complete. Implies return of same string, though explicit mention would be ideal. No output schema, but 'echoes back' suffices.

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

Parameters3/5

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

Schema coverage is 100%; parameter 'message' already described as 'Message to echo'. Description adds no additional semantic value, baseline 3.

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

Purpose5/5

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

Description uses specific verb 'echoes' and resource 'input string', clearly stating the tool's function. Distinct from sibling tools like 'get-annotated-message'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. Sibling tools have different purposes but no explicit when/when-not advice.

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

firewall_confirmB

Call this tool ONLY when the user provides the correct 4-digit approval code to confirm a paused action.

ParametersJSON Schema

Name	Required	Description	Default
`otp`	Yes	The 4-digit code provided by the user.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool confirms a paused action but fails to describe side effects, auth requirements, or success/failure behavior. Critical details are missing for a security-related tool.

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

Conciseness5/5

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

The description is a single concise sentence that immediately states the tool's purpose and usage condition. No unnecessary words, well front-loaded.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description should provide more context about what 'paused action' means, prerequisites, and post-conditions. It is insufficient for an agent to correctly invoke the tool in all scenarios.

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

Parameters3/5

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

Schema coverage for parameters is 100%, so baseline is 3. The description mentions the '4-digit approval code', which is similar to the schema's '4-digit code provided by the user', providing no additional meaning beyond what the schema already offers.

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

Purpose5/5

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

The description clearly states the tool's purpose: to confirm a paused action using a 4-digit approval code. It uses the word 'confirm' as a specific verb and identifies the resource ('paused action'), making it distinct from sibling tools.

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

Usage Guidelines3/5

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

The description explicitly says 'ONLY when the user provides the correct 4-digit approval code', providing clear context for when to use. However, it does not mention what happens on incorrect input or suggest alternative tools for other scenarios.

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

get-annotated-messageGet Annotated Message ToolC

Demonstrates how annotations can be used to provide metadata about content.

ParametersJSON Schema

Name	Required	Description	Default
`messageType`	Yes	Type of message to demonstrate different annotation patterns
`includeImage`	No	Whether to include an example image

TDQS

C2.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or output structure. It only says it 'demonstrates annotations' without elaboration.

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

Conciseness3/5

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

The description is a single short sentence, which is concise but insufficient. It lacks necessary information such as output format or usage context.

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

Completeness2/5

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

Given no output schema and low complexity, the description should clarify what the tool returns (e.g., an annotated message). It fails to do so, leaving the agent guessing.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already documents both parameters (messageType with enum, includeImage with default). The description adds no additional meaning beyond the schema.

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

Purpose2/5

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

The description 'Demonstrates how annotations can be used to provide metadata about content' is vague and meta. It does not clearly state what the tool does (e.g., retrieves a message with annotations) or distinguish it from other tools.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings. The context signals list 13 other tools with no differentiation criteria.

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

get-envPrint Environment ToolA

Returns all environment variables, helpful for debugging MCP server configuration

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so description carries the burden. It states the tool returns environment variables, but does not disclose behavioral traits like output format, security implications (e.g., sensitive data exposure), or that it's a read-only operation.

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

Conciseness5/5

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

Single sentence with no wasted words. Every part is essential and front-loaded.

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

Completeness5/5

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

For a simple tool with zero parameters, no output schema, and no nested objects, the description is complete. It states purpose and usage context, sufficient for an AI agent to select and invoke correctly.

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

Parameters4/5

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

No parameters exist, and schema coverage is 100%. The description adds the 'debugging' context, which provides additional meaning beyond the schema. Baseline 4 is appropriate given no parameters.

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

Purpose5/5

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

Description clearly states 'returns all environment variables' with a specific verb and resource. The additional context 'helpful for debugging MCP server configuration' distinguishes it from sibling tools, none of which retrieve environment variables.

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

Usage Guidelines4/5

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

Explicitly states usage context 'debugging MCP server configuration', which guides when to use. No explicit when-not or alternative tools are needed as the tool's function is unique among siblings.

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

get-resource-linksGet Resource Links ToolC

Returns up to ten resource links that reference different types of resources

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	Number of resource links to return (1-10)

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as whether the operation is read-only, idempotent, or has side effects. It only states the result content, which is insufficient.

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

Conciseness4/5

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

Single sentence that is front-loaded and concise. Every word serves a purpose, though additional context could be added without becoming verbose.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description is adequate but does not explain what a 'resource link' is or how it differs from sibling tools, leaving some gaps.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter 'count', which is well-documented. The description adds no additional meaning beyond the schema, resulting in a baseline score.

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

Purpose3/5

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

Description states 'Returns up to ten resource links' which is clear about action and resource, but does not distinguish from sibling 'get-resource-reference', making the purpose somewhat vague in context.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'get-resource-reference'. The description lacks any context about appropriate use cases or exclusions.

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

get-resource-referenceGet Resource Reference ToolC

Returns a resource reference that can be used by MCP clients

ParametersJSON Schema

Name	Required	Description	Default
`resourceType`	No		Text
`resourceId`	No	ID of the text resource to fetch

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only states the return type (resource reference) without mentioning side effects, authorization, or response format.

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

Conciseness4/5

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

The description is a single efficient sentence. However, brevity comes at the cost of completeness; it could be expanded without losing conciseness.

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

Completeness2/5

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

For a simple tool with 2 parameters and no output schema, the description fails to explain what a 'resource reference' is or how the response should be used. It lacks sufficient context for an AI agent to invoke correctly.

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

Parameters2/5

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

Schema description coverage is 50% (only resourceId has a description). The tool description adds no additional meaning to either parameter, leaving the resourceType enum undocumented.

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

Purpose3/5

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

The description 'Returns a resource reference that can be used by MCP clients' states the basic action but does not differentiate from sibling tools like get-resource-links or get-structured-content. It is not a tautology but lacks specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, constraints, or use case.

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

get-structured-contentGet Structured Content ToolB

Returns structured content along with an output schema for client data validation

ParametersJSON Schema

Name	Required	Description	Default
`location`	Yes	Choose city

Output Schema

ParametersJSON Schema

Name	Required	Description
`temperature`	Yes	Temperature in celsius
`conditions`	Yes	Weather conditions description
`humidity`	Yes	Humidity percentage

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must fully inform about behavior. It does not disclose side effects, authentication needs, rate limits, or error handling. It implies a read operation 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.

Conciseness5/5

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

The description is a single sentence that is direct and front-loaded with the action. It contains no fluff and is appropriately sized for the simple tool.

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

Completeness3/5

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

The tool has an output schema, so return values are covered externally. However, the description does not explain the relationship between the location parameter and the returned structured content, leaving some context missing.

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

Parameters3/5

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

The input schema covers 100% of parameters with a clear description for 'location'. The tool description adds no additional parameter context beyond what the schema provides, meeting the baseline but not exceeding it.

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

Purpose4/5

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

The description clearly states the tool returns structured content with an output schema for client data validation. It uses a specific verb 'returns' and specifies the resource. However, it does not explicitly differentiate from sibling tools, leaving some ambiguity about uniqueness.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools like 'echo' exist, but no comparison or usage context is given, leaving agents without decision support.

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

get-sumGet Sum ToolB

Returns the sum of two numbers

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes	First number
`b`	Yes	Second number

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits, but it does not mention error handling, overflow behavior, or limitations. It only states the basic operation.

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

Conciseness5/5

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

The description is a single, efficient sentence with no redundant information, making it highly concise and front-loaded.

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

Completeness4/5

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

Given the simplicity of the tool (two numbers, no output schema), the description adequately explains the behavior. However, it could be improved by mentioning the return type or potential edge cases.

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

Parameters3/5

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

The input schema has 100% coverage with descriptions for both parameters. The tool description adds no extra meaning beyond what the schema provides, meeting the baseline expectation.

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

Purpose5/5

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

The description clearly states the verb 'Returns' and the resource 'sum of two numbers', making the purpose unambiguous. The sibling tools are unrelated, so no confusion arises.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, 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.

get-tiny-imageGet Tiny Image ToolA

Returns a tiny MCP logo image.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, has side effects, or any other behavioral traits beyond returning an image.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys the purpose without any wasted words.

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

Completeness4/5

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

Given the tool's simplicity (no params, no output schema), the description is largely complete. It could mention the expected output format or size, but it is adequate for basic understanding.

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

Parameters4/5

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

Tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter information. Baseline of 4 is appropriate.

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

Purpose5/5

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

The description clearly states that the tool returns a tiny MCP logo image, which is a specific verb+resource. It differentiates from siblings as none of them are image-related.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not indicate any prerequisites or context for invoking this tool.

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

gzip-file-as-resourceGZip File as Resource ToolA

Compresses a single file using gzip compression. Depending upon the selected output type, returns either the compressed data as a gzipped resource or a resource link, allowing it to be downloaded in a subsequent request during the current session.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	Name of the output file	README.md.gz
`data`	No	URL or data URI of the file content to compress	https://raw.githubusercontent.com/modelcontextprotocol/servers/refs/heads/main/README.md
`outputType`	No	How the resulting gzipped file should be returned. 'resourceLink' returns a link to a resource that can be read later, 'resource' returns a full resource object.	resourceLink

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description should disclose behavioral traits. It mentions output modes and that the result can be used later, but does not detail side effects, authorization needs, or file size limits. It's adequate but not comprehensive.

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

Conciseness5/5

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

The description is two sentences, front-loading the core purpose. Every word adds value, with no fluff or repetition. It is concise and well-structured.

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

Completeness4/5

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

For a simple compression tool with 3 fully described parameters and no output schema, the description covers the essential behavior. It could mention that the original file is not modified, but overall it is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 100% from the input schema, so the description adds minimal extra meaning beyond restating the output type options. The baseline score of 3 is appropriate as the schema already provides good parameter descriptions.

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

Purpose5/5

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

The description clearly states the action ('compresses a single file using gzip compression') and the resource, with specific details about output types. It effectively distinguishes from sibling tools like echo or get-env by focusing on a compression operation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply describes what it does without context for decision-making.

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

simulate-research-querySimulate Research QueryA

Simulates a deep research operation that gathers, analyzes, and synthesizes information. Demonstrates MCP task-based operations with progress through multiple stages. If 'ambiguous' is true and client supports elicitation, sends an elicitation request for clarification.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The research topic to investigate
`ambiguous`	No	Simulate an ambiguous query that requires clarification (triggers input_required status)

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses progress stages and elicitation behavior for ambiguous queries, but does not cover all behavioral aspects like side effects or final output nature.

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

Conciseness5/5

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

Two sentences, front-loaded with core purpose, no redundant information. Every sentence adds value.

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

Completeness3/5

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

Given no output schema, description should explain return value; it mentions progress stages but not final output. Adequate for a simulation tool but missing return specification.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds extra meaning to 'ambiguous' parameter by specifying it triggers input_required status and elicitation request, surpassing schema documentation.

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

Purpose5/5

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

The description clearly states it simulates a deep research operation and demonstrates MCP task-based operations, distinguishing it from sibling tools like echo or get-sum which are unrelated.

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

Usage Guidelines3/5

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

The description implies use for demonstration/simulation but does not explicitly state when to use or not use this tool compared to alternatives, leaving usage context inferential.

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

toggle-simulated-loggingToggle Simulated LoggingB

Toggles simulated, random-leveled logging on or off.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states it toggles logging on/off, without detailing what 'simulated' means, side effects, or state persistence.

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

Conciseness4/5

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

One short sentence, no wasted words. Could be slightly expanded without losing conciseness, but currently efficient.

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

Completeness3/5

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

Adequate for a simple toggle tool with no parameters, but lacks context on scope (global/session) and effect on other tools. Siblings provide similar patterns, so more detail would help.

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

Parameters4/5

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

No parameters exist; schema coverage is 100%. The description adds no parameter info but none is needed. Baseline score of 4 for zero-parameter tools.

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

Purpose5/5

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

The description uses specific verb 'toggles' and resource 'simulated, random-leveled logging', clearly distinguishing it from sibling tools like 'toggle-subscriber-updates'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. With sibling tools like 'toggle-subscriber-updates', the description should clarify scenarios for each.

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

toggle-subscriber-updatesToggle Subscriber UpdatesA

Toggles simulated resource subscription updates on or off.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses the basic action (toggling on/off) but, in the absence of annotations, does not clarify side effects, persistence, or state changes beyond the immediate toggle.

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

Conciseness5/5

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

A single, concise sentence that directly states the tool's purpose with no unnecessary words or repetition.

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

Completeness4/5

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

For a simple no-parameter toggle tool, the description is mostly complete, though a brief note on the scope or effect of 'subscriber updates' would enhance understanding.

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

Parameters4/5

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

With no parameters and 100% schema coverage, the description adds no parameter details but is adequate given the simplicity; baseline of 4 applies per zero-param rule.

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

Purpose5/5

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

The description clearly specifies the verb 'toggles' and the resource 'simulated resource subscription updates', making it distinct from sibling tools like 'toggle-simulated-logging'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as 'toggle-simulated-logging' or other sibling tools. The agent lacks context for decision-making.

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

trigger-long-running-operationTrigger Long Running Operation ToolC

Demonstrates a long running operation with progress updates.

ParametersJSON Schema

Name	Required	Description	Default
`duration`	No	Duration of the operation in seconds
`steps`	No	Number of steps in the operation

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'progress updates' but omits critical details such as whether the operation is destructive, how to cancel it, or any side effects. This is insufficient for an agent to understand the tool's impact.

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

Conciseness3/5

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

The description is a single short sentence, which is concise but at the expense of clarity. It is front-loaded with the weak verb 'Demonstrates', reducing effectiveness. While not verbose, it lacks structure and important details.

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

Completeness2/5

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

Given the tool's complexity (two simple numeric parameters) and absence of an output schema, the description should provide sufficient behavioral context. It fails to do so, omitting safety, cancellation, and result details. The mention of progress updates is the only meaningful addition.

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

Parameters3/5

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

The input schema has 100% description coverage for both parameters ('duration' and 'steps'), so the schema already documents their meaning. The description adds no extra semantic value beyond noting progress updates, which is not parameter-specific. Baseline score of 3 applies.

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

Purpose2/5

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

The description says 'Demonstrates a long running operation', which essentially restates the tool's name without specifying a concrete action. 'Demonstrates' is vague and does not clearly indicate that the tool triggers an operation, making it a tautology.

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

Usage Guidelines2/5

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

No guidance is provided on when or why to use this tool. The description does not mention use cases, prerequisites, or alternatives among sibling tools, leaving the agent without context for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

14 tool updatesv0.3.0Mar 26, 2026
- First observedecho
- First observedfirewall_confirm
- First observedget-annotated-message
- First observedget-env
- First observedget-resource-links
- First observedget-resource-reference
- First observedget-structured-content
- First observedget-sum
- First observedget-tiny-image
- First observedgzip-file-as-resource
- First observedsimulate-research-query
- First observedtoggle-simulated-logging
- First observedtoggle-subscriber-updates
- First observedtrigger-long-running-operation

Deploy Server

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

TDQS

C2.9/5.0

Scored 2026-04-30 00:35 across 14 tools

Disambiguation4/5

Most tools have clearly distinct purposes, but some get-* tools like get-annotated-message and get-structured-content could be confused, and get-resource-links vs get-resource-reference are similar.

Naming Consistency2/5

Tool names mix hyphens (get-env) and underscores (firewall_confirm), and verbs vary inconsistently (echo, get-, toggle-, simulate-, trigger-, gzip-), lacking a uniform pattern.

Tool Count3/5

14 tools is a reasonable count, but the server name implies a firewall/pause/confirm focus, while most tools are demo utilities, creating a scope mismatch.

Completeness2/5

The server name suggests a firewall use case, but only one tool (firewall_confirm) supports that; the remaining tools are unrelated demos, leaving a significant gap between promise and functionality.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2
Sunaiva Gate — Agent Rule Enforcement A
io.sunaivacore
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Security Autonomous Agents
162
gatewayOAuth
ai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security Agent Orchestration
11

Related MCP Servers

MCP Security Audit Server
Security Developer Tools Code Execution
qianniuspace
A
license
C
quality
D
maintenance
Audits npm package dependencies for security vulnerabilities, providing detailed reports and fix recommendations with MCP integration.
Updated a year ago (2025-07-18 09:03 UTC)
1
19
57
MIT
sovr-mcp-proxy
Security Autonomous Agents Developer Tools
xie38388
F
license
Not graded
quality
Not graded
maintenance
A transparent proxy and execution firewall that intercepts and audits AI agent tool calls against configurable security policies before forwarding them to downstream MCP servers. It provides safe execution environments with features like data redaction, anti-loop protection, and unified alert dispatching.
Updated 7 months ago (2026-02-19 15:06 UTC)
-
SINT Protocol
Security Autonomous Agents Agent Orchestration
sint-ai
A
license
A
quality
A
maintenance
Security-enforcing MCP proxy that sits between an AI agent and any number of downstream MCP servers, intercepting every tool call through a capability-token policy gateway that can allow, deny, or escalate to human approval before the call reaches any real tool. It also exposes built-in operator tools for approval workflows, audit trail queries, token management, voice/HUD output, and hierarchical
Updated a month ago (2026-08-12 20:48 UTC)
21
13
Apache 2.0
border-patrol-mcp
Security Shell Access
pavlealeksic
A
license
Not graded
quality
B
maintenance
A policy-enforcing MCP gateway that intercepts all tool calls to downstream MCP servers, applying allow/deny/ask rules with human approval and audit logging for safe access to dangerous tools.
Updated a month ago (2026-07-31 11:07 UTC)
8
MIT

🔥 MCP Action Firewall

Works with any MCP-compatible agent

How It Works

Installation

Quick Start — MCP Client Configuration

More Examples

The OTP Flow

Configuration

CLI Reference

--target (required)

--name (optional)

--config (optional)

-v / --verbose (optional)

Project Structure

Try It — Interactive Demo

Known Limitations

Argument Inspection

Development

License

Available Tools

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`--target` (required)

`--name` (optional)

`--config` (optional)

`-v` / `--verbose` (optional)