Skip to main content
Glama

Dispatch to a local model

ollama_dispatch

Run a local Ollama model for summarization, extraction, and reformatting; reads files server-side so only the answer consumes your context.

Instructions

Run one generation on a local Ollama model and return its output. Use for summarization, extraction, reformatting and other mechanical work you do not want to spend your own context on. Supports structured output (format), multi-turn messages, tool definitions, and server-side file reading via files/file_globs so file contents never enter your context. Select the model with model: a literal name, role:NAME, or caps:a+b. Note that reasoning tokens and answer tokens share one num_predict budget — thinking is off by default for that reason. Every response ends with a metrics line naming the model actually used and how it was resolved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoOverride the base URL of the local inference server for this call only, e.g. "http://localhost:11434". Omit to use the configured host.
seedNoRNG seed. Pair with temperature 0 for reproducible output.
stopNoUp to 8 stop sequences. Generation halts when one is produced.
filesNoAbsolute (or cwd-relative) file paths to include as context. THE SERVER READS THESE LOCALLY AND FEEDS THEM STRAIGHT TO THE LOCAL MODEL — the file contents never enter your context. This is the main reason to use this tool: hand off a large file, get back only the answer. Reads are confined to a configured root allowlist.
modelNoModel selector. Three grammars are accepted: (1) a literal installed model name or configured alias, used as-is; (2) "role:NAME" — resolve through the named role, which carries an ordered fallback chain plus its own sampling defaults; (3) "caps:a+b" — pick the best installed model advertising ALL of the named capabilities (e.g. "caps:vision+tools"), ranked by the configured policy. Omit this field entirely to use the configured default role, which is the right choice unless you have a reason. Selectors never name a model in server code — availability is discovered at runtime, so an unknown or un-pulled name is an error, not a silent substitution.
thinkNoEnable reasoning on a thinking-capable model: true/false, or an effort level ("low" | "medium" | "high" | "max"). Default is OFF. WARNING: reasoning tokens and answer tokens are drawn from the SAME num_predict budget, so a small num_predict with thinking enabled routinely spends the whole budget reasoning and returns EMPTY content. If you turn thinking on, raise num_predict well above the default.
toolsNoTool definitions offered to the model, in the standard function-calling format. Requires a model with the "tools" capability. Any tool calls come back to you to execute; this server never executes them.
top_kNoTop-k sampling cutoff.
top_pNoNucleus sampling threshold.
detailNoResponse verbosity. "concise" returns the answer plus minimal provenance; "detailed" adds the resolution trail, token counts, timings and warnings. Default is the configured value.
formatNoConstrain the output shape: "json" for free-form JSON, or a JSON Schema object for structured output matching that schema. Ask for the fields you need in the prompt too — the schema constrains form, not content.
imagesNoBase64-encoded images attached to the prompt. Only valid with `prompt`; when using `messages`, attach images to the relevant turn instead. Requires a vision-capable model.
promptNoSingle-turn user prompt. Provide EITHER prompt OR messages, never both and never neither. Use prompt for one-shot work; use messages when prior turns matter.
systemNoSystem instruction prepended to the conversation. Applied whether you passed prompt or messages; if messages already begins with a system turn, this is merged ahead of it.
num_ctxNoContext window in tokens for this call. Raising it costs VRAM; exceeding the model window silently drops the OLDEST content, so the server checks it rather than letting that happen quietly.
optionsNoEscape hatch for runtime options this schema does not name. Merged under the typed fields above, which win on conflict. Use when the local server gains an option newer than this tool.
messagesNoFull conversation, oldest turn first. Mutually exclusive with prompt. Prefer this when the model needs earlier turns, tool results, or per-turn images.
file_globsNoGlob patterns expanded on the server, e.g. "src/**/*.ts". Same token-saving property as `files`: matched contents go to the local model, not to you. Expansion is confined to the root allowlist, skips node_modules/.git/dotdirs, and can NEVER match a sensitive file (.env, keys, credentials) regardless of other settings.
keep_aliveNoHow long the model stays resident in VRAM after this call: a duration string such as "10m", or seconds as a number. 0 unloads immediately; a negative number keeps it loaded indefinitely. Keeping a model warm avoids re-paying a multi-second load on the next call.
timeout_msNoPer-request timeout in milliseconds. Large models on a cold load can take tens of seconds before the first token, so prefer generous values over retrying.
num_predictNoMaximum tokens to generate. -1 means unlimited. This budget is shared with reasoning tokens when `think` is on, so size it for both.
temperatureNoSampling temperature. 0 is near-deterministic; higher is more varied.
allow_sensitiveNoPermit reading a file the deny-list would normally block (.env, *.pem, *.key, ssh/aws material, anything named like a credential or secret). Only ever applies to a path named explicitly in `files`; globs can never pull in a sensitive file. Off by default.
include_thinkingNoReturn the reasoning trace alongside the answer. Off by default because traces are long and land in YOUR context. Useful when debugging why an answer went wrong.
max_output_charsNoHard cap on the number of characters returned to you. Output beyond this is trimmed and the trim is reported, never hidden. Use it to protect your own context window.
require_capabilitiesNoCapabilities the chosen model MUST advertise, e.g. ["vision"], ["tools"], ["thinking"]. Applied on top of whatever `model` selects, and a mismatch is a hard error rather than a silent downgrade. Capability names are whatever the local server reports — the set grows between releases, so unknown names are passed through, not rejected.
Behavior5/5

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

The description goes far beyond the basic annotations, disclosing that reasoning and answer tokens share one num_predict budget, thinking is off by default, files are read server-side and never enter the caller's context, resolution never silently substitutes unknown models, and output trimming is reported. This is substantial behavioral disclosure with no contradiction against annotations.

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?

The description is dense and front-loaded, with the first sentence stating purpose immediately. Every subsequent sentence adds unique information—use cases, context protection, model resolution, token budget, and output metrics—with no filler or repetition.

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

Completeness5/5

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

Given the tool's complexity (26 params, no output schema) and sparse annotations, the description is remarkably complete: it covers purpose, when to use, model resolution, file handling, security constraints, token-budget caveats, and what the response includes. The schema handles individual parameter details, and the description fills the behavioral and selection gaps.

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?

With 100% schema description coverage, the baseline is 3, but the description adds valuable context beyond the schema: the three model-selector grammars, the token-saving rationale behind files/file_globs, and the warning about num_predict sharing with thinking tokens. This elevates it above the baseline without being redundant.

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 is a specific verb+resource statement: 'Run one generation on a local Ollama model and return its output.' It clearly differentiates from siblings by emphasizing a single generation, and the rest of the description enumerates concrete use cases like summarization and extraction.

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?

The description gives clear context for when to use it ('mechanical work you do not want to spend your own context on') and highlights the file-reading feature. However, it does not explicitly name alternatives or state when NOT to use it, such as pointing to ollama_dispatch_batch for multiple generations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Clickt-Digital-Marketing-Inc/ollama-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server