Which integrations are available for this server?

Provides tools to generate, validate, and test Wirefilter WAF and Smart Firewall rules for Cloudflare's rule engine, grounded in live schema and CVE exploit templates.

How do I use Gen0Sec WAF Rule MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gen0Sec WAF Rule MCP Server Validate a WAF rule to block CVE-2024-21626 exploitation attempts." 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.

Gen0Sec WAF Rule MCP Server

Official

by gen0sec

Overview Schema Related Servers Score Discussions

Python

Hybrid

WAF & Smart-Firewall Rule Generation for Agentic LLMs

An MCP server that lets an LLM author, validate, and test Wirefilter WAF and Smart Firewall rules — grounded in live schema and real CVE exploit templates instead of guesswork.

What it does:

Validates rules against a real engine — expressions are checked (and optionally test-matched) through the Wirefilter rules-validator API, so the model gets real pass/fail feedback, not a hallucinated opinion
Grounds generation in live schema — serves the authoritative actions / expressions / fields / functions / operators / values straight from the rules-validator, so rules use fields that actually exist
Pulls real exploit context — fetches CVE-indexed Nuclei templates from multiple sources (Nuclei Open Source via GitHub, Nuclei Paid via the ProjectDiscovery API) to inform CVE-driven rule generation
Self-updating — periodically refreshes the Wirefilter context and CVE template repositories in the background

Runs anywhere Python 3.12+ runs · ships as a Claude Desktop bundle, a stdio MCP server, or an HTTP container

Related MCP server: crowdsec-local-mcp

Quick start

Claude Desktop (bundle)

# Prerequisites: mcpb (npm install -g @anthropic-ai/mcpb)
make pack          # produces the thin, portable gen0sec-mcp-server.mcpb

Open the generated gen0sec-mcp-server.mcpb file — Claude Desktop installs it in about a minute, after which the tools, resources, and prompts are available.

Which bundle: thin vs offline

The GitHub release ships two .mcpb files:

gen0sec-mcp-server.mcpb (thin, default) — carries no native wheels, so it runs on any supported interpreter. On first launch it builds a small private virtualenv from requirements.txt, which needs one-time network access to PyPI. Nothing global is touched, and the host Python is never modified.
gen0sec-mcp-server-offline.mcpb (air-gapped) — carries prebuilt wheels for several interpreter targets under server/lib/<abi-tag>/ (CPython 3.12–3.13 on macOS arm64, Linux x86_64/aarch64, Windows x86_64). On a covered target it starts with no network access. On an uncovered interpreter it degrades to the thin bundle's first-run venv.

The extension picks the right path automatically; the only difference is whether a one-time network install can happen at first launch. Set Path to Python executable in the extension config to a Python ≥ 3.12 if the default python3 isn't suitable.

Building locally:

make pack          # thin bundle (release default)
make vendor-multi  # add this host's ABI dir to server/lib/<abi-tag>/
make pack-offline  # offline bundle from whatever ABI dirs are present

The full cross-platform offline bundle is assembled in CI, where each target is vendored natively (see .github/workflows/offline-bundle.yaml).

Cursor IDE — local (stdio)

Add to ~/.cursor/mcp.json (%USERPROFILE%\.cursor\mcp.json on Windows):

{
  "mcpServers": {
    "waf-rule-mcp": {
      "command": "uv",
      "args": [
        "run",
        "--project", "/absolute/path/to/mcp-server",
        "/absolute/path/to/mcp-server/server/main.py"
      ],
      "env": {
        "WAF_VALIDATION_API_URL": "https://public.gen0sec.com/v1/waf/validate"
      }
    }
  }
}

WAF_VALIDATION_API_URL is optional — if unset, the value from server/config.yaml is used. Restart Cursor to apply.

Docker (HTTP)

docker build -t waf-rule-mcp .
docker run -p 8000:8000 waf-rule-mcp

Then point your MCP client at it:

{
  "mcpServers": {
    "waf-rule-mcp": { "url": "http://localhost:8000" }
  }
}

The WAF rule validation API must be reachable for the validation tools to work. Set its URL via WAF_VALIDATION_API_URL or server/config.yaml.

MCP surface

Tools

