Skip to main content
Glama

EasyTerritory MCP

extract_tal_branch

[Tier 1 — Delegation Extract] When: senior planner sends a regional subtree to a delegate for bounded editing. Prerequisites: master TS with hierarchical TAL; branch rollup or path identified. Next: store branch extract + branch_metadata; delegate opens MC on extract only. Scenarios: DL-001, DL-002.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tsNo
tal_idYes
ts_handleNo
delegate_refNo
exclude_lockedNo
map_session_idNo
guidance_handleNo
expected_revisionNo
branch_territory_pathNo
expected_content_hashNo
branch_rollup_territory_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and mostly does not. It implies isolation ('delegate opens MC on extract only') but never says whether extraction mutates or locks the source TS, what the returned extract contains relative to branch_metadata, or how exclude_locked/handles affect behavior. 11 parameters with 0% schema coverage make this a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Telegraphic and front-loaded: the tier tag, When, Prerequisites and Next are laid out in order with no filler sentences. It is dense with domain jargon rather than purely concise, but every clause carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 explained, but for a delegation/mutation-prone tool with no annotations, 11 undocumented parameters, and handle-based session state, the description omits too much: source-object side effects, what a valid delegate_ref is, and how the handles interact.

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?

Eleven parameters at 0% schema description coverage, and the description explains almost none of them. 'Branch rollup or path identified' loosely maps to branch_rollup_territory_id and branch_territory_path, and 'master TS' to ts/ts_handle, but delegate_ref, map_session_id, guidance_handle, expected_revision and expected_content_hash get no meaning 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?

States a specific verb+resource ('extract' a TAL branch) and frames it as a Tier 1 delegation extraction of a regional subtree for bounded editing, which lets an agent place it in the workflow. However, the obvious counterpart/reverse operation (reintegrate_branch) is never named, so sibling differentiation relies on the agent inferring it from the tier label.

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 When ('senior planner sends a regional subtree to a delegate'), Prerequisites (master TS with hierarchical TAL; branch rollup or path identified) and Next step (store extract + branch_metadata, delegate opens MC on extract only). It is a real when-to-use block, but no when-not-to-use or named alternative is offered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources