GenFlick

Call native studio tool

call_studio_tool

DestructiveIdempotent

Execute an exact canonical tool from get_toolset in your admitted native studio session. Supply its native argument object, catalog version, and hashes of the required skills you read. All native handlers, current permissions, selected homes, finite shared budget, exact-read requirements and Stop apply. The result is durable; use read_studio_tool_result. Reusing the request key adopts the same call, never repeats provider work.

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>",
      "tool_id": "<tool_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "call_studio_tool"
  }
}

Input Schema

Name	Required	Description
`tool_id`	Yes
`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/5.0

Behavior4/5

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

Adds real context beyond the annotations: calls are subject to current permissions, selected homes, a finite shared budget, exact-read requirements and Stop, and results are durable rather than returned inline. It also explains the idempotentHint in practice, that reusing the request key adopts the same call and never repeats provider work. It does not spell out what side effects the destructive handlers can have, but the permission and budget warnings cover much of that ground.

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?

Four dense sentences, front-loaded with purpose and followed by inputs, constraints and the result path, with no filler. The jargon load ('exact canonical tool', 'selected homes') is high, but each sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, open-world, destructive dispatcher with a nested object and an output schema, the description covers result retrieval and runtime constraints well but omits how work_id is obtained and how a session is admitted or prepared (prepare_studio_session, start_studio_session are siblings). Those are real prerequisites an agent must resolve elsewhere.

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?

The description covers the arguments object, expected catalog version and read-skill hashes, and explains request-key reuse semantics. With schema coverage at 43%, work_id and tool_id are left essentially undocumented in both places, so the description does not fully compensate for the gap. The three parameters that do carry schema descriptions mean it is not starting from zero.

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?

States a specific verb and resource ('Execute an exact canonical tool from get_toolset') and scopes it to an admitted native studio session. It also names the two adjacent tools an agent needs, get_toolset for discovery and read_studio_tool_result for retrieval, so it is distinguishable from the many native.* siblings that do the work directly.

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?

Gives clear context for use: the tool must come from get_toolset, the session must already be admitted, skills must have been read, and the result must be fetched with read_studio_tool_result. It does not say when an agent should skip this dispatcher and call a direct native.* sibling instead, which is the main routing question given the huge sibling list.

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?