Tool	Purpose
`fetch_cve_vulnerability_template`	Retrieve a CVE-indexed vulnerability template from a preferred source (Nuclei Open Source or Nuclei Paid API)
`fetch_cve_from_all_sources`	Fetch a CVE template from all enabled sources for cross-source comparison
`list_cve_sources`	List the registered CVE source plugins and their status
`validate_waf_expression`	Validate a Wirefilter rule expression (`rule_type` selects the scheme)
`validate_waf_expression_with_tests`	Validate a Wirefilter rule and match it against test data (mock data if none given)
`get_waf_context`	Fetch WAF context from Wirefilter docs: actions, expressions, fields, functions, operators, values
`get_rule_fields`	Fetch the live, authoritative Wirefilter field/function schema directly from the rules-validator

Resources

URI	Reference
`wafcontext://actions`	Actions available in the Rules language
`wafcontext://expressions`	Expressions available in the Rules language
`wafcontext://fields`	Fields available in the Rules language
`wafcontext://functions`	Functions available in the Rules language
`wafcontext://operators`	Operators available in the Rules language
`wafcontext://values`	Values available in the Rules language

Prompts

Prompt	Generates a rule from…
`natural_waf_rule_generation_prompt`	a natural-language description
`cve_waf_rule_generation_prompt`	a CVE index
`smart_firewall_rule_generation_prompt`	a natural-language description, as an L3/L4 + JA4 Smart Firewall rule (no `http.*` fields; `block`/`allow` actions)

Architecture

flowchart TD
    LLM([Agentic LLM / MCP client]) <--> MCP

    subgraph MCP[Gen0Sec WAF Rule MCP Server]
        T[Tools]
        R["Resources<br/>wafcontext://*"]
        P[Prompts]
        RU[Resource updater<br/>periodic refresh]
    end

    T -->|validate / fields| RV[Wirefilter rules-validator API]
    R -->|live schema| RV
    T -->|CVE templates| CS

    subgraph CS[CVE sources]
        N1[Nuclei Open Source<br/>GitHub]
        N2[Nuclei Paid<br/>ProjectDiscovery API]
    end

    RU -.refreshes.-> CS
    RU -.refreshes.-> RV

Documentation


Gen0Sec Docs	Product documentation and guides
`server/config.yaml`	Validation API URL, CVE source toggles, update intervals
`manifest.json`	Claude Desktop bundle manifest and user-configurable options
Wirefilter	The rule expression language this server targets

Thank you!

Cloudflare for Wirefilter
ProjectDiscovery for the Nuclei templates

Available Tools

7 tools

fetch_cve_from_all_sourcesFetch CVE from all sourcesA

Fetch CVE vulnerability template from ALL enabled sources. Useful for comparing data across different sources.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral details such as what happens if a source fails, how data is combined, or authentication needs. The description only states the basic action, offering little beyond the title.

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, no wasted words, and front-loaded with the main action. Efficient and to the point.

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

Completeness3/5

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

Given the tool's simplicity (one param, no output schema), the description is minimally adequate. However, it does not explain what the output looks like or what 'all enabled sources' means, leaving gaps for an agent to infer 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?

With 0% schema description coverage and only one parameter (cve_id), the description does not explain what cve_id is (e.g., format like CVE-xxxx-xxxx). The schema provides no additional meaning, so the tool description fails to compensate.

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 ('Fetch') and the resource ('CVE vulnerability template from ALL enabled sources'), distinguishing it from sibling tools like fetch_cve_vulnerability_template which likely fetches from a single source.

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

Usage Guidelines4/5

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

The description mentions it is 'useful for comparing data across different sources,' providing a specific use case. However, it does not explicitly state when not to use this tool versus alternatives like fetch_cve_vulnerability_template, though the implication is clear.

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

fetch_cve_vulnerability_templateFetch CVE vulnerability templateB

