decisionnode/DecisionNode
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_decisionsA | MANDATORY: Call this FIRST before ANY code changes. When user asks you to: add a feature, modify code, fix a bug, implement something, refactor, style UI, or make ANY technical choice — you MUST call this tool FIRST to check for existing conventions. Skipping this causes inconsistency and wasted rework. Query with what you're about to work on: "button styling", "error handling", "API design", "authentication", "database schema", "component structure". If no decisions exist, proceed freely; if decisions exist, FOLLOW them. |
| list_decisionsA | List all recorded decisions for the project. Use this when you need a complete overview of project conventions, or when starting work on a new feature area to understand existing patterns. |
| get_decisionA | Get full details of a specific decision by ID. Use this after search_decisions returns relevant results to get complete context including rationale and constraints. |
| add_decisionA | Call this IMMEDIATELY when user says phrases like: "Let's use...", "From now on...", "Always do...", "Never do...", "I prefer...", "The standard is...", "We should always...", or confirms ANY technical approach. Also call when: (1) A design pattern is established, (2) An architectural choice is made, (3) Coding standards are discussed, (4) UI/UX conventions are agreed, (5) Technology stack decisions happen. Capture decisions DURING the conversation, not after. Focus on WHY, not just WHAT. |
| update_decisionA | Update an existing decision when requirements change or the approach evolves. Use this instead of creating duplicate decisions. |
| delete_decisionA | Permanently delete a decision. Only use when a decision was created in error. For outdated decisions, prefer update_decision with status=deprecated to preserve history. |
| get_historyA | View the activity log of recent decision changes. Use this to understand what decisions were recently added or modified. |
| get_statusA | Get project decision status overview including total count and last activity. Use this for a quick health check of the decision store. |
| list_projectsA | Call this FIRST if unsure which project to use. In monorepos or multi-project workspaces, this lists all projects with decisions. Match the returned project name to the subfolder in the user's active file path. Example: if user is editing ".../my-app/src/component.tsx", look for project "my-app" in the results. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool serves a distinct purpose: add/delete/get/update for individual decisions, list/search for retrieval, history for changelog, status for overview, and list_projects for context. No overlapping functionality.
All tools follow a consistent verb_noun pattern in snake_case, e.g., add_decision, search_decisions, list_projects. No mixing of styles or ambiguous verbs.
9 tools cover the decision management domain without excess or deficiency. Each tool earns its place, supporting CRUD, search, history, status, and project context.
The tool surface covers full lifecycle: creation, retrieval, update, deletion, listing, searching, history tracking, and status overview. No obvious gaps for typical decision management workflows.