Skip to main content
Glama
Sign In
vmware-sandbox-mcp

vmware-sandbox-mcp

by rumenjordanov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sandbox_check

Check whether a background command started in the sandbox is still running and retrieve its exit code, stdout, and stderr collected so far.

Instructions

Look at a background command started with sandbox_start: is it still running, and what has it printed?

Returns status ("running", "exited" when it ended by itself, or "stopped" when it was killed), exit_code (only when status is "exited"; 0 means success), and stdout and stderr collected so far. If the output is longer than about 1 MB only the newest part is returned, and stdout_truncated / stderr_truncated say so. Calling this does not affect the command; call it again later to see newer output.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sandbox_id": "<sandbox_id>",
      "job_id": "<job_id>"
    },
    "name": "sandbox_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes
sandbox_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it enumerates the three status values, defines exit_code semantics and its conditional presence, discloses the ~1MB truncation with the *_truncated flags, and explicitly says the call is non-mutating and re-callable. It stops short of stating error behavior for an unknown/missing job_id or whether the call ever blocks.

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?

Front-loaded with the question the tool answers, followed by the returned fields and then the polling note — good ordering. The return-value sentences are somewhat redundant given an output schema exists, but the truncation caveat earns its place.

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?

For a two-required-parameter background-job introspection tool, the description is complete on return semantics (helped further by an output schema) but leaves the key gap: identifying and sourcing the two identifiers. Adequate, with one real hole relative to the schema's 0% coverage.

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?

Schema description coverage is 0% and the description never names or explains sandbox_id or job_id — critically, it does not say where an agent obtains job_id (presumably from sandbox_start's response) or what happens if it is stale. The only implicit mapping comes from the phrase 'a background command started with sandbox_start', which is thin for a tool where both parameters are required.

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?

Opens with a specific verb and resource framed as a question ('Look at a background command started with sandbox_start'), then states the two things it reports: liveness and accumulated output. That framing clearly separates it from sandbox_start (which launches) and sandbox_stop/destroy without needing the schema.

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

Usage Guidelines4/5

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

Usage context is explicit: it applies to a command launched via sandbox_start that is running in the background, and the closing sentence tells the agent to poll ('call it again later to see newer output'). What's absent is any when-not guidance, e.g. that it is not the way to retrieve results after the job is gone or to block until completion.

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