Skip to main content
Glama
MatthewDegtyar

Claude Project History MCP Server

Record Decision

cph_decision_record

Record architectural, design, or process decisions to preserve institutional memory and explain why choices were made, including context, rationale, and alternatives.

Instructions

Record an architectural, design, or process decision.

This is the institutional memory of the project. Future sessions — and future engineers — will use this to understand why things are built the way they are.

Record a decision when:

  • You chose between two or more approaches

  • You made an assumption about requirements

  • The word "because" appears in your reasoning

  • You're doing something non-obvious that someone will question later

The post-commit hook will automatically attach the commit hash to recent decisions — you don't need to provide it manually.

Args:

  • workflow_id, title, decision: Required

  • context: What problem were you solving? What constraints existed?

  • rationale: Why this option over the alternatives?

  • alternatives_considered: Structured list of options evaluated and why rejected

  • trade_offs: What does this choice cost or foreclose?

  • tags: Comma-separated (e.g. "auth,database,performance") or array

  • reversibility: How hard is it to undo? (reversible | costly | irreversible)

  • confidence: How confident are you? (low | medium | high)

  • files_affected: Which files does this decision impact?

  • forcing_constraint: What external force required this decision now?

  • revisit_if: Under what conditions should this be revisited?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflow_idYes
titleYes
decisionYesThe actual choice made
contextNo
rationaleNo
alternatives_consideredNoStructured alternatives: [{option, rejected_because}]
trade_offsNo
task_idNo
tagsNoComma-separated tags or array
forcing_constraintNoWhat external force required this decision now?
unlocksNoWhat does this decision enable?
constrainsNoWhat does this decision prevent or limit?
revisit_ifNoUnder what conditions should this be revisited?
blocker_idNoBlocker this decision resolves
files_affectedNoFile paths affected by this decision
reversibilityNoHow hard to undo?
confidenceNoDecision confidence level
Behavior3/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false. Description explains it records decisions and mentions the post-commit hook, but does not disclose potential side effects (e.g., triggering notifications). Behavior is straightforward for a recording tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is somewhat lengthy with a detailed parameter list that partially repeats schema info. The usage guidelines are front-loaded, but the parameter section could be more concise.

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?

For a tool with 17 parameters and no output schema, the description covers purpose, usage scenarios, parameter semantics, and a behavioral note about commit hashes. It is fairly complete for successful invocation.

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 65%. Description adds meaning to parameters like 'context' (problem and constraints), 'rationale' (why this option), and 'alternatives_considered' (structured list). Enums for reversibility and confidence are described.

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's purpose: 'Record an architectural, design, or process decision.' It distinguishes itself from sibling tools like cph_decision_get, cph_decision_list, and cph_decision_search by focusing on recording new 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?

Provides explicit scenarios for when to record a decision (e.g., 'chose between two or more approaches', 'made an assumption about requirements', 'the word "because" appears'). It does not explicitly state when not to use, but the positive guidance is sufficient.

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/MatthewDegtyar/claude-project-history'

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