lmstudio

LM Studio: one-off prompt

chat

Send a single prompt to a local model and get an answer with speed stats; no memory is kept. Attach text files or images for one-off queries.

Instructions

Send a single prompt (with optional text files and images) to a local model and get its answer with speed stats; nothing is remembered. Loads the model if needed. For conversations use sessions, for long jobs task_start.

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>",
      "prompt": "<prompt>"
    },
    "name": "chat"
  }
}

Input Schema

Name	Required	Description
`files`	No	Absolute paths to text files (code, logs, documents) to add to the message, up to 2 MB each. Use this instead of pasting file contents.
`model`	Yes	Model key or loaded instance id.
`images`	No	Absolute paths to PNG, JPEG, WebP or GIF files, for vision models.
`prompt`	Yes	The user message.
`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	Minimum context for this prompt; the model is loaded with it if needed. 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.
`include_reasoning`	No	Also return the model's reasoning text.
`max_output_tokens`	No	Upper limit for generated tokens per answer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.2Nov 13, 2026

changedInput schema / properties / context_length / description

Previous value: -"Minimum context for this prompt; the model is loaded with it if needed."New value: +"Minimum context for this prompt; the model is loaded with it if needed. 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."

addedInput schema / properties / files

Added value: +{
+  "description": "Absolute paths to text files (code, logs, documents) to add to the message, up to 2 MB each. Use this instead of pasting file contents.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedv0.1.0Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag non-readOnly, non-idempotent, closed-world, non-destructive, so the safety bar is partly covered. The description adds genuinely useful behavior the annotations cannot convey: no conversation state is retained, the model may be loaded on demand, and the response includes speed statistics. It stops short of describing error or failure behavior, but the key side effect (loading) is disclosed.

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?

Two sentences, zero filler, and the most important constraint (one-off, stateless) is front-loaded before the routing advice. Nothing in it repeats the title or the parameter list unnecessarily.

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 a 12-parameter, no-output-schema tool the description covers the essential model: statelessness, implicit model loading, and the sibling alternatives, while the rich schema handles the parameters. The only mild gap is that the shape of the returned answer (beyond 'speed stats') is left implicit, which is acceptable given no output schema exists to describe it.

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

Parameters3/5

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

Schema description coverage is 100% and every one of the 12 parameters carries its own description, including the 2 MB file cap and the caution about overriding context_length. The description only echoes 'optional text files and images', adding no meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource — send one prompt to a local model, get the answer plus speed stats — and scopes it with 'single' and 'nothing is remembered'. That scope statement alone separates it from session_send and task_start 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.

Usage Guidelines5/5

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

Explicitly routes the agent: conversations go to sessions, long jobs go to task_start. Both the exclusion and the named alternatives are present, so selection is decided by the description rather than by inference.

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