lmstudio

LM Studio: load model

load_model

Load a model into memory with settings like GPU offload, context length, and TTL. Keeps an already loaded model unless replace is set to true.

Instructions

Load a model into memory. Large models can take minutes and most of the RAM: run estimate_load first and get the user's OK for big ones. If the model is already loaded it is kept as it is; pass replace: true to reload it with other settings. Saved model_defaults fill in missing settings. ttl, gpu, parallel and identifier use the lms CLI (LM Studio on this machine only); flash_attention, eval_batch_size, num_experts and offload_kv_cache_to_gpu use the REST API. The two groups can't be mixed in one call.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model": "<model>"
    },
    "name": "load_model"
  }
}

Input Schema

Name	Required	Description
`gpu`	No	GPU offload: "off", "max" or a ratio such as "0.5".
`ttl`	No	Unload automatically after this many idle seconds.
`model`	Yes	Model key from list_models.
`replace`	No	Unload the loaded instance(s) of this model first, then load it with these settings.
`parallel`	No	How many predictions may run at the same time.
`identifier`	No	Custom instance id; loads a separate instance even if the model is already loaded.
`num_experts`	No	Active experts for MoE models (llama.cpp engine only).
`context_length`	No	Context window in tokens. Default: the saved default, else the model's own setting. Leave it out unless the user asks for a specific context: a saved default is the user's choice for this model.
`eval_batch_size`	No	Tokens per evaluation batch (llama.cpp engine only).
`flash_attention`	No	Flash attention (llama.cpp engine only).
`offload_kv_cache_to_gpu`	No	false keeps the KV cache in RAM (llama.cpp engine only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.2Nov 13, 2026

changedInput schema / properties / context_length / description

Previous value: -"Context window in tokens. Default: the saved default, else the model's own setting."New value: +"Context window in tokens. Default: the saved default, else the model's own setting. Leave it out unless the user asks for a specific context: a saved default is the user's choice for this model."

First observedv0.1.0Nov 11, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive mutation, and the description adds genuinely non-obvious behavior: multi-minute load time, RAM consumption, the keep-as-is idempotency-like rule, and the hard constraint that CLI-backed (ttl, gpu, parallel, identifier) and REST-backed (flash_attention, eval_batch_size, num_experts, offload_kv_cache_to_gpu) settings cannot be mixed. That backend split is exactly the kind of context annotations cannot convey. It loses points only because failure modes and what happens to other loaded models under RAM pressure are left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, then the risk warning, then the reload rule, then the backend constraint. Dense but every clause carries operational information; nothing restates the tool name or the schema.

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?

For an 11-parameter mutation tool with no output schema, the description covers the critical unknowns: cost, defaults inheritance, replace semantics, and the CLI/REST incompatibility. It stops short of describing the return value or post-load verification (e.g., using server_status), which would make it fully self-sufficient.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining that saved model_defaults fill in omitted settings and by partitioning the parameters into two mutually exclusive groups, which the schema itself does not express. It does not add detail for context_length or the MoE-only params beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Load a model into memory') and immediately scopes it against siblings: estimate_load for cost checking and unload_model as the inverse. The replace/identifier semantics also separate it from a plain no-op reload.

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

Usage Guidelines5/5

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

Explicit when-to guidance: run estimate_load first and get user approval for big models; leave an already-loaded model alone unless replace: true is needed. It also names the condition for loading a separate instance via identifier, so the agent does not have to infer alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.