Skip to main content
Glama
LiLara-AI

ShadowGraph

Official

shadowgraph_update_status

Move a decision to a new lifecycle state to record its progress, outcome, or abandonment.

Instructions

Move one decision to another lifecycle state. shadowgraph_supersede replaces a decision, shadowgraph_maintain alone produces stale, shadowgraph_record_outcome records the result. stale and superseded are system-owned and rejected. Setting the current state writes nothing but still commits a revision.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYesTarget state. Legal moves are proposed to planned/in_progress/abandoned/archived; planned to in_progress/abandoned/archived; in_progress to executed/failed/abandoned/archived; executed to validated/failed/reconsidered/archived; validated to reconsidered/archived; failed to reconsidered/abandoned/archived; reconsidered to planned/in_progress/abandoned/archived; stale to reconsidered/archived; abandoned to archived. stale and superseded cannot be set by a caller.
decisionIdYesIdentifier of an existing decision, as returned by shadowgraph_record_decision, shadowgraph_search, or shadowgraph_retrieve.

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.3/5.0
Behavior4/5

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

The description adds meaningful non-obvious behavior beyond the annotations: stale and superseded are system-owned and rejected, and setting the current state 'writes nothing but still commits a revision.' This clarifies side effects and edge-case behavior. It does not contradict the annotations, and the annotations already signal a mutating operation.

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?

Three short sentences cover the core action, sibling differentiation, and two important behavioral caveats. The main purpose is front-loaded, and every sentence adds value without redundancy.

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 two-parameter tool with a fully documented schema and an output schema present, the description covers the operation, alternatives, restrictions, and the subtle current-state behavior. Nothing essential for correct invocation is missing.

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?

Schema description coverage is 100%, and the status parameter's legal-move matrix is fully documented in the schema. The description adds general operational context but does not need to restate parameter details. Baseline 3 is appropriate because the schema carries the parameter-semantics burden.

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 opens with a specific verb and resource: 'Move one decision to another lifecycle state.' It also differentiates this tool from close siblings by noting what shadowgraph_supersede, shadowgraph_maintain, and shadowgraph_record_outcome do, making the tool's purpose unmistakable.

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 gives useful context for choosing among related tools by contrasting update_status with supersede, maintain, and record_outcome. It also states constraints such as stale and superseded being system-owned. It does not explicitly spell out a 'use X when...' rule, but the alternatives are clearly named and their roles distinguished.

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