Retrieve a CVE Indexed vulnerability template from multiple sources (Nuclei Open Source, Nuclei Paid API). Returns detailed information for the exploit including metadata, severity, description, references, classification, and characteristic request patterns.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes
`source`	No

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description must fully convey behavior. It lists the type of returned data (metadata, severity, etc.), which is helpful for a read operation. However, it does not explicitly state that the tool is read-only, nor does it mention potential costs or rate limits associated with the paid API source.

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 concise sentences that directly state the tool's purpose and output. No extraneous information, and it is front-loaded with the main action.

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 fetch tool with 2 parameters and no output schema, the description covers the main purpose and return content. However, it lacks details on the optional 'source' parameter and does not mention any constraints or limitations, which leaves some gaps in completeness.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must clarify parameter meaning. It explains 'cve_id' implicitly by context, but the 'source' parameter is not described at all. The description says 'from multiple sources' but does not specify valid values or default behavior, leaving ambiguity for the agent.

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 retrieves a CVE vulnerability template from multiple sources and lists what is returned (metadata, severity, etc.). It specifies the verb 'retrieve' and the resource 'CVE vulnerability template', but does not explicitly differentiate from sibling tool 'fetch_cve_from_all_sources' which might have a broader scope.

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 like 'fetch_cve_from_all_sources' or 'list_cve_sources'. It does not mention the optional 'source' parameter or when to specify one source over the other, nor any prerequisites or exclusions.

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

get_rule_fieldsGet authoritative rule fields (WAF or Smart Firewall)A

Fetch the live, authoritative Wirefilter field/function schema directly from the rules-validator for the given rule_type ('waf' = HTTP L7 fields; 'smart_firewall' = L3/L4 + JA4 fields, no http.*). This is the single source of truth and never drifts from what validation accepts — prefer it over the static wafcontext://fields resource when building expressions. Falls back to static context if the validator is unreachable.

ParametersJSON Schema

Name	Required	Description	Default
`rule_type`	No		waf

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses that this tool is the single source of truth and never drifts from what validation accepts, establishing trustworthiness. It also details the behavioral difference between rule types (waf gives HTTP L7 fields; smart_firewall gives L3/L4 + JA4 fields, no http.*) and the fallback to static context if the validator is unreachable. Since no annotations are provided, the description carries the full burden and addresses it comprehensively.

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 with no wasted words. It is front-loaded with the action 'Fetch the live, authoritative...', and every sentence adds value: the first explains what and how, the second asserts authority and notes fallback. It is concise yet information-dense.

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

Completeness5/5

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

Given the tool has only one parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, parameter semantics, behavioral details (authoritativeness, fallback), usage guidance (prefer over static), and even comparative scope differences between rule types. It is fully self-contained and leaves no key question unanswered.

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

Parameters5/5

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

The input schema has 0% description coverage with one parameter (rule_type) lacking enums or descriptions. The description adds significant meaning by explaining that 'waf' returns HTTP L7 fields and 'smart_firewall' returns L3/L4 + JA4 fields with no http.*, and that it fetches from the rules-validator. This fully compensates for the missing schema detail.

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

Purpose5/5

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

The description clearly states it fetches the live authoritative Wirefilter field/function schema for a given rule_type ('waf' or 'smart_firewall'), specifying the source (rules-validator) and the scope. It distinguishes itself from siblings like validate_waf_expression and get_waf_context by emphasizing it is the single source of truth for field definitions.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: when building expressions, prefer it over the static wafcontext://fields resource. It also mentions the fallback behavior if the validator is unreachable. However, it does not explicitly state when not to use it or describe scenarios where alternatives might be preferred, missing a full when/when-not distinction.

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

get_waf_contextGet WAF contextB

Fetch WAF context from Wirefilter documentation about actions, expressions, fields, functions, operators and values.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are present, so the description carries full burden. It implies a read-only fetch operation, which is reasonable, but does not disclose any potential side effects, authentication needs, or limitations (e.g., caching behavior). Adequate for a simple retrieval.

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 sentence that front-loads the primary action and resource. It is concise and wastes no words, though listing the covered items could be slightly more structured (e.g., bulleted).

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

Completeness3/5

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

