Skip to main content
Glama

session_detect_drift

Detects when an agent session diverges from its original goal by scoring semantic alignment. Provides warnings for goal drift, context collapse, and quality degradation.

Instructions

Detect whether the current agent session has semantically drifted from its original goal. Scores recent ledger entries against the goal using synalux's HRR embedding stack (GloVe → Gemini/Voyage → cosine similarity), then runs the rolling-window drift detector algorithm.

Triggers:

  • goal-drift — cumulative alignment loss is high and monotonic (not random tangents)

  • context-collapse — average output quality has dropped below floor

Pre-warning:

  • quality-degrading — quality slope steeply negative before collapse

Returns: drifted, reason, warning, drift_score (0..1), goal_alignment, quality_avg, sample_count, adaptive_threshold, recommendation.

Use alongside GATE 5 (60-minute drift check): call this tool instead of session_cognitive_route for goal-alignment drift detection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesThe original session goal — the task you started this session to accomplish. Used as the semantic reference vector. Be specific: 'implement drift detection for prism-mcp' is better than 'work on prism'.
domainNoOptional domain for domain-specific drift signals. 'coder' adds file_entropy, summary_vagueness, test_coverage_ratio, trajectory_divergence. 'bcba' adds clinical_specificity, function_aligned, contraindication_safe (requires behavior_functions, contraindications, client_descriptors params). 'aac' is reserved for future AAC prediction drift (use the AAC-specific endpoint instead).
projectYesProject identifier. Must match the project used in session_save_ledger.
window_hoursNoHow many hours of ledger history to evaluate. Default 1. Range 0.083–24 (5 min to 24 h).
assessment_typeNoBCBA domain only: assessment instrument name (e.g. 'vb-mapp', 'vineland', 'ablls-r').
conversation_idNoOptional. Session key (same id used in session_load_context). When provided, resets the server-side drift timer for this conversation.
contraindicationsNoBCBA domain only: known medical conditions (e.g. ['epilepsy', 'pica']).
behavior_functionsNoBCBA domain only: identified behavior functions for this client (e.g. ['escape-maintained', 'attention-maintained']).
client_descriptorsNoBCBA domain only: client-specific terms to check for specificity (e.g. ['7-year-old', 'aggression at transitions']).
min_directional_ratioNoDirectional ratio floor for the tremor filter (0..1). Random topic tangents that return to the goal are suppressed below this threshold. Default 0.2. Set to 0 to disable filter.
Behavior3/5

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

No annotations provided, so description carries full burden. It explains the algorithm and return values but does not disclose side effects, permissions, rate limits, or error conditions. It implies a read operation but does not explicitly confirm safety.

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?

Well-structured with clear sections: purpose, triggers, pre-warning, returns. Each sentence adds value. Slightly long but no wasted words.

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?

Given no output schema and no annotations, the description covers detection logic, triggers, return fields, parameters, and usage. Lacks details on error handling and performance, but sufficient for selection among siblings.

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% with detailed property descriptions. The tool description adds extra context (e.g., specificity recommendation for goal, domain-specific signals), improving understanding beyond the schema.

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 detects semantic drift from the original goal using specific methods. It distinguishes itself from sibling tool 'session_cognitive_route' by explicitly saying to call this tool instead for goal-alignment drift detection.

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?

The description provides explicit triggers (goal-drift, context-collapse) and pre-warning (quality-degrading). It gives direct usage guidance: 'Use alongside GATE 5... call this tool instead of session_cognitive_route for goal-alignment drift detection.' This tells when and when not to use it.

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/dcostenco/prism-coder'

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