lmstudio

LM Studio: start a session

session_start

Start a persistent conversation with a local LM Studio model, loading it if needed, then send messages or run background tasks within the same memory context.

Instructions

Start a conversation with a local model that LM Studio remembers across messages. Loads the model if needed, with context_length (else the saved default) as the minimum context. Then use session_send, or task_start to run a message in the background.

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": "session_start"
  }
}

Input Schema

Name	Required	Description
`model`	Yes	Model key from list_models.
`title`	No	Short name to recognise the session later.
`reload`	No	If the model is loaded with a smaller context than needed, unload it and load it again.
`reasoning`	No	Reasoning effort, for models that support it.
`temperature`	No	0 is deterministic.
`integrations`	No	LM Studio plugins or MCP servers the local model may use, as configured in LM Studio, e.g. "mcp/github".
`system_prompt`	No	System instructions.
`context_length`	No	Context the session needs. Default: the model's saved default. Leave it out unless the user asks for a specific context: a saved default is the user's choice for this model.
`max_output_tokens`	No	Upper limit for generated tokens per answer.

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 the session needs, e.g. 262144. Default: the model's saved default."New value: +"Context the session needs. Default: the model's saved default. 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.3/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the key side effect that a model may be loaded on demand, and that context_length is a minimum that can trigger a reload. It is silent on cost/latency of loading a large model and on failure modes, but the important mutating behavior is surfaced.

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?

Three short sentences, front-loaded with what the tool does, then the loading side effect, then the next-step routing. Every sentence carries information an agent needs; nothing is repeated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter session-creating tool with no output schema, the description covers lifecycle and follow-up calls but never says what comes back or how the created session is referenced later (the title param implies identification, but this is left to inference). It is adequate rather than complete.

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, but the description adds meaning the schema does not: context_length is a minimum requirement (not a target) and the saved default is framed as the user's deliberate choice. That is genuine guidance beyond the field descriptions.

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 description names a specific verb and resource ('Start a conversation with a local model') plus the defining scope ('that LM Studio remembers across messages'), which is exactly what separates it from stateless siblings like chat or session_send. An agent can identify the tool without opening the schema.

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

Usage Guidelines4/5

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

It explicitly routes the agent forward ('Then use session_send, or task_start to run a message in the background') and gives a conditional rule for context_length ('Leave it out unless the user asks for a specific context'). It does not state exclusions against siblings such as chat or server_start, so it falls short of a full when/when-not guide.

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