Given the lack of output schema, the description lists the categories of information returned (actions, expressions, etc.), which provides adequate context for a simple fetch. However, it does not specify the return format or any constraints (e.g., data source freshness).

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 tool has no parameters, and schema description coverage is 100% (trivially). The description does not add parameter-specific meaning, but no parameters exist to clarify. Baseline 3 applies per guidelines.

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 'Fetch' and the resource 'WAF context', and specifies the scope by listing the types of documentation covered: actions, expressions, fields, functions, operators, values. This distinguishes it from siblings like validation tools.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. While siblings are different (e.g., validation, CVE fetching), the description does not explain scenarios where fetching context is appropriate or required.

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

list_cve_sourcesList CVE sourcesB

List all registered CVE source plugins and their status.

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 are provided, so the description must disclose behavioral traits. It states the action (list) and scope (all registered plugins with status) but does not mention if any authentication is required, whether the list is cached, or what 'status' entails (e.g., enabled/disabled). This lack of detail leaves the agent uncertain about side effects or constraints.

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 succinct and front-loaded with the action and outcome. Every word is necessary, and there is no redundancy or filler.

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?

Despite the tool's simplicity, the description omits the structure or format of the return value. Since there is no output schema, the description should clarify what 'status' looks like (e.g., plugin IDs, names, enabled/disabled flags). This gap forces the agent to guess or risk misinterpreting the output.

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

Parameters4/5

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

The input schema has zero parameters with 100% coverage. Since there are no parameters, the description need not add parameter-level details. The baseline for 0 parameters is 4, and the description appropriately does not clutter with parameter info.

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 lists all registered CVE source plugins along with their status. It uses a specific verb ('list'), resource ('CVE source plugins'), and scope ('all'). This distinguishes it from siblings like 'fetch_cve_from_all_sources' which retrieves data from sources rather than listing them.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or when not to use it. For a tool that lists sources, it would be helpful to indicate that this is for discovery before fetching CVEs from specific sources.

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

validate_waf_expressionValidate a rule expression (WAF or Smart Firewall)A

Validate a Wirefilter rule expression. rule_type selects the scheme: 'waf' (HTTP L7 fields, default) or 'smart_firewall' (L3/L4 + JA4 fields; http.* fields are NOT available and will be rejected). Optionally test against custom test data. Returns a dictionary with valid (boolean) and error_message (string) when invalid.

ParametersJSON Schema

Name	Required	Default
`test`	No
`rule_type`	No	waf
`expression`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses return format (dictionary with valid boolean and error_message string) and constraint that http.* fields are rejected for smart_firewall. Lacks mention of side effects or authorization, but none likely.

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 efficient sentences. All information is relevant and front-loaded with purpose. No wasted words.

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?

With no output schema and low schema coverage, the description provides essential details: purpose, rule_type options, return format. However, it omits details about the test parameter structure and success return (only mentions error_message for invalid). Adequate but has 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 description coverage is 0%. Description adds meaning for rule_type (explains two values and their behavior) and indicates test is optional custom data. However, it does not specify structure of test parameter, leaving ambiguity.

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 validates a Wirefilter rule expression, specifies the two rule types (waf and smart_firewall) with their scope, and indicates optional testing. This distinguishes it from siblings like 'validate_waf_expression_with_tests'.

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?

Describes when to use each rule_type and mentions that smart_firewall does not support http.* fields. Provides context for selecting the correct scheme. Does not explicitly mention when not to use this tool versus siblings.

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

validate_waf_expression_with_testsValidate a rule expression with tests (WAF or Smart Firewall)A

Validate a Wirefilter rule expression and match it against test data (mock data if none given). rule_type selects the scheme: 'waf' (HTTP L7, default) or 'smart_firewall' (L3/L4 + JA4; no http.* fields). Returns valid (boolean), error_message (string), matched (boolean), and test_error (string) if the test fails.

ParametersJSON Schema

Name	Required	Default
`rule`	Yes
`test`	No
`rule_type`	No	waf

TDQS

A3.8/5.0

Behavior3/5

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

The description explains return values and the difference between WAF and Smart Firewall, but is vague about 'mock data if none given'—it does not specify what mock data is used. No annotations exist, so the description should provide full transparency; this gap lowers the score.

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?

Three sentences cover purpose, rule_type options, and return fields with no waste. Information is front-loaded and 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?

For a tool with 3 parameters (1 required, 1 nested object) and no output schema, the description lacks details on test object structure and mock data behavior. Return fields are listed, but completeness is hampered by missing parameter semantics.

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

