Off Shoring MCP

Select branch

select_branch

Sets and persists the active branch for a story so later reads and writes default to that branch; requires expected_revision for concurrency checks.

Instructions

Persist which branch is active for a story, so later reads and writes default to it. Requires expected_revision. Nothing about the branches themselves changes.

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>",
      "branch_id": "<branch_id>",
      "expected_revision": "<expected_revision>"
    },
    "name": "select_branch"
  }
}

Input Schema

Name	Required	Description	Default
`story_id`	Yes
`branch_id`	Yes
`expected_revision`	Yes

Output Schema

Name	Required	Description	Default
`ok`	No
`revision`	Yes
`story_id`	Yes
`active_branch`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations present, the description carries the full burden. It usefully discloses that this is a state-mutating persistence operation, that it requires expected_revision (implying optimistic concurrency), and that branch data itself is untouched — a meaningful scoping statement. It omits what happens on a revision mismatch, whether the call is idempotent, and any permission requirements.

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?

Two tight sentences with no filler, and the core effect on subsequent reads/writes is front-loaded. Every clause carries 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?

The output schema is present, so return values need not be described. However, for a three-parameter mutation with zero annotation coverage, the definition leaves notable gaps: the meaning and provenance of expected_revision and the failure mode on revision conflict.

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 three required parameters, so the description must compensate and largely does not. It names expected_revision and asserts it is required, but never explains that it is a concurrency token or where an agent obtains it, and story_id and branch_id receive no clarification at all.

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 gives a specific verb and resource ('Persist which branch is active for a story') plus the downstream effect ('later reads and writes default to it'). The clause 'Nothing about the branches themselves changes' implicitly separates it from the mutating sibling branch_story, though no sibling is named explicitly.

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?

It conveys the use case (making a branch the default for subsequent operations) but offers no explicit when-to-use versus when-not guidance and no reference to the alternative tools in the family. The requirement of expected_revision is stated, but not the condition under which selection should be made or avoided.

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

Deploy Server