Skip to main content
Glama
zscaler

zscaler-mcp-server

Official
by zscaler

zdx_get_software_details

Read-only

Expand one ZDX software key into its per-user/device install rows.

Instructions

Expand one ZDX software key into its per-user/device install rows.

Read-only. Returns the users and devices that have the given software_key installed. Obtain the key from zdx_list_software.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional 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.
geo_idNo
user_idsNo
device_idsNo
location_idNo
software_keyYes
department_idNo
Install Server

TDQS

A4.4/5.0
Behavior5/5

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

The description explicitly states it is read-only, matching the annotation, and describes the output (returns users and devices), giving transparency about behavior and side effects.

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 succinct and directly conveys the purpose, read-only nature, and key source without redundant information.

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

Completeness4/5

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

It provides necessary context by linking to zdx_list_software and stating the return type, though it lacks detail on the exact structure of the returned data, which is acceptable for a get operation without an output schema.

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?

Only the required software_key parameter is explained in the description; the other optional parameters (query, geo_id, user_ids, device_ids, location_id, department_id) lack any semantic clarification, leaving most parameters undefined.

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's function: expanding a software key into per-user/device install rows, which distinguishes it from zdx_list_software and other list/get tools.

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

Usage Guidelines5/5

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

The description explicitly mentions obtaining the key from zdx_list_software, providing a clear prerequisite and usage context for when to invoke this tool.

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

Other Tools

Latest Blog Posts

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/zscaler/zscaler-mcp-server'

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