vram-mcp lets AI agents inspect, coordinate, and manage shared NVIDIA GPU VRAM for Ollama workloads.
Inspect GPU memory, resident models, claims, activity, and pressure with vram_status() and list_loaded().
Free VRAM by unloading named models (unload) or reaching a target (ensure_free), respecting claims/busy signals unless force=True.
Load or refresh Ollama models with warm(), checking reservations and reporting succeeded|refused|failed|unknown plus pending windows.
Coordinate shared use with model claims (claim, renew, release, list_claims) and capacity reservations (reserve) for training or other non-Ollama GPU work.
Review audit history and free-VRAM trends with history() and trend(); get heuristic config suggestions with advise().
Interpret pressure states (ok, tight, degraded, thrashing, unknown) using coverage/observations, treating unavailable telemetry as unknown rather than empty.
Coordination is cooperative; direct Ollama calls can bypass vram-mcp.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vram-mcp Free up 2GB of VRAM"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give your AI agents a shared view of GPU memory. Through MCP, they can inspect what's using VRAM, make room for Ollama models, and see which sessions are already relying on them.
Each client runs its own server; sessions under the same OS user share claims, reservations, pending-operation records, and an audit log. Capacity and process readings apply to one configured GPU. Claimed or recently busy models are protected from eviction by default.
Use Python 3.10+, a running Ollama instance, and an NVIDIA GPU with
drivers for memory readings. Windows and Linux are tested. Without
nvidia-smi or NVML, model operations and claims still work, but some readings
are unavailable.
Run vram-mcp on the machine hosting Ollama and the GPU. Changing
OLLAMA_BASE_URL redirects model requests; GPU and process inspection always
remain local. On a multi-GPU host, set VRAM_MCP_GPU_INDEX in every client's
server environment to select the same device; the default is GPU index 0.
With uv and Git
installed, choose your client below. uvx fetches vram-mcp from GitHub into an
isolated environment; no source checkout is needed.
claude mcp add vram --scope user -- uvx --from git+https://github.com/sushiHex/vram-mcp@v0.3.1 vram-mcpcodex mcp add vram -- uvx --from git+https://github.com/sushiHex/vram-mcp@v0.3.1 vram-mcpHermes — merge into ~/.hermes/config.yaml:
mcp_servers:
vram:
command: uvx
args: ["--from", "git+https://github.com/sushiHex/vram-mcp@v0.3.1", "vram-mcp"]Merge this entry into your client's MCP configuration:
{
"mcpServers": {
"vram": {
"command": "uvx",
"args": ["--from", "git+https://github.com/sushiHex/vram-mcp@v0.3.1", "vram-mcp"]
}
}
}If the client cannot find uvx, use its absolute executable path. In JSON,
Windows paths need escaped backslashes, such as C:\\tools\\uvx.exe.
On Windows, the MCP SDK needs pywin32, which has no free-threaded build. If
uv picks a free-threaded Python (3.14t) and the install fails, add
--python 3.13 right after uvx.
Reconnect your client after registration. It launches the server over stdio;
running vram-mcp by hand waits for MCP input. Prefer a local installation?
See installing from source.
Upgrading from 0.2? Stop every client using vram-mcp first; old and new servers must never share one ledger. See the 0.3.0 notes and the 0.3.1 fix.
Ask your agent:
Check GPU memory with vram-mcp. Show what's loaded, who is using it, and how much room is left. Report any unavailable readings.
The agent should call vram_status() and list_claims(). Status includes a
readable summary, the selected GPU, loaded models, available process details
(command lines cut to 160 characters unless cmdline_chars says otherwise; see
configuration), and observations metadata. Check each observation's status; unavailable
means the corresponding value is unknown, rather than empty or zero.
list_claims() also shows capacity reserved for training or other non-Ollama
work.
Related MCP server: mcp-gpu-server
These examples are MCP tool calls made inside a connected client, not shell
commands or a Python API. Use a descriptive session label for owner and by,
such as codex:review, so another agent can identify your work.
Inspect before changing memory. Call vram_status() and list_claims().
Model names are canonicalized consistently: a bare final name such as
llama3 becomes llama3:latest; comparison is case-insensitive, and
Ollama's default registry/library prefix is removed.
Claim a model before relying on it. Replace the example model below
with one already installed in Ollama. Continue only if the claim succeeds,
and save its returned claim_id.
claim(model="llama3:latest", owner="codex:review", purpose="Review local code")Make room when needed. ensure_free(gb=8, by="codex:review") unloads
unprotected models largest-first. Choose the target for your workload and
check outcome, free_mb, declined, reserved_mb, and observations.
It does not evict when selected-GPU capacity or Ollama residency is unknown.
Reaching the target does not give you ownership of that space.
Load and check. Call
warm(model="llama3:latest", keep_alive="10m", by="codex:review") when needed.
Inspect outcome, reason, and observations. succeeded means residency
was reconciled after the request; refused means no Ollama request was sent;
failed means Ollama definitively rejected it; and unknown means the
request may still be running and includes pending_until. Do not retry a
same-model mutation until that pending window ends. Warm admission is also
serialized across models sharing the selected GPU. A model that was already
resident has zero incremental residency cost (reason="already_resident").
Loading successfully does not guarantee full GPU residency. Run inference
through your usual Ollama client.
Renew and release. Claims expire after one hour by default. Call
renew(claim_id="<returned claim_id>") before expiry for longer work and
release(claim_id="<returned claim_id>") when finished, including if loading
fails. Releasing a claim does not unload the model; claim expiry and Ollama's
keep_alive are separate.
For training or diffusion, use reserve(gb=8, owner="codex:training", purpose="LoRA training") to declare capacity, then renew/release its claim_id
in the same way. A reservation records intent; it does not allocate memory.
Validation rejects invalid requests: capacities, TTLs, and trend windows
must be finite and positive; model, owner, purpose, and caller labels must be
nonblank; warm accepts a positive Ollama duration or -1 for indefinite
residency. Use unload() rather than a zero keep_alive.
Coordination is cooperative. Direct Ollama calls can bypass it. force=True
on unload, ensure_free, or warm overrides claims, busy protection, or
reservation admission; use it only after resolving competing work. It does not
bypass an unreadable coordination ledger or another pending mutation.
busy=null means unknown and does not block eviction on its own. See
coordination details.
| Meaning |
| Nothing is wrong, and every input that claim rests on was actually read. Missing evidence yields |
| Less than 1 GiB is free on the selected GPU. |
| Ollama placed part of a model on the CPU; expect slower inference. |
| The driver is paging VRAM: in at least 5 of the last 10 seconds, WDDM's memory manager kept the GPU busy. |
Missing required telemetry produces pressure.state="unknown". Read
pressure.coverage and top-level observations to see which evidence was
available. Paging detection is best effort. It needs a paging reading for the
selected GPU, which vram-mcp takes on Windows from a sampler that starts with
the server. On Linux no such reading exists, so pressure reads unknown
where it would read ok. The detection is a measured correlation, not a WDDM
contract; see the acceptance notes.
Non-local memory is reported but does not decide the verdict. CPU
offload is tracked separately. Disabling auditing
stops history detection and trend sampling, but does not disable current GPU or
process observations.
Use history() to investigate a model disappearing and trend(hours=1) to
review memory changes. Trends are sampled when vram_status() reads the GPU;
there is no background sampler. See diagnostics.
The client's MCP schema provides full arguments and defaults.
Tool | Purpose |
| Inspect GPU memory, models, claims, activity, and pressure. |
| List resident models and their claim/busy details. |
| Try to reach a free-memory target by unloading unprotected models. |
| Evict a named model, respecting claims and recent activity. |
| Load a model for a chosen |
| Declare model use or capacity needed for other GPU work. |
| Extend or end your claim or reservation. |
| See active model claims and capacity reservations. |
| Review recorded actions, observed changes, and memory samples. |
| Get configuration suggestions; no settings are changed. |
Guide | Read it for |
Source installation, environment variables, and connection troubleshooting. | |
Claims, reservations, protection limits, pressure, and audit history. | |
The opt-in run against a real GPU and Ollama, and the environments it has validated. |
git clone https://github.com/sushiHex/vram-mcp.git
cd vram-mcp
python -m venv .venvActivate with source .venv/bin/activate on Linux or
.\.venv\Scripts\Activate.ps1 in PowerShell, then run:
python -m pip install -e ".[dev]"
python -m pytest -qTests use mocked GPU, process, and HTTP calls; no GPU or Ollama daemon is needed. Validation on real hardware is a separate, opt-in run; see hardware acceptance. CI covers Python 3.10–3.14 on Windows and Linux. Current model management targets Ollama and NVIDIA; AMD/Intel telemetry and vLLM/llama.cpp management are future work.
MIT — see LICENSE. Companion project: hardline-mcp for agent messaging.
Suggest env/config changes to keep VRAM healthy (heuristics).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that it 'suggests' changes, which implies a non-mutating action, but it does not explicitly say it is read-only, nor does it describe the output format, whether it performs any analysis, or how the heuristics work. The agent cannot anticipate side effects or data returned.
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, concise sentence that communicates the core purpose without unnecessary words. It is front-loaded with the primary action ('Suggest') and resource, making it easy to scan. It earns full credit for conciseness.
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 absence of an output schema, the description should explain what the tool returns. It does not mention whether it returns a list, a message, or structured advice. It also lacks details on the nature of the heuristics or any examples. This leaves the agent with insufficient information to fully understand the tool's behavior or output.
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 the description does not need to elaborate on any. According to the rubric, a baseline of 4 is appropriate when there are no params. The description aligns with the schema, which has an empty properties object.
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 states a specific verb ('Suggest') and resource ('env/config changes') with a clear purpose ('to keep VRAM healthy'). It uses 'heuristics' to indicate the nature of the suggestions. However, it could be more specific about the types of changes (e.g., environment variables, configuration files) and the format of suggestions, so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description does not mention any conditions, prerequisites, or alternatives such as `ensure_free` or `vram_status`. An agent is left to infer that this is an advisory tool, but there is no explicit direction on when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Declare that you're using model for purpose.
Lets other sessions see who's using a model and why before deciding to
evict it. Renew before ttl_seconds elapses if still in use — an
un-renewed claim simply expires, so a crashed session never leaves a
permanently-stuck claim.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| owner | Yes | ||
| purpose | Yes | ||
| ttl_seconds | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| model | Yes | |
| detail | Yes | |
| reason | Yes | |
| outcome | Yes | |
| summary | Yes | |
| claim_id | Yes | |
| expires_at | Yes |
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 discloses the TTL-based lease lifecycle, that un-renewed claims expire, and that a crashed session cannot leave a permanently-stuck claim. It omits what happens on conflicting claims (e.g., model already claimed) and any permission requirements, so it's strong but not complete.
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?
Two short paragraphs, front-loaded with the action and its rationale, with no filler sentences. The TTL explanation earns its place by encoding the caller's obligation to renew.
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 presence of an output schema relieves the description from explaining return values, and the lifecycle coverage is good. However, for a state-mutating lease tool with 0% param coverage and a required ``owner`` argument never defined, plus no mention of conflict behavior, the definition leaves meaningful gaps.
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 description coverage is 0% across 4 parameters, so the description must compensate. It gives semantics for ``model`` and ``purpose`` and implies ``ttl_seconds`` via the renewal sentence, but the required ``owner`` parameter is never mentioned in either schema or description, and no format constraints are provided for any parameter.
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 and resource: "Declare that you're using ``model`` for ``purpose``." It explains the effect (other sessions see who's using a model and why) and ties into the renew sibling implicitly. It does not explicitly contrast against siblings like reserve or ensure_free, but the claim concept 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?
It states when to use the tool (before using a model, to advertise usage before others decide to evict) and when to act again ("Renew before ttl_seconds elapses if still in use"). It does not name alternative siblings or exclusions, so no explicit routing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free VRAM until at least gb GB is available. Skips claimed/busy models
unless force=True. by records the requester in the audit log.
Also reports reserved_mb — how much of the resulting free VRAM other
sessions have reserved for non-Ollama work (None if unreadable).
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | unknown | |
| gb | Yes | ||
| force | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| model | Yes | |
| detail | Yes | |
| reason | Yes | |
| free_mb | Yes | |
| outcome | Yes | |
| summary | Yes | |
| attempts | Yes | |
| declined | Yes | |
| unloaded | Yes | |
| target_mb | Yes | |
| reserved_mb | Yes | |
| retry_after | Yes | |
| already_free | Yes | |
| observations | Yes | |
| pending_until | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that claimed/busy models are skipped by default, that force overrides that safeguard, and that 'by' writes to an audit log. It stops short of stating destructiveness (whether models are unloaded/killed), permissions required, or whether the call blocks until the target is met.
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?
Front-loads the core action in the first sentence and uses two terse follow-ups for the skip/force rule, audit attribution, and reserved_mb. The reserved_mb sentence borders on restating the output schema, but adds interpretation ('reserved for non-Ollama work') that the schema alone would not convey.
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?
An output schema exists, so the description is not obligated to explain return values, and its brief reserved_mb note is a bonus rather than a gap-filler. What remains thin is the mutation profile — whether freeing VRAM evicts models, what happens if the target cannot be reached, and whether the call is blocking.
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 description coverage is 0%, so the description must supply all parameter meaning, and it does: gb is the target free GB threshold, force overrides the claimed/busy skip, and by records the requester in the audit log. Every one of the three parameters is semantically explained.
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?
States a specific verb (Free VRAM) plus a quantified goal condition (until at least gb GB is available), which is far more precise than a bare name restatement. It tacitly differentiates from siblings like unload and vram_status by being goal-directed rather than model-specific or observational, though it never names them.
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 gives a clear usage condition for the force flag (skips claimed/busy models unless force=True), which implies when to reach for it. However, it never states when to prefer ensure_free over unload, claim, or vram_status, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The VRAM audit trail, newest first: who ran unload/ensure_free/warm, and
which models/processes appeared or disappeared (with a best-effort cause).
Filter by model, type (action|disappeared|appeared), limit, or an
ISO since floor. Answers 'what happened to model X?'.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| model | No | ||
| since | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It specifies that the trail is newest first, includes a best-effort cause, and lists event types (action|disappeared|appeared). It does not mention aspects like response format, pagination, or performance, but it gives a solid behavioral overview sufficient for a read-only audit tool.
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 concise and front-loaded with the core purpose ('VRAM audit trail, newest first'), followed by what it records and filters. Every sentence adds value: the cause detail, filter options, and the direct question it answers. No redundant information.
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 moderate complexity (4 optional params, no required fields, no output schema), the description is fairly complete for a read-only history tool. It explains what the data is, filters available, and the kind of question it answers. However, it lacks specifics on return format or how to interpret the 'cause' field, which might be needed for advanced use.
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 description coverage is 0%, so the description must compensate. It mentions filtering by model, type, limit, and since, but provides minimal extra detail beyond the schema property names. For example, it explains 'since' as an ISO floor, which is useful, but does not elaborate on accepted formats for 'type' or 'model', leaving room for ambiguity.
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: retrieving the VRAM audit trail, sorted newest first, showing actions like unload/ensure_free/warm and model/process appearance/disappearance with causes. It explicitly mentions filtering by model, type, limit, and since, and answers a specific question ('what happened to model X?'), which distinguishes it from sibling tools like vram_status or list_loaded.
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 usage for auditing historical events and answering questions about changes, but it does not explicitly state when to use this tool versus alternatives like vram_status or trend. It provides some context (audit trail) but lacks explicit when-to-use or when-not-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See who's claiming what right now (all models, or one).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| claims | Yes | |
| outcome | Yes | |
| summary | Yes | |
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys only that this is a read of current state; it says nothing about permissions, rate limits, pagination, or how staleness/emptiness of results behaves.
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?
One short, front-loaded sentence with no filler and the scoping clarification in parentheses. It is efficient, though arguably terse enough to leave gaps.
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 (one optional param) and an output schema exists, so return values need not be described. Still, the description gives no routing context among the many claim-related siblings (claim, reserve, renew, release), leaving the agent to infer when this list view is appropriate.
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 description coverage is 0% and the single parameter is only labeled 'Model' with a null default. The description compensates by explaining the parameter's effect: passing a model scopes to one, omitting it covers all models — exactly the semantics the schema lacks.
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?
States a specific verb and resource: 'See who's claiming what right now' clearly indicates a read of current claim holders, and '(all models, or one)' gives the scope. It implicitly distinguishes itself from sibling list_loaded (loaded models vs claims), though it never names that sibling explicitly.
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 phrase 'all models, or one' implies when to pass the model argument versus omitting it, and 'right now' implies a real-time snapshot. But there is no explicit when-to-use guidance relative to list_loaded, history, or trend, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the models currently resident in VRAM, with claim/busy detail.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' implies a non-mutating read operation, and 'claim/busy detail' names the returned state, but it does not explicitly state the absence of side effects, how claim/busy is determined, or any blocking/load behavior. Adequate but not richly transparent.
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 sentence that front-loads the verb and resource, then adds the key detail. Every word earns its place; there is no filler or redundancy.
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 parameterless list operation, the description covers the core semantics: what is listed and what detail is included. However, because there is no output schema or annotations, 'claim/busy detail' remains somewhat vague, and no sibling routing is provided. Still, the tool is simple enough that an agent can 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, so the baseline is 4. The description adds no parameter semantics, but none are necessary for invocation; the empty schema already covers this completely.
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?
Description opens with the imperative 'List' and identifies the specific resource ('models currently resident in VRAM'), plus a distinguishing output detail ('claim/busy detail'). This clearly separates it from sibling tools like list_claims, which likely lists claim records rather than VRAM-resident models.
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 gives no explicit when-to-use guidance and names no alternatives or exclusions. With siblings like list_claims, vram_status, and ensure_free, an agent must infer when this tool is the right choice, rather than being directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release a claim early, before its TTL would expire.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| model | Yes | |
| detail | Yes | |
| reason | Yes | |
| outcome | Yes | |
| summary | Yes | |
| claim_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one real behavioral trait: the claim terminates earlier than its TTL would have allowed, which tells the agent about lifecycle impact. However, it says nothing about idempotency, behavior on an unknown or already-released claim_id, or whether the caller must own the claim.
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 front-loaded sentence with no filler; the verb and effect lead. It is efficient, though for a mutation tool with zero annotations it is arguably too terse to be fully 'appropriately sized'.
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?
An output schema exists, so return values need not be explained. For a state-mutating claim-lifecycle tool with no annotations and a crowded sibling set (claim, renew, list_claims, reserve), the description is adequate but omits error/idempotency and permissions context that an agent would want before invoking.
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?
One parameter (claim_id) with 0% schema description coverage, so the description technically must compensate and does not. In practice the parameter name is self-explanatory and enumerates the single required identifier, so the value added beyond the schema is minimal but the gap is low-risk.
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?
States a specific verb (release) and resource (a claim), plus a scoping detail: it happens early, before TTL expiry. That distinguishes it from the natural alternative, renew, which extends rather than ends a claim. It does not explicitly name a sibling, so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before its TTL would expire' implies when an agent would call this (deliberately ending a claim early), but it never states prerequisites, ownership requirements, or how it relates to renew/list_claims. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend an existing claim's expiry before it lapses.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes | ||
| ttl_seconds | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| model | Yes | |
| detail | Yes | |
| reason | Yes | |
| outcome | Yes | |
| summary | Yes | |
| claim_id | Yes | |
| expires_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does disclose the meaningful precondition that renewal must happen before expiry, but says nothing about what happens if the claim is already lapsed, whether ttl_seconds replaces or adds to remaining time, or any permission requirements.
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 short sentence with the action and precondition front-loaded and zero filler. Appropriately sized for a two-parameter tool.
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 output schema relieves the description of explaining return values, but for a mutation with no annotations and 0% schema coverage the definition leaves key behavior undefined: failure mode on lapsed or nonexistent claims and the semantics of the optional ttl_seconds.
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 description coverage is 0%, so the description must compensate and largely fails to. "existing claim" loosely maps to claim_id and "expiry" to ttl_seconds, but there is no explanation of the ttl_seconds default of null, units, or what a null value means.
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?
States a specific verb ("Extend") and resource ("an existing claim's expiry"), which is clear enough to separate it from sibling writers like claim, reserve, and release. It lacks any explicit contrast with those siblings, so the agent must infer the distinction from names alone.
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?
"before it lapses" implies the correct timing and an implicit precondition, giving some usage context. It does not name alternatives (e.g., what to do once a claim has already lapsed) or state exclusions, so guidance remains 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.
Reserve gb GB of VRAM — a claim on capacity, not on a named model.
Use this for non-Ollama GPU work (a training run, a diffusion job) so other
sessions can see the VRAM is spoken for. pid is advisory. Reservations
expire by TTL like claims, so a crashed session never leaves one stuck.
COOPERATIVE: this gates vram-mcp's own warm(), but vram-mcp cannot
intercept an Ollama auto-load triggered by a direct /api/generate call
from another process.
| Name | Required | Description | Default |
|---|---|---|---|
| gb | Yes | ||
| pid | No | ||
| owner | Yes | ||
| purpose | Yes | ||
| ttl_seconds | No |
| Name | Required | Description |
|---|---|---|
| gb | Yes | |
| ok | Yes | |
| model | Yes | |
| detail | Yes | |
| reason | Yes | |
| outcome | Yes | |
| summary | Yes | |
| claim_id | Yes | |
| expires_at | Yes |
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 discloses TTL-based expiry, crash-safety (no stuck reservations), that `pid` is advisory only, and honestly flags the cooperative-only enforcement limit. It does not say what happens when insufficient VRAM is free (fail vs. oversubscribe) or whether reservations are per-owner, which are material behaviors for a capacity tool.
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?
Front-loaded purpose sentence, then usage, then caveats, with a labeled COOPERATIVE paragraph for the most surprising constraint. Every sentence adds information; 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?
An output schema exists, so return values need no explanation, and the behavioral story (TTL, advisory pid, cooperative limits) is well covered. Gaps remain on failure semantics when capacity is unavailable and on the two undocumented required string parameters.
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 meaningfully explains `gb` (GB of VRAM), `pid` (advisory), and the TTL expiry concept, but leaves the required `owner` and `purpose` parameters entirely undefined and never states TTL units or bounds.
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?
States a specific verb (Reserve) and resource (GB of VRAM), and immediately draws the boundary against the sibling `claim` by clarifying this is capacity, not a named model. An agent can distinguish `reserve` from `claim`/`warm`/`ensure_free` without opening any schema.
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?
Gives an explicit use case (non-Ollama GPU work such as a training run or diffusion job) and implies the exclusion (use `claim` for named-model work). It also names what it gates (`warm()`) and states the boundary case where it is powerless (direct Ollama /api/generate auto-load).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free-VRAM trend over the last hours, from the sampled audit log.
Answers "was this a gradual erosion or a sudden spike?" — the question a
point-in-time vram_status() cannot. Returns direction, min/max/latest
free MB (latest is null when the newest sample carries no reading),
how many samples showed driver spill, and the raw samples.
samples holds at most the 200 most recent rows so a long window can't
flood the caller's context; samples_truncated says whether older rows
were dropped. Every summary figure is computed over the FULL window either
way.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the return structure (direction, min/max/latest, spill count, raw samples), edge cases (latest is null when the newest sample lacks a reading), and truncation behavior (samples limited to 200 rows, samples_truncated flag, and summaries over the full window). This is comprehensive and transparent.
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 well-structured: it opens with the core purpose, then details the output and truncation behavior. Every sentence adds useful information, and the formatting (backticks, line breaks) aids readability. It is slightly longer than necessary but not padded, earning a 4.
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 has no output schema, so the description must explain return values, which it does in detail. It covers the main purpose, all output fields, an edge case, and the truncation mechanism. For a tool of this complexity, nothing an agent needs to invoke it correctly is missing.
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 only parameter is 'hours' with a default of 1, and the schema provides no description (coverage 0%). The description mentions 'over the last hours' but does not elaborate on units, range, or whether fractional hours are allowed. It adds minimal value beyond the parameter name itself. Since the description does not fully compensate for the schema gap, a baseline of 3 is appropriate.
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 reports a free-VRAM trend over a time window, with specific outputs (direction, min/max/latest, spill samples, raw samples). It explicitly differentiates itself from vram_status(), a point-in-time tool, so an agent can select it correctly. The verb 'trend' plus the resource (free VRAM) and time window make 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to answer whether VRAM change was gradual or sudden, contrasting with vram_status() which cannot. It also gives guidance on sample truncation to manage context. However, it does not mention other alternatives like history() or ensure_free(), but the primary distinction is clear. It implies use when you need trend analysis rather than a snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evict a single model from VRAM now (Ollama keep_alive=0).
Refuses by default if model has an active claim or a best-effort busy
signal — pass force=True to override (busy is windowed and can lag a few
seconds past a generation). by records who requested the eviction in the
audit log (see history).
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | unknown | |
| force | No | ||
| model | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| busy | Yes | |
| model | Yes | |
| scope | Yes | |
| claims | Yes | |
| detail | Yes | |
| reason | Yes | |
| free_mb | Yes | |
| outcome | Yes | |
| refused | Yes | |
| summary | Yes | |
| resident | Yes | |
| protected | Yes | |
| keep_alive | Yes | |
| operations | Yes | |
| headroom_mb | Yes | |
| reserved_mb | Yes | |
| retry_after | Yes | |
| retry_count | Yes | |
| observations | Yes | |
| operation_id | Yes | |
| reservations | Yes | |
| additional_mb | Yes | |
| model_size_mb | Yes | |
| pending_until | Yes | |
| size_verified | Yes | |
| coordination_warning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: refusal-by-default semantics, the force override, the caveat that the busy signal is windowed and can lag a few seconds past a generation, and audit attribution via 'by'. It stops short of stating the consequence of forcing past an in-flight generation (interrupted work), failure behavior, or any permission requirements.
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 tight sentences, front-loaded with the action, then the guard condition, then the audit side effect. No filler, no restatement of the tool name.
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?
An output schema exists, so return values need no explanation, and the description covers the risky behavior an agent needs before calling. It is nearly complete; only the post-force outcome and error-vs-no-op behavior are left implicit.
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 has to compensate, and it explains both non-obvious parameters: 'force' overrides the refusal guard and 'by' is recorded for audit. 'model' is left uncharacterized (name vs. tag vs. ID), which is the only real gap.
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 a specific verb and scope: 'Evict a single model from VRAM now', with the mechanism (Ollama keep_alive=0) named explicitly. This clearly separates it from warm/claim/reserve and from any bulk-freeing sibling, though it never names the alternative for multi-model freeing.
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?
It gives an explicit when-not: the call refuses if the model has an active claim or a recent busy signal, and states the escape hatch (force=True). What it lacks is routing advice against named siblings such as release/ensure_free when the caller's real goal is freeing capacity rather than terminating a specific model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cmdline_chars | No |
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.
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.
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.
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.
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.
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.
Load a model or refresh its keep-alive (e.g. "5m"; "-1" pins indefinitely).
An already resident model requires zero additional capacity. New loads account for reservations using an approximate model size; size_verified describes that estimate, while outcome describes verified residency. Returns succeeded|refused|failed|unknown. On unknown, inspect residency and pending_until before retrying. force=True bypasses admission checks but cannot override a pending operation. Zero durations must use unload().
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | unknown | |
| force | No | ||
| model | Yes | ||
| keep_alive | No | 5m |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| busy | Yes | |
| model | Yes | |
| scope | Yes | |
| claims | Yes | |
| detail | Yes | |
| reason | Yes | |
| free_mb | Yes | |
| outcome | Yes | |
| refused | Yes | |
| summary | Yes | |
| resident | Yes | |
| protected | Yes | |
| keep_alive | Yes | |
| operations | Yes | |
| headroom_mb | Yes | |
| reserved_mb | Yes | |
| retry_after | Yes | |
| retry_count | Yes | |
| observations | Yes | |
| operation_id | Yes | |
| reservations | Yes | |
| additional_mb | Yes | |
| model_size_mb | Yes | |
| pending_until | Yes | |
| size_verified | Yes | |
| coordination_warning | Yes |
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 discloses that resident models cost zero capacity, that new loads account for reservations via an approximate size, the meaning of size_verified vs outcome, the four possible outcomes, retry guidance on 'unknown', and force semantics. It omits auth/permission requirements and any concurrency or rate-limit behavior.
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?
Front-loads the core action, then layers behavioral detail in a logical order. Dense but every sentence contributes; the outcome/retry guidance is the only section that could be tightened.
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?
An output schema exists, so return values need not be explained, yet the description still usefully enumerates outcomes and retry logic. For a zero-annotation tool with complex capacity semantics it is largely complete, with the undocumented 'by' parameter the main gap.
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 keep_alive semantics ('5m', '-1' pins indefinitely) and force behavior, and implies model, but the 'by' parameter is never described in either schema or description. Partial compensation for a 4-param tool with zero schema documentation.
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 gives a specific verb+resource ('Load a model or refresh its keep-alive') and disambiguates the closest sibling by routing zero durations to unload(). An agent can distinguish this from unload() without opening either schema.
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?
Clear context for when to use it (load or refresh keep-alive), plus explicit guidance on force=True (bypasses admission checks, cannot override pending) and on handling the 'unknown' outcome before retrying. It stops short of naming alternatives like reserve/claim/ensure_free for capacity cases, so it lacks full when-not coverage.
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.
v0.3.1claim1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "claim_id",
+ "expires_at"
+ ],
+ "title": "ClaimResult",
+ "type": "object"
+}ensure_free1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ClaimEntry": {
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "claimed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claimed At"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "gb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Gb"
+ },
+ "kind": {
+ "enum": [
+ "model",
+ "reservation"
+ ],
+ "title": "Kind",
+ "type": "string"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "owner": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Owner"
+ },
+ "pid": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pid"
+ },
+ "purpose": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Purpose"
+ },
+ "renewed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Renewed At"
+ },
+ "ttl_seconds": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Ttl Seconds"
+ }
+ },
+ "required": [
+ "claim_id",
+ "kind",
+ "model",
+ "gb",
+ "pid",
+ "owner",
+ "purpose",
+ "claimed_at",
+ "renewed_at",
+ "ttl_seconds",
+ "expires_at"
+ ],
+ "title": "ClaimEntry",
+ "type": "object"
+ },
+ "OperationEntry": {
+ "properties": {
+ "expires_at": {
+ "title": "Expires At",
+ "type": "string"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "lease_expired": {
+ "title": "Lease Expired",
+ "type": "boolean"
+ },
+ "lifecycle": {
+ "enum": [
+ "in_flight",
+ "unknown",
+ "unrecognized"
+ ],
+ "title": "Lifecycle",
+ "type": "string"
+ },
+ "model": {
+ "title": "Model",
+ "type": "string"
+ },
+ "operation_id": {
+ "title": "Operation Id",
+ "type": "string"
+ },
+ "outcome": {
+ "anyOf": [
+ {
+ "const": "unknown",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Outcome"
+ },
+ "owner_live": {
+ "title": "Owner Live",
+ "type": "boolean"
+ },
+ "pending_until": {
+ "title": "Pending Until",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "title": "Scope",
+ "type": "string"
+ },
+ "started_at": {
+ "title": "Started At",
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation_id",
+ "model",
+ "kind",
+ "scope",
+ "started_at",
+ "expires_at",
+ "pending_until",
+ "lifecycle",
+ "owner_live",
+ "lease_expired",
+ "outcome",
+ "reason",
+ "retry_count",
+ "retry_after"
+ ],
+ "title": "OperationEntry",
+ "type": "object"
+ },
+ "ResidencyResult": {
+ "properties": {
+ "additional_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Additional Mb"
+ },
+ "busy": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Busy"
+ },
+ "claims": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claims"
+ },
+ "coordination_warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Coordination Warning"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "free_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Free Mb"
+ },
+ "headroom_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Headroom Mb"
+ },
+ "keep_alive": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Keep Alive"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "model_size_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model Size Mb"
+ },
+ "observations": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Observations"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "operation_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operation Id"
+ },
+ "operations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/OperationEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operations"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "pending_until": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pending Until"
+ },
+ "protected": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Protected"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "refused": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Refused"
+ },
+ "reservations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reservations"
+ },
+ "reserved_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reserved Mb"
+ },
+ "resident": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Resident"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Scope"
+ },
+ "size_verified": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Size Verified"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "operation_id",
+ "pending_until",
+ "retry_after",
+ "retry_count",
+ "keep_alive",
+ "resident",
+ "protected",
+ "busy",
+ "claims",
+ "operations",
+ "observations",
+ "reservations",
+ "refused",
+ "size_verified",
+ "model_size_mb",
+ "headroom_mb",
+ "reserved_mb",
+ "additional_mb",
+ "scope",
+ "free_mb",
+ "coordination_warning"
+ ],
+ "title": "ResidencyResult",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "already_free": {
+ "title": "Already Free",
+ "type": "boolean"
+ },
+ "attempts": {
+ "items": {
+ "$ref": "#/$defs/ResidencyResult"
+ },
+ "title": "Attempts",
+ "type": "array"
+ },
+ "declined": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "title": "Declined",
+ "type": "array"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "free_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Free Mb"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "observations": {
+ "additionalProperties": true,
+ "title": "Observations",
+ "type": "object"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "pending_until": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pending Until"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "reserved_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reserved Mb"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ },
+ "target_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Target Mb"
+ },
+ "unloaded": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Unloaded",
+ "type": "array"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "pending_until",
+ "retry_after",
+ "already_free",
+ "free_mb",
+ "unloaded",
+ "declined",
+ "attempts",
+ "target_mb",
+ "reserved_mb",
+ "observations"
+ ],
+ "title": "EnsureFreeResult",
+ "type": "object"
+}list_claims1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ClaimEntry": {
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "claimed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claimed At"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "gb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Gb"
+ },
+ "kind": {
+ "enum": [
+ "model",
+ "reservation"
+ ],
+ "title": "Kind",
+ "type": "string"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "owner": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Owner"
+ },
+ "pid": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pid"
+ },
+ "purpose": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Purpose"
+ },
+ "renewed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Renewed At"
+ },
+ "ttl_seconds": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Ttl Seconds"
+ }
+ },
+ "required": [
+ "claim_id",
+ "kind",
+ "model",
+ "gb",
+ "pid",
+ "owner",
+ "purpose",
+ "claimed_at",
+ "renewed_at",
+ "ttl_seconds",
+ "expires_at"
+ ],
+ "title": "ClaimEntry",
+ "type": "object"
+ },
+ "OperationEntry": {
+ "properties": {
+ "expires_at": {
+ "title": "Expires At",
+ "type": "string"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "lease_expired": {
+ "title": "Lease Expired",
+ "type": "boolean"
+ },
+ "lifecycle": {
+ "enum": [
+ "in_flight",
+ "unknown",
+ "unrecognized"
+ ],
+ "title": "Lifecycle",
+ "type": "string"
+ },
+ "model": {
+ "title": "Model",
+ "type": "string"
+ },
+ "operation_id": {
+ "title": "Operation Id",
+ "type": "string"
+ },
+ "outcome": {
+ "anyOf": [
+ {
+ "const": "unknown",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Outcome"
+ },
+ "owner_live": {
+ "title": "Owner Live",
+ "type": "boolean"
+ },
+ "pending_until": {
+ "title": "Pending Until",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "title": "Scope",
+ "type": "string"
+ },
+ "started_at": {
+ "title": "Started At",
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation_id",
+ "model",
+ "kind",
+ "scope",
+ "started_at",
+ "expires_at",
+ "pending_until",
+ "lifecycle",
+ "owner_live",
+ "lease_expired",
+ "outcome",
+ "reason",
+ "retry_count",
+ "retry_after"
+ ],
+ "title": "OperationEntry",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "claims": {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "title": "Claims",
+ "type": "array"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "operations": {
+ "items": {
+ "$ref": "#/$defs/OperationEntry"
+ },
+ "title": "Operations",
+ "type": "array"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "claims",
+ "operations",
+ "summary"
+ ],
+ "title": "ListClaimsResult",
+ "type": "object"
+}release1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "claim_id"
+ ],
+ "title": "ReleaseResult",
+ "type": "object"
+}renew1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "claim_id",
+ "expires_at"
+ ],
+ "title": "RenewResult",
+ "type": "object"
+}reserve1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "gb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Gb"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "claim_id",
+ "expires_at",
+ "gb"
+ ],
+ "title": "ReserveResult",
+ "type": "object"
+}unload1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ClaimEntry": {
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "claimed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claimed At"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "gb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Gb"
+ },
+ "kind": {
+ "enum": [
+ "model",
+ "reservation"
+ ],
+ "title": "Kind",
+ "type": "string"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "owner": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Owner"
+ },
+ "pid": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pid"
+ },
+ "purpose": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Purpose"
+ },
+ "renewed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Renewed At"
+ },
+ "ttl_seconds": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Ttl Seconds"
+ }
+ },
+ "required": [
+ "claim_id",
+ "kind",
+ "model",
+ "gb",
+ "pid",
+ "owner",
+ "purpose",
+ "claimed_at",
+ "renewed_at",
+ "ttl_seconds",
+ "expires_at"
+ ],
+ "title": "ClaimEntry",
+ "type": "object"
+ },
+ "OperationEntry": {
+ "properties": {
+ "expires_at": {
+ "title": "Expires At",
+ "type": "string"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "lease_expired": {
+ "title": "Lease Expired",
+ "type": "boolean"
+ },
+ "lifecycle": {
+ "enum": [
+ "in_flight",
+ "unknown",
+ "unrecognized"
+ ],
+ "title": "Lifecycle",
+ "type": "string"
+ },
+ "model": {
+ "title": "Model",
+ "type": "string"
+ },
+ "operation_id": {
+ "title": "Operation Id",
+ "type": "string"
+ },
+ "outcome": {
+ "anyOf": [
+ {
+ "const": "unknown",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Outcome"
+ },
+ "owner_live": {
+ "title": "Owner Live",
+ "type": "boolean"
+ },
+ "pending_until": {
+ "title": "Pending Until",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "title": "Scope",
+ "type": "string"
+ },
+ "started_at": {
+ "title": "Started At",
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation_id",
+ "model",
+ "kind",
+ "scope",
+ "started_at",
+ "expires_at",
+ "pending_until",
+ "lifecycle",
+ "owner_live",
+ "lease_expired",
+ "outcome",
+ "reason",
+ "retry_count",
+ "retry_after"
+ ],
+ "title": "OperationEntry",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "additional_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Additional Mb"
+ },
+ "busy": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Busy"
+ },
+ "claims": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claims"
+ },
+ "coordination_warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Coordination Warning"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "free_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Free Mb"
+ },
+ "headroom_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Headroom Mb"
+ },
+ "keep_alive": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Keep Alive"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "model_size_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model Size Mb"
+ },
+ "observations": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Observations"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "operation_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operation Id"
+ },
+ "operations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/OperationEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operations"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "pending_until": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pending Until"
+ },
+ "protected": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Protected"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "refused": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Refused"
+ },
+ "reservations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reservations"
+ },
+ "reserved_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reserved Mb"
+ },
+ "resident": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Resident"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Scope"
+ },
+ "size_verified": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Size Verified"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "operation_id",
+ "pending_until",
+ "retry_after",
+ "retry_count",
+ "keep_alive",
+ "resident",
+ "protected",
+ "busy",
+ "claims",
+ "operations",
+ "observations",
+ "reservations",
+ "refused",
+ "size_verified",
+ "model_size_mb",
+ "headroom_mb",
+ "reserved_mb",
+ "additional_mb",
+ "scope",
+ "free_mb",
+ "coordination_warning"
+ ],
+ "title": "ResidencyResult",
+ "type": "object"
+}vram_status1 field changedInput schema / properties / cmdline_charsAdded value: +{
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": 160,
+ "title": "Cmdline Chars"
+}warm1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ClaimEntry": {
+ "properties": {
+ "claim_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claim Id"
+ },
+ "claimed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claimed At"
+ },
+ "expires_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Expires At"
+ },
+ "gb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Gb"
+ },
+ "kind": {
+ "enum": [
+ "model",
+ "reservation"
+ ],
+ "title": "Kind",
+ "type": "string"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "owner": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Owner"
+ },
+ "pid": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pid"
+ },
+ "purpose": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Purpose"
+ },
+ "renewed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Renewed At"
+ },
+ "ttl_seconds": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Ttl Seconds"
+ }
+ },
+ "required": [
+ "claim_id",
+ "kind",
+ "model",
+ "gb",
+ "pid",
+ "owner",
+ "purpose",
+ "claimed_at",
+ "renewed_at",
+ "ttl_seconds",
+ "expires_at"
+ ],
+ "title": "ClaimEntry",
+ "type": "object"
+ },
+ "OperationEntry": {
+ "properties": {
+ "expires_at": {
+ "title": "Expires At",
+ "type": "string"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "lease_expired": {
+ "title": "Lease Expired",
+ "type": "boolean"
+ },
+ "lifecycle": {
+ "enum": [
+ "in_flight",
+ "unknown",
+ "unrecognized"
+ ],
+ "title": "Lifecycle",
+ "type": "string"
+ },
+ "model": {
+ "title": "Model",
+ "type": "string"
+ },
+ "operation_id": {
+ "title": "Operation Id",
+ "type": "string"
+ },
+ "outcome": {
+ "anyOf": [
+ {
+ "const": "unknown",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Outcome"
+ },
+ "owner_live": {
+ "title": "Owner Live",
+ "type": "boolean"
+ },
+ "pending_until": {
+ "title": "Pending Until",
+ "type": "string"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "title": "Scope",
+ "type": "string"
+ },
+ "started_at": {
+ "title": "Started At",
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation_id",
+ "model",
+ "kind",
+ "scope",
+ "started_at",
+ "expires_at",
+ "pending_until",
+ "lifecycle",
+ "owner_live",
+ "lease_expired",
+ "outcome",
+ "reason",
+ "retry_count",
+ "retry_after"
+ ],
+ "title": "OperationEntry",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "additional_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Additional Mb"
+ },
+ "busy": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Busy"
+ },
+ "claims": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Claims"
+ },
+ "coordination_warning": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Coordination Warning"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Detail"
+ },
+ "free_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Free Mb"
+ },
+ "headroom_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Headroom Mb"
+ },
+ "keep_alive": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Keep Alive"
+ },
+ "model": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model"
+ },
+ "model_size_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Model Size Mb"
+ },
+ "observations": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Observations"
+ },
+ "ok": {
+ "title": "Ok",
+ "type": "boolean"
+ },
+ "operation_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operation Id"
+ },
+ "operations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/OperationEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Operations"
+ },
+ "outcome": {
+ "enum": [
+ "succeeded",
+ "refused",
+ "failed",
+ "unknown"
+ ],
+ "title": "Outcome",
+ "type": "string"
+ },
+ "pending_until": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Pending Until"
+ },
+ "protected": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Protected"
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reason"
+ },
+ "refused": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Refused"
+ },
+ "reservations": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/ClaimEntry"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reservations"
+ },
+ "reserved_mb": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Reserved Mb"
+ },
+ "resident": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Resident"
+ },
+ "retry_after": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Retry After"
+ },
+ "retry_count": {
+ "title": "Retry Count",
+ "type": "integer"
+ },
+ "scope": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Scope"
+ },
+ "size_verified": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Size Verified"
+ },
+ "summary": {
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "outcome",
+ "model",
+ "reason",
+ "detail",
+ "summary",
+ "operation_id",
+ "pending_until",
+ "retry_after",
+ "retry_count",
+ "keep_alive",
+ "resident",
+ "protected",
+ "busy",
+ "claims",
+ "operations",
+ "observations",
+ "reservations",
+ "refused",
+ "size_verified",
+ "model_size_mb",
+ "headroom_mb",
+ "reserved_mb",
+ "additional_mb",
+ "scope",
+ "free_mb",
+ "coordination_warning"
+ ],
+ "title": "ResidencyResult",
+ "type": "object"
+}v0.2.0adviseclaimensure_freehistorylist_claimslist_loadedreleaserenewreservetrendunloadvram_statuswarmScored across 13 tools
Most tools have clearly distinct purposes, but there is real overlap between list_loaded and vram_status (both report residency) and between history and trend (both surface historical data). The descriptions do enough to separate them, so an agent can mostly disambiguate, but these pairs require reading carefully.
There is a discernible pattern — verb_noun for actions (list_loaded, ensure_free, list_claims) and bare verbs for mutations (unload, warm, renew, release) — but query tools use bare nouns (history, trend, advise, claim, reserve), mixing conventions. It is readable but not a single predictable scheme.
13 tools is well-scoped for VRAM lifecycle management: monitoring, eviction/loading, and a cooperative claim/reservation system. Each tool earns its place without redundancy or padding.
The claim lifecycle is complete (claim/renew/release/list_claims) and monitoring covers status, history, trend, and advice. Minor gap: reservations (reserve) lack an explicit release/list counterpart, so non-Ollama capacity reservations may be harder to inspect or cancel.
Rent cloud GPUs from AI agents: live prices, VRAM estimates, launch, logs and stop.
Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
On-demand GPU nodes for agents: create nodes, run commands, and submit jobs, billed by the minute.
GPU cloud for AI agents: launch GPUs, run jobs that stop their own billing, schedule runs.
