Skip to main content
Glama

Delegate several tasks to Luna workers

delegate_tasks

Delegate a batch of bounded tasks to an AI worker for autonomous implementation, verification, and integration. Use sequential for dependencies or parallel for independent scopes.

Instructions

Delegate a batch intended for two or more owned seams to gpt-5.6-luna; one task remains accepted for compatibility, but prefer delegate_task when no scheduling is needed. Use sequential for dependencies/shared workspace state and parallel only for genuinely independent disjoint declared scopes. Do not create artificial seams. At most 12 tasks are accepted and at most 3 run concurrently; the rest queue. Each task needs a self-contained contract and a concise activityLabel when a safe label exists. The parent owns architecture/interfaces and exceptional judgement; Luna owns exploration, implementation, verification, and repair. automaticRepair is one bounded task-local turn.

Parallel same-file edits prevent automatic integration. allowOverlappingScopes:true only accepts the declared overlap; it is not a write sandbox and does not permit same-file integration. integrate=false skips copying and retention follows operator policy. Partial outcomes remain visible. automaticRecovery defaults true: at most one evidence-eligible timeout continuation or exact process-exit retry; a counter alone never authorizes retry. Repair precedes recovery and neither nests. Successes, cancellation, scope/security/evidence failures, refused checks, discrepancies, and conflicts are never retried. Successful streams survive sibling failure.

After integration, deterministic code reruns the deduplicated union of declared checks in the final workspace. completionState=verified-complete means all seams, integration, and final checks passed; the default text-only handoff then tells the parent to finish without rereading files or rerunning checks. Any failure/refusal/conflict returns rich evidence for targeted diagnosis. resultDetail is one batch-level compatibility choice. More workers are not automatically cheaper; raw tokens are not credit cost and savings depend on the parent and task mix. While pending with no meaningful new state, remain silent; do not narrate waiting or polling. Report only a result, error, cancellation, timeout, or actionable state change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
tasksYes
integrateNo
resultDetailNohandoff
computePolicyNoOptional per-call compute envelope. Narrows this installation's operator-owned baseline only and can never widen it. Omit to use the baseline.
routingPreflightNoOptional advisory routing declaration. Solo advice never blocks execution; declarations gate: every surface refuses empty seams, parallel also refuses mutable sharedState, shared-core coreOverlap, or tasks > seams. "unknown" biases advice solo, never refuses.
workingDirectoryNo
automaticRecoveryNo
allowOverlappingScopesNo
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It goes far beyond a basic summary by specifying concurrency limits, queueing, retry rules, automaticRecovery defaults, repair scope, integration behavior, completionState semantics, and reporting etiquette. This is exceptional transparency for a complex tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and dense, but the tool is genuinely complex and nearly every sentence adds an operational constraint or decision rule. It is grouped into thematic paragraphs and front-loaded with the primary purpose, but it is still a wall of text rather than a structured, skimmable format.

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, absence of annotations, and absence of output schema, this description is remarkably complete. It covers selection criteria, operational limits, concurrency and queueing, integration and overlap semantics, retry and recovery behavior, failure handling, result semantics, and even reporting etiquette. An agent has enough context to decide when to call it and how to configure a valid batch.

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

Parameters5/5

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

Schema description coverage is only 22%, so the description must compensate, and it does. It explains the behavioral meaning of allowOverlappingScopes:true, integrate=false, resultDetail, automaticRepair, automaticRecovery, and sequential/parallel mode, which the bare schema enums do not provide. It also gives practical guidance like requiring self-contained contracts and concise activityLabels.

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 states a specific verb and resource: delegate a batch to Luna workers. It also differentiates from the sibling tool delegate_task by explaining that a single task is accepted for compatibility but delegate_task is preferred when no scheduling is needed.

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?

The description explicitly says when to prefer delegate_task, and gives clear rules for choosing sequential vs parallel: sequential for dependencies/shared state, parallel only for independent disjoint scopes. It also forbids artificial seams, leaving no ambiguity about when this tool is appropriate.

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

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/mahadansar/sol-luna-orchestrator'

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