Skip to main content
Glama
Sign In
Linksee Memory

Linksee Memory

by michielinksee
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

drift_status

Check current decision drift across projects to see which decisions, constraints, and hypotheses are misaligned, need review, are held, or aligned; filter by domain or inspect one anchor.

Instructions

Check what's drifting right now ā€” the "Intent Datadog" for your product decisions.

Returns a structured truth map showing which decisions/constraints/hypotheses are: šŸ”“ drift (unaccounted divergence from intent) šŸŸ” review (soft signal, awaiting human decision) āšŖ held (acknowledged, time-boxed, not forgotten) šŸ”µ aligned (reality matches intent)

Nodes are classified into 4 species: ā€¢ hypothesis ā†’ Decision Cards (decision journal format) ā€¢ constraint ā†’ Rules (pass/fail checklist) ā€¢ commitment ā†’ Heartbeats (cadence monitoring) ā€¢ source_of_truth ā†’ Reference (stable anchors)

WHEN TO CALL: ā€¢ At session start ā€” "what needs my attention?" ā€¢ Before making a decision ā€” check for existing anchors on the topic ā€¢ After completing work ā€” verify drift state changed ā€¢ When the user asks about product health / what's broken / what's stale

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "drift_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainNoFilter by domain (strategy, product, engineering, growth, etc.)
verboseNoReturn full aligned nodes and all candidates. Default is compact: attention items in full, aligned as id+statement per domain, candidates as counts.
anchor_idNoDeep-dive into ONE decision instead of the map: its state, premises, drift edges, pending candidates. (Absorbs check_decision.)
decision_modeNoFilter by decision_mode (hypothesis, constraint, commitment, source_of_truth)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does disclose return structure (four states, four species, per-domain compact vs. verbose output) and the anchor_id deep-dive mode, but never states explicitly that this is a read-only, side-effect-free operation, nor any permission or performance characteristics.

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

Conciseness4/5

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

Front-loaded with the core action, then scannable bullets for states, species, and triggers. Slightly padded by branding language ('Intent Datadog') and emoji, but every bullet conveys usable information.

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?

There is no output schema, so the description must explain return values, and it does reasonably: the four drift states, the four node species, and compact-vs-verbose output shape. What's missing is any statement of read-only safety and what to do next with a flagged node (the handoff to resolve_drift).

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%, so the baseline is 3; the description adds value by expanding decision_mode into the four species and mapping each to its artifact format (Decision Cards, Rules, Heartbeats, Reference), which the schema only lists as bare strings with no enum. The meaning of the šŸ”“/šŸŸ”/āšŖ/šŸ”µ states returned per node is also only defined here.

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

Purpose4/5

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

States a specific verb and resource ('Check what's drifting right now') and immediately defines the payload as a truth map of decisions/constraints/hypotheses. It distinguishes itself from the memory siblings (remember/recall/declare_anchor/resolve_drift) by being the read/status view, but never names those siblings explicitly.

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 WHEN TO CALL block gives four concrete triggers (session start, before a decision, after completing work, user asks about product health), which is well above typical. It stops short of stating when NOT to use it or routing to alternatives ā€” e.g. that resolve_drift is the tool for actually clearing a flagged item.

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

Deploy Server

Other Tools