Skip to main content
Glama

get_resolution_context

Get peer code and resolution guardrails for live code collisions to adapt your edit and avoid overwriting peer work.

Instructions

Resolve a live code collision with a peer BEFORE you write (Layer C resolution handoff).

Call this when the Stop hook's collision report (or complete_intent's resolution_required gate) surfaced a live peer (a teammate or AI agent editing the same lines). Pass that collision's uid as peerUid and its overlapping ranges. You get back:

  • peerSnippet — the peer's actual (decrypted) code at the overlapping lines, so you can see what they wrote.

  • decisions — recorded reasoning attached to this file (region context).

  • guardrail — the policy you must follow when resolving: • Never overwrite a peer's COMMITTED work — yield or merge. Only override an uncommitted live diff, and only with a recorded rationale. • Your resolution is an ordinary git edit (revert/diff is the undo) — stay in your own working tree; build no bespoke undo. • Before completing, record_decision(type=fork|tradeoff, …) explaining how you resolved (and supersedes the peer's decision if you overrode it). • Choose or synthesize ONE coherent result — never blindly interleave both diffs.

This is advisory and proactive (no lock). Use it to adapt your edit and avoid the conflict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rangesYesOverlapping [start, end] line ranges (from the collision) to fetch the peer code for.
peerUidYesThe peer HAI whose live edits overlap — the `uid` of a collision from the Stop hook collision report.
filePathYesPath to the file being edited (relative to repoPath)
intentIdNoActive intent ID (advisory). Auto-detected by Kawa Code when omitted.
repoPathYesLocal path to the repository root
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It details the return values (peerSnippet, decisions, guardrail) and lists behavioral policies (advisory, no lock). While it doesn't explicitly state side effects or idempotency, the description is sufficiently transparent about the tool's non-mutating, advisory nature.

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 description is lengthy but well-structured: it starts with a one-line purpose, then a usage condition, followed by bullet points for return values and guardrail rules. Although some redundancy exists (e.g., repeating 'advisory'), it is organized and front-loaded.

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?

Given the tool's complexity (8 parameters, nested objects, no output schema) and rich context of sibling tools, the description covers the essential aspects: when to call, what it returns, and behavioral policies. It lacks an explicit return type description, but the narrative explains the return fields. Overall, it is sufficiently complete for an AI agent to use the tool correctly.

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?

All parameters have descriptions in the input schema (100% coverage). The tool description adds contextual meaning beyond the schema, e.g., explaining that peerUid comes from a collision report, and that ranges are overlapping line ranges. It also clarifies optional parameters like forkAuthor and workspaceId, stating they are usually auto-detected.

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 description clearly states the tool's purpose: to resolve a live code collision with a peer before writing. It specifies the triggering condition (Stop hook collision report) and the outcome (peer snippet, decisions, guardrail). This distinguishes it from sibling tools like arbiter_resolve or record_decision.

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?

The description explicitly states when to call the tool: when a collision report surfaces a live peer. It also provides clear prohibitions (never overwrite committed work, stay in own working tree) and references related tools (record_decision). This gives unambiguous guidance on usage and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodeAwareness/kawa.mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server