Parameters2/5

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

The description explains rule_type well (defaults, allowed values, field relevance) but provides no information about the test parameter structure, despite the schema having 0% coverage. The test parameter is essential for usage in testing scenarios, and its omission is a significant gap.

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 validates a Wirefilter rule expression and matches it against test data. It specifies the two rule_type schemes (WAF and Smart Firewall) and lists return fields, 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.

Usage Guidelines4/5

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

The description sets clear usage context by distinguishing between rule types, but does not explicitly contrast with sibling tools like validate_waf_expression (which likely lacks testing). The guidance is good but could be stronger.

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. Dates show when Glama detected each change.

7 tool updatesv0.0.7Jul 29, 2026
- First observedfetch_cve_from_all_sources
- First observedfetch_cve_vulnerability_template
- First observedget_rule_fields
- First observedget_waf_context
- First observedlist_cve_sources
- First observedvalidate_waf_expression
- First observedvalidate_waf_expression_with_tests

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Tools are clearly divided into two groups: CVE vulnerability template retrieval and WAF rule validation/context. Within each group, tools have distinct purposes (e.g., fetch specific template vs. list sources vs. fetch from all; validate expression vs. validate with tests vs. get context vs. get fields). No overlapping functionality.

Naming Consistency4/5

Naming conventions are consistent within each tool group: 'validate_waf_expression' and 'get_waf_context' follow a verb_noun pattern, while CVE tools use 'fetch_cve_*' and 'list_*'. There is slight inconsistency across groups, but overall readable and predictable.

Tool Count5/5

Seven tools is well-scoped for the server's purpose, covering both CVE template access and WAF rule validation/documentation without being excessive or insufficient.

Completeness4/5

The tool set covers core CVE retrieval (fetch specific, list sources, fetch all) and comprehensive WAF validation (validate expressions, test with data, get context, get authoritative fields). Minor gap: no CVE search/filtering or rule management tools, but these are arguably outside the intended scope.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agent-prompt-injection-firewall-mcp
io.github.CSOAI-ORG
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Security AI & Machine Learning
2
agent-sec A
ai.kernora
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Security Code Analysis
221
shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2
ai·rete·rag AOAuth
com.ai-rete-rag
Author rules from policy docs, then decide: a Rete engine gives the verdict, an LLM explains why.
RAG Systems AI & Machine Learning Knowledge & Memory
81

Related MCP Servers

MCP Security Emulator
Penetration Testing Testing & QA Tools
olegzhr
A
license
Not graded
quality
C
maintenance
Simulates security attacks by providing LLM attack test payloads to validate ModSecurity-compatible detection rules.
Updated 3 months ago (2026-06-12 20:28 UTC)
Apache 2.0
crowdsec-local-mcpofficial
Security Developer Tools
crowdsecurity
A
license
B
quality
B
maintenance
Generates, validates, and deploys CrowdSec WAF rules and scenarios through natural language.
Updated 25 days ago (2026-08-12 10:55 UTC)
24
22
MIT
regex-quality
Code Analysis Testing & QA Tools
XlogicX
A
license
A
quality
C
maintenance
Provides tools to test regex patterns for correctness, performance (ReDoS), and memory usage, and suggests safe rewrites. Enables LLMs to iterate on regex generation with verifiable feedback.
Updated 2 months ago (2026-06-28 01:13 UTC)
9
MIT
PolicyPilot MCP Server
Security Networking & Infrastructure
alshawwaf
F
license
Not graded
quality
B
maintenance
Enables LLM agents to automate Check Point firewall rule changes by translating natural language access requests into correct, first-match-safe policy updates via MCP tools.
Updated 2 months ago (2026-07-14 20:03 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gen0sec/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

WAF & Smart-Firewall Rule Generation for Agentic LLMs

Quick start

Claude Desktop (bundle)

Which bundle: thin vs offline

Cursor IDE — local (stdio)

Docker (HTTP)

MCP surface

Tools

Resources

Prompts

Architecture

Documentation

Thank you!

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

crowdsec-local-mcpofficial

Latest Blog Posts

MCP directory API