Skip to main content
Glama

record_decision

Record development decision points—forks, tradeoffs, constraints—to build a reasoning changelog that captures why choices were made.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesType 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)
sourceNoProvenance: 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.
contextNoWhat we were trying to accomplish when this decision was made
summaryYesBrief summary of the decision (< 100 chars recommended)
symptomNoObservable symptom that indicates this decision is relevant (e.g., error messages, runtime panics, unexpected behavior). Useful for discovery and constraint decisions.
intentIdNoThe intent ID this decision belongs to. Omit for repo-scoped decisions (discoveries, constraints) not tied to a specific work unit
repoPathYesLocal path to the repository root (enables offline sync)
rationaleYesWhy this decision was made
confidenceNoSelf-rated confidence in the decision. Meaningful only for extractor and infer_history sources — leave null for deliberate recordings.
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
supersedesNoDecision 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.
appliesWhenNoTrigger 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.
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
alternativesNoOther options that were considered
consequencesNoDownstream implications of this decision
relatedFilesNoFile paths affected by this decision
sourceThoughtIdsNoThought-chain entry IDs this record was extracted from. Only set by the extractor path.
resolvedCollisionNoLayer 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.
constraintsCheckedNoWhich architectural constraints were verified before this decision
constraintViolationsNoAlternatives that were rejected due to constraint violations
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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