QuestionPunk

Studio Use Edited Version

studio_use_edited_version

Save a Studio board as a new revision of the production candidate or tested concept it was opened from. The old revision and everything tested or published from it stay unchanged; the new one starts unreviewed. An unchanged board returns its latest revision. Spends nothing.

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": {
      "designProjectId": "<designProjectId>"
    },
    "name": "studio_use_edited_version"
  }
}

Input Schema

Name	Required	Description	Default
`designProjectId`	Yes	The Studio board (design project) the edits were made on

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The description adds real behavior beyond the annotations: the old revision and anything tested or published from it are preserved, the new revision starts unreviewed, and an unchanged board returns its existing latest revision rather than creating one. 'Spends nothing' is a useful cost/quota disclosure absent from the annotations. The unchanged-board short-circuit sits in mild tension with idempotentHint=false, but it is scoped to unchanged boards rather than a genuine contradiction.

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?

Three short sentences, each carrying a distinct fact: the operation, the preservation guarantee plus resulting state, and the no-op/cost behavior. The purpose is front-loaded and nothing is filler.

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?

With an output schema present, return shape need not be described, and the description covers the mutation's blast radius, resulting state, and cost. It could go further on prerequisites (the board must originate from a candidate) and on permissions, but it is otherwise sufficient for correct invocation.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains that designProjectId identifies the Studio board the edits were made on. The description never mentions the parameter, so it adds nothing beyond the schema baseline.

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 states a specific verb and resource chain: save a Studio board as a new revision of the production candidate or tested concept it was opened from. That is precise and would let an agent identify the operation without opening the schema. No sibling in the provided list performs this operation, so there is nothing to differentiate against, which is the only thing keeping this from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer that this is called after editing a board to promote those edits while preserving the tested revision. There is no explicit when-to-use, when-not-to-use, or named alternative, and no stated prerequisite such as the board having been opened from a candidate.

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

All QuestionPunk 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?