hive

Overview Schema Source Related Servers Discussions Admin

Delegate Task

delegate_task

Offload processing to a cheaper model and summarize large vault files automatically, falling back to raw content when workers are unavailable.

Instructions

Offload work to a cheaper model or summarize vault files.

When project is provided, reads a vault file. Small files (≤50 lines) are returned directly. Large files are auto-delegated to a worker for summarization — falls back to raw content if workers are unavailable.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No	Relative path to a .md file. Overrides section.
`model`	No	Concrete model id. Empty uses the configured worker model. The 4.0.0 removal retired 'auto', 'ollama', 'openrouter-free' and 'openrouter'; passing one is rejected rather than ignored.
`prompt`	No	The task description or code to process.
`context`	No	Optional system context for the model.
`project`	No	Project slug for vault summarization mode.
`section`	No	Shortcut name for summarization. Ignored if path is set.	context
`timeout_s`	No	Per-dispatch deadline in seconds. 0 uses the ambient tool timeout. A value ABOVE the ambient one raises the ceiling rather than being clamped by it — a deadline a 60s default can silently cap is not a deadline (HIVE-384 AC3).
`max_tokens`	No	Maximum tokens in the response.
`structured`	No	Return a JSON record instead of prose. Prose is the default so every existing caller's contract is unchanged; the dispatcher asks for JSON because it needs the status as a VALUE. Exception types do not survive the JSON-RPC boundary between the daemon and its clients, so "the pool refused" and "the worker answered badly" cannot be told apart by type on the far side — and a dispatcher that cannot tell them apart turns a rate limit into a silent retry against a different model.
`max_summary_lines`	No	Target summary length for summarization.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.1.0Aug 23, 2026

addedInput schema / properties / structured

Added value: +{
+  "default": false,
+  "description": "Return a JSON record instead of prose. Prose is the\ndefault so every existing caller's contract is unchanged; the\ndispatcher asks for JSON because it needs the status as a\nVALUE. Exception types do not survive the JSON-RPC boundary\nbetween the daemon and its clients, so \"the pool refused\" and\n\"the worker answered badly\" cannot be told apart by type on the\nfar side — and a dispatcher that cannot tell them apart turns a\nrate limit into a silent retry against a different model.",
+  "type": "boolean"
+}

addedInput schema / properties / timeout_s

Added value: +{
+  "default": 0,
+  "description": "Per-dispatch deadline in seconds. 0 uses the ambient\ntool timeout. A value ABOVE the ambient one raises the ceiling\nrather than being clamped by it — a deadline a 60s default can\nsilently cap is not a deadline (HIVE-384 AC3).",
+  "type": "number"
+}

Changed3 schema fields changedv4.0.0Aug 23, 2026

removedInput schema / properties / max_cost_per_request

Removed value: -{
-  "default": 0,
-  "description": "Max USD. 0 = free models only.",
-  "type": "number"
-}

changedInput schema / properties / model / default
```
Previous value: -"auto"New value: +""
```

changedInput schema / properties / model / description

Previous value: -"'auto', 'ollama', 'openrouter-free', 'openrouter' (paid), or model ID."New value: +"Concrete model id. Empty uses the configured worker model.\nThe 4.0.0 removal retired 'auto', 'ollama', 'openrouter-free'\nand 'openrouter'; passing one is rejected rather than ignored."

Addedv1.21.0May 28, 2026
Removedv1.13.0May 20, 2026
First observedv1.11.0Mar 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The annotations are neutral (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden of behavior disclosure. It reveals genuinely non-obvious traits: the ≤50 line direct-return threshold, automatic delegation of large files, and the fallback to raw content when workers are unavailable. It stops short of stating side effects (whether summaries persist back to the vault) or cost/latency implications of delegation.

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 sentences with zero filler. The one-line purpose statement is front-loaded, and the conditional flow is compressed into a tight, scannable second sentence. Every clause 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?

For a 10-parameter dual-mode tool with an output schema, the description captures the core decision logic (mode selection, size threshold, fallback) while the schema documents parameters and return values. The main gaps are the relationship between the two modes and whether summarization has persistent side effects, but the rich schema compensates for most of what the description omits.

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 exceptionally rich per-parameter descriptions (model-value rejection semantics, timeout ceiling behavior with HIVE-384 reference, structured-mode rationale). Per the rubric, high coverage sets a baseline of 3. The tool description adds connective flow logic (project triggers file reading; size threshold drives delegation) but no parameter-level detail beyond what the schema already provides.

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

Purpose4/5

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

The description opens with a specific verb-resource pair: "Offload work to a cheaper model or summarize vault files." This clearly distinguishes it from the vault_* siblings and worker_status. However, "offload work" is slightly vague about what the work actually is, and the dual-purpose framing splits focus, so it just misses the top score.

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

Usage Guidelines3/5

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

The description explains mode selection implicitly: "When project is provided, reads a vault file" and the small/large file branching. It does not explicitly name alternatives or say when to prefer this tool over vault_ask or other siblings — an agent could not tell from this alone whether to pick delegate_task or vault_ask for a summarization request.

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

Deploy Server