Skip to main content
Glama

Delegate a task

delegate
DestructiveIdempotent

Queues one task for one of the owner's apps (Claude Code, Codex, Cursor or T3 Code on the owner's Mac, or a cloud AI) by executor_id or role; name neither and Prometheor chooses under the owner's settings (state executor_choice_needed lists executor_ids to pick from; nothing is queued). The task runs visibly in that app. target_offline: the Mac is asleep or off and nothing is queued; ask the owner whether to queue it until it wakes. A cloud AI whose wake subscription ran out takes no task: another app that fits gets it (rerouted_from names the first one; tell the owner and give them next_step's sentence), and target_not_listening means none fits. Brief, folder, scope and checks are fixed at delegation; the same idempotency_key with the same content returns the same task. follow_up_of continues an app chat; web_session sends the brief into a person's chat. Refused while orchestration is off: follow next_step. When it fits: the owner names an app or computer (that executor_id gets exactly that task), or says Council (several apps advise on the same question with skill council, nobody changes files, you answer with one combined recommendation) or Team ("use the team", "orchestrate": the apps build one result together with skill team, and the results come back as one answer); say who takes part first. Without such words the owner's settings apply: by default the work stays with you or you ask once ("Shall I give this to Codex?"); with auto_delegate "on" in an answer, new work goes on with auto true. A step that needs an ability you lack (Mac apps, the owner's Chrome, a browser, Computer History: Codex; Claude in Chrome: Claude Code) goes to the app that has it. Set execution only when the owner asks, after checking that executor's execution_options in list_agents (a task with options its app does not take fails).

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": {
      "brief": "<brief>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "delegate"
  }
}

Input Schema

