Gen0Sec WAF Rule MCP Server

Official

by gen0sec

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.7
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.
Average 3.7/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 commits in the last 12 weeks
- Last stable release on June 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/gen0sec/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/gen0sec/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/gen0sec/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gen0sec/mcp-server)

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