Skip to main content
Glama
Sign In
vram-mcp

vram-mcp

by sushiHex
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

vram_status

Report GPU VRAM pressure and Ollama model residency so you can free memory for loading new models.

Instructions

Report the selected GPU and server-wide Ollama model residency.

Includes device identity, source health/timestamps/coverage, claims, recent GPU activity, and pressure (ok|tight|degraded|thrashing|unknown). Unavailable residency is null; unavailable telemetry never establishes an empty or healthy GPU. thrashing means the driver was measured paging VRAM.

Each other_processes command line is cut to its first cmdline_chars characters (default 160), ending in "…" when cut. 0 omits the field; null returns command lines whole.

Input Schema

NameRequiredDescriptionDefault
cmdline_charsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.1
    • addedInput schema / properties / cmdline_chars
      Added value: +{
+  "anyOf": [
+    {
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": 160,
+  "title": "Cmdline Chars"
+}
  2. First observedv0.2.0

TDQS

A3.8/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 well: it defines the pressure enum values, states that unavailable residency is null, and clarifies that unavailable telemetry never implies an empty or healthy GPU, plus what 'thrashing' means. It omits permission/auth requirements and rate limits, but the semantic/safety context provided is substantial.

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?

Purpose is front-loaded in the first sentence, and each subsequent sentence adds distinct information. It is dense and mixes high-level output description with low-level parameter semantics, but there is little true waste.

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?

With no output schema and no annotations, the description describes the returned fields (device identity, health/coverage, claims, pressure) and the parameter's behavior, which is close to sufficient for an agent to call it. It could still name sibling alternatives to be fully complete.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it fully documents cmdline_chars: default 160, truncation with an ellipsis, 0 omits the field, and null returns full command lines. The edge-case semantics are spelled out rather than restated.

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 verb and resource ('Report the selected GPU and server-wide Ollama model residency') and enumerates exactly what the report contains. It does not, however, name or distinguish itself from siblings like list_loaded, history, or trend, so it stops short of a 5.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives such as list_loaded (loaded models) or history/trend (time series). Usage is only implied by the read-like verb 'Report'.

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