Siren

studio_edit

Change a Studio video by asking, as the human would in the chat. Only what the ask names changes; Siren replies with what it changed (before and after) and the new version number. Waits up to about 25 seconds for the reply. No credits are spent until studio_export. A greeting or a question gets an answer and no new version.

Input Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	The change, in plain words: "shorter hook", "show the timer first", "use our orange", "make it vertical". May be empty when attachments say it all.
`thread_id`	Yes	The thread id from studio_start or studio_threads.
`attachments`	No	Optional files to use: URLs from upload_media (a screenshot to show, a logo to put in, a reference). Up to 6.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

addedInput schema / properties / attachments

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional files to use: URLs from upload_media (a screenshot to show, a logo to put in, a reference). Up to 6."
+}

changedInput schema / properties / text / description

Previous value: -"The change, in plain words: \"shorter hook\", \"show the timer first\", \"use our orange\", \"make it vertical\"."New value: +"The change, in plain words: \"shorter hook\", \"show the timer first\", \"use our orange\", \"make it vertical\". May be empty when attachments say it all."

AddedOct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing a ~25-second wait for the reply, the cost model (no credits until studio_export), the mutation scope ('only what the ask names changes'), and the no-op case for greetings/questions. These are exactly the runtime traits an agent needs and none are in the structured fields.

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

Conciseness5/5

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

Four short sentences, front-loaded with the core action before the behavioral caveats. Every sentence carries a distinct fact (scope, return, latency, billing, no-op case) with no filler.

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 non-idempotent, open-world mutation tool taking a thread id and natural-language text, the description covers scope of change, latency, cost timing, and the trivial-input case. Nothing needed to invoke it correctly is missing.

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?

Schema coverage is 100%, so the schema already explains thread_id, text, and attachments in detail. The description's 'only what the ask names changes' reinforces the text semantics but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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+resource ('Change a Studio video') and the modality ('by asking, as the human would in the chat'). It also names the sibling it interacts with ('No credits are spent until studio_export'), so an agent can separate editing from exporting without opening another schema.

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?

The conversational-ask framing and the note that a greeting/question yields an answer with no new version clearly delimit acceptable input. It does not explicitly say when to prefer studio_start or studio_get instead, so it stops short of full alternative routing.

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

All Siren 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.