Off Shoring MCP

Branch story

branch_story

Fork a story at a chosen turn to create a new branch with history only up to that point, leaving the source branch unchanged—use it for regeneration or revision without overwriting the original.

Instructions

Fork the story at a turn, creating a new branch that inherits history only up to that fork point. Nothing is copied or erased: the source branch is left exactly as it was, and later source turns do not appear on the new branch. Use this for a regeneration or a revision instead of overwriting an original turn.

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": {
      "story_id": "<story_id>",
      "fork_turn_id": "<fork_turn_id>",
      "expected_revision": "<expected_revision>"
    },
    "name": "branch_story"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`select`	No
`story_id`	Yes
`fork_turn_id`	Yes
`from_branch_id`	No
`idempotency_key`	No
`expected_revision`	Yes

Output Schema

Name	Required	Description
`ok`	No
`note`	Yes	The source branch is unchanged by a fork.
`branch`	Yes
`revision`	Yes
`selected`	Yes
`story_id`	Yes
`fork_turn_id`	Yes
`source_branch_id`	Yes
`idempotent_replay`	No	True when this result was replayed from an earlier identical call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the key trait: the fork is non-destructive ("Nothing is copied or erased: the source branch is left exactly as it was") and history-isolated on the new branch. However, it says nothing about what happens when expected_revision is stale, whether the call can conflict or fail, or how idempotency_key and select/name affect behavior.

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 tight sentences: the fork semantics come first, the non-destructive guarantee second, and the intended use case last. No redundant restatement of the name or title, and every clause adds 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?

An output schema exists, so return values need not be described, and the core fork semantics are covered. But for a 7-parameter mutation with zero schema descriptions and no annotations, omitting guidance on expected_revision conflicts and idempotency leaves real gaps an agent must guess at when invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. It only indirectly implies fork_turn_id ("at a turn"); expected_revision, idempotency_key, select, name, and from_branch_id receive no explanation of meaning or constraints despite concurrency and idempotency being non-obvious semantics.

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 ("Fork the story at a turn") plus the resulting object ("a new branch"), and the scope of the new branch's history is defined precisely. This is clearly distinguishable from siblings like create_story or append_turn, which do not fork existing history.

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 an explicit use case: "Use this for a regeneration or a revision instead of overwriting an original turn," which tells the agent when to prefer branching over in-place editing. It stops short of naming the alternative sibling tools (update_story / append_turn) or stating when branching is not appropriate.

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

Deploy Server