tower-mcp

claim_intent

Register intent to edit code before editing and get collisions with other active agents up front. Track declarations you read so signature changes are surfaced.

Instructions

Register intent to edit code BEFORE editing. Returns any collisions with other active agents. Call this first, always. Also pass reads: the declarations you consulted to write this — the functions, methods or types you are calling or implementing against. Tower tells you when one of them changes under you, and shows the old and new signature so you can patch your call sites without re-reading the file. If you are changing a symbol's signature, set declares on it to the new declaration as it will read in the source, up to the body (e.g. function verify(token: string, opts: Opts): boolean): agents whose work reads it are handed that contract immediately and can code against it in parallel instead of waiting for you. If the claim is refused, the response carries alternatives: what to avoid, and advice. Don't stop — work outside avoid; Tower messages you when it frees up.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repo`	Yes
`files`	No
`force`	No
`reads`	No
`branch`	Yes
`repoId`	No
`agentId`	Yes
`purpose`	No
`symbols`	No
`projectId`	No
`etaMinutes`	No

Output Schema

TableJSON Schema

Name	Required	Default
`claimId`	Yes
`blocking`	No
`conflicts`	Yes
`alternatives`	No
`projectWarning`	No
`recommendation`	No	proceed
`unreadMessages`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

No annotations, so the description carries the full burden and does so well: it discloses collision reporting, that Tower notifies on read changes and shows old/new signatures, that `declares` hands a contract to parallel agents, and the refusal response shape (`alternatives`, `avoid`). It omits auth/permission and rate-limit behavior, keeping it from a 5.

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?

Front-loaded with the core action and effect, then elaborates on reads/declares/refusal. It is a long single paragraph, but nearly every sentence conveys actionable behavior rather than filler.

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 no explanation, and the collision/refusal behavior is described. However, for an 11-parameter tool with 0% schema documentation, the roles of `files` vs `symbols`, `force`, and `etaMinutes` are left to inference, leaving gaps an agent must still resolve.

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 11 parameters, so the description must compensate. It explains the subtle `reads` and `declares` semantics well (including example syntax), but leaves central parameters like `files`, `force`, `purpose`, `etaMinutes`, `repoId`, and `projectId` entirely undocumented. Partial compensation for a large parameter surface.

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 ('Register intent to edit code') and its primary effect ('Returns any collisions with other active agents'). The intent is unambiguous and distinguishable from adjacent siblings like release_claim or propose_intent. It stops short of explicitly naming the sibling it differs from, so it lands at 4 rather than 5.

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?

Strong temporal directive: 'Register intent to edit code BEFORE editing' and 'Call this first, always.' It also gives an explicit fallback path for refusal ('work outside avoid; Tower messages you when it frees up'). It does not name alternative tools (e.g. record_reads vs the reads param), so it is clear context without explicit tool alternatives.

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