GenFlick

Send a running task a correction or a message, or reply on a thread

native.direct_work

DestructiveIdempotent

Send a running task a correction or a message, or reply on a thread. A correction changes what the agent is doing and quotes the revision you read; the agent reads it at its next step. A message is information both ways: the agent decides what to do and may reply, and you read the reply in your next step. Several can go in one response. 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.direct_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

A3.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely useful behavior: the agent reads a correction at its next step, replies to a message arrive in your next step, several messages can go in one response, and corrections must quote the revision read. It still does not state what the destructive side actually is (does a correction discard in-progress work?), nor anything about permissions or failure modes, which is the main gap for a destructive, open-world call.

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?

Content is front-loaded: the mode distinction comes first, then attachment semantics. Sentences are dense but each carries substantive meaning, including the important negative constraint about what does not count as an attachment ID. Minor cost is the run-on middle section about the native agent reading its own target project, which takes a re-read to parse.

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 6-parameter, nested-schema, destructive tool with an output schema present, the description covers the decision-relevant surface: mode choice, revision quoting, thread replies, and attachment ID rules. Remaining gaps are the identifier/idempotency plumbing (work_id, request_key, delegation_id), which the schema mostly names but does not explain, so an agent knows what to send but not fully why.

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 only 50%, and the description compensates well for the undocumented parameters: source_ids is defined as exact attachment or message source IDs with a clear negative list (project documents, clips, tool-result IDs, read_resource addresses are not attachment IDs), and source_roles is tied to selected attachments' exact resource IDs with omit-when-empty guidance. It also implicitly documents expected_revision as the quoted revision required for a correction. work_id, request_key, and delegation_id remain unexplained in the description.

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 leads with a concrete verb and resource set — send a correction or message to a running task, or reply on a thread — and clearly separates the two modes (correction changes behavior, message is informational/two-way). It does not name sibling tools such as answer_work_question, delegate_work, or continue_work, so an agent must infer routing from the mode definitions rather than an explicit sibling contrast.

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?

It gives clear when-to-use context for the two modes: a correction 'changes what the agent is doing' and requires quoting the revision you read, while a message is information both ways where the agent decides and may reply. What's missing is any exclusion or routing against adjacent tools (raising/answering a question, continuing or delegating work), so the agent gets mode selection but not tool selection.

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?