Skip to main content
Glama
Sign In
musterd

musterd

Official
by musterd-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

lane_resolve

Mark a lane done to clear warnings, release its surface, and optionally attest a landed merge with PR, SHA, and authorizer for the audit log.

Instructions

Mark a lane done — clears its warnings and releases its surface. If its branch landed, attest the merge: pass pr, sha, and authorized_by so the audit log joins your seat to the landed SHA and the authorizing human. Landed without a PR? Omit pr and pass sha alone. Closing someone else's lane? The worker's own lane_submit stamp stands and your flags are ignored (ADR 305); pass them only when the lane has no attestation yet, which then records yours. Prefer lane_submit (ADR 192): a self-close records unconfirmed unless acceptance-exempt.

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": {
      "id": "<id>"
    },
    "name": "lane_resolve"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYeslane id
prNolanded PR number; omit for a local merge
shaNosquash-merge SHA on main
follows_upNo
read_verdictNo
authorized_byNothe human whose authority the merge ran under

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses side effects (warnings cleared, surface released), the ADR 305 rule that a worker's own lane_submit stamp wins and your flags are silently ignored, and the consequence that a self-close records 'unconfirmed'. It stops short of stating permissions required, failure modes, or what the call returns.

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?

The core action is front-loaded and each subsequent sentence introduces a distinct rule (attestation, local merge, foreign lane, sibling preference) rather than restating. It is dense with ADR references and domain jargon, which costs a point but no sentence is filler.

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?

For a mutation tool with no annotations and no output schema, this covers effects, precedence rules, and the preferred alternative well. The remaining gaps are the two undescribed parameters and the absence of any statement about the resulting lane state or error behavior.

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

Parameters4/5

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

Schema coverage is 67%, and the description genuinely adds meaning beyond the schema for pr, sha, and authorized_by — explaining that they join the audit log to the landed SHA and the authorizing human, and the omit-pr-for-local-merge rule. However, follows_up and read_verdict are documented in neither the schema nor the description, leaving two of six parameters opaque.

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?

The opening clause states a specific verb and resource — 'Mark a lane done' — and immediately scopes it with the effects 'clears its warnings and releases its surface'. It also names a sibling (lane_submit) as the preferred path, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditional routing rather than a generic blurb: use lane_submit per ADR 192 for self-close, use this tool with pr+sha+authorized_by when a branch landed with a PR, omit pr for a local merge, and pass flags only when the lane lacks an attestation. Exclusion cases (closing someone else's lane, flags already stamped) are spelled out explicitly.

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

Deploy Server

Other Tools