Problem
The deterministic maintainer-side intelligence builders are largely orphaned from the MCP surface, so an agent / CLI helping a maintainer can't pull them. In particular, buildMaintainerLaneReport (src/signals/engine.ts) — which synthesizes a repo's lane recommendation in the context of the configured maintainer cut, queue health, config quality, and contributor-intake health — powers the repo-intelligence response but has no MCP tool.
gittensory_get_repo_context deliberately exposes only a subset of repo signals (lane, queueHealth, queueTrends, collisions, configQuality, dataQuality) and does not include the maintainer-lane synthesis (maintainer cut, intake health, the recommendedAction). The per-builder REST routes (/v1/repos/:owner/:repo/maintainer-lane, etc.) were intentionally consolidated away, so MCP is the appropriate surface for this.
Proposal
Add a maintainer-authenticated MCP tool gittensory_get_maintainer_lane that serves buildMaintainerLaneReport over MCP — advisory only, no write actions — so agents/CLI can read the maintainer's own-lane triage view. This continues the maintainer-side MCP tool series and is the natural sibling of the already-merged noise tool.
Technical detail
Mirror the established, merged pattern (see prior art below): a thin load-or-compute service (src/services/maintainer-lane.ts) that loads the repo's cached signals (getRepository / listIssueSignalSample / listOpenPullRequests / listRecentMergedPullRequests), builds the collision report, and runs the existing deterministic builder; plus the server.registerTool registration + an output schema + a getMaintainerLane method gated by the existing requireRepoAccess. Output flows through the existing redactSensitiveForMcp wrapper. MCP-tool-only — no new REST route (avoids re-adding a consolidated-away surface), no DB migration, no auth-policy change.
Acceptance
- New
gittensory_get_maintainer_lane tool with an output schema, listed in tools/list.
- Service unit test + an MCP call-test + the tool-list assertion; ≥97% patch coverage (lines and branches) on the new
src/** lines.
npm run test:ci green; no migration / auth / route changes.
Prior art / references
Note: filed as a design/tracking record for the implementation; issueDiscoveryPolicy here is discouraged, so this is documentation for an already-prepared change rather than open issue-discovery work.
Problem
The deterministic maintainer-side intelligence builders are largely orphaned from the MCP surface, so an agent / CLI helping a maintainer can't pull them. In particular,
buildMaintainerLaneReport(src/signals/engine.ts) — which synthesizes a repo's lane recommendation in the context of the configured maintainer cut, queue health, config quality, and contributor-intake health — powers the repo-intelligence response but has no MCP tool.gittensory_get_repo_contextdeliberately exposes only a subset of repo signals (lane,queueHealth,queueTrends,collisions,configQuality,dataQuality) and does not include the maintainer-lane synthesis (maintainer cut, intake health, therecommendedAction). The per-builder REST routes (/v1/repos/:owner/:repo/maintainer-lane, etc.) were intentionally consolidated away, so MCP is the appropriate surface for this.Proposal
Add a maintainer-authenticated MCP tool
gittensory_get_maintainer_lanethat servesbuildMaintainerLaneReportover MCP — advisory only, no write actions — so agents/CLI can read the maintainer's own-lane triage view. This continues the maintainer-side MCP tool series and is the natural sibling of the already-merged noise tool.Technical detail
Mirror the established, merged pattern (see prior art below): a thin load-or-compute service (
src/services/maintainer-lane.ts) that loads the repo's cached signals (getRepository/listIssueSignalSample/listOpenPullRequests/listRecentMergedPullRequests), builds the collision report, and runs the existing deterministic builder; plus theserver.registerToolregistration + an output schema + agetMaintainerLanemethod gated by the existingrequireRepoAccess. Output flows through the existingredactSensitiveForMcpwrapper. MCP-tool-only — no new REST route (avoids re-adding a consolidated-away surface), no DB migration, no auth-policy change.Acceptance
gittensory_get_maintainer_lanetool with an output schema, listed intools/list.src/**lines.npm run test:cigreen; no migration / auth / route changes.Prior art / references
feat(mcp): expose maintainer queue-noise triage via gittensory_get_maintainer_noise(merged) — the immediately-preceding tool in this maintainer-side MCP series;buildMaintainerNoiseReportgot its MCP surface there, and this issue does the same forbuildMaintainerLaneReport.feat(mcp): expose outcome calibration via gittensory_get_outcome_calibration(merged) — the canonical service + tool + output-schema blessed pattern this follows.feat(agent): automation controls surface (dashboard + CLI + MCP)(closed) — the broader agent/MCP-surfaces lineage.