Off Shoring MCP

Get story context

get_story_context

Retrieve a story’s current branch, characters, scene setup, summaries, revision, and a bounded turn window for inspection; optionally include incomplete turns without changing saved state.

Instructions

Return the selected branch, character assignments, stored profiles, scene setup, summaries, the story revision, and a bounded window of turns. By default the window contains only completed turns; set include_incomplete=true to also see drafts, cancellations and failures. The window reports truncation flags and a cursor for older turns. Read-only: it never changes saved state.

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>"
    },
    "name": "get_story_context"
  }
}

Input Schema

Name	Required	Description	Default
`story_id`	Yes
`branch_id`	No
`full_text`	No
`turn_limit`	No
`before_cursor`	No
`include_incomplete`	No

Output Schema

Name	Required	Description
`ok`	No
`setup`	Yes
`title`	Yes
`turns`	Yes
`window`	Yes
`branches`	Yes
`profiles`	Yes
`revision`	Yes
`story_id`	Yes
`summaries`	Yes
`user_role`	Yes	Character the user plays. Stored assignment, not behaviour.
`created_at`	Yes
`updated_at`	Yes
`active_branch`	Yes
`assistant_role`	Yes	Character the assistant plays. Stored assignment, not behaviour.
`saved_state_note`	Yes	Reminder that this is stored scene state. Dialogue that was only spoken in the client's conversation and never passed to append_turn is not in this result.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full safety burden and does it well: 'Read-only: it never changes saved state' states the side-effect profile plainly. It also discloses default filtering of incomplete turns, the existence of truncation flags, and a cursor for paging backwards, though it says nothing about authorization needs or failure 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?

Four tight sentences, front-loaded with the payload inventory before the option and paging details. Every clause carries information; nothing is restated from the title.

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?

Return values need not be spelled out since an output schema exists, and the description still previews the shape usefully. The remaining shortfall is parameter-level: full_text and turn_limit are undocumented despite zero schema descriptions, which matters for a six-parameter read tool.

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 0% across six parameters, so the description must compensate and only partly does. It explains the include_incomplete toggle and implies the window bound, cursor, and branch selection, but never names turn_limit or before_cursor and gives no explanation of full_text at all — a real, silent gap for a caller who needs full turn bodies.

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 opens with a concrete verb ('Return') and enumerates exactly what comes back: branch, character assignments, profiles, scene setup, summaries, revision, and a bounded turn window. That makes it clearly distinguishable from list-oriented siblings, but it never explicitly contrasts itself with read_turns or select_branch, which also surface branch/turn data.

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 gives one explicit usage rule — 'set include_incomplete=true to also see drafts, cancellations and failures' — which a caller can act on directly. However, it offers no guidance on when to reach for this aggregate context call versus read_turns, export_story, or select_branch, and no prerequisites are stated.

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

Deploy Server