Integrates with GitHub to fetch PR descriptions, review comments, and issue discussions for richer context.
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 check for conflicts on file src/index.ts"
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.
Optional. When the agent is about to edit code that has prior recorded reasoning attached (an overlapping intent's blocks, or a constraint with the file in relatedFiles), the hook surfaces it before the Edit fires. Recommendation maps to action: silent (proceed), advisory context injected (review), or blocked with stderr message (investigate-upstream).
Wire it as a Claude Code PreToolUse hook in your ~/.claude/settings.json or project .claude/settings.json:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "npx -y -p @kawacode/mcp kawacode-on-pre-edit" }
]
}
]
}
}Override paths when blocked:
Persistent (recommended): record a fork decision that supersedes the existing one and retry the Edit.
record_decision(type: "fork", supersedes: ["<surfaced-decision-id>"], rationale: "...")One-off escape hatch: add force: true to the Edit tool args. The hook acks the surfaced decisions in the session cache and allows the edit. Cache resets when the Kawa Code daemon restarts.
Disable the hook for a session with KAWA_PRE_EDIT_CHECK=off.
Every pre-edit check fire (and force-override) appends a JSON line to a daily-rotated file at ~/.kawa-code/logs/pre-edit-decision-check-YYYY-MM-DD.jsonl. Logs are local only — nothing leaves your machine. The defaults keep the last 30 days, capped at 100 MB total (oldest files dropped first).
Each line records what fired, why, and what was filtered out — useful for tuning the recommendation thresholds and spotting false positives over time.
Disable telemetry with KAWA_PRE_EDIT_TELEMETRY=off.
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.
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.
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.
# 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. It discloses key behaviors: accepts cloud IDs and local UUIDs, multi-active model (no blocking), and transparent restoration of soft-deleted decisions for abandoned intents. This exceeds typical description detail and prevents misuse.
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 section headers (Use this to, Accepts both, Multi-active, Resuming abandoned) and front-loaded main sentence. While slightly long, each section adds essential information without redundancy. Could be slightly more concise, but structure compensates.
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 5 parameters (2 required, nested objects) and no output schema, the description adequately covers activation behavior, multi-active semantics, and abandoned intent handling. It does not describe the return value, but for a mutation tool this is acceptable. The explanation of edge cases (abandoned intents) adds 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%, but description adds value beyond schema by explaining the dual ID acceptance and auto-resolution behavior for forkAuthor and workspaceId ('usually resolved by Muninn automatically'). This context helps agents decide when to provide overrides.
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 'Activate an existing intent by ID — sets it as THIS session's current focus.' It specifies the verb (activate), resource (intent), and scope (existing, by ID, session-specific). It distinguishes from siblings like create_and_activate_intent and check_active_intent, making the purpose unambiguous.
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 use cases: switch focus, re-activate deactivated, resume work, resume abandoned. Also explains the multi-active model (no locks, only session pointer moves) and when to use alternative tools (e.g., list_team_intents to find intents). This gives clear when-to and when-not-to guidance.
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 explains the conditional write behavior (trivial tier, agent-owned worktree), records decisions, and warns about file changes. It could add authorization or rate-limit details, but current coverage is strong.
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 front-loaded with the key action and uses bullet-like structure for outcomes. It is slightly lengthy but each sentence adds value, so it remains clear and efficient.
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 (6 params, nested objects, no output schema), the description covers conditional behavior, return format, and post-invocation steps. It is comprehensive for an AI agent to select and 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?
Schema coverage is 100%, but the description adds meaning: it explains that overlaps come from the Stop collision report, and that forkAuthor and workspaceId are usually auto-resolved. This supplements the schema effectively.
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 verb 'Resolve' and resource 'live code overlaps', specifies the auto-apply behavior for the trivial tier, and distinguishes it from arbiter_resolve by detailing when it writes vs. suggests.
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 gives explicit guidance: 'Call it when you are ready to incorporate the result' and instructs to re-read applied files. It also directs users to get_resolution_context for unapplied overlaps, providing clear alternatives.
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?
The description discloses safety (SUGGEST-ONLY, never writes), zero-knowledge decryption, and output details (compatible/auto_resolvable/conflict, confidence, perf/security risk, tier). No annotations exist, so description carries full burden. Minor gap: no mention of auth or rate limits, but detailed enough.
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 dense but well-structured, front-loading the key purpose and safety guarantee. It efficiently explains input, output, and usage flow without 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?
Given 6 parameters, nested objects, and no output schema, the description comprehensively explains inputs, output fields, and workflow integration. Slightly missing explicit response format, but output details are described inline.
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 descriptions for all 6 parameters. The description adds context beyond schema: intentId is advisory/auto-detected, overlaps format from Stop report, forkAuthor and workspaceId typically auto-resolved. This significantly aids parameter understanding.
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 Kawa Code's AI verdict for live code overlaps with peers — SUGGEST-ONLY, never writes.' It identifies the specific verb (get verdict) and resource (overlaps), and distinguishes from sibling tools like arbiter_apply and get_resolution_context.
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 says 'Use it to understand a forming conflict before acting.' and directs when to use alternatives: 'For a surfaced tier-2/3 overlap, call get_resolution_context... To actually apply the safe tier, use arbiter_apply.' This provides clear when/when-not guidance.
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?
With no annotations provided, the description fully discloses behavior: returns intent/hasActiveIntent and activeIntents, explains status semantics (active vs terminal states), and describes the multi-active model. It implies no side effects (read-only check) and details response composition.
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 bolded requirement, bullet points, and sections. It is informative but slightly lengthy; however, every sentence contributes value. Some minor redundancy could be trimmed, but overall efficient.
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 covers the return shape (intent, hasActiveIntent, activeIntents) and status semantics. It could be more explicit about the full structure of the intent object, but provides enough for an agent to use 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 adequate descriptions for each parameter. The tool description itself does not add further parameter semantics beyond the schema, so baseline 3 is appropriate. Nested object forkAuthor is described sufficiently in 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 returns the current session's active intent, with explicit verb 'Returns' and resource 'session's current intent'. It distinguishes from siblings by mentioning 'PER SESSION' and referencing create_and_activate_intent for when no intent exists.
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?
Starts with 'REQUIRED: Call this tool BEFORE writing any code', providing a clear when-to-use directive. It also instructs to call create_and_activate_intent if no active intent, explicitly guiding the agent on next steps. The multi-active model explanation further clarifies context.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's actions: updating status, storing commit SHA, clearing the active intent. It details three possible response outcomes (success, transient failure, deferred conflicts) and instructs the agent on how to respond to each. This is exemplary transparency.
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 with clear sections, bullet points for outcomes, and front-loaded purpose. While it could be more concise, every sentence adds necessary detail for correct tool invocation. The organization aids readability despite the length.
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 (9 parameters, nested objects, no output schema), the description is remarkably complete. It covers all aspects: tool action, parameter usage, response handling, edge cases (transient failures, deferred conflicts), and even provides scripts for the agent to follow. This fully compensates for the lack of output schema and ensures the agent can 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 are described in the schema (100% coverage), so the description's added value is in explaining parameter interactions and conditional usage (e.g., 'supersededBy' required when status is 'superseded', 'humanApproved' only for cross-author intents). This enhances understanding beyond schema definitions, justifying a score above baseline 3.
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: 'Mark the active intent as completed and clear it.' It specifies the verb ('complete') and resource ('active intent'), and distinguishes from sibling tools like 'update_intent' by focusing on completion and clearing. The description also provides concrete use cases (after git commit) and lists status values, making it highly specific.
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 extensive usage context, including when to call (after successful git commit) and detailed response handling for different outcomes. It also explains status values and when to use parameters like 'humanApproved'. However, it does not explicitly state when NOT to use this tool or name direct alternatives, which is a minor gap. Still, the guidance is thorough and actionable.
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?
Despite no annotations, the description thoroughly explains the multi-active model, no lock conflicts, conflict detection behavior, and the effect of force parameter. 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?
Well-structured and concise. Front-loaded with purpose and when-to-use, then details on multi-active model and conflict handling. Each sentence is informative.
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 the main workflow, conflict handling, and parameter explanations. No output schema, so return info is not expected. Some minor details like the exact return behavior on success could be added, but overall complete for a tool with 9 params.
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 context for force (after conflict review), auto-detection for repoOrigin and workspaceId, and explains forkAuthor and workspaceId as override/testing. Adds significant value 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 tool creates an intent and activates it for the current session. Distinguishes from sibling tools like check_active_intent and activate_intent by describing the workflow.
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 (after check_active_intent returns none), prerequisite steps (summarize, get user confirmation), and how to handle conflicts (present to user, retry with force). Also addresses multi-active model.
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 transparency burden. It explains the tool finds and returns scored conflict candidates with specific fields, and notes the list is informational. This sets appropriate expectations. It does not explicitly state whether it modifies data, but given the purpose, it is clearly read-only. Minor improvement could be an explicit read-only hint.
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-organized with a clear summary, 'When to use' section, 'Inputs of note', 'Returns' section with bulleted fields, and a closing note. Every sentence adds value with no redundancy. It is concise yet comprehensive.
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 (6 parameters, no output schema, nested objects), the description covers all essential aspects: tool purpose, appropriate usage scenario, key inputs with rationale, and the structure of the return value. It fits well among sibling tools without gaps. No further detail is needed for typical 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 description coverage is 100%, so baseline is 3. The description adds value by highlighting intentId and minScore with contextual explanations beyond the schema ('the active intent to check against', 'minimum match score to include in results'). For other parameters (repoPath, forkAuthor, etc.), the schema descriptions suffice. This extra context for key parameters justifies a 4.
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 specific verb 'find' and resource 'conflicting intents' from other team members against the active intent. It clearly distinguishes from sibling tools like list_team_intents (which lists all team intents) and get_intents_for_file (by file), making the tool's unique purpose immediately clear.
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: Before committing, to surface overlapping team work so the user can coordinate before merging.' This provides clear situational guidance. While it doesn't list explicit alternatives or exclusions, the use case is well-defined and implies when not to use (e.g., when only listing intents). Could include more explicit 'when not to use' but still strong.
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?
Discloses that only ephemeral session decisions are editable and that synced decisions are immutable. Notes that forkAuthor and workspaceId are auto-resolved. Could add more on side effects or reversibility, but given no annotations, it's strong.
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: a one-line summary, bulleted actions, a constraint sentence, and a purpose sentence. No wasted words, well organized.
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 mutation tool with no output schema, the description adequately covers purpose, usage constraints, and parameter context. Slightly incomplete in not describing return values, but overall sufficient for 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 description coverage is 100%, so baseline is 3. Description adds value by noting auto-resolution for forkAuthor and workspaceId and clarifying actions, but doesn't elaborate on updates fields 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?
The description clearly states 'Edit or delete a decision in the current session.' It distinguishes from sibling tools like record_decision (create) and get_session_decisions (read) by specifying this is for reviewing before commit.
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 ('when reviewing decisions before commit'), provides the two actions (update/delete), and explicitly warns that synced decisions are immutable, directing to use record_decision with supersedes instead.
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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: runs asynchronously, returns immediately with a started/pending status, progress reported separately, and optional persistence via `repoPath`. This adds significant context about the tool's operation beyond a simple function call.
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 sections (When to use, Inputs, Behavior) and uses concise bullet-style prose. Every sentence adds value, with no redundancy. It is front-loaded with the key purpose and usage, making it easy to scan.
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 (6 parameters, nested objects, async behavior, no output schema), the description covers purpose, usage, parameters, and behavior well. However, it lacks specification of the output or return value structure. It mentions 'started/pending status' but does not describe what the final result looks like, which is a gap since there is no output schema to compensate.
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 adds meaning beyond the schema: explains that `stories` come from a previous `infer_history` run, `repoPath` triggers persistence, `model` specifies an Anthropic model, and that `forkAuthor`, `repoOrigin`, `workspaceId` are usually auto-resolved. This enriches parameter understanding.
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: 'Curate a set of previously extracted stories so that only the decisions still worth keeping are persisted.' It distinguishes from the sibling tool `infer_history` by noting that it is rarely needed standalone because `infer_history` already chains this step. This makes the tool's purpose specific and differentiated.
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: after `infer_history` in story-only mode or when re-curating pre-existing stories. It mentions that `infer_history` already chains this step automatically, implying the rare case. However, it does not explicitly list when not to use or compare to other sibling tools beyond `infer_history`.
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, 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?
No annotations provided, so description carries full burden. It discloses the return fields (rationale, context, etc.) and the 'found: false' case. It implies higher cost than recall surfaces, adding valuable behavioral context. Lacks explicit read-only statement but 'get' implies it.
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 concise, well-structured, and front-loaded. First sentence states purpose, followed by usage guidance, input list, and return details. No waste—every sentence earns its place.
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, description fully explains return values. It covers purpose, usage, parameters (key one detailed), return fields, and error case. For a simple read tool with moderate complexity, it is 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 has 100% description coverage, baseline 3. Description adds important context for decisionId (source from recall result), which surpasses baseline. Other params are not elaborated in description but are clear in 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 'Expand one decision to its full detail' with a specific verb and resource. It distinguishes from sibling tools by contrasting with recall surfaces that return summaries only.
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 clearly states when to use this tool (after getting summaries from recall surfaces) and when not to (when summary suffices). It names specific alternative tools (get_relevant_context, get_project_decisions, get_session_decisions).
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 are provided, so the description carries the full burden. It discloses the return values (title, counts, warnings) but does not explicitly state that the tool is read-only or has no side effects—it's implied by 'get'.
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: two paragraphs, no wasted words. The first sentence states the purpose, and the rest provides usage context with an example.
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 4 parameters (1 required, 1 nested) and no output schema, the description covers the return value components well. It could mention that forkAuthor and workspaceId are auto-resolved, but the schema descriptions already hint at 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 baseline is 3. The description does not add extra meaning beyond the schema; it only summarizes what the tool returns.
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 ('Get') and resource ('uncommitted changes... along with active intent info'), clearly distinguishing it from sibling tools like 'check_active_intent' or 'get_intents_for_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 states to use this tool 'before prompting the user about committing' and explains the output components, but does not mention when not to use it or alternatives.
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?
With no annotations, the description carries full burden. It discloses return value details (author, status, line ranges) and implies read-only behavior. No side effects or contradictions noted. Could mention if the operation is expensive, but adequate for a read tool.
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?
Two paragraphs: first line is the core action, then bullet points for usage. Every sentence adds value—no fluff. Front-loaded with the verb and resource.
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 5-parameter tool with no output schema and no annotations, the description covers the tool's purpose, usage context, and return value. It could add more detail about corner cases, but it's complete for typical 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 description coverage is 100%, so all parameters are already documented in the schema. The description adds no additional parameter-level semantics beyond the tool's overall purpose. 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 starts with a clear verb+resource: 'Get all intents that have code blocks in this file.' It distinguishes from sibling 'get_intents_for_lines' by specifying file-level scope. The addition of usage context further clarifies its purpose.
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 modifying a file' and lists specific scenarios (see work in progress, identify conflicts, understand context). While it does not mention when not to use or compare to alternatives, the guidance 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?
No annotations provided, so description carries the burden. It discloses conflict-checking behavior and return of overlap details, but does not explicitly state the tool is read-only or describe side effects like rate limits or permissions.
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: two sentences with bullet points. Front-loaded with purpose, then usage guidance. No superfluous 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?
No output schema, but description mentions return of overlap details. Explains core use case and behavior well. Lacks detail on output format and edge cases, but sufficient for selective 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% with descriptions for all parameters. The description does not add further detail about parameter semantics beyond the schema, meeting the baseline but not exceeding it.
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 retrieves intents for a specific line range, and implies differentiation from sibling tool 'get_intents_for_file' which operates on entire files.
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: before modifying lines to check for conflicts. Lists benefits (warns about overlaps, avoids merge conflicts) but does not mention when not to use or compare with alternative conflict-detection tools.
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?
No annotations are provided, so the description carries the full burden. It discloses that decisions are summary-only and mentions related files and constraint violations. However, it does not address performance, authentication, or whether the operation is read-only. This is adequate but not comprehensive.
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 bullet points and clear sections. It is front-loaded with the main purpose. While it includes details on return structure, this is helpful given the lack of an output schema. Slightly verbose but efficient.
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 no output schema and 4 parameters, the description covers the return format well, detailing each decision field. It also notes the need for get_decision_detail for full information. Adequately 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 the schema already documents all parameters. The description adds minimal extra meaning beyond stating that some parameters are auto-resolved. 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 all decisions recorded for a project across all intents.' It uses a specific verb ('get') and resource ('decisions') with a clear scope, distinguishing it from siblings like get_session_decisions and get_decision_detail.
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 clear usage scenarios ('Use this to review the project's decision history') and lists concrete use cases. While it does not explicitly state when not to use or name direct alternatives, the sibling tool names imply differentiation.
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 carries the full burden. It discloses return types (relevantIntents, relevantDecisions), notes that decisions are summary-only, and suggests get_decision_detail for full rationale. It does not mention auth or read-only nature, but the tool is clearly non-destructive.
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 sections: main purpose, when to use, inputs of note, returns, recommended sequence. It is front-loaded with the core purpose, and every sentence adds value 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 9 parameters, 100% schema coverage, no output schema, the description explains return values and usage sequence. It provides enough context for an agent to decide when and how to use the tool, including prerequisites and follow-up steps.
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 explaining the purpose of key parameters: prompt (paraphrase allowed), activeFiles (improves relevance), maxIntents/maxDecisions/minRelevance (result-shaping), and forkAuthor/workspaceId (auto-resolved). This helps the agent use parameters correctly.
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 'Find past intents and decisions relevant to the current user request.' It uses specific verb-resource, and distinguishes from sibling tools like get_intents_for_file by returning both intents and decisions, and by being task-specific.
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 provides 'When to use' conditions, advising against vague prompts and recommending use after initial exploration. It also gives a preferred use case for large projects. However, it does not explicitly name sibling tools as alternatives or state when not to use this tool.
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?
With no annotations, the description carries the full behavioral disclosure. It explains the tool returns peerSnippet, decisions, and a guardrail policy, and explicitly states it is 'advisory and proactive (no lock)' and does not modify state. This provides strong transparency, though it could mention potential side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, and each sentence contributes meaning. However, it is somewhat lengthy with a bullet list and repeated emphasis on policy; a slightly tighter structure would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, nested objects, no output schema), the description covers the tool's trigger, return values, and behavioral policy thoroughly. It lacks explicit output format details but compensates with detailed guardrail instructions and context for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 8 parameters. The tool description adds context for how the returned guardrail guides parameter usage, but does not significantly enhance individual parameter meanings beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves live code collisions with a peer, specifying the verb 'resolve' and the resource 'code collision with a peer'. It contrasts with sibling tools like 'detect_intent_conflicts' and 'arbiter_resolve', making its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to call the tool (when a Stop hook collision report surfaces a live peer) and advises it's proactive and advisory. While it doesn't list alternatives or when not to use, the context is sufficiently clear for an agent to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 are provided, so the description carries full burden. It discloses that decisions are 'summary-only' and that they can be edited or removed via other tools (implying mutability). It does not mention side effects or permissions, but for a read-only retrieval tool, the disclosure is 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 very concise: three clear sections (purpose, usage, return format). Bullet points are used for returns. 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 5 parameters, 2 required, no output schema, the description covers the return structure (intentId, decisions, count) and notes that decisions are summary-only. It provides enough context for correct invocation and interpretation of results, though a note on optional parameters like forkAuthor would be nice but not essential.
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% (all 5 parameters have descriptions in the schema). The tool description does not add any additional parameter meaning beyond the schema. Baseline is 3, and no extra value is 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?
The description starts with a clear verb-resource pair: 'Get all decisions recorded in the current session for an intent.' This distinguishes it from siblings like get_decision_detail (full decision) and record_decision (create). It precisely identifies what is retrieved and the scope.
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: 'Use this before committing to review what decisions were captured during development.' Also tells when not to use alternatives: for full rationale, call get_decision_detail. This provides clear decision-making guidance for the agent.
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?
With no annotations, description fully discloses async behavior, persistence, resume logic, re-run guard with force, and forge detection. Covers edge cases like non-default branches.
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 with sections, but somewhat lengthy. Every sentence earns its place, but could be tightened.
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 and no output schema, description comprehensively covers interactions, async behavior, error states, and re-run logic. Highly 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?
Adds significant value beyond 100% schema coverage—explains mutual exclusivity of commits/commitRange, defaults, and usage context for each parameter.
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 it analyzes git commit history to produce structured intents/decisions. Distinguishes from sibling tools that manage intents/decisions but don't infer them from history.
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: bootstrap repos or extend coverage. Provides context on default branch and force flag, but could mention alternative tools more directly.
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, the description carries full burden. It explains server-side filtering and pagination (default 50 per page, limit/offset, count meaning). However, it does not state that the operation is read-only or mention auth/rate limits.
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: a short introductory sentence, bullet points for use cases, then a concise paragraph on filtering/pagination. It is front-loaded and avoids 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?
Given 10 parameters and no output schema, the description covers basic behavior and pagination but lacks details on return format or how to interpret results. Parameters like forkAuthor and workspaceId are mentioned but not fully explained.
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 context about server-side filtering and pagination behavior for limit/offset/count, but does not significantly enhance individual parameter meanings 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 'List intents from team members for this repository' with a specific verb and resource. It distinguishes from siblings by focusing on team-wide listing, while other tools deal with creation, activation, or 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?
The description explicitly lists use cases: 'See what your team is working on', 'Check for potential overlapping work', 'Review the status'. It provides clear context but does not explicitly mention when not to use it or alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses deprecation and planned removal, but does not describe any other behavioral traits (e.g., what happens when called, side effects, or permissions). The deprecation status itself is a key behavioral disclosure.
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 very concise and front-loaded with the critical deprecation note. Every sentence serves a purpose, and there is no wasted text. It efficiently communicates the key message.
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 is sufficiently complete in telling agents to avoid it. However, it lacks information about the original purpose of log_work, which might be relevant for understanding legacy workflows. Given the deprecation, 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 coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning about parameters, meeting the baseline of 3.
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 focuses on deprecation and instructs not to use the tool, but does not clearly state what the tool originally did. It mentions trivial changes should skip the intent workflow, but the tool's function is implied rather than explicitly described.
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 'Do not call this tool' and provides context for when it is unnecessary (trivial changes). It gives clear guidance to avoid using it, but does not explain when alternatives like other tools should be used.
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?
No annotations provided, so description carries full burden. Discloses in-memory cache, reset on server exit, silent dedup, and return values (acknowledged count, cacheSize). Could mention error cases or side effects more explicitly.
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 front-loaded with purpose, then usage, then behavior, then returns. Some redundancy (e.g., 'the rest of this session' appears twice), but overall each section serves a purpose. Could be slightly shortened.
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, description explains return values. Covers lifecycle, dedup behavior, and session scoping. Missing details on error handling (e.g., invalid decision IDs) and if there are any side effects.
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 context: repoPath enables repo attribution, forkAuthor and workspaceId auto-resolved, sessionToken defaults to SESSION_ID. This adds value 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: 'Mark decisions as consciously overridden for the rest of this session.' It specifies the context (Phase 3 PreToolUse hook) and differentiates from sibling tools like pre_edit_decision_check and 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?
Explicitly says when to use: 'when the agent passes force: true on an Edit tool call to bypass a pre_edit_decision_check block.' Also provides an alternative: 'For persistent override across sessions, record a fork decision via record_decision(type: "fork", supersedes: [<id>]) instead.'
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 provided, the description must disclose behavioral traits itself. It explains what the tool surfaces (Tier 1a, Tier 1b), that overridden decisions are filtered out, the recommendation mapping, and the return of the smallest enclosing function symbol (with language limitations). It does not detail side effects or performance, but the read-only nature is implied. Sufficient transparency for an 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 well-structured with front-loaded purpose and separate paragraphs for tiers, filtering, recommendation mapping, and extra return value. While somewhat verbose, each sentence adds necessary detail. Minor room for tightening, but overall 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?
Despite lacking an output schema, the description adequately conveys the return value (recommendation with actions and a function symbol). It covers when to use, what data is surfaced, and filtering logic. For a 9-parameter tool with nested objects, this is sufficient for an agent to invoke and interpret 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 coverage is 100%, so baseline is 3. The description adds value by explaining that intentId is auto-detected, and that forkAuthor, workspaceId, and sessionToken are usually auto-resolved. It also clarifies that repoPath is used to read the file for AST symbol detection. This goes 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 what the tool does: 'Check whether the line range about to be edited has prior recorded reasoning attached.' It details two tiers of surfaced context (Tier 1a and Tier 1b), explains what is no longer reported, and maps recommendations to actions. This is highly specific and distinguishes it from sibling tools like pre_edit_acknowledge or get_resolution_context.
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 says 'Call this BEFORE editing code in a kawa-indexed repo,' providing clear usage context. It also notes that live-collaborator awareness is handled elsewhere, implicitly guiding when not to rely on this tool for collisions. However, it does not explicitly list alternative tools for other scenarios.
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) | |
| 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 provided, so description carries full burden. Discloses silent recording, accumulation behavior, and constraintViolations requirement. Does not cover auth, rate limits, or detailed 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?
Well-structured with bullet points and sections. Front-loaded purpose. Slightly verbose but every sentence adds value; could be tightened.
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 21 parameters and no output schema, description fully explains workflow, decision types, scoping, and important usage notes. Feels complete for the tool's purpose.
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?
100% schema coverage so baseline 3. Description adds value by highlighting key param guidance (omit intentId for repo-scoped, include constraintViolations) beyond 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?
Clearly states 'Silently record a decision point during development' with specific verb and resource. Lists exact decision types and distinguishes from read/edit siblings like get_session_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?
Explicit conditions for calling (fork, abandoned, discovery, etc.) and scoping rules (intent-scoped vs repo-scoped). Lacks explicit when-not-to-use or comparisons to other tools.
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, description covers key behavioral traits: additive only, skips already assigned intents, runs in Kawa Code desktop app, returns feature count. Could mention reversibility or permissions 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?
Description is concise and well-structured: purpose first, then usage, then behavior bullets. No wasted words, 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?
Given one parameter and no output schema, description provides all needed information: what it does, when to use, behavioral details, and return value. 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?
Only parameter repoPath has full schema coverage. Description does not add extra meaning beyond schema's 'Local path to the repository root'. 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?
Description clearly states it updates the project's feature catalog from recorded intents. It specifies the additive nature and contrasts with other tools by focusing on feature catalog updates.
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' section with two specific scenarios. Lacks explicit when-not-to-use or alternative tools, 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.
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 carries full burden for behavioral transparency. It explains that intents are living documents and gives common triggers, but does not disclose side effects, authorization needs, or whether the update is atomic. The description is adequate but lacks depth about error states or confirmation.
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, well-structured, and front-loaded with the core purpose. It includes a brief intro, a paragraph with usage triggers, and a note about intentId. No unnecessary words or 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 tool's straightforward nature (updating fields) and high schema coverage, the description covers the main purpose and usage context. It lacks detail about return values or error handling, but since there is no output schema, and the action is simple, it is reasonably 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 baseline is 3. The description adds value by explaining that intentId defaults to the active intent and provides rationale for updating intents. However, for most parameters, the schema already describes them well; the description does not add significant new semantics beyond the schema except for the default behavior.
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 verb (update) and resource (intent), lists the updatable fields (title, description, scope, constraints), and distinguishes its purpose as reformulating intents as understanding evolves. This is specific and differentiates it from creation or completion tools.
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 clear context on when to use the tool: when understanding evolves, with common triggers listed. It also clarifies the behavior when intentId is omitted. However, it does not explicitly mention when not to use it or compare with sibling tools like create_and_activate_intent or complete_intent, leaving some ambiguity.
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.8.1activate_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_intentTools are mostly distinct, with clear descriptions differentiating similar ones like get_session_decisions and get_project_decisions. However, there is some potential confusion between check_active_intent and get_intent_changes, and between pre_edit_decision_check and pre_edit_acknowledge, though descriptions help.
All tool names use snake_case, which is consistent. However, the naming pattern varies: some use verb_noun (e.g., check_active_intent), while others use more complex prefixes like pre_edit_ or arbiter_. This minor inconsistency prevents a perfect score.
25 tools is on the higher end, but the scope of the server—managing intents, decisions, and conflicts—justifies the count. Some tools could be merged (e.g., get_session_decisions and get_project_decisions), but overall the number is reasonable for the domain.
The tool surface covers the full lifecycle of intents and decisions, including creation, activation, tracking, conflict detection, and resolution. Minor gaps exist, such as no tool to list all active intents (only team intents), and no direct deletion tool for intents, but these are manageable.
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.
One shared brain for your AI coding agents: team memory, agent Q&A, tasks, and file claims.
Shared debugging memory for AI coding agents
Shared memory for coding agents. Stop re-explaining your codebase every session.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kawacode-ai/kawa.mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