NameRequiredDescriptionDefault
autoNoOnly while an answer showed auto_delegate "on": true when you hand work on by yourself, without the owner naming Prometheor or an app. Name no executor_id, role, follow_up_of, web_session or part_of; Prometheor picks the app(s).
roleNo
briefYesThe task as a short message to a colleague, at most 1000 characters, in the owner's language. Line 1: the goal in one sentence (it becomes the chat title). Then "Constraints:" with only what matters (what not to touch, whether to push, relevant logbook decisions). Then "Done when:" with a checkable end. Labels in the owner's language. Leave out headers, rules, report format and context the app can read itself: Prometheor adds the header, rules, folder and report format.
scopeNoPaths in the folder the task may change; only when the owner limits the task.
skillNoOptional. Only when the owner said Council or Team: the round this task belongs to. council: the app advises and changes no files (Prometheor adds that rule to the brief); team: the app builds part of one shared result.
titleNo3 to 6 words in the owner's language, starting with the goal's verb, e.g. "Fix Safari export button". The owner finds the task by it in the task list, menu bar and app chat. Always give one; with follow_up_of only when the subject changed (the app chat is renamed).
folderNoOptional. A folder on the owner's computer as the owner names it, e.g. ~/code/shop, or a named project's folder (list_tasks include_sessions, projects); in a team round every app gets the same one. Never guess. Apps take turns in a folder (parts of the same task excepted). Without it the app starts in the home folder. Changed files are checked and committed only inside a Git repository.
part_ofNoOnly while working on a Prometheor task yourself and passing part of it on: that task's id (its "Task:" line). At most three links in a chain.
big_taskNoOne job keeps one number. Left out on a new task, or "new": a new topic with a new number; an earlier job's number (e.g. "#500") or task id when it continues that job. Not with part_of or follow_up_of, which keep their number. A message into a chat (web_session) without it keeps the number of the job you gave a task in from this chat in the last 30 minutes (answer: same_job).
deadlineNoLatest claim time; default 24 hours, at most 7 days.
handoverNoOptional, at most 6000 characters, only when the owner wants this chat continued in another app (like switching AIs): a short summary you write for that app (not a transcript): the goal, what was decided and done, the current state, open points and the details it needs (files, names, numbers), newest last. The app reads it first as an earlier chat. New tasks only; for a Codex, Claude Code or Cursor chat on the Mac use context_from instead. No secrets.
replacesNoOnly when this task takes over an earlier task that has not started (for example one queued for a Mac that sleeps): its task_id. In one step the earlier task ends and this one is queued, so the work is not done twice. If the earlier task already runs or has its result, nothing is queued (replaced_task_running or replaced_task_done): wait for it instead.
reply_ofNoOptional: when you answer a message that reached you through Prometheor, the task id it named; your answer then shows as an answer, not a new request. With web_session when the message named a chat to answer into; without it the answer reaches the AI that asked (a cloud AI such as a Grok Bot or a Dot).
assistantNoOnly when several assistants share this connection (for example two Grok Bots of one account, or several Dots in one ChatGPT account): your own fixed name for Prometheor, a Grok Bot its bot id, otherwise a short name in lowercase. Pass the same value on every call (delegate, worker_setup, worker_claim, worker_report), so Prometheor keeps your tasks, your wake and the answers to your questions apart from the others'. Leave it out when you are the only one.
executionNoSet a field only when the owner asks; otherwise the app's own settings on that computer apply. Only model, reasoning effort and /goal can be set: permissions, sandbox and approvals always stay as the owner set them in the app. To limit the work (for example to one folder), say so in the brief.
acceptanceNoChecks the server compares against the executor's evidence.
backgroundNoOptional, at most 4000 characters: details the app may need (measurements, paths, earlier findings, a proposed approach). The app gets them apart from the brief, as a file it reads when needed, so its chat shows only the brief. Leave out when the brief is enough.
files_fromNoOptional. Earlier tasks whose result files the app works on; they are copied into the folder's prometheor-files subfolder first.
executor_idNo
owner_wordsNoOptional, at most 2000 characters: what the owner said about this task, in their own words and language (quote them; drop only greetings and parts meant for other apps). The app's chat shows only these words, so the owner recognises their request there; your brief goes along unseen as the app's instructions. Leave out when the owner said nothing about it (e.g. a step you start yourself).
web_sessionNoOptional. Sends the brief as a message into a person's chat instead of an app task: a Claude Code web session or Claude project chat of the owner, by session id (session_...), claude.ai/code link, a name saved with save_chat (see list_agents), the claude.ai/code/project link of a saved project, or the title of one thread of a Claude project (list_agents threads) to write to that thread alone. For a project chat use its saved name or project link, never a session id you remember: it changes when the chat restarts. Needs Claude Code on one of the owner's computers; leave out executor_id, role and follow_up_of. A person reads it: plain words in the owner's language, no tool or field names, ids or test codes, and no Constraints:/Done when: lines unless you ask that chat to do a task. Prometheor adds a short header naming you.
context_fromNoOptional. Hands a chat to this app, like switching AIs: a session_id from list_tasks or an earlier task_id. Prometheor reads that Codex, Claude Code or Cursor chat on the owner's computer (newest ~16,000 tokens, secrets removed; the text never passes Prometheor's server) and the app reads it first. Same computer only. Starts a new chat; continue it with follow_up_of = the new task_id.
follow_up_ofNoContinues a task, or a session_id from list_tasks, in the same app chat: a running task gets the message at once, a finished one continues as a new task, a question is answered. With another app's executor_id an ended task or chat goes to that app as a new chat that reads the earlier one first.
reply_sessionNoOnly when you are a Claude Code web session or Claude project chat, and then always: your session id or claude.ai/code link; that chat then hears of this task's result, question or end, and other chats of your app do not take it as theirs.
acceptance_modeNoLeave out: the result is verified once the runner's and declared checks pass. requester_review (accept with task_review) or owner_confirm only when the owner wants to review first.auto
idempotency_keyYes
queue_if_offlineNoOnly after the owner said yes: queue although the Mac is asleep or off; it starts when the Mac wakes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / big_task / description
      Previous value: -"One job keeps one number. Without this field a new task keeps the number of the job you work on, or gave a task in from this chat in the last 30 minutes (answer: same_job). \"new\" for a separate job or another topic. An earlier job's number (e.g. \"#500\") or task id to continue that one. Not with part_of or follow_up_of."New value: +"One job keeps one number. Left out on a new task, or \"new\": a new topic with a new number; an earlier job's number (e.g. \"#500\") or task id when it continues that job. Not with part_of or follow_up_of, which keep their number. A message into a chat (web_session) without it keeps the number of the job you gave a task in from this chat in the last 30 minutes (answer: same_job)."
    • removedInput schema / properties / kind
      Removed value: -{
      -  "description": "Optional. The kind of work: code, research, computer_use, writing (texts, documents, design) or other. When no executor_id is named, Prometheor gives it to the app the owner set for that kind (owner_stack in list_agents or your recall).",
      -  "enum": [
      -    "code",
      -    "research",
      -    "computer_use",
      -    "writing",
      -    "other"
      -  ],
      -  "type": "string"
      -}
    • addedInput schema / properties / owner_words
      Added value: +{
      +  "description": "Optional, at most 2000 characters: what the owner said about this task, in their own words and language (quote them; drop only greetings and parts meant for other apps). The app's chat shows only these words, so the owner recognises their request there; your brief goes along unseen as the app's instructions. Leave out when the owner said nothing about it (e.g. a step you start yourself).",
      +  "maxLength": 2000,
      +  "type": "string"
      +}
    • addedInput schema / properties / skill
      Added value: +{
      +  "description": "Optional. Only when the owner said Council or Team: the round this task belongs to. council: the app advises and changes no files (Prometheor adds that rule to the brief); team: the app builds part of one shared result.",
      +  "enum": [
      +    "council",
      +    "team"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / execution / description
      Previous value: -"Set a field only when the owner asks; otherwise the app's own settings on that computer apply."New value: +"Set a field only when the owner asks; otherwise the app's own settings on that computer apply. Only model, reasoning effort and /goal can be set: permissions, sandbox and approvals always stay as the owner set them in the app. To limit the work (for example to one folder), say so in the brief."
    • removedInput schema / properties / execution / properties / permission_mode
      Removed value: -{
      -  "description": "Only on the owner's explicit words. A mode above the app's own default (up to full, which bypasses all approvals) applies only if the owner allowed higher rights for that app in Prometheor; the result says which applied.",
      -  "enum": [
      -    "read_only",
      -    "ask",
      -    "edits",
      -    "auto",
      -    "full"
      -  ],
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • changedInput schema / properties / big_task / description
      Previous value: -"Optional: when this new task is a question, answer or next step about an earlier big task, its number (e.g. \"#500\") or one of its task ids; the task then carries that number. Not with part_of or follow_up_of, which keep it anyway."New value: +"One job keeps one number. Without this field a new task keeps the number of the job you work on, or gave a task in from this chat in the last 30 minutes (answer: same_job). \"new\" for a separate job or another topic. An earlier job's number (e.g. \"#500\") or task id to continue that one. Not with part_of or follow_up_of."
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the visibility model (the task runs visibly in that app), idempotency semantics (same key plus same content returns the same task), and a set of named failure states (target_offline, target_not_listening, rerouted_from, executor_choice_needed) with what each means for the caller. This is unusually rich behavioral context for a mutation tool flagged destructive.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, but the body is a single dense run-on block of semicolon-chained clauses with no grouping or headings. Nearly every sentence carries information, yet the packing makes it hard for an agent to scan for the one rule that applies.

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?

For a 27-parameter tool with nested objects and no output schema, the description covers the routing decision, the refusal/offline cases, the idempotency contract and the response signals an agent must react to. Nothing essential to calling it correctly appears to be missing.

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?

Schema coverage is already 89%, so most parameters are self-documenting, yet the description still adds real routing meaning: it explains when execution may be set, how follow_up_of and web_session change the nature of the call, and how auto depends on a prior auto_delegate signal. It does not cover every parameter (e.g. acceptance, deadline, assistant are left entirely to the schema), which keeps it below a 5.

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 clause names a specific verb and resource ("Queues one task for one of the owner's apps") and immediately enumerates the possible executors and the executor_id/role routing mechanism. It also distinguishes the tool from schedule_task, task_review and follow_up_of by describing what each sibling does in contrast.

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 spells out concrete decision paths: the owner names an app or computer, says Council or Team, or nothing is said and the owner's settings apply. It also gives explicit negative guidance (ask the owner when target_offline, follow next_step when refused while orchestration is off, set execution only when the owner asks after checking execution_options).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources