Skip to main content
Glama

Opsphere — DevOps & SRE Intelligence

Cloudflare: WAF IP allowlist audit

cf_waf_ip_audit
Read-only

Read-only: compare IPs/CIDRs against WAF custom rules: ip.src in {…} literals, ip.src eq , and (when resolveLists is true) ip.src in $list_name via Account Rules Lists API. Returns found/not_found per IP, unparseable rules, listRefsRequested/Resolved, warnings. Token needs Zone → Firewall Services → Read; for $lists also Account → (Rules) Lists → Read. Optional CLOUDFLARE_ACCOUNT_ID or accountId if zone response lacks account.id.

Input Schema

NameRequiredDescriptionDefault
ipsYesIPv4/v6 addresses or CIDRs to check
zoneYesZone name (e.g. your-tenant.com) or zone ID
accountIdNoCloudflare account ID for Lists API; overrides env CLOUDFLARE_ACCOUNT_ID and zone account
context_idNoOptional explicit Connection Hub work context (ctx_*). Omit to use the conversation's active workspace; global Hub tools ignore it.
account_slugNoCloudflare account slug. Required when the workspace has multiple accounts and the zone is not yet cataloged.
resolveListsNoExpand ip.src in $name using Account Rules Lists (default: true)
environment_slugNoCloud Catalog environment used as an account-routing preference when no zone is provided.

Output Schema

NameRequiredDescriptionDefault
okYes
dataYes
contractVersionYes
dataSchemaVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changed
    • changedOutput schema / properties / data / additionalProperties
      Previous value: -trueNew value: +false
    • removedOutput schema / properties / data / properties / count
      Removed value: -{
      -  "type": "number"
      -}
    • removedOutput schema / properties / data / properties / errors
      Removed value: -{
      -  "items": {
      -    "$ref": "#/properties/data/properties/result/anyOf/0/items"
      -  },
      -  "type": "array"
      -}
    • addedOutput schema / properties / data / properties / gaps
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / data / properties / ips
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedOutput schema / properties / data / properties / items
      Removed value: -{
      -  "$ref": "#/properties/data/properties/result/anyOf/0"
      -}
    • addedOutput schema / properties / data / properties / listRefs
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedOutput schema / properties / data / properties / messages
      Removed value: -{
      -  "items": {
      -    "anyOf": [
      -      {
      -        "type": "string"
      -      },
      -      {
      -        "$ref": "#/properties/data/properties/result/anyOf/0/items"
      -      }
      -    ]
      -  },
      -  "type": "array"
      -}
    • addedOutput schema / properties / data / properties / partial
      Added value: +{
      +  "type": "boolean"
      +}
    • removedOutput schema / properties / data / properties / result
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "items": {
      -        "additionalProperties": true,
      -        "properties": {},
      -        "type": "object"
      -      },
      -      "type": "array"
      -    },
      -    {
      -      "$ref": "#/properties/data/properties/result/anyOf/0/items"
      -    }
      -  ]
      -}
    • removedOutput schema / properties / data / properties / result_info
      Removed value: -{
      -  "$ref": "#/properties/data/properties/result/anyOf/0/items"
      -}
    • addedOutput schema / properties / data / properties / rulesScanned
      Added value: +{
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • removedOutput schema / properties / data / properties / success
      Removed value: -{
      -  "type": "boolean"
      -}
    • addedOutput schema / properties / data / properties / truncated
      Added value: +{
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / data / properties / unparseableRules
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "expression": {
      +        "type": "string"
      +      },
      +      "ruleId": {
      +        "type": "string"
      +      },
      +      "ruleName": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "ruleId",
      +      "ruleName",
      +      "expression"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / data / properties / warnings
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / data / properties / zoneId
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / data / required
      Added value: +[
      +  "rulesScanned",
      +  "listRefs",
      +  "ips",
      +  "unparseableRules",
      +  "warnings",
      +  "partial",
      +  "truncated",
      +  "gaps"
      +]
    • addedOutput schema / properties / dataSchemaVersion
      Added value: +{
      +  "const": 2,
      +  "type": "number"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "contractVersion",
      -  "ok",
      -  "data"
      -]New value: +[
      +  "contractVersion",
      +  "dataSchemaVersion",
      +  "ok",
      +  "data"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses the exact return shape (found/not_found per IP, unparseable rules, listRefsRequested/Resolved, warnings), conditional list resolution behavior, and the required token permissions. This is substantial behavioral context that an agent could not infer from annotations alone.

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 definition is front-loaded with the core purpose and packs useful details into a dense paragraph. It is longer than ideal but every clause carries operational value and there is no filler.

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 7-parameter tool with full schema coverage, an output schema, and annotations, the description is complete: it covers purpose, conditional list handling, return values, and permission fallbacks. An agent has everything needed to call it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: resolveLists controls expansion of ip.src in $list_name via the Account Rules Lists API, and accountId/CLOUDFLARE_ACCOUNT_ID is an optional fallback when the zone response lacks account.id.

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 states a specific verb and resource: 'compare IPs/CIDRs against WAF custom rules' for an audit. It clearly distinguishes this from sibling tools like cf_waf_custom_rules_list by focusing on IP membership checking rather than rule listing.

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 read-only audit context is clear and the conditional behavior of resolveLists is explained, which helps an agent understand when list resolution applies. However, it does not explicitly name alternatives or state when-not to use this tool versus cf_waf_custom_rules_list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources