Skip to main content
Glama

read_capability

Read-onlyIdempotent

Execute read-only Prisma SD-WAN API actions from the registry by ID for direct data access when semantic tools lack coverage.

Instructions

Execute one exact read-only registry capability as an expert escape hatch.

Prefer the semantic tools first. Use list_capabilities to discover an action_id. Parameters are validated against the registry and every response passes through central recursive secret redaction and response-size limits.

Curated actions that still need live verification are blocked here by default; set MCP_ALLOW_UNVERIFIED_COMPAT=true only after completing the validation checklist shipped with this project.

Args: action_id: Exact action identifier from list_capabilities, e.g. "sites_devices.sites". Not a free-text search term. path_parameters: One key per required/optional path parameter that action's list_capabilities entry lists under path_parameters (e.g. {"site_id": "..."}). Omit or use {} for actions with none. Unknown keys are rejected. body: JSON object matching that action's body_schema. Only meaningful for POST actions — passing any non-empty body to a GET action is rejected, as is any field the action's schema does not declare (the error names the valid fields). Two traps on the standard query body: retrieved_fields is refused — the controller answers it with the full record and a fabricated value in every unrequested field, so the reply looks right and is wrong; and a limit inside the body is not this tool's limit — it truncates at the controller and reports the truncated total with no cursor, stranding the rest. Page with the limit/cursor arguments below instead. cursor: Opaque pagination token copied from a previous response's next_cursor. Only applies when the result is a list. A cursor is bound to the tool that issued it — one from another tool is rejected rather than applied to an unrelated list. limit: Max items to return in this page when the result is a list. Omit to use the server default page size (50; max 200). This is the tool's own paging, applied after the response arrives — prefer it over a limit field in body. detail: "compact" (default) lets a large response drop fields that neither identify a record nor report its condition, so more records fit in one reply; whatever it held back is listed in omitted_fields. Pass "full" to get every field of every record instead, at the cost of fewer records per page. Small responses are unaffected either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoJSON object matching that action's ``body_schema``. Only meaningful for ``POST`` actions — passing any non-empty body to a ``GET`` action is rejected, as is any field the action's schema does not declare (the error names the valid fields). Two traps on the standard query body: ``retrieved_fields`` is **refused** — the controller answers it with the full record and a fabricated value in every unrequested field, so the reply looks right and is wrong; and a ``limit`` *inside* the body is not this tool's `limit` — it truncates at the controller and reports the truncated total with no cursor, stranding the rest. Page with the `limit`/`cursor` arguments below instead.
limitNoMax items to return in this page when the result is a list. Omit to use the server default page size (50; max 200). This is the tool's own paging, applied after the response arrives — prefer it over a ``limit`` field in `body`.
cursorNoOpaque pagination token copied from a previous response's `next_cursor`. Only applies when the result is a list. A cursor is bound to the tool that issued it — one from another tool is rejected rather than applied to an unrelated list.
detailNo``"compact"`` (default) lets a large response drop fields that neither identify a record nor report its condition, so more records fit in one reply; whatever it held back is listed in ``omitted_fields``. Pass ``"full"`` to get every field of every record instead, at the cost of fewer records per page. Small responses are unaffected either way.
action_idYesExact action identifier from `list_capabilities`, e.g. ``"sites_devices.sites"``. Not a free-text search term.
path_parametersNoOne key per required/optional path parameter that action's `list_capabilities` entry lists under ``path_parameters`` (e.g. ``{"site_id": "..."}``). Omit or use ``{}`` for actions with none. Unknown keys are rejected.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes further: it discloses central recursive secret redaction, response-size limits, default blocking of unverified actions, and two specific traps (retrieved_fields being answered with fabricated values, and body-level limit truncating without a cursor). These are critical behavioral details beyond what annotations convey. No contradiction with annotations.

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 front-loaded with a one-sentence purpose, followed by usage guidance and then a structured Args section. Every sentence earns its place: it covers validation, redaction, the blocked-action env var, pagination, body traps, and detail modes. Although long, the tool is complex (6 parameters, multiple caveats), and the structure makes it easy to scan.

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?

Given the tool's complexity (6 parameters, output schema, annotations), the description is complete: it explains purpose, when to use it, parameters, pagination, detail mode, validation, and the unverified-compat guardrail. The output schema handles return-value documentation, so the description need not repeat that. No notable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% parameter description coverage, and the schema's descriptions exactly reuse the description's Args text. Therefore, the description adds no meaning beyond the schema for parameters. Baseline 3 applies because high schema coverage means the schema already carries the burden.

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 opens with a specific verb and resource: 'Execute one exact read-only registry capability as an expert escape hatch.' This clearly identifies the tool's function and distinguishes it from semantic sibling tools (get_*, find_*) by framing it as a low-level escape hatch. The phrase 'one exact read-only registry capability' also conveys precision and scope, making the purpose unambiguous.

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 provides explicit usage guidance: 'Prefer the semantic tools first' and 'Use list_capabilities to discover an action_id.' It also warns about the MCP_ALLOW_UNVERIFIED_COMPAT environment variable and that unverified actions are blocked by default. This gives clear recommendations on when to use the tool versus alternatives and how to handle blocked actions.

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

Install Server

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/iamdheerajdubey/prisma-sdwan-mcp'

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