GenFlick

Hand a bounded piece of work to another agent in its own studio and conversation

native.delegate_work

DestructiveIdempotent

Hand a bounded piece of work to another agent in its own studio and conversation. The task has its own saved chat, its own Stop and the enclosing spending limit, or a smaller cap you set. Send several tasks and messages in one response when they are independent. If the target is already held by another agent, nothing starts: your brief reaches that agent as a message in its next step and you get a thread to follow. Queued work is not complete: read it with read_work or wait for it before reporting completion. When your next step needs its result, set wait: the request waits for the tasks this response hands out with wait set, spending no model call, and your next step receives their views, so no wait_for_work follows. For a Film task, adapter_options.direct_actions is { expected_revision, actions }, and every document action in it names its document with document_id or document_title. source_ids selects only exact attachment or message source IDs accepted in this conversation. Omit it to carry this message's attachments. Project documents, clips, tool-result IDs and read_resource addresses are not attachment IDs: the native agent reads its own target project; put relevant context from other projects in the brief or message. source_roles uses the selected attachments' exact resource IDs; omit it when no attachments are selected.

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": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.delegate_work"
  }
}

Input Schema

Name	Required	Description
`work_id`	Yes
`arguments`	Yes
`read_skills`	Yes	Exact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
`request_key`	Yes
`publication_proposal_id`	No	For native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
`expected_catalog_version`	Yes	For a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond annotations, it discloses that a held target starts nothing and routes the brief as a message, that queued work is not complete, and that wait consumes no model call while feeding views into the next step. It also clarifies attachment and source-ID boundaries, adding substantial behavior beyond the destructive/idempotent hints.

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?

Purpose is front-loaded and most sentences carry necessary operational detail, including wait behavior and source restrictions. The long paragraph mixes parameter rules with edge cases, making it denser than ideal, though there is little obvious redundancy.

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 complex delegation tool with an output schema, the description covers the main lifecycle, waiting behavior, and tricky source/adapter rules. Remaining gaps are mostly session plumbing parameters that are partly documented in the schema.

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 50%, and the description adds substantial meaning for wait, target resource IDs, allocation caps, source_ids, and source_roles. It still leaves top-level parameters such as work_id, request_key, and read_skills mostly to the schema, so it is strong but not fully complete.

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?

States a specific action (hand a bounded piece of work) and scope (to another agent in its own studio and conversation), which separates it from same-conversation work. It does not explicitly name the closest sibling, direct_work, so sibling differentiation is good but not complete.

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?

Explains when to set wait, when to batch independent tasks, what happens if the target is held, and that queued work must be read with read_work or wait_for_work. It lacks an explicit statement of when to prefer direct_work or prepare_work over delegation.

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

All GenFlick tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?