Skip to main content
Glama
LiLara-AI

ShadowGraph

Official

shadowgraph_record_decision

Record a decision with its chosen option, assumptions, evidence, and rejected alternatives, including rules for when to reconsider. Preserves the reasoning behind choices for later review.

Instructions

Record one decision: chosen option, assumptions, evidence, and rejected alternatives with reopenWhen rules. Use shadowgraph_record_attempt for something tried, shadowgraph_record_fact for an observation, shadowgraph_remember for a note. Appends a decision and a journal entry; without idempotencyKey each call adds another and commits a revision.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoWhat the decision is meant to achieve. Searchable content.
actorNoWho performed this write, such as an agent or person name. Stored for audit; never used to grant trust.
titleYesShort name of the decision. Required, non-empty, and searchable content.
chosenYesThe option actually chosen. Required, non-empty, and searchable content.
clientNoWhich client software performed this write, such as the host application name.
projectNoProject namespace. Defaults to "default"; an empty string is rejected.
evidenceNoSupporting evidence. Counted as declared evidence in the confidence basis, but never re-checked.
sessionIdNoCaller-owned identifier that groups related writes in the audit trail.
confidenceNoStarting confidence, 0-1. Defaults to 0.5. Later outcomes and evidence move it from this baseline; it is a degree of belief, never a verification status.
assumptionsNoWhat the decision takes for granted. Record each as a fact too if it should be able to reopen the decision.
sourceClassNoClaimed origin, never proof: agent_claimed (the default), tool_observed, human_confirmed, or production_verified. It weights confidence only. An unrecognised label downgrades to agent_claimed, kept verbatim in sourceRaw.
alternativesNoOptions considered and rejected. Alternatives belong to the decision and have no separate write API; they are what shadowgraph_review reconsiders.
idempotencyKeyNoRetry key scoped by project and operation: reuse it so a retry returns the first result instead of writing a duplicate. Without it every call creates a new entity.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesStable entity identifier.
goalNoWhat the decision was trying to achieve.
kindYesEntity kind: decision, attempt, memory, fact, relation, review, or alternative.
actorNoWho performed the write.
titleNoShort name of the decision.
chosenNoThe option that was chosen.
clientNoWhich client performed the write.
statusNoLifecycle state. Legacy records may carry a value this build does not recognise; shadowgraph_validate reports those.
outcomeNoThe recorded outcome, or null until one is recorded.
projectNoProject namespace; records imported from a schema that predates projects may carry null.
evidenceNoNormalised evidence entries: source, type, sourceClass, confidence, observedAt, detail.
createdAtNoISO 8601 creation time.
migrationNoPresent only on migrated records; records the legacy value a field was mapped from.
sessionIdNoSession identifier recorded with the write.
sourceRawNoThe original origin label when it differed from sourceClass. Audit only; never evidence.
updatedAtNoISO 8601 time of the last change.
confidenceNoAuditable confidence: initial, current (0-1), policy, a history entry per move, and a basis summarising the contributions it was folded from. Legacy records may lack basis.
supersedesNoIdentifiers of decisions this one replaced.
assumptionsNoAssumptions the decision rests on. Searchable content.
reviewAfterNoISO 8601 instant after which shadowgraph_maintain marks this decision stale.
sourceClassNoClaimed origin class recorded with the write. A claim, never proof.
alternativesNoRejected alternatives, each with id, label, reasonRejected, status, and the reopenWhen rules that make it reconsiderable.
supersededByNoIdentifier of the decision that replaced this one.
schemaVersionNoStorage schema version this entity was written under. A value above the build’s own version is preserved rather than downgraded.
failedAttemptsNoAttempt identifiers or notes attached to this decision.
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses the write behavior beyond the annotations: it 'appends a decision and a journal entry', says each call 'commits a revision', and flags the non-idempotent nature without idempotencyKey. This complements the sparse boolean annotations with actionable side-effect context.

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?

Two dense sentences earn their place: the first states the core action and content, the second routes to alternatives and reveals the side-effect/idempotency behavior. No filler and the most decision-relevant information is front-loaded.

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?

For a 13-parameter write tool, the combination of a fully documented schema, an explicit side-effect statement, and clear sibling routing leaves nothing essential missing. An output schema exists, so the description does not need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes all 13 parameters with 100% coverage, so the baseline of 3 applies. The description lightly signals the important parameters (chosen option, assumptions, evidence, rejected alternatives, reopenWhen rules) but adds no meaning beyond the schema's own field 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?

The description states a specific verb ('Record') and exact resource ('one decision') and enumerates the content it captures: chosen option, assumptions, evidence, and rejected alternatives with reopenWhen rules. It also distinguishes itself from sibling tools by naming shadowgraph_record_attempt, shadowgraph_record_fact, and shadowgraph_remember and what each is for.

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

Usage Guidelines5/5

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

It explicitly tells an agent when to pick this tool over closely related options ('Use shadowgraph_record_attempt for something tried, shadowgraph_record_fact for an observation, shadowgraph_remember for a note'). This is direct routing guidance rather than leaving the choice to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/LiLara-AI/shadowgraph'

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