Skip to main content
Glama

Operations in progress

cs_admin_environment_status

Check the status of tenant operations still running, such as copies, restores, resets, and deletions, by running pac admin status with the active auth profile.

Instructions

Status of the tenant operations that are still running (copies, restores, resets, deletions). Runs 'pac admin status' with the active pac auth profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory for pac (for project commands: the solution project folder)
profileNopac auth profile to run as: the admin account for tenant commands. Defaults to CPS_ADMIN_PROFILE for admin commands and CPS_PAC_PROFILE otherwise, then the active profile. cs_init lists the profiles.
backgroundNoRun in the background and return a jobId immediately, for a command that takes longer than the client will wait. Poll cs_job_status.
timeoutSecondsNoDefault 600

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.8
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.1.5

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the mechanism ('Runs pac admin status') and that it uses the active pac auth profile, which signals a read-only CLI query, but it never explicitly states read-only/non-destructive behavior, permission requirements, or what the status output contains.

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?

Two tight sentences, front-loaded with the resource and its scope, followed by the implementation note. No filler, though the 'pac admin status' sentence is slightly more internal detail than an agent strictly needs.

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

Completeness3/5

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

No output schema exists, so the description should ideally characterize the returned status (fields, format, how to interpret 'still running'). It stops at naming the operation types, leaving the shape of the response unspecified for a tool whose entire purpose is reporting status.

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?

Schema description coverage is 100%, so the schema already documents cwd, profile, background, and timeoutSeconds in detail. The description adds only a passing reference to the 'active pac auth profile', which relates to the profile param but adds no real semantics beyond what the schema provides.

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?

States a specific resource and scope: 'Status of the tenant operations that are still running', with the concrete operation types (copies, restores, resets, deletions) named. This distinguishes it from the generic cs_status and from cs_job_status, though it never explicitly contrasts with those siblings.

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

Usage Guidelines3/5

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

Usage is only implied: the reader infers this is the tool to check for in-flight tenant operations. The only routing help is buried in the background param description ('Poll cs_job_status'), and there is no explicit statement of when to use this versus cs_job_status or cs_list_org_agents.

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