Skip to main content
Glama

Dispatch many prompts to local models

ollama_dispatch_batch

Run many generations in one call, grouping by model to avoid reload overhead, returning results in input order with isolated failures.

Instructions

Run many generations in one call. Items are grouped by resolved model and the groups run sequentially, so a cold model load is paid at most once per model instead of thrashing VRAM. Results are returned in input order regardless of execution order, and one failing item never voids the run. Prefer this over many separate ollama_dispatch calls: it is faster and costs you far less context.

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.
itemsYesThe work list, 1-64 items. Results always come back in THIS order regardless of execution order, and a failed item is reported as a failure without voiding the rest.
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.
detailNoResponse verbosity. "concise" returns the answer plus minimal provenance; "detailed" adds the resolution trail, token counts, timings and warnings. Default is the configured value.
defaultsNoPer-item settings applied wherever the item itself is silent.
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.
concurrencyNoHow many items of the SAME model run at once. Default 1, which is the VRAM-safe choice; raise it only for small models on a machine with headroom. Groups themselves always run one after another.
stop_on_errorNoAbort remaining items after the first failure. Off by default — partial results beat no results, and unstarted items are reported as such.
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.
Behavior5/5

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

Beyond annotations, the description reveals non-obvious execution semantics: grouping by resolved model, sequential group execution to avoid VRAM thrashing, input-order result return, per-item failure isolation, and context cost savings. These traits are not encoded in the annotations (readOnlyHint, openWorldHint, etc.) and materially shape the agent's expectations.

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?

Four concise sentences, each adding distinct value: the core purpose, grouping/VRAM rationale, result ordering/failure isolation, and the explicit comparison with the sibling. No redundant or filler content; every sentence earns its place.

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?

Despite having 10 parameters and nested objects, the description covers the most important behavioral context—batching rationale, ordering, failure handling, and context cost—while the schema documents parameter details in depth. It does not explicitly describe the result item structure, but the item schema's 'id echoed back' and 'results returned in input order' imply a list of per-item outputs, so the gap is minor.

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 coverage is 100% with rich descriptions for all 10 parameters (e.g., model grouping, concurrency, keep_alive). The description's high-level statements about grouping and ordering are already replicated in the schema's parameter descriptions, so it adds no new parameter-level meaning; 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?

Description opens with 'Run many generations in one call', a specific verb+resource statement. It clearly distinguishes from sibling 'ollama_dispatch' by explicitly recommending batching over multiple separate calls, establishing its scope as the batch variant.

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 instructs to 'Prefer this over many separate ollama_dispatch calls' when handling many prompts, naming the alternative and the concrete benefits (faster and less context). This gives clear when-to-use guidance and an implicit when-not-to-use for single dispatch, matching the level of the calibration example for get_calls.

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