zscaler-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

zpa_list_access_policy_rules

Read-only

List ZPA access policy rules with optional filtering, search, and pagination. Retrieve read-only rule details for auditing or automation.

Instructions

List ZPA access policy rules (read-only).

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No
`query`	No	Optional JMESPath expression applied to the results after the API call, for client-side filtering and projection. Examples: "[?enabled==`true`]", "[*].{name: name, id: id}", "length(@)". Omit to get the full records. IMPORTANT: field names are the keys of the returned records, which are usually snake_case (`custom_category`) even where the Zscaler API documents camelCase (`customCategory`) — guessing the spelling yields an empty list that looks like a real answer. If you have not already seen a record from this tool, call it once without `query` and read the keys off the response.
`search`	No
`page_size`	No
`microtenant_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.15.3Aug 19, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / microtenant_id / title
```
Added value: +"Microtenant Id"
```

addedInput schema / properties / page

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Page"
+}

addedInput schema / properties / page_size

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Page Size"
+}

changedInput schema / properties / query / description

Previous value: -"Optional JMESPath expression applied to the results after the API call, for client-side filtering and projection. Field names are exactly what the Zscaler API returns. Examples: \"[?enabled==`true`]\", \"[*].{name: name, id: id}\", \"length(@)\". Omit to get the full records."New value: +"Optional JMESPath expression applied to the results after the API call, for client-side filtering and projection. Examples: \"[?enabled==`true`]\", \"[*].{name: name, id: id}\", \"length(@)\". Omit to get the full records. IMPORTANT: field names are the keys of the returned records, which are usually snake_case (`custom_category`) even where the Zscaler API documents camelCase (`customCategory`) — guessing the spelling yields an empty list that looks like a real answer. If you have not already seen a record from this tool, call it once without `query` and read the keys off the response."

addedInput schema / properties / query / title
```
Added value: +"Query"
```

addedInput schema / properties / search

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Search"
+}

addedInput schema / title

Added value: +"zpa_list_access_policy_rulesArguments"

Changed9 schema fields changedv0.14.0Jul 28, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
removedInput schema / properties / microtenant_id / description
```
Removed value: -"Microtenant ID for scoping."
```
removedInput schema / properties / microtenant_id / title
```
Removed value: -"Microtenant Id"
```

changedInput schema / properties / query / description

Previous value: -"JMESPath expression for client-side filtering/projection of results."New value: +"Optional JMESPath expression applied to the results after the API call, for client-side filtering and projection. Field names are exactly what the Zscaler API returns. Examples: \"[?enabled==`true`]\", \"[*].{name: name, id: id}\", \"length(@)\". Omit to get the full records."

removedInput schema / properties / query / title
```
Removed value: -"Query"
```

removedInput schema / properties / query_params

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Optional query parameters for filtering.",
-  "title": "Query Params"
-}

removedInput schema / properties / service

Removed value: -{
-  "default": "zpa",
-  "description": "The service to use.",
-  "title": "Service",
-  "type": "string"
-}

removedInput schema / title

Removed value: -"zpa_list_access_policy_rulesArguments"

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "zpa_list_access_policy_rulesOutput",
-  "type": "object"
-}New value: +null

First observedv0.12.7Jun 24, 2026

TDQS

C2.7/5.0

Behavior2/5

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

The description only says 'read-only,' which is redundant with the readOnlyHint annotation. It discloses no additional behavioral context such as pagination defaults, response shape, filtering semantics, or any API-specific side effects, so the description adds little beyond the annotations.

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?

A concise one-sentence description with no waste. It is easy to parse, but it is so terse that it borders on under-specification, so it loses the top score for completeness of expression.

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?

With 5 optional parameters, no output schema, and no tool-level explanation of pagination/search behavior, this description is minimal. The valuable JMESPath guidance lives only in the query parameter's schema description, not in the tool description, leaving an incomplete picture for a complex list operation.

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 only 20% (query), and the tool description itself mentions none of the five parameters. page, page_size, search, and microtenant_id are left to inference from names, while the description does not compensate for the low coverage.

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?

Description uses a specific verb ('List') and an exact resource ('ZPA access policy rules'), so the core purpose is immediately clear. It does not explicitly contrast with zpa_get_access_policy_rule or the other ZPA policy/list siblings, but the verb and resource are enough to avoid basic confusion.

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 about when to choose this tool over zpa_get_access_policy_rule or the other list_* policy-rule tools. The description simply states the action and read-only nature, with no alternatives, prerequisites, or selection criteria.

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

Deploy Server

zpa_list_access_policy_rules

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools