Loading ToolBench
Official Zscaler Integrations MCP Server. Manage the Zscaler Zero Trust Exchange — ZPA, ZIA, ZDX, ZCC, ZCell, ZTW, ZIdentity, EASM, Z-Insights and ZMS — through the Model Context Protocol. Read-only by default; write tools require an explicit allowlist and every delete is confirmed by a human.
Scoring was not performed
No output schemas documented. The rubric requires documented output schemas so LLMs understand what fields to expect for downstream tool selection and chaining. None of the 18 tools document their response structure.
Parameters lack enum constraints for known-value fields. 'metric_name' in zdx_get_application_metric accepts free-form strings instead of declaring enum ['pft', 'dns', 'availability']. Similarly, 'score_bucket' in zdx_list_application_users lacks enum constraint even though it mentions allowed values in description. This invites LLM hallucination of invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Destructive operations lack confirmation pattern. zpa_delete_application_server and zpa_delete_server_group have a mysterious 'kwargs' parameter described as 'Hidden parameter for confirmation' but this is not a proper confirmation-request pattern. No dry-run, no explicit confirmation mechanism, no recovery tools documented.
No error handling guidance visible in descriptions. Patterns like recovery-guide require that error responses tell the LLM what to do next. No tool description explains what errors are retryable, user-fixable, or fatal, or what the LLM should do on failure.
Parameter descriptions lack format/range constraints. Numeric parameters like 'since' (hours to look back) and 'page_size' in zpa_list_server_groups have no min/max bounds specified. This allows LLMs to pass unbounded or absurd values. Description should state 'default 2h, range 1-168 hours' etc.
Inconsistent parameter naming across tools. Some tools use 'server_id', others use 'group_id' for similar resource references. While not identical, the lack of consistency increases cognitive load. Additionally, 'query_params' in zpa_list_application_servers is overly generic and should document what specific filters are accepted.
Missing pagination documentation. Tools like zpa_list_application_servers and zdx_list_applications list collections but descriptions do not clarify result limits, pagination mechanism (offset/cursor), or maximum result size. Per the rubric, LLM reasoning degrades with large result sets, limits should be documented.
Descriptions do not explain WHEN to use each tool vs. similar ones. For example, zdx_get_application vs. zdx_get_application_metric vs. zdx_get_application_score_trend are three distinct operations but their descriptions do not clarify which to call first or in what sequence. This forces LLMs to reason by trial-and-error.