This server provides read-only operational and health monitoring for a local vLLM server (typically systemd-managed in WSL2). Capabilities include:
Check health: Liveness check via /v1/models (deep=False) or full generation test via /v1/chat/completions (deep=True) to confirm text generation. Deep checks are rate-limited (20 calls/min) and return status (up/degraded/down), latency, and completion time.
List models: Retrieve the list of model IDs currently loaded/served via /v1/models.
Test completion: Submit an on-demand text completion with a custom prompt for manual sanity checks. Rate-limited; max_tokens is clamped to 1024, prompt capped at 8000 characters.
Get GPU status: Per-GPU VRAM usage (used/total) and utilization via nvidia-smi, plus per-process VRAM (may be unreliable in WSL2).
Get service status: Systemd unit status (load/active/sub state, restart count, main PID, last-active timestamp) via systemctl, with WSL compatibility.
Inspect launch flags: Retrieve the live vLLM command-line flags from /proc//cmdline (falling back to the exec script if the process is down), with sensitive values automatically redacted.
Provides GPU/VRAM status monitoring via nvidia-smi for NVIDIA GPUs, including per-GPU memory usage and utilization, and per-process VRAM attribution (best-effort).
Read-only ops/health MCP server for a local, WSL2/systemd-managed vLLM server -- liveness vs. real-completion health tiers, GPU/VRAM status, systemd service status, and live serve-flag introspection. Built to the same standard as mcp-factory and desktop-mcp, and other local tooling in this operator's portfolio: own pyproject, own fastmcp server, honest README, real test suite, no product code before a spec was confirmed.
This is not a container-lifecycle manager. It assumes vLLM already runs
as a bare-metal systemd unit inside WSL2 (this operator's actual setup --
see vllm-autostart), not inside Docker/Podman.
// ~/.claude.json (or any MCP-host stdio client config)
{
"mcpServers": {
"vllm-ops-mcp": {
"type": "stdio",
"command": "C:\\Users\\<you>\\projects\\vllm-ops-mcp\\.venv\\Scripts\\python.exe",
"args": ["C:\\Users\\<you>\\projects\\vllm-ops-mcp\\run_server.py"]
}
}
}Related MCP server: infra-mcp
Tool | What it does | What it can't do |
|
| Cannot fix a degraded server -- reports ground truth only. |
|
| No detail beyond what vLLM's API itself exposes. |
| On-demand real completion with a caller-supplied prompt, for manual sanity checks. | Rate-limited (same bucket as |
|
| Per-process VRAM attribution does not work on this operator's actual WSL2 setup -- live-verified empty even while the vLLM process holds 13.7GB (see Limitations). Treat |
|
| Read-only -- cannot start/stop/restart the unit. No computed uptime duration (deliberately -- see Limitations, clock-discipline note). |
| Read-only launch-flag introspection. Prefers the LIVE process's actual argv ( | vLLM doesn't expose its own launch flags over the API, so this never queries the server itself -- it's always shelling out. Exec-script fallback parsing is best-effort shell-text parsing (less precise than the live-argv path). |
restart_service (Phase 2, not built)Deliberately not implemented in this release. Per the spec: vLLM is
shared infra other bots/tools depend on (options-bot, qwen_cli.py
callers, DeerFlow fallback), so a restart tool needs its own gating design
(off by default, VLLM_OPS_MCP_ENABLE_RESTART=1, refuse to touch a healthy
instance unless force=True, rate-capped) before it ships -- not
retrofitted onto a read-only MVP. Tracked as a v2 idea, not a current
capability. If built, it should wrap run-vllm.cmd's exact recipe (systemctl start vllm only, never blind stop/restart) rather than reinvent it.
Every health signal in this server comes from an actual HTTP request to the
OpenAI-compatible API (urllib.request, not a socket/connect check). This
is deliberate, not incidental: Get-NetTCPConnection and other
listener-based checks miss WSL2-mirrored-networking-relayed ports
entirely -- a genuinely healthy 127.0.0.1:8000 can be invisible to a
listener probe run from the Windows host. check-vllm.cmd already embodies
this lesson; this server generalizes it into two tiers (liveness vs. real
generation) that nothing else in this operator's fleet exposes as MCP tools.
Read this before you register vllm-ops-mcp. Honesty about blast radius is the point.
This server shells out to nvidia-smi, systemctl (via wsl -d), and
reads /proc/<pid>/cmdline. All six tools are read-only -- nothing here
starts, stops, restarts, or kills a process, and no tool accepts an
argument that gets passed to a shell unescaped (unit/distro names come
from server-side config, not caller input; shlex.quote wraps the one
caller-adjacent path that does reach a shell string, the unit name in
systemctl show).
check_health(deep=True) and test_completion fire a real inference
call against a shared GPU server. Rate-limited (default 20 calls/min,
VLLM_OPS_MCP_DEEP_RATE_LIMIT_PER_MIN) specifically because this vLLM
instance is shared infra other bots/tools depend on -- a caller hammering
this MCP could starve or slow other consumers even though every call
individually looks "read-only."
get_serve_config's live-process path reads /proc/<pid>/cmdline,
which can include secrets if any were ever passed as CLI flags (none are,
in this operator's actual setup -- the model path and flags are all
non-secret; auth, if any, is environment-injected inside the exec script,
not passed as an argv flag). Defense-in-depth: any argv entry whose
preceding flag name matches a known-sensitive pattern (token, key,
secret, password, passwd, credential -- config. SENSITIVE_ARGV_FLAG_PATTERNS) has its value redacted to
[REDACTED] before being returned, in both the structured argv/flags
fields and raw_text; the flag name itself is left visible so the shape
is still diagnosable. This applies across all three sources
(live_process, exec_script, local_config_mirror).
No tool has any write/mutate capability in this release. There is no
env var that turns one on -- restart_service doesn't exist in this
codebase yet (see Future extension above), so there's nothing to
accidentally enable.
Claim | Implementation | Verified by |
Liveness health tier ( |
|
|
Deep/real-completion health tier |
|
|
Model list passthrough |
|
|
On-demand completion sanity check |
|
|
GPU/VRAM status via nvidia-smi |
|
|
Per-process VRAM attribution |
| Unit-tested with a mocked non-empty response; live-verified to return EMPTY on this operator's actual WSL2 setup -- see Limitations |
systemd unit status via structured |
|
|
Live-process launch-flag introspection via |
|
|
Exec-script fallback when the unit is down |
|
|
Local config-mirror override path |
|
|
Sensitive-flag-value redaction in |
|
|
Deep-inference rate limiting (shared-infra protection) |
|
|
WSL-vs-native shell-out abstraction |
|
|
All 6 tools registered, no Phase-2 tool present |
|
|
Per-process VRAM attribution is unreliable under this operator's actual
WSL2 GPU-passthrough config. get_gpu_status's live smoke test (real
nvidia-smi.exe against the real running vLLM process) returned an
empty processes list even though the same call's gpus[0]. memory_used_mib correctly showed 13.7GB in use by that process. This is a
documented nvidia-smi --query-compute-apps limitation under some
WSL2/passthrough configurations, not a bug in this server's parsing --
the tool reports the empty result honestly (ok: true, processes: [])
rather than fabricating attribution. Don't rely on processes for
VRAM-overshoot root-causing on this setup; gpus[].memory_used_mib is the
reliable signal.
No computed service uptime. get_service_status returns the raw
ActiveEnterTimestamp string from systemctl (already timezone-labeled,
e.g. MDT) rather than computing an elapsed duration server-side --
deliberately, per this operator's own clock-discipline rule (never state
an elapsed/ETA time from estimation; artifact timestamps are often UTC
while local is UTC-6/-7). Compute the delta at the call site if you need
it, with an explicit timezone conversion.
get_serve_config's exec-script fallback is best-effort shell-text
parsing, not an exact argv array -- it handles \ line continuations
and basic quoting via shlex.split, but a sufficiently unusual exec
script could parse incorrectly. The live-process path (/proc/<pid>/ cmdline) does not have this limitation (it's the kernel's exact argv,
null-separated) and is always preferred when the unit is up.
WSL2-specific by default, but the seam is explicit. get_service_status
and get_serve_config's live-process path assume this server runs on the
Windows host and shells into WSL2 via wsl -d <distro>. Set
VLLM_OPS_MCP_RUNS_IN_WSL=1 if this server process itself runs inside
WSL2/Linux natively (native systemctl/cat, no wsl -d hop) -- both
paths are unit-tested (TestGetServiceStatus::test_uses_wsl_prefix_on_windows
/ test_no_wsl_prefix_when_native), but only the Windows-host path has
been live-verified against this operator's actual setup.
Single vLLM instance, single GPU, this operator's setup. No
multi-instance/multi-GPU aggregation; get_gpu_status returns whatever
nvidia-smi --query-gpu enumerates, which is every GPU visible to the
process, not scoped to "the GPU vLLM is using" if more than one exists.
No lifecycle control whatsoever in this release. See "Future extension" above -- this is intentional, not an oversight.
Var | Effect | Default |
| OpenAI-compatible base URL |
|
| served-model-name, used in completion payloads |
|
| WSL distro hosting vLLM |
|
| systemd unit name |
|
| WSL-side path to the serve exec script (fallback source) |
|
| local file mirror of the exec script; if set, | unset |
|
|
|
|
| auto-detected via |
| cap on |
|
|
| unset (skip) |
// A tool call from the MCP host, illustrative -- not a shell command.
{"tool": "check_health", "arguments": {"deep": true}}
// -> {"ok": true, "status": "up", "tier": "deep", "model_id": "qwen3-14b",
// "latency_ms": 32.0, "completion_s": 0.218, "error": ""}
{"tool": "get_serve_config", "arguments": {}}
// -> {"ok": true, "source": "live_process", "pid": 5645,
// "flags": {"model": "Qwen/Qwen3-14B-AWQ", "served_model_name": "qwen3-14b",
// "port": "8000", "max_model_len": "8192",
// "gpu_memory_utilization": "0.72", "max_num_seqs": "8",
// "enable_auto_tool_choice": true, "tool_call_parser": "qwen3_xml", ...}}
// rate limit exceeded (21st deep call within a minute):
{"tool": "test_completion", "arguments": {"prompt": "hi"}}
// -> {"ok": false, "error": {"type": "rate_limited", "group": "deep_inference",
// "tool": "test_completion", "limit_per_min": 20, "retry_after_s": 4.87}}CI (.github/workflows/ci.yml) runs this suite on every push/PR (ubuntu-latest --
the unit suite mocks HTTP/subprocess, no live server/GPU/WSL required) and
fails the build if the Tests badge above drifts from what the suite
actually reports -- see scripts/check_readme_counts.py.
# unit suite (mocked HTTP/subprocess, no live server/GPU/WSL required)
.venv\Scripts\python.exe -m pytest -q
# -> 95 passed, 7 skipped
# handshake check -- prints every registered tool name
.venv\Scripts\python.exe scripts\list_tools.py
# real-infra smokes (real vLLM completion, real nvidia-smi, real systemctl
# via WSL, real /proc/<pid>/cmdline read) -- read-only, safe to run anytime
# vLLM is up
VLLM_OPS_MCP_LIVE=1 .venv\Scripts\python.exe -m pytest -v -m live
# -> 7 passed (all live, against the actual running qwen3-14b instance)python -m venv .venv
.venv\Scripts\python.exe -m pip install -r requirements.txtRegistered in ~/.claude.json as vllm-ops-mcp (stdio, own .venv, no env
overrides needed for this operator's default setup).
Maintained by Jaimen Bell. For production MCP integrations, custom servers, or agent-reliability work, see jaimenbell.dev.
Building your own MCP server? The MCP Starter Kit has templates, a build playbook, and packaging war-stories from shipping this one.
mcp-name: io.github.jaimenbell/vllm-ops-mcp
Two-stage health probe for the local vLLM server, mirroring check-vllm.cmd. deep=False (default): GET /v1/models liveness check only. deep=True: additionally fires one minimal real /v1/chat/completions call to confirm the server actually generates text, not just reports a model loaded (rate-limited -- this consumes real GPU inference cycles on shared infra). Returns {ok, status: up|degraded|down, tier, model_id, latency_ms, completion_s, error}.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 excellently. It discloses the two-stage behavior, the exact HTTP calls, the side effect of GPU consumption, and the complete return envelope. This is unusually transparent for a health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place. The description efficiently covers purpose, parameter semantics, behavioral caveats, and return value without redundancy. It is front-loaded with the main verb and resource, then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is complete. It explains the two modes, the side effects, and the return structure. No important aspect is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a bare 'deep' boolean with no description. The description fully explains the parameter's meaning, default, and the behavioral difference between true and false, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Two-stage health probe for the local vLLM server.' It clearly distinguishes this from siblings like list_models or test_completion by framing it as a health check, not a utility for listing or textual generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use deep=False (liveness check) versus deep=True (verifying actual text generation) and warns that deep=True is rate-limited and consumes GPU cycles. However, it does not explicitly name sibling alternatives or state when not to use this tool in favor of another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nvidia-smi wrapper: per-GPU VRAM used/total and utilization%, plus per-process VRAM usage (to catch VRAM-overshoot). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states 'Read-only,' which is a key safety trait, and explains the per-process VRAM tracking rationale. It adds context beyond the tool name, though it omits potential failure modes (e.g., nvidia-smi not available).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence that front-loads the essential information ('nvidia-smi wrapper') and efficiently includes all necessary details without waste. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with no parameters and an output schema, the description adequately covers purpose, key metrics, and safety. It does not explain return format, but the existence of an output schema makes that unnecessary. The only gap is the lack of explicit usage guidance, but this is partially covered under that dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description adds no parameter details (as none are needed) but clarifies what the tool reports, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an nvidia-smi wrapper for GPU status, listing specific metrics (VRAM used/total, utilization%, per-process VRAM usage). This distinguishes it from sibling tools like check_health or get_service_status, which suggest broader system or service monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the phrase 'to catch VRAM-overshoot,' indicating a troubleshooting scenario. However, there is no explicit statement about when to prefer this tool over alternatives or any exclusions, leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only introspection of the current vLLM launch flags. Prefers the LIVE process's real argv (/proc//cmdline of the systemd unit's MainPID) as ground truth; falls back to the static exec script if the process isn't currently up. vLLM does not expose its own launch flags over the API, so this never queries the server itself. Any argv value following a flag matching a known-sensitive pattern (token/key/secret/password/credential) is redacted before being returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and excels. It discloses that it never queries the server, sources data from /proc/<pid>/cmdline with fallback to the exec script, and redacts sensitive values (token/key/secret/password/credential). This provides the agent with a complete safety and operational profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first establishes purpose, the second explains the data source and fallback, the third explains redaction. It is front-loaded with the core action and avoids any redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a parameter-less tool with an output schema. It covers the source of truth, fallback logic, API interaction avoidance, and security redaction. Given no annotations and no params, there are no critical gaps in the agent's ability to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not applicable. The description does not need to compensate for schema gaps, and the baseline of 4 for parameter-less tools is appropriate. The description's detailed behavior adds context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: read-only introspection of vLLM launch flags. It names the specific resource (vLLM launch flags) and action (introspection), and the use of 'read-only' distinguishes it from mutation tools. Among siblings like check_health or list_models, this is uniquely about configuration, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool prefers live process data over static fallback, which implies it should be used to get launch flags regardless of process state. However, it does not explicitly contrast with sibling tools or say when not to use it. There is no direct alternative mentioned, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
systemd unit status for the vLLM service (via wsl -d <distro> -- systemctl show, or native systemctl if this server runs inside WSL2/Linux). Returns load/active/sub state, restart count, main PID, and last-active timestamp. Read-only -- never starts/stops the unit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only -- never starts/stops the unit,' which is a key safety disclosure. It also details the execution context (WSL vs native systemctl) and lists the returned fields, adding transparency beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences that front-load the purpose, then add the command detail and safety note. Every phrase earns its place; the WSL/native distinction is relevant without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is fully complete. It states what the tool does, the execution environment, the specific return data, and the critical read-only constraint. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description adds no parameter-specific detail beyond mentioning the distro placeholder in the underlying command. Since the schema already fully covers parameters (none), the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports the systemd unit status for the vLLM service, describing both the underlying command and the specific data returned. This distinguishes it from sibling tools like check_health (likely HTTP health) or get_gpu_status (hardware status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when systemd unit status is needed, but it does not explicitly contrast with alternatives or state when not to use it. No explicit when/when-not guidance is provided, though the read-only note hints at suitable contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET /v1/models passthrough -- lists model IDs currently loaded/served.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states this is a GET passthrough, signaling a safe read-only operation, and clarifies that it returns currently loaded/served model IDs. With no annotations, it carries the burden well, though it omits details about error behavior or data freshness; for such a simple list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It states the action and resource directly, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no parameters, and an output schema exists, so the description only needs to state its purpose. It does so clearly, and the sibling tool names provide additional context for placement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so description parameter guidance is unnecessary; the baseline for 0 params is 4. The description does clarify that the output consists of model IDs, complementing the existing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'lists' and identifies the resource as 'model IDs currently loaded/served,' clearly distinguishing it from sibling tools like check_health or get_service_status. The 'GET /v1/models passthrough' prefix reinforces the operational scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use when querying available/loaded model IDs, but provides no explicit when-to-use or when-not-to-use guidance. It does not name alternative tools, leaving usage timing to inference based on the tool's name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
On-demand real /v1/chat/completions call with a caller-supplied prompt, for manual sanity-checking (same mechanism as check_health(deep=True) but user-controlled). Rate-limited -- consumes real GPU inference cycles on shared infra. max_tokens is clamped server-side to config.MAX_TEST_COMPLETION_TOKENS and the prompt is capped at config.MAX_TEST_COMPLETION_PROMPT_CHARS (oversized prompts are rejected) -- the rate limiter bounds call frequency, not the cost of a single call. Returns {ok, model_id, completion_s, text, error}.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| max_tokens | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it is a real inference call, rate-limited, consumes GPU cycles, clamps max_tokens, caps prompt size (rejects oversized), and the rate limiter bounds frequency not per-call cost. Return shape is also given. This goes well beyond a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the core purpose and packs in all critical constraints, alternatives, and return fields without redundancy. Every clause adds value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need to detail return values but does anyway. It covers purpose, usage, safety, rate limits, parameter constraints, and alternatives. For a tool with 2 params and moderate complexity, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains prompt as 'caller-supplied' and adds behavioral semantics for max_tokens (clamped) and prompt (capped, oversized rejected). It doesn't mention max_tokens is optional or its default, but the schema already shows default=16. This is a strong addition, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs a real /v1/chat/completions call with a user-supplied prompt for manual sanity-checking. It distinguishes itself from siblings by explicitly comparing to check_health(deep=True) and noting the user-controlled nature, and from the other get/list tools which are obviously not completion calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'for manual sanity-checking' and directly names the alternative check_health. It also warns about rate limiting and GPU consumption, implying it should be used sparingly, and clarifies when not to rely on it (costly, rate-limited).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_healthget_gpu_statusget_serve_configget_service_statuslist_modelstest_completionTools target distinct resources (health, models, GPU, service, config) and actions. The only potential overlap is between check_health(deep=true) and test_completion, but their purposes are clearly differentiated as health probe vs. user-driven test.
All tool names follow a consistent snake_case verb_noun pattern: check_health, list_models, test_completion, get_gpu_status, get_service_status, get_serve_config. No mixed conventions or vague verbs.
Six tools is well-scoped for a vLLM operations server. Each tool covers a distinct operational need without redundancy or bloat, fitting comfortably in the ideal 3-15 range.
The tool set covers core read-only monitoring (health, models, GPU, service, config) and testing. Minor gaps include lack of service control (start/stop/restart) and log retrieval, but these are likely intentional given the read-only nature of the service status tool.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Read-only health context MCP server for Iris users.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jaimenbell/vllm-ops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
