Integrates with GitHub CLI to fetch pull request descriptions, review comments, and issue discussions for richer data tiers in context retrieval.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kawa Code MCP what are my teammates currently editing?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Team-aware memory for AI coding assistants. Track intent, record decisions, and see when a teammate is editing the same code — in real time, before commit.
@kawacode/mcp is the official Model Context Protocol (MCP) server for Kawa Code. It lets Claude Code, Cursor, and any MCP-compatible AI assistant:
Remember what you're working on across sessions, branches, and machines — no more re-explaining the architecture every morning.
Surface team conflicts before they happen — know when a teammate is editing the same file or function in their working copy right now, before either of you commits.
Capture architectural decisions with their reasoning — future you (and future AI sessions) inherit the team's accumulated context instead of relitigating choices.
Link commits to intent automatically — every commit gets the why attached, not just the diff.
Node.js >= 18.0.0 — runtime for the MCP server
Kawa Code desktop app running — kawa.mcp is a thin MCP-to-IPC adapter; all git operations, storage, and API communication happen in Kawa Code
Anthropic API key — your own Claude API key, passed as a parameter to the inference tools
GitHub CLI (gh) — enables richer data tiers (PR descriptions, review comments, issue discussions). Without gh, tiers 2 and 4 are skipped automatically
Related MCP server: Projectmem
Add the MCP in your AI configuration, for example on Claude Code:
claude mcp add -s user kawa-intents -- npx -y @kawacode/mcp
For Cursor AI, install the MCP with npm install -g @kawacode/mcp and add it to ~/.cursor/mcp.json.
{
"mcpServers": {
"kawa-intents": {
"command": "kawacode-mcp"
}
}
}Note that the MCP will not be automatically updated to future versions in this scenario.
To upgrade to a newer release, run npm update -g @kawacode/mcp.
For the project you want Kawa Code to run on, create a .mcp.json file in your project root (recommended for teams — commit it to git):
{
"mcpServers": {
"kawa-intents": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@kawacode/mcp"]
}
}
}The MCP server works together with the Kawa Code application, Kawa Code IDE extensions, and AI code generators such as Cursor AI and Claude Code.
Retired 2026-08-14. Do not wire this up. Kawa Code no longer installs it, and the setup wizard no longer asks for it.
This hook fired before every Edit/Write and surfaced prior reasoning attached to the file being changed. It was retired because its retrieval could not reach the decisions that mattered: it read only the most recently updated 100 decisions per repository, and architectural constraints — precisely what it existed to surface — are written once and then age out of a recency window permanently. On one of our own repositories, 160 decisions were of the surfaced types and only 17 were still inside that window.
If you already installed it, nothing breaks. The kawacode-on-pre-edit binary still ships, and an existing entry in your settings.json keeps working. Kawa Code will not remove it for you — delete it yourself if you want it off:
"PreToolUse": [ { "matcher": "Edit|Write", "hooks": [ … ] } ]Nothing is lost on team coordination. The live collision signal moved to the Stop hook some time ago, and that is now the only edit-level coordination surface. It reports teammates whose in-progress, uncommitted edits overlap the lines you touched this turn — conflict detection before a merge conflict can exist. See Team conflict detection.
Real-time team conflict detection — see when a teammate is editing the same files or lines in their working copy, before either of you commits. Most version-control tooling shows you this after the merge conflict; Kawa shows you before. Kawa can also judge an overlap and apply the safe tier of merge for you — though that write only happens in an agent-owned worktree.
Cross-session AI memory — your AI assistant picks up where it left off across days, branches, and machines. No re-explaining the architecture every morning.
Decision history with reasoning — record forks, trade-offs, and abandoned approaches with their why. Future sessions and teammates inherit the context instead of re-deriving it.
Commit ↔ intent linkage — every commit is automatically associated with the intent that drove it. git log shows what changed; Kawa shows why.
Smart context retrieval — relevance-based loading; only what the current task needs.
Zero-knowledge encryption — code blocks encrypted client-side before sync. The Kawa cloud cannot decrypt your team's code.
Cross-platform — works with Claude Code, Cursor, and any MCP-compatible AI assistant.
Kawa Code is built for more than one worker on a repository at a time — that's what the conflict detection is for. If those workers are AI agents you're running yourself, give each one its own git worktree. Agents sharing a single checkout overwrite each other's edits with no conflict marker and no git history: nothing is committed between the two writes, so nothing notices.
In Claude Code, background sessions already require a worktree — worktree.bgIsolation defaults to "worktree", which blocks edits to the main checkout until the session enters one. You only need to touch it if a project has explicitly opted out with "none". Subagents take isolation: "worktree" per spawn.
Two settings are worth tuning, because the defaults surprise people:
{
"worktree": {
"baseRef": "head",
"symlinkDirectories": ["node_modules", "target"]
}
}baseRef — defaults to "fresh", which branches from origin/<default-branch>. If you work on unpushed commits, set "head" to branch from your local HEAD instead. Either way this is a commit boundary: uncommitted working-tree changes don't travel into a new worktree, so land your work before spawning agents that need it.
symlinkDirectories — nothing is symlinked unless you say so, so every worktree gets its own copy of whatever you leave out. Symlink dependency directories freely: node_modules is the same content for every worktree, and sharing it costs nothing. Do not symlink compiled-language build output — target/, build/, obj/. Those tools name artifacts deterministically from the crate/module and its inputs, without encoding which checkout they came from, so two worktrees building into one directory write the same filenames and silently overwrite each other. The symptom is the dangerous part: your suite goes green while running another checkout's binaries. Only a test that resolves a path baked in at compile time (Rust's env!("CARGO_MANIFEST_DIR"), include_str!, or an equivalent) will notice; everything else passes. If a suite ever looks suspiciously green after another checkout built in the same place, clean the build directory and re-run before believing it.
Because compiled build directories can't be shared, they multiply — one per worktree, each growing independently, and they get large enough to matter (a mature Rust target/ reaches hundreds of gigabytes). Two things keep that affordable, and they solve different halves:
Speed — a compiler cache such as sccache is safe across worktrees precisely because it caches results keyed by input hash rather than sharing an output directory.
Disk — prune periodically. For Rust, cargo-sweep removes stale artifacts by age or to a size cap; wire it into whatever cadence fits your setup — after merging a worktree back is a natural trigger. One caveat worth knowing before you rely on it: sweeping only reclaims artifacts the build tool still tracks. If that index has been lost, the leftovers are orphaned and a sweep reports nothing to do no matter the flags — a full clean is the only thing that reclaims them.
Isolation alone would just give you several agents doing overlapping work in private. Kawa's job is the coordination on top.
Each agent session gets its own identity, and intents are tracked per session — so several intents can be active on one repository at once, each with its own current focus, without a lock and without agents clobbering each other's context. From there the normal machinery applies across agents exactly as it does across teammates: get_relevant_context surfaces what the other agents have already decided, create_and_activate_intent reports a conflict when new work overlaps something already in flight, and the pre-edit check fires on reasoning any of them recorded.
The practical result: your agents inherit each other's decisions instead of re-deriving them, and you find out about overlapping work while it's still cheap to redirect — not at merge time.
Kawa can do more than report an overlap — arbiter_resolve judges each one, and arbiter_apply will write the safe tier of merge for you. That write is deliberately gated:
arbiter_applywrites only in an agent-owned worktree. On a human checkout — or when a peer holds the file-set lock — it stays suggest-only.
This is the sharpest practical reason to put agents in worktrees. Run them on a shared checkout and auto-resolution silently never engages; you get the conflict surfaced and nothing else, with no error to tell you a capability was switched off. The guardrail is intentional — Kawa won't rewrite a human's working tree underneath them — but it does mean the setup decides whether half the feature is available.
Because the reasoning behind your work — your intents and recorded decisions — lives in Kawa Code rather than in the chat log, a teammate can pick up where you left off from a single prompt. No transcript sharing, no session restore.
Commit or push your code first. A handoff prompt carries your reasoning, not your uncommitted working tree — so land the code (or publish the pre-commit diff) before you hand off, otherwise your teammate inherits the decisions without the diff that goes with them.
Grab the intent id. The id of the intent you were working under — your agent can read it back with check_active_intent, or you can find it in the Kawa Code app.
Hand over a one-line prompt, e.g. Follow up on intent <intent-id>: <what's left to do>.
Your teammate pastes it into a fresh session. Their agent calls resume_intent(<id>) — one call that adopts the intent as their current focus and loads its recorded decisions — resuming the thread with full context, even though it never saw your chat.
What transfers: the intent, its decisions, and (once committed) its code. What doesn't: your chat transcript and any session-local state. An acknowledgment you made to a pre-edit block is your judgment in your session, so your teammate re-evaluates it rather than inheriting it — which is what you want.
Teams: to make the handoff seamless, add one line to your shared CLAUDE.md so the agent always treats a follow-up prompt as resuming the named intent instead of opening a new one:
When a prompt says "follow up on intent
<id>" (or similar), callresume_intent(<id>)to adopt that intent and load its decisions — do not create a new intent for it.
When you port a codebase to a new language or rebuild it in a fresh repository, the code moves — but the reasoning usually doesn't. The source repo's decision history knows why retired approaches were retired, which constraints are load-bearing, and where the security landmines are. With Kawa Code, that history becomes a first-class migration input.
Decisions are scoped per repository, so the new repo won't surface the old repo's history automatically. Transplant them slice by slice as you port — this is the recall-transplant workflow:
Recall before porting each slice. Call get_relevant_context against the source repo with a description of the subsystem you're about to port (name its key files). This surfaces the forks, constraints, trade-offs, and discoveries that shaped it.
Expand what matters. Recall returns summaries — call get_decision_detail on the load-bearing hits for the full rationale and consequences.
Classify: stack-portable vs stack-bound. Domain truths port: protocol contracts, cost/scale rationale, security discoveries, "we tried X and retired it" warnings. Mechanics of the old stack don't: build-tooling quirks, runtime workarounds, library-specific fixes. Only the portable ones move.
Re-record the portable ones in the target repo with record_decision, citing provenance in the summary or rationale (e.g. [transplanted from <source-repo> <decision-id>]). Merge decisions that form one lineage into a single record.
Let the transplants shape the port and its tests. A transplanted durability rationale should become a test that proves the property survived the rewrite; a retired-approach warning should stop the new stack from reintroducing it.
The payoff compounds: the port doesn't re-litigate settled arguments or faithfully reproduce old bugs, negative knowledge survives even though the code that motivated it was deleted long ago, and at cutover the new repo starts with a curated decision corpus instead of an empty one.
The CLAUDE.md template ships a compact version of this workflow, so agents set up through the Kawa Code welcome flow follow it automatically.
Most Kawa tools run every turn — check the active intent, recall context, record a decision. The operations below are different: you run them rarely, sometimes once per repository. They cost real time and money, and they are not part of the per-turn loop.
infer_historyA brand-new Kawa repo knows nothing about work that predates it. infer_history mines the existing commit history into intents and decisions, so recall has something to draw on from day one. Run it once when you connect a repo with meaningful history; after that it extends incrementally.
It is agent-invoked — ask your assistant, e.g. "Run infer_history with max 3000 commits". There is no button for it in the Kawa Code app.
Always estimate first. The tool defaults to estimateOnly: true, which returns a token/cost preview without running anything. Look at the number, then re-run with estimateOnly: false to actually start. A run is asynchronous — it returns immediately and reports progress in the Kawa Code app — and resumes from where it stopped if interrupted.
Parameter | Default | Purpose |
|
| Preview cost without running. Set |
| resume | How many recent commits to analyze. Omit to continue from the last run. |
| — | Git revspec ( |
|
| Pull in PR/MR descriptions and issue discussions. Needs an authenticated |
|
| Enable when one commit often mixes unrelated changes. |
| — | Per-run cap on stories analyzed. |
| — | Affects the estimate only. The run's model is configured in the Kawa Code app. |
|
| Override the re-run guard — see below. |
The re-run guard. If the repo already has intents and the run can't cleanly resume (missing or unreachable cursor), or HEAD isn't on the default branch, the call stops and returns needsDecision instead of running. That's deliberate: re-running blind duplicates intents. Read the reason, and only pass force: true if it genuinely applies. Prefer running on main/master; force exists for the deliberate feature-branch case.
GitHub and GitLab are both supported; the forge is detected from the remote origin.
Curating decisions into an evolution graph is phase 5 of infer_history, run automatically once the analysis completes. There is no separate step and nothing to invoke.
Earlier versions exposed an
evolve_decisionstool. It has been removed: it required astoriesarray that only ever existed inside the pipeline's own memory, so no assistant could construct a valid call. Nothing is lost — the curation still runs, as part ofinfer_history.
Features group a repo's intents into a browsable catalog. Rebuild it from the Features panel in the Kawa Code app:
Update features — additive. Folds intents that aren't in the catalog yet into the existing features. This is the everyday action.
Rebuild — cold rebuild from scratch, keeping locked features. Use when the catalog has drifted badly.
Progress shows in the app, and the catalog also extends automatically after an infer_history run.
Earlier versions exposed an
update_featuresMCP tool that sent the same request as the Update features button. It has been removed — one button and one tool doing the identical thing meant every session paid for a tool schema it never needed. Press the button instead.
# Watch mode (auto-rebuild on file changes)
npm run dev
# Build TypeScript to JavaScript
npm run build
# Clean build artifacts
npm run clean
# Run the MCP server directly
npm startTo test the MCP server without integrating it into an AI assistant:
Build the project: npm run build
Run the server: npm start
The server communicates via stdio (standard input/output)
You can send MCP protocol messages via stdin to test tool functionality
Use npm run dev to auto-rebuild during development
Check stderr for server logs (stdout is reserved for MCP protocol)
Ensure Kawa Code is running before testing
Claude Code / Cursor AI
↓ MCP Protocol (stdio)
kawa.mcp (this server)
↓ Huginn IPC (Unix socket / Named pipe)
Kawa Code Desktop App
└─ HTTP Client
↓ REST + SSE
Kawa API (cloud)
└─ Team sync & zero-knowledge encryptionContributions are welcome. Please read CONTRIBUTING.md and CLA.md.
This project is source-available under the Kawa Code Source Available License.
You may run and modify the software for personal or internal use.
See LICENSE for details.
Activate an existing intent by ID — sets it as THIS session's current focus.
Use this to:
Switch your current focus to a different intent found via list_team_intents or get_relevant_context
Re-activate an intent that was deactivated (e.g., to complete it)
Resume work on a previously created intent
Resume an "abandoned" intent (see below)
Accepts both cloud IDs (from get_relevant_context / API) and local UUIDs (from list_team_intents).
Multi-active model: activating an intent only moves YOUR session's current pointer. Many intents can be active on a repo at once (one current per session/teammate), so this never blocks on or displaces another session's active intent — there is no lock to take over.
Resuming abandoned intents:
Abandoned intents have their decisions soft-deleted (invisible to recall and get_relevant_context). Activating one transparently restores them — single-intent decisions for this intent get their soft-delete cleared so the prior reasoning becomes visible again. Multi-intent decisions stay visible throughout (they were never soft-deleted).
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The cloud ID (preferred) or local UUID of the existing intent to activate. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Thoroughly explains the multi-active model (no lock, per-session pointer), restoration of soft-deleted decisions for abandoned intents, and acceptance of both cloud IDs and local UUIDs. Also notes automatic resolution of certain parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections and bullet points, front-loaded with main purpose. Every sentence adds value, though slightly longer than necessary. Still efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, and no output schema, the description covers behavior comprehensively: multi-active model, decision restoration, accepted IDs. Missing output behavior, but overall complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining the difference between cloud ID and local UUID for intentId, and that forkAuthor and workspaceId are usually auto-resolved. Provides context on repoOrigin auto-detection, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Activate' and the resource 'existing intent by ID', specifying it sets the intent as the current session's focus. Distinguishes from sibling tools like 'create_and_activate_intent' and 'list_team_intents' by listing specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use the tool: switching focus, re-activating deactivated intents, resuming work, and resuming abandoned intents. Implicitly excludes creation (handled by sibling) and provides context for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve live code overlaps and AUTO-APPLY the safe tier. Kawa judges → adversarially verifies → and, for the trivial tier only (high-confidence single-range merge that passes verify), writes the merge to your worktree, records a decision, and republishes. Writes happen ONLY in an agent-owned worktree (a linked git worktree); on a human checkout — or when a peer holds the file-set lock — it behaves like arbiter_resolve (suggest-only, no writes). Returns per-overlap outcomes { tier, applied, announcement, verifyIssue?, verdict }. Call it when you are ready to incorporate the result, then RE-READ any file it applied to (it changed on disk). For surfaced (not-applied) overlaps, use get_resolution_context to see the peer code and resolve manually.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | No | Active intent ID (advisory; the auto-resolution decision is recorded under it). | |
| overlaps | Yes | The overlaps to resolve — each { peerUid, filePath, ranges } from the Stop collision report. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral aspects: automated verification, writing conditions, return format, and side effects (files changed on disk).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded, but slightly verbose with detailed internal process steps. Every sentence earns its place, but could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very complete for a complex tool with no output schema, describing behavior, conditions, and post-actions. Minor gap: return structure is vague (only names, no types).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds context beyond schema: e.g., intentId is advisory, overlaps from Stop report, forkAuthor/workspaceId auto-resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves live code overlaps and auto-applies the safe tier, specifying conditions (trivial tier only) and actions. It distinguishes from sibling arbiter_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('when ready to incorporate result'), warns to re-read files, and explains when it behaves like arbiter_resolve (human checkout or peer lock).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Kawa Code's AI verdict for live code overlaps with peers — SUGGEST-ONLY, never writes. For each overlap ({peerUid, filePath, ranges} from the Stop collision report), Kawa decrypts the peer's version locally (zero-knowledge) and judges it compatible / auto_resolvable / conflict, with confidence, a perf/security risk read, and a tier (0 no-op · 1 trivially auto-appliable · 2 draft-and-confirm · 3 conflict). Use it to understand a forming conflict before acting. For a surfaced tier-2/3 overlap, call get_resolution_context to read the peer's actual code. To actually apply the safe tier, use arbiter_apply.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | No | Active intent ID (advisory). Auto-detected by Kawa Code when omitted. | |
| overlaps | Yes | The overlaps to judge — each { peerUid, filePath, ranges } from the Stop collision report. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States read-only ('never writes'), zero-knowledge decryption, output categories (compatible/auto_resolvable/conflict) with confidence, risk read, and tier. Does not cover error handling or authentication, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose. All sentences add information, though slightly verbose. Good structure overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return categories and tier system. Covers prerequisites and relationships to sibling tools. Complete for understanding the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% gives baseline 3. Description adds value by explaining overlaps come from Stop collision report, details each field, and notes that forkAuthor and workspaceId are auto-detected unless overridden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'AI verdict for live code overlaps', specifies it is SUGGEST-ONLY, never writes. Differentiates from sibling tools like get_resolution_context and arbiter_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use it to understand a forming conflict before acting.' Also provides when to use alternatives: for tier-2/3 overlaps, use get_resolution_context; to apply, use arbiter_apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
REQUIRED: Call this tool BEFORE writing any code.
Returns THIS session's current intent (intent / hasActiveIntent) if one is
set. If not, ask the user to confirm intent details and then call
create_and_activate_intent.
Multi-active model: the active intent is PER SESSION. Many intents can be active
on a repo at once — your current is independent of other sessions'/teammates'.
The response also includes activeIntents: the repo's full active set (every
session's current intent, with id/title/status/createdBy/author) for awareness
and orchestration. hasActiveIntent reflects only YOUR session; activeIntents
may be non-empty even when you have no current.
An active intent tracks what the user is working on, enabling:
Better code context for AI-generated changes
Conflict detection with team members
Automatic assignment of code blocks to the intent
Status semantics:
"active" — normal, in-progress. A stale intent simply stays "active"; the sweeper preserves its work without any status transition.
terminal states — committed / pushed / done / abandoned / superseded.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It fully discloses the per-session model, the multi-active support, and the status semantics. It explains the difference between 'hasActiveIntent' (session-specific) and 'activeIntents' (repo-wide). This level of detail compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with logical sections (requirement, return value, model explanation, status semantics). It front-loads the critical call-to-action. However, it is somewhat lengthy for a read-only check tool; some detail about status semantics could be omitted or moved. Still, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the complexity of the multi-active model, the description thoroughly covers the return values ('intent', 'activeIntents'), the status lifecycle, and behavioral nuances. It leaves no obvious gaps for an agent to misunderstand how to use the tool or interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra value for parameters: it clarifies that 'forkAuthor' and 'workspaceId' are automatically resolved and need override only for testing. This is helpful but not essential, keeping the score at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary function: 'Returns THIS session's current intent'. It uses specific verbs ('check', 'returns') and distinguishes itself from siblings like 'create_and_activate_intent' by specifying the prerequisite nature. The tool's role in the intent life cycle is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description starts with 'REQUIRED: Call this tool BEFORE writing any code.' It provides explicit guidance on when to use it (before all coding) and when to fall back to 'create_and_activate_intent'. This leaves no ambiguity about the tool's invocation context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark the active intent as completed and clear it.
Call this after a successful git commit to:
Update the intent status (committed/pushed/done/abandoned)
Store the commit SHA for tracking
Clear the active intent so a new one can be started
Status values:
"committed": Code is committed locally (default)
"pushed": Code has been pushed to remote
"done": Work is fully complete
"abandoned": Work was discarded without committing
REQUIRED: Inspect the response after calling this tool. Three outcomes:
response.success === true: The task is complete. Briefly acknowledge the commit and — if response.committedDecisionCount > 0 — mention that N distilled architectural decisions were recorded for the intent. Do NOT enumerate the decisions inline; they're visible via the orchestration panel and via get_intent_decisions / get_relevant_context if the user wants details. If response.apiSyncDeferred === true, also mention that the API sync was deferred; the queued writes will replay on the next sync tick. If response.collisions is non-empty, a live collaborator's (HAI's) in-progress edits overlap the work you just completed — surface it as a coordination heads-up (who, and which files), naming response.collisions[].label and the files. It's advisory, not a failure; the completion still succeeded. If response.deferredConflicts is non-empty, the distillation produced N decisions that conflict with existing standards — the completion STILL SUCCEEDED (the commit landed: status flipped, code blocks captured). Those decisions are deferred: parked for a disposition in the Orchestration panel, where the user picks per decision: supersede the standard, keep both (records a "contradicts" edge for a deliberate divergence / false positive), or reject the distilled decision. Tell the user "N decision(s) need a disposition in the panel." There is NOTHING to retry — do NOT re-run complete_intent.
response.success === false AND response.reason === "transient-failure": The distiller LLM call or the conflict-check API call errored. The ephemerals are preserved (the bucket is intact), and the intent stays "active". Tell the user the failure stage (response.failedStage) and the underlying error, then suggest retrying once the issue clears, or abandoning if the failure persists.
In a non-interactive (autonomous) session: if response.deferredConflicts is non-empty, log it at INFO and continue — the commit already landed and the decisions await disposition in the panel. There is no blocking state.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | The new status for the intent. Use "committed" after git commit, "done" when work is complete, "abandoned" to discard, "superseded" when another intent replaces this one. | |
| intentId | No | Target intent to complete/abandon. When omitted, completes THIS session's current intent. When provided, targets that specific intent directly — this is how you force-close an intent that is not your current one (e.g. another session's). Completing an intent created by ANOTHER team member additionally requires humanApproved=true (see below). | |
| repoPath | Yes | Local path to the repository root | |
| commitSha | No | The git commit SHA to associate with this intent (if already committed) | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| supersededBy | No | Intent ID that supersedes this one. Required when status is "superseded". | |
| humanApproved | No | Set to true ONLY when the human has explicitly confirmed closing an intent created by ANOTHER team member. Required for that cross-author case; ignored for your own intents. NEVER set this on your own initiative — always ask the user first and only set it after they approve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details outcomes (success, transient failure, deferred conflicts, collisions) and how to handle each. Highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured with numbered outcomes and status list. Front-loaded with core purpose. Could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and complex error handling, the description covers all major behaviors, error states, and response processing. Describes response fields adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaning by explaining status usage, intentId cross-author behavior, and humanApproved policy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks an intent as completed and clears it. It specifies the verb, resource, and context ('after successful git commit'), distinguishing it from siblings like update_intent or create_and_activate_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after git commit) and lists status values with meanings. Does not explicitly compare to alternatives but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new intent from the user's request and mark it as active for THIS session.
Call this when check_active_intent returns no active intent for your session. Before calling:
Summarize what the user is asking for
Ask the user to confirm the intent details (title, description, type)
Then call this tool with the confirmed details
This ensures all AI-generated code gets properly tracked and attributed.
Multi-active model: many intents can be active on a repo at once (one per session/teammate). Creating + activating one only sets YOUR session's current focus — it never blocks or displaces another session's active intent, so there is no lock conflict to resolve.
If the tool returns conflicts (action="conflict"), it found an existing team-member intent that overlaps semantically or in files. Present the conflict details to the user and ask whether to proceed. If yes, retry with force=true to bypass conflict detection.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Bypass conflict detection. Set to true after the user has reviewed detected conflicts and chosen to proceed anyway. | |
| title | Yes | Short, descriptive title for the intent | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| constraints | No | Requirements or constraints for this work | |
| description | Yes | What this intent accomplishes | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| templateType | No | Type of work |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains the multi-active model (no lock conflicts), creation+activation scoped to session, conflict detection behavior, and the effect of the 'force' parameter. Transparent about auto-detection of repoOrigin and automatic resolution of forkAuthor/workspaceId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose and key steps. Every sentence adds value, no redundancy. Clear separation of usage, multi-active model, and conflict handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return behavior (action=conflict) and all usage scenarios. Given the tool's complexity (9 params, nested objects), it provides complete guidance for selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains 'force' bypasses conflict detection after user review, 'repoOrigin' auto-detected, 'forkAuthor' and 'workspaceId' typically auto-resolved. Provides context for 'constraints' and 'templateType' beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new intent and marks it as active for the current session. It uses a specific verb-resource pair ('create' and 'activate') and distinguishes itself from siblings like 'check_active_intent' and 'activate_intent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to call this tool ('when check_active_intent returns no active intent'), prerequisites (summarize and get user confirmation), and handling of conflicts (present to user, retry with force=true). Includes step-by-step instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find intents from other team members that potentially conflict with the active intent.
When to use:
Before committing, to surface overlapping team work so the user can coordinate before merging.
Inputs of note:
intentId: the active intent to check against.
minScore (optional): minimum match score to include in results.
Returns scored conflict candidates with:
score: how strongly the candidate matches (higher = more likely conflict).
overlappingFiles: files affected by both intents.
decisions: decisions attached to the conflicting intent.
author: who is working on the conflicting intent.
The list is informational — review candidates and their decisions to decide whether coordination is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The active intent ID | |
| minScore | No | Minimum similarity score threshold (default: 0.5) | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
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 explains that the tool returns scored conflict candidates with specific fields, that the list is informational, and that review is needed. This gives a good understanding of the tool's read-only nature and expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main purpose, when to use, inputs of note, and returns. Each sentence contributes meaning, and the key information is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description provides a solid overview. It explains the most important parameters and the output format. It could be more complete by mentioning all parameters, but the essential information is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the intentId and minScore parameters with additional context, as well as describing the return fields. Although not all parameters are detailed, the description enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds intents from other team members that potentially conflict with the active intent. It uses specific verbs and resources (find, conflicting intents), and distinguishes itself from siblings like list_team_intents or check_active_intent by focusing on conflict detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Before committing, to surface overlapping team work so the user can coordinate before merging.' While it doesn't mention when not to use or provide alternatives, the context is clear and sufficient for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit or delete a decision in the current session.
Use this when reviewing decisions before commit:
action: "update" - Modify the decision fields
action: "delete" - Remove the decision entirely
Only ephemeral (in-flight) session decisions are editable. Once a decision is
synced to Kawa Code, it is immutable — refine it instead by recording a new
decision with supersedes: [<id>].
This allows users to curate their decision history before it's persisted.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: update modifies the decision, delete removes it | |
| updates | No | Partial fields to update (only for action=update) | |
| intentId | Yes | The intent ID the decision belongs to | |
| repoPath | Yes | Local path to the repository root | |
| decisionId | Yes | The decision ID to edit or delete | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that only ephemeral decisions are editable and synced ones are immutable. It describes the two actions (update/delete) but lacks details on side effects like confirmations or reversibility. Nonetheless, it provides sufficient behavioral context for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only three short paragraphs and bullet points. No unnecessary sentences; each part adds meaning. Structure is front-loaded with the core purpose, followed by usage details and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 4 required, and no output schema, the description covers the primary purpose, action semantics, and parameter usage hints. It could mention what the tool returns or any side effects, but overall it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that 'forkAuthor' and 'workspaceId' are usually auto-resolved and only needed for override/testing. The 'action' parameter's enum values are contextualized with 'update' and 'delete' descriptions. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit or delete a decision in the current session', using specific verbs and resources. It distinguishes from related siblings like 'record_decision' by emphasizing pre-commit review and immutability of synced decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when reviewing decisions before commit' and describes when to use each action. Provides clear exclusion criteria: once synced, decisions are immutable and should be refined via new decisions with 'supersedes'. This differentiates from siblings effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curate a set of previously extracted stories so that only the decisions still worth keeping are persisted.
When to use:
After running infer_history in story-only mode (rare — infer_history already chains this step automatically).
When you have a pre-existing set of stories you want to re-curate without re-running history extraction.
Inputs:
stories: array of story objects from a previous infer_history run.
repoPath (optional): when provided, curated results are persisted as intents and decisions for the repo after curation finishes.
model (optional): Anthropic model used for the curation pass.
Behavior:
Runs asynchronously — returns immediately with a started/pending status while progress is reported separately.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Anthropic model used for the curation pass (default: claude-haiku-4-5-20251001). | |
| stories | Yes | Array of story objects from a previous infer_history run | |
| repoPath | No | Local path to the repository root (required for auto-persist after evolution) | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL (auto-detected from repoPath if not provided) | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description provides key behavioral details: it runs asynchronously, returns immediately with a started/pending status, and optionally persists results when repoPath is provided. This adds significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for usage, inputs, and behavior. It is concise without being overly terse, though the first sentence could be slightly more direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects, async behavior, no output schema), the description covers the essential context: when to use, inputs, and asynchronous nature. It could elaborate on how progress is reported, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the purpose of stories and optional parameters but does not add new meaning beyond what's in the schema. The information about auto-persist with repoPath is already present in the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'curate a set of previously extracted stories so that only the decisions still worth keeping are persisted.' It clearly distinguishes itself from sibling tools like infer_history and record_decision by focusing on re-curation after initial extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly states scenarios: after infer_history in story-only mode or when re-curating existing stories without re-running history extraction. It lacks explicit 'when not to use' or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand one decision to its full detail.
Recall surfaces (get_relevant_context, get_project_decisions, get_session_decisions) return decisions summary-only to keep context lean. Use this to pull the full reasoning for a single decision you want to open — pay for detail only where you ask for it.
Inputs:
decisionId: the decision to expand (the id / decisionId from a recall result).
Returns the decision's rationale, context, consequences, alternatives, symptom, appliesWhen, surface, and related metadata. found: false when the id is unknown in this repo.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Local path to the repository root | |
| decisionId | Yes | The decision ID to expand (from a recall result, e.g. get_relevant_context) | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output fields, that `found: false` occurs when unknown, and that some parameters are auto-resolved. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose sentence, usage context, input explanation, output explanation. Every sentence is necessary and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, outputs, and usage context. Missing potential error conditions but sufficient for a detail retrieval tool. No output schema, so description explains return fields adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by specifying that `decisionId` comes from a recall result and that `forkAuthor`, `repoOrigin`, `workspaceId` are usually auto-resolved, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Expand one decision to its full detail.' It uses a specific verb (expand) and resource (decision), and distinguishes from sibling tools that return summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: after getting a summary from recall surfaces, and to 'pay for detail only where you ask for it.' It contrasts with recall tools that return summaries-only, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get uncommitted changes in the repository along with the active intent info.
Use this tool before prompting the user about committing to show:
The active intent title and description
Number of modified, added, and untracked files
Any warnings (e.g., pre-existing changes from before intent activation)
This helps you construct an informative commit prompt like: "You have uncommitted work on '[intent title]' (N files changed)..."
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full responsibility. It discloses output details (active intent title/description, file counts, warnings) and implies a read-only operation ('get'). It does not discuss permissions or side effects, but the verb 'get' and the output description make the behavior clear. A minor gap is the lack of explicit read-only declaration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-sentence purpose, followed by a structured list of what to expect, and a concrete example. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain return values. It does so adequately by listing active intent info, file counts, and warnings. It also provides usage context. However, it omits potential error conditions (e.g., if repoPath is invalid) and assumes git availability. Given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters have descriptions). The description adds value by explaining the purpose of the tool (retrieving uncommitted changes and intent info) but does not enhance parameter semantics 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get uncommitted changes in the repository along with the active intent info', specifying the verb (get) and resource (uncommitted changes + intent info). This distinguishes it from siblings like check_active_intent (which only checks active intent) and get_intents_for_file (which focuses on file-specific intents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool before prompting the user about committing' and provides a concrete example of how to construct a commit prompt. This gives clear when-to-use guidance and hints at alternatives (e.g., not for other contexts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all intents that have code blocks in this file.
Use this before modifying a file to:
See what work is already in progress
Identify potential conflicts with team members
Understand the context of existing code changes
Returns intent details including author, status, and specific line ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file (relative to repo root) | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the function is to 'Get' intents, implying a read-only operation, but doesn't explicitly declare it as non-destructive or disclose any side effects, auth needs, or rate limits. The description adds moderate value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose statement, followed by a bullet list of use cases. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description adequately covers purpose and use cases. It partially compensates for lack of output schema by listing return fields (author, status, line ranges). However, it could be more complete about which parameters are required vs. optional, but schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters. The description does not add any additional explanation or context for individual parameters, leaving it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all intents that have code blocks in this file,' using a specific verb and resource. This distinguishes it from siblings like 'get_intents_for_lines' which targets specific lines, not the whole file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use before modifying a file, listing three specific use cases (see progress, identify conflicts, understand context). While it doesn't cover when to avoid or mention alternative tools, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get intents covering a specific line range.
Use this before modifying specific lines to check for conflicts:
Warns if the lines overlap with another team member's active intent
Shows the exact overlap range
Helps avoid merge conflicts and duplicate work
Returns overlap details so you can work around or coordinate with team members.
| Name | Required | Description | Default |
|---|---|---|---|
| endLine | Yes | End line number (1-based, inclusive) | |
| filePath | Yes | Path to the file (relative to repo root) | |
| repoPath | Yes | Local path to the repository root | |
| startLine | Yes | Start line number (1-based) | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits such as warning about overlaps and returning details. However, it does not state that the tool is read-only or describe other behavioral aspects like authentication needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences and front-loaded with the purpose. However, it contains some redundancy (e.g., overlap warnings repeated) and could be more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains the tool checks conflicts and returns overlap details. It does not cover behaviors like empty results, permissions, or error scenarios, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get intents covering a specific line range', which is a specific verb+resource. It differentiates from the sibling tool 'get_intents_for_file' by focusing on a line range, though not explicitly naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this before modifying specific lines to check for conflicts', providing clear context and recommended usage. However, it does not specify when not to use or mention alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all decisions recorded for a project across all intents.
Use this to review the project's decision history:
See what architectural decisions have been made
Understand past trade-offs and their rationale
Find decisions affecting specific files
Review constraint violations that were avoided
Returns:
decisions: Array of decisions with their intent context
count: Total number of decisions
Each decision includes (summary-only, to keep context lean — call get_decision_detail(decisionId) for full rationale/context/consequences/alternatives):
intentIds: The intents this decision belongs to (array — a decision can span multiple intents)
type: fork, abandoned, discovery, constraint, tradeoff, or dependency
summary: Brief description of the decision
relatedFiles: Files affected by this decision
constraintViolations: Options that were rejected due to constraints
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns summary-only decisions, lists included fields, explains that decisions can span multiple intents, and enumerates decision types. No contradiction or omission noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet points for usage, and a detailed return value summary. While comprehensive, it is slightly verbose in the usage bullet list but remains front-loaded and contains no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return structure (decisions array with fields, count) and nested object details. It references sibling tool get_decision_detail for deeper context, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions for each parameter. The description adds no additional information beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all decisions recorded for a project across all intents,' providing a specific verb and resource. It distinguishes itself from sibling tools like get_decision_detail (for full details) and get_session_decisions (session-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases under 'Use this to review the project's decision history' and advises to call get_decision_detail for full rationale, providing explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find past intents and decisions relevant to the current user request.
When to use:
After you have done a quick initial exploration of the user's request and know which files are involved. Calling earlier with only a vague prompt gives weak results.
To pull task-specific context instead of dumping all recent activity — preferred for large projects.
Inputs of note:
prompt: the user request, in their words or your paraphrase.
activeFiles (recommended): files you have identified as relevant to the request. Significantly improves relevance.
maxIntents, maxDecisions, minRelevance: result-shaping caps and threshold.
Returns:
relevantIntents: past work units (intents) related to the task, scored by relevance.
relevantDecisions: prior decisions related to the task — both intent-scoped and repo-scoped. Summary-only (no inline rationale, to keep context lean); call get_decision_detail(decisionId) for the full rationale/context/consequences of any decision you want to open.
Recommended sequence:
check_active_intent at session start to resume any existing work.
Briefly explore the user's request to identify involved files.
get_relevant_context with the prompt and activeFiles to inform the approach.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The user request to find relevant context for | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| maxIntents | No | Maximum number of intents to return | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| activeFiles | No | Files currently being discussed or recently opened | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| maxDecisions | No | Maximum number of decisions to return | |
| minRelevance | No | Minimum relevance score (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of transparency. It discloses that results include relevantIntents and relevantDecisions, that decisions are summary-only, and that full details require calling get_decision_detail. It also notes that forkAuthor and workspaceId are usually auto-resolved, and that calling early with vague prompts yields weak results. No contradictions with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, when to use, inputs of note, returns, and recommended sequence. Every sentence adds necessary information without redundancy. It is front-loaded with the core purpose and efficiently expands on usage and details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a tool with 9 parameters and no output schema. It covers the tool's purpose, usage context, key inputs (especially activeFiles), return fields with guidance on how to use them (e.g., calling get_decision_detail for full rationale), and a recommended sequence linking to sibling tools. It provides enough context for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant value beyond the schema: it explains that activeFiles is recommended and improves relevance, that forkAuthor and workspaceId are for override/testing only, and it describes the return fields and their nature (summary-only decisions). It also provides a recommended sequence that clarifies parameter usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find past intents and decisions relevant to the current user request.' It uses a specific verb ('Find') and identifies the resources ('past intents and decisions'). It distinguishes itself from sibling tools like get_intents_for_file by focusing on task-specific context and recommending use after initial exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details when to use the tool: after initial exploration when files are known, and for task-specific context in large projects. It provides a recommended sequence involving check_active_intent and exploration first. It also advises against calling too early with a vague prompt, effectively telling when not to use it, and contrasts with other tools by stating its preference for large projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ranges | Yes | Overlapping [start, end] line ranges (from the collision) to fetch the peer code for. | |
| peerUid | Yes | The peer HAI whose live edits overlap — the `uid` of a collision from the Stop hook collision report. | |
| filePath | Yes | Path to the file being edited (relative to repoPath) | |
| intentId | No | Active intent ID (advisory). Auto-detected by Kawa Code when omitted. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
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.
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.
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.
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.
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.
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.
Get all decisions recorded in the current session for an intent.
Use this before committing to review what decisions were captured during development. Decisions are presented for user review and can be edited or removed before being persisted.
Returns:
intentId: The intent these decisions belong to
decisions: Array of decision points (summary-only — call get_decision_detail(decisionId) for full rationale/context/consequences/alternatives)
count: Number of decisions recorded
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to get decisions for | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that decisions are summary-only and can be edited/removed before persistence. Implies read-only operation (get), but could be more explicit about side-effects (none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, one for usage context, then bullet-like return format. Every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description fully specifies return fields (intentId, decisions summary, count). Points to get_decision_detail for full details. Adequate for the tool's complexity, though decisions array structure could be described slightly more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond the input schema for parameters; focuses on output structure and relationships to other tools. No extra parameter guidance provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get all decisions recorded in the current session for an intent.' Distinguishes from siblings like get_project_decisions (broader scope) and get_decision_detail (single decision details) by specifying session and summary nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this before committing to review what decisions were captured during development.' This gives clear context. Could further contrast with alternatives like get_project_decisions or log_work, but current guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a repository's git commit history and produce structured development knowledge (intents and decisions) for the repo.
When to use:
To bootstrap a repository that has no recorded intents/decisions yet.
To extend coverage for new commits since the last run (resumes automatically when no commits value is provided).
Inputs of note:
estimateOnly (default true): returns a token/cost estimate without running. Call with estimateOnly: true first to preview cost, then re-call with estimateOnly: false to run.
commits (optional): how many recent commits to analyze. Omit to resume from where the last run stopped (or fall back to a sensible default on first run).
commitRange (optional): git revspec selecting a specific window — "sha1..sha2", "branch1..branch2", "sha1^!" for a single commit. Mutually exclusive with commits. Useful for recovering from dropped batches or backfilling specific PRs / branches without re-running the full history.
contextIssues: include PR/MR descriptions and issue discussions when an authenticated forge CLI (gh or glab) is available; auto-skipped otherwise.
allowCommitSplitting: enable when commit history is messy and a single commit may cover unrelated changes.
model, maxStories: Anthropic model and per-run cap.
force (default false): override the re-run guard (see Behavior).
Behavior:
A run is asynchronous — returns immediately with a started/pending status; progress is reported separately.
Results are persisted as intents and decisions for the repo on completion.
If interrupted, re-running resumes from where it left off.
Re-run guard: a clean incremental resume runs automatically. But if the repo already has intents and the run cannot cleanly resume (missing/unreachable cursor), or HEAD is not on the default branch, the call STOPS and returns needsDecision instead of running — re-running blind there risks duplicate intents. Present the reason to the user and, if they confirm, re-call with force: true. Run on the default branch (main/master) whenever possible; inferring a feature branch is what force is for.
GitHub and GitLab are supported; the forge is detected from the remote origin.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Override the re-run guard. When the repo already has intents and infer_history cannot cleanly resume (missing/unreachable cursor), or when HEAD is not on the default branch, the run is stopped and a confirmation is requested. Set `force: true` to proceed anyway, accepting the duplicate-intent risk. Exact-commit duplicates are still skipped automatically; overlapping re-groupings are not. A forced run on a non-default branch additionally does NOT advance the resume cursor. Does not override a hard failure such as the desktop app being unreachable. | |
| model | No | Anthropic model to use (default: claude-sonnet-4-20250514) | |
| commits | No | Number of recent commits to analyze. If omitted, the server resumes from the last commit infer_history processed for this repo (or falls back to 50 on first run). Mutually exclusive with `commitRange`. | |
| repoPath | Yes | Local path to the repository root | |
| maxStories | No | Maximum number of stories to analyze in this run (0 = unlimited). | |
| commitRange | No | Optional git revspec to process a specific commit range instead of the N most recent (e.g. "sha1..sha2", "branch1..branch2", "sha1^!" for a single commit). Useful for recovering from dropped batches or targeted backfills. Mutually exclusive with `commits`. | |
| estimateOnly | No | If true (default), only estimate token cost without running the pipeline. Set to false to run the full pipeline. | |
| contextIssues | No | Include context issues from commit date range (requires gh/glab CLI) | |
| allowCommitSplitting | No | Allow splitting a single commit into multiple stories when it contains unrelated changes (recommended for repos with messy commit history) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly describes async execution, automatic resume on interruption, the re-run guard (needsDecision scenario), forced run behavior on non-default branches, and supported forges. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to use, Inputs, Behavior) and front-loaded purpose. While long, each sentence adds necessary detail for a complex tool. Slightly verbose but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no output schema, no annotations), the description is remarkably complete. It covers parameter interactions, edge cases (resume, force), async nature, and prerequisites (gh/glab). Leaves no major gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond schema: default values (estimateOnly, force), mutual exclusivity of commits and commitRange, resume logic for commits, conditional contextIssues availability, and detailed force behavior including duplicate-intent risks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Analyze a repository's git commit history and produce structured development knowledge (intents and decisions).' Immediately distinguishes from sibling tools that manage existing intents/decisions rather than generating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly states bootstrap and new-commit scenarios. It explains the re-run guard and force flag for special cases. However, it does not explicitly say when to avoid this tool in favor of alternatives, missing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List intents from team members for this repository.
Use this to:
See what your team is working on
Check for potential overlapping work before starting a new task
Review the status of various features/refactors in progress
Filtering (status, author, date range) and pagination are applied server-side across the full result set (default: 50 per page; use limit/offset to page). count is the total number of matching intents, not just the returned page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of intents to return (default: 50) | |
| since | No | Filter intents updated after this ISO8601 date (e.g. "2026-04-01") | |
| until | No | Filter intents updated before this ISO8601 date | |
| author | No | Filter by author name or ID | |
| offset | No | Number of intents to skip for pagination (default: 0) | |
| status | No | Filter by intent status. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explains server-side filtering and pagination (default 50 per page), the meaning of the 'count' field, and that parameters like forkAuthor are auto-resolved. While it doesn't describe all behaviors (e.g., ordering), it adds significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by bullet points for use cases and key behavioral details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema), the description adequately covers the tool's functionality, filtering, pagination, and the meaning of the count field. It does not describe the full output structure but is sufficient for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds extra value by specifying the default limit value (50), the ISO8601 format for date filters, and noting that forkAuthor and workspaceId are auto-resolved. This goes beyond the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List intents from team members for this repository' with specific use cases like checking overlapping work and reviewing status. It distinguishes itself from siblings by focusing on team-wide intents, not file-specific or intent-specific actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool with three bullet-point scenarios. However, it does not mention when not to use it or direct users to alternative sibling tools like get_intents_for_file or get_intents_for_lines, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — trivial changes (typos, one-line fixes, obvious bugs, doc updates, config changes) should skip the intent workflow entirely: just make the change and commit, no intent needed. Do not call this tool. Kept available for backwards compatibility only and will be removed in a future release.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | File paths modified (relative to repo root) | |
| title | Yes | Short description of the work done | |
| repoPath | Yes | Local path to repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations are absent, the description transparently communicates the tool's deprecated status and that it will be removed. It does not detail behavioral traits like side effects, but for a deprecated tool, the clear warning and backwards-compatibility note are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with just three short sentences. It is front-loaded with the deprecation warning and clear instructions, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated tool, the description covers everything needed: it states deprecation, provides examples of trivial changes, instructs to not use it, and mentions backwards compatibility and future removal. No output schema exists, but the explanation is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter-specific meaning beyond what the input schema already provides. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is deprecated for logging work in an intent workflow, and it clearly defines its purpose by indicating what trivial changes should do instead. The 'DEPRECATED' label and the instruction to skip the intent workflow make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Do not call this tool.' It explains when not to use it—for trivial changes—and offers an alternative workflow (make and commit without intent). This is exceptionally clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark decisions as consciously overridden for the rest of this session.
Phase 3's PreToolUse hook calls this when the agent passes force: true on an Edit tool call to bypass a pre_edit_decision_check block. Adds the surfaced decision IDs to an in-memory session cache; subsequent pre_edit_decision_check fires filter those IDs out so the same block doesn't re-fire.
The cache resets when the MCP server process exits (= the agent session ends). For persistent override across sessions, record a fork decision via record_decision(type: "fork", supersedes: [<id>]) instead.
Returns:
acknowledged: number of newly-added IDs (existing IDs are deduped silently)
cacheSize: total IDs currently in the session override cache
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | No | Local path to the repository root. Enables repo attribution of the acted-on value-metric. | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. Used only to attribute the acted-on value-metric to a repo. | |
| decisionIds | Yes | Decision IDs to acknowledge (mark as overridden for the rest of this session) | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| sessionToken | No | Session scope for the force-override cache. Should match the sessionToken passed to pre_edit_decision_check. Defaults to the MCP server's SESSION_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers session cache behavior, reset on server exit, dedup behavior, and return values. It could be more explicit about idempotency but is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, context, behavior, returns. It is slightly longer than necessary but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values. It covers session token defaults and nested parameter (forkAuthor). Could mention that decisionIds is required, but context is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter semantics beyond the schema, though it explains return values which are not in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'marks decisions as consciously overridden for the rest of this session' and differentiates from sibling tools like 'pre_edit_decision_check' and 'record_decision' by explaining the session cache and persistent alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when the tool is used (when force:true bypasses a block) and provides an alternative for persistent override (record_decision), but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the line range about to be edited has prior recorded reasoning attached.
Call this BEFORE editing code in a kawa-indexed repo. Surfaces:
Tier 1a — overlapping intents whose blocks cover these lines (line-precise team coordination + intent-scoped decisions)
Tier 1b — repo decisions whose relatedFiles include this file (file-coarse, catches infer_history-extracted constraints)
(Live-collaborator code-collision awareness is no longer reported here — it now arrives once per turn at the Stop hook. This tool is purely the semantic, decision-based check.)
Decisions already overridden via record_decision(supersedes=...) are filtered out automatically.
Recommendation maps to action:
"proceed" — nothing relevant; safe to edit
"review" — surfaced context worth inspecting before editing
"investigate-upstream" — prior constraint or abandoned approach matches; don't proceed without reading the rationale and either revising the change or recording a new fork decision that supersedes the old one
Also returns the smallest enclosing function/method symbol via tree-sitter (Rust/TS/JS/Python only; null for other languages) for warning readability.
| Name | Required | Description | Default |
|---|---|---|---|
| endLine | Yes | End line of the touched range (1-based, inclusive) | |
| filePath | Yes | Path to the file being edited (relative to repoPath) | |
| intentId | No | Active intent ID for supersedes scoping. Auto-detected by Muninn when omitted. | |
| repoPath | Yes | Local path to the repository root (also used to read the file for AST symbol detection) | |
| startLine | Yes | Start line of the touched range (1-based, inclusive) | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| sessionToken | No | Session scope for the force-override cache. Defaults to the MCP server's SESSION_ID; PreToolUse hook callers should pass Claude Code's session_id so writes from one process are visible to the other. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: surfaces Tier 1a and 1b, filters overridden decisions, returns recommendation, and provides enclosing function symbol (with language limitations). All key traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, uses bullet points for clarity. Slightly verbose but every sentence adds value. Could be tightened slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (9 params, nested objects, no output schema), description adequately covers return behavior and recommendations. Missing structured output schema is partially mitigated by textual description. Good overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by noting auto-detection for intentId, repoOrigin, forkAuthor, workspaceId, and sessionToken defaults. This context aids correct usage beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Check whether... has prior recorded reasoning attached') and specific resource ('line range about to be edited'). Differentiates from siblings by specifying it's a pre-edit semantic decision check, not a generic intent query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this BEFORE editing code' and mentions what is no longer covered (live-collaborator collisions). Provides recommendation mapping for actions. However, does not explicitly contrast with alternatives like get_intents_for_lines or when to skip this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Silently record a decision point during development.
Call this tool when you:
Choose between multiple alternatives (type: fork)
Try an approach that fails or is rejected (type: abandoned)
Find unexpected behavior or limitations (type: discovery)
Identify a hard constraint that must be respected (type: constraint)
Make an explicit trade-off between competing concerns (type: tradeoff)
Select an external library or dependency (type: dependency)
Decisions can be intent-scoped (tied to a specific work unit) or repo-scoped (general knowledge like discoveries and constraints). Omit intentId for repo-scoped decisions.
Decisions are accumulated silently during the session and presented for review before commit. This creates a "reasoning changelog" that captures not just what was done, but why.
IMPORTANT: Include constraintViolations when alternatives are rejected due to architectural constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of decision: fork (chose between alternatives), abandoned (tried and rejected), discovery (found unexpected behavior), constraint (identified hard requirement), tradeoff (made explicit trade-off), dependency (selected library/tool) | |
| source | No | Provenance: user (human-recorded), agent (AI deliberately recorded via this tool — the default), extractor (from thought-chain extraction), infer_history (from commit-history extraction). Most callers leave this as the default. | |
| context | No | What we were trying to accomplish when this decision was made | |
| summary | Yes | Brief summary of the decision (< 100 chars recommended) | |
| surface | No | Which ceremony(ies) this decision should be surfaced at, controlling when it interrupts future work. Values: "pre-edit" (per-edit block via pre_edit_decision_check — for correctness/security constraints), "intent-create" (injected at intent-framing time — for design/scalability constraints that must shape the approach, not a keystroke), "stop" (once-per-turn Stop/review gate — aggregate/after-the-fact checks), "recall" (passive; only via get_relevant_context). Omit for ordinary decisions — empty means default type-based routing. Strong-signal-only: set it only when the decision genuinely belongs at a non-default ceremony. | |
| symptom | No | Observable symptom that indicates this decision is relevant (e.g., error messages, runtime panics, unexpected behavior). Useful for discovery and constraint decisions. | |
| intentId | No | The intent ID this decision belongs to. Omit for repo-scoped decisions (discoveries, constraints) not tied to a specific work unit | |
| repoPath | Yes | Local path to the repository root (enables offline sync) | |
| rationale | Yes | Why this decision was made | |
| confidence | No | Self-rated confidence in the decision. Meaningful only for extractor and infer_history sources — leave null for deliberate recordings. | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| supersedes | No | Decision IDs that this one replaces. When a later decision supersedes an earlier one, pass the earlier decisionId(s) here so the evolve pipeline can track the lineage. | |
| appliesWhen | No | Trigger condition / "How to apply" — populate ONLY when the decision is plainly conditional (e.g. "language is Go", "when running in production", "when working in module X", "when the error is ECONNRESET"). Skip when the rule has no clean activation condition or when the rationale already implies universality. Treat applies_when as load-bearing context the LLM uses at recall time to decide whether the decision is relevant — not a soft hint. Strong-signal-only. | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. | |
| alternatives | No | Other options that were considered | |
| consequences | No | Downstream implications of this decision | |
| relatedFiles | No | File paths affected by this decision | |
| sourceThoughtIds | No | Thought-chain entry IDs this record was extracted from. Only set by the extractor path. | |
| resolvedCollision | No | Layer C audit — set ONLY when this decision records how you resolved a completion-time code collision (i.e. after complete_intent returned resolution_required). Links the decision to the live peer you yielded to or overrode. | |
| constraintsChecked | No | Which architectural constraints were verified before this decision | |
| constraintViolations | No | Alternatives that were rejected due to constraint violations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that decisions are recorded silently, accumulated during the session, and presented before commit. It also notes behavioral traits like constraintViolations handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear bullet points and sections. It is concise yet thorough, front-loaded with the purpose, and each sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, no output schema, and no annotations, the description is complete in explaining the recording process, scoping, and key fields. It adequately prepares the agent for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed parameter descriptions. The description adds value by explaining scoping rules (e.g., omitting intentId for repo-scoped) and emphasizing the constraintViolations parameter, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Silently record a decision point during development.' It lists specific scenarios (fork, abandoned, discovery, constraint, tradeoff, dependency) which precisely differentiates it from sibling tools used for retrieval or other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to call the tool for each decision type, explains intent-scoped vs repo-scoped usage, and highlights important actions like including constraintViolations. It effectively informs the agent of appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the project's feature catalog from its recorded intents.
Additively groups any intents that are not yet assigned to a feature into the running catalog (an incremental "extend"), without disturbing existing features. The feature catalog is the high-level "what does this project actually do?" view, derived from the repo's intents.
When to use:
After recording or completing intents, to keep the feature list current.
On demand, when you want the catalog refreshed with recent work.
Behavior:
Additive only — never deletes or re-derives existing features.
Intents already assigned to a feature are skipped; only unassigned ones are processed.
Runs in the Kawa Code desktop app and returns the resulting feature count.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Local path to the repository root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: additive only, no deletions, skips assigned intents, runs in desktop app, and returns feature count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with clear sections (main purpose, When to use, Behavior). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately explains the function, behavior, and return value (feature count), making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so schema fully defines the parameter; description adds no extra semantic detail about the path parameter beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates the feature catalog from intents in an additive manner, and explicitly distinguishes it from sibling tools like update_intent by focusing on features rather than intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' scenarios (after recording/completing intents or on demand), but does not explicitly state when not to use or suggest alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an active intent's title, description, scope, or constraints.
Use this to reformulate an intent as understanding evolves during work. Intents are living documents — they should be updated to reflect what the work actually became, not left as the initial guess. Common triggers for reformulation:
The real problem turned out to be different from the initial hypothesis
Scope expanded or narrowed during investigation
The approach changed after discovering constraints
If no intentId is provided, the currently active intent is updated.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Updated scope for the intent | |
| title | No | Updated title for the intent | |
| intentId | No | ID of the intent to update. If omitted, updates the currently active intent. | |
| repoPath | Yes | Local path to the repository root | |
| forkAuthor | No | Fork attribution; usually resolved by Muninn automatically — pass only for override / testing. | |
| repoOrigin | No | Git remote origin URL. Auto-detected from repoPath via git if not provided. | |
| constraints | No | Updated constraints for this work | |
| description | No | Updated description for the intent | |
| workspaceId | No | Workspace identifier; usually resolved by Muninn automatically — pass only for override / testing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like mutation, merging behavior, return value, and permissions. It only states 'update' without detailing whether fields are overwritten or merged, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded paragraphs. The first sentence captures the action and fields, and the examples are relevant. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, nested objects, and no output schema, the description lacks details on return values, error handling, and update semantics. It does not fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds minimal extra semantics beyond the schema, mainly repeating the fields and the default behavior for intentId. The rationale for updating is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an active intent's title, description, scope, or constraints. It distinguishes itself from sibling tools like create_and_activate_intent and activate_intent by emphasizing reformulation of existing intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit triggers for reformulation and notes that omitting intentId updates the active intent. However, it does not explicitly state when not to use this tool, such as for creating or activating intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v6.9.0activate_intentarbiter_applyarbiter_resolvecheck_active_intentcomplete_intentcreate_and_activate_intentdetect_intent_conflictsedit_session_decisionevolve_decisionsget_decision_detailget_intent_changesget_intents_for_fileget_intents_for_linesget_project_decisionsget_relevant_contextget_resolution_contextget_session_decisionsinfer_historylist_team_intentslog_workpre_edit_acknowledgepre_edit_decision_checkrecord_decisionupdate_featuresupdate_intentSeveral tools have overlapping purposes, such as get_intents_for_file and get_intents_for_lines, get_session_decisions and get_project_decisions, and detect_intent_conflicts and pre_edit_decision_check. However, the descriptions generally clarify the specific use cases, reducing ambiguity.
Tool names follow a consistent snake_case convention with verb prefixes (get_, check_, create_, etc.), but there are some inconsistencies like 'check_active_intent' vs 'get_intents_for_file' and 'list_team_intents' vs 'get_intent_changes'. Overall pattern is predictable.
With 25 tools, the set is on the higher end but still appropriate for the server's broad scope covering intent management, decision recording, conflict detection, history inference, and collaboration. Each tool serves a distinct purpose, though some could be consolidated.
The tool set covers the full lifecycle of intents (create, activate, update, complete), decision recording and retrieval, conflict detection, history inference, and feature updates. Minor gaps (e.g., no explicit delete intent tool) but overall comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Coordination for AI coding agents: declare plans, catch design conflicts early, share team memory.
Shared debugging memory for AI coding agents
One shared brain for your AI coding agents: team memory, agent Q&A, tasks, and file claims.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
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
