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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.15.3
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / department_id / title
      Added value: +"Department Id"
    • addedInput schema / properties / device_ids / title
      Added value: +"Device Ids"
    • addedInput schema / properties / geo_id / title
      Added value: +"Geo Id"
    • addedInput schema / properties / location_id / title
      Added value: +"Location Id"
    • 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 / software_key / title
      Added value: +"Software Key"
    • addedInput schema / properties / user_ids / title
      Added value: +"User Ids"
    • addedInput schema / title
      Added value: +"zdx_get_software_detailsArguments"
  2. Changed17 schema fields changedv0.14.0
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / department_id / description
      Removed value: -"Filter by department ID(s)."
    • removedInput schema / properties / department_id / title
      Removed value: -"Department Id"
    • removedInput schema / properties / device_ids / description
      Removed value: -"Filter by device ID(s)."
    • removedInput schema / properties / device_ids / title
      Removed value: -"Device Ids"
    • removedInput schema / properties / geo_id / description
      Removed value: -"Filter by geolocation ID(s)."
    • removedInput schema / properties / geo_id / title
      Removed value: -"Geo Id"
    • removedInput schema / properties / location_id / description
      Removed value: -"Filter by location ID(s)."
    • removedInput schema / properties / location_id / title
      Removed value: -"Location Id"
    • addedInput schema / properties / query
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "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 / service
      Removed value: -{
      -  "default": "zdx",
      -  "description": "The service to use.",
      -  "title": "Service",
      -  "type": "string"
      -}
    • removedInput schema / properties / software_key / description
      Removed value: -"The software name and version key."
    • removedInput schema / properties / software_key / title
      Removed value: -"Software Key"
    • removedInput schema / properties / user_ids / description
      Removed value: -"Filter by user ID(s)."
    • removedInput schema / properties / user_ids / title
      Removed value: -"User Ids"
    • removedInput schema / title
      Removed value: -"zdx_get_software_detailsArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "items": {
      -        "additionalProperties": true,
      -        "type": "object"
      -      },
      -      "title": "Result",
      -      "type": "array"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "zdx_get_software_detailsOutput",
      -  "type": "object"
      -}New value: +null
  3. First observedv0.12.7

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.

Deploy Server

Other Tools