studio_waitPause processing for up to 10 seconds without replaying input, invalidating the current token so you can observe the Insta360 Studio app before sending the next action.
Wait up to ten seconds without replaying input. Invalidates token; observe before input.
| Name | Required | Description | Default |
|---|---|---|---|
| milliseconds | No |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the 10-second ceiling and a token-invalidation side effect, but "Invalidates token" is never explained and sits in uneasy tension with readOnlyHint — an agent cannot tell what token, what breaks after it is invalidated, or whether prior observations must be redone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Only two short sentences, with the duration limit front-loaded. Nothing is padded, but the density is achieved by eliding meaning rather than by precision — the second sentence packs two unexplained concepts into seven words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single-parameter, no-output-schema tool should be fully describable, yet an agent still lacks the default value, the token semantics, and any differentiation from `studio_wait_ready`. The description is too thin for the ambiguity its own jargon introduces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single `milliseconds` parameter, so the description must carry the load. It conveys the upper bound (ten seconds) implicitly but never names the parameter, never states the 1000 ms default, and never explains what a value of 0 or a mid-range value does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb and effect ("Wait up to ten seconds") are concrete, but the two qualifiers ("without replaying input", "invalidates token") are jargon that an agent cannot resolve without inside knowledge. Nothing distinguishes it from the near-identically named sibling `studio_wait_ready`, so an agent cannot tell the two waits apart from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Observe before input" is the only sequencing hint, and it is oblique — it implies a wait should be followed by an observation, but never states the condition for calling this tool. There is no guidance on when to prefer it over `studio_wait_ready` or `studio_status`, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.