Skip to main content
Glama

get_resolution_context

Resolve live code collisions by retrieving peer code, recorded decisions, and resolution policies to adapt your edit and avoid conflicts.

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?

With no annotations, the description carries the full behavioral disclosure. It explains the tool returns peerSnippet, decisions, and a guardrail policy, and explicitly states it is 'advisory and proactive (no lock)' and does not modify state. This provides strong transparency, though it could mention potential side effects or resource usage.

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 front-loaded with purpose and usage, and each sentence contributes meaning. However, it is somewhat lengthy with a bullet list and repeated emphasis on policy; a slightly tighter structure would improve conciseness.

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 complexity (8 params, nested objects, no output schema), the description covers the tool's trigger, return values, and behavioral policy thoroughly. It lacks explicit output format details but compensates with detailed guardrail instructions and context for agent decision-making.

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?

The input schema has 100% coverage with descriptions for all 8 parameters. The tool description adds context for how the returned guardrail guides parameter usage, but does not significantly enhance individual parameter meanings beyond the schema. Baseline 3 is appropriate.

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 resolves live code collisions with a peer, specifying the verb 'resolve' and the resource 'code collision with a peer'. It contrasts with sibling tools like 'detect_intent_conflicts' and 'arbiter_resolve', making its unique role evident.

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?

The description explicitly tells when to call the tool (when a Stop hook collision report surfaces a live peer) and advises it's proactive and advisory. While it doesn't list alternatives or when not to use, the context is sufficiently clear for an agent to select this tool over others.

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/kawacode-ai/kawa.mcp'

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