Skip to main content
Glama

add_decision

Record architectural decisions, tech choices, or conventions with links to code files and symbols. Each decision includes temporal validity and can be invalidated later.

Instructions

Manually record an architectural decision, tech choice, preference, or convention. Links to code symbols/files and optionally to a specific subproject for code-aware memory. Decisions have temporal validity — they can be invalidated later when they become outdated. Mutates the decision store (creates a new record). For automated extraction from session logs use mine_sessions instead. Returns JSON: { added: { id, title, type } }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesShort summary of the decision
contentYesFull decision text — reasoning, context, tradeoffs
typeYesDecision type
service_nameNoSubproject name this decision is about (e.g., "auth-api", "user-service")
symbol_idNoSymbol FQN this decision is about (e.g., "src/auth/provider.ts::AuthProvider#class")
file_pathYesFile path this decision is about
tagsNoTags for categorization (e.g., ["auth", "security"])
git_branchNoGit branch this decision belongs to. Omit to auto-detect from the project root, or pass null to make the decision branch-agnostic (visible from every branch).
Behavior4/5

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

Annotations already indicate mutation (readOnlyHint=false). The description adds that it mutates the decision store, creates a new record, returns JSON with added id/title/type, and mentions temporal validity and future invalidation. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences with clear structure: purpose, features, lifecycle, mutation statement, alternative, return format. Every sentence is necessary and no extra words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description explicitly defines the return format. Covers main usage, parameter roles (linking, subproject), and lifecycle. The sibling tool alternative is provided. Sufficient for a creation tool.

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?

Schema coverage is 100% with descriptions for all 8 parameters. The description adds value by explaining linking to symbols/files and subprojects, and details the git_branch auto-detect vs null behavior. This exceeds the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool records architectural decisions, tech choices, preferences, or conventions. It distinguishes itself by specifying manual recording and linking to code symbols/files, differentiating from automated extraction via mine_sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use mine_sessions instead for automated extraction, but does not provide guidance on other related tools like approve_decision or invalidate_decision. Still, it offers a clear alternative and context for manual recording.

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/nikolai-vysotskyi/trace-mcp'

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