Skip to main content
Glama

restore_context

Read-only
Resume work from a saved cognitive context.

This provides a narrative briefing to quickly orient you to:
- The investigation that was in progress
- Key discoveries and insights made
- Current hypotheses being tested
- Open questions and blockers
- Suggested next steps
- All relevant memories with their connections

The briefing reconstructs the cognitive state, not just the data. You'll understand
not just WHAT was discovered, but WHY it matters and HOW the understanding evolved.

Example of what you'll receive:
"[API Timeout Investigation - Resuming after 2 hours]

SITUATION: You were investigating production API timeouts that occur at exactly batch_size=100.
This investigation started when user reported timeouts only in production, not staging.

PROGRESS MADE:
- Identified sharp cutoff at 100 items (not gradual degradation)
- Disproved connection pool theory (monitoring showed only 43/200 connections used)
- Found root cause: MAX_BATCH_SIZE=100 hardcoded in batch_handler.py:147
- Confirmed staging uses different config override (MAX_BATCH_SIZE=500)

EVIDENCE CHAIN:
User report → Reproduced locally → Noticed batch_size correlation → Searched codebase for 
limits → Found MAX_BATCH_SIZE → Checked staging config → Discovered config difference

CORRECTED MISUNDERSTANDINGS:
- Initially thought it was Redis connection exhaustion (disproven by monitoring)
- Assumed gradual performance degradation (actually sharp cutoff)
- Thought staging/production were identical (config differs)

CURRENT HYPOTHESIS: Production deployment uses default MAX_BATCH_SIZE=100 from code, while 
staging has environment variable override. Fix requires either code change or prod config update.

BLOCKED ON: Need production deployment access to apply fix. User considering whether to 
change code default or add production environment variable.

RECOMMENDED NEXT STEPS:
1. Verify production environment variables (check if MAX_BATCH_SIZE is set)
2. If not set, add MAX_BATCH_SIZE=500 to production config
3. If code change preferred, update default in batch_handler.py
4. Run load test with batch_size=100-500 range to verify fix

KEY MEMORIES FOR REFERENCE:
- 'Initial timeout report from user' - Starting point of investigation
- 'MAX_BATCH_SIZE discovery' - Root cause identification
- 'Redis monitoring data' - Evidence disproving connection theory
- 'Staging config analysis' - Explanation for environment difference"

This cognitive handoff ensures you can continue the work with full understanding of
the problem space, previous attempts, and current direction. The narrative preserves not
just facts but the reasoning process, mistakes made, and lessons learned.

SPECIAL CASE: restore_context("awakening")
The name "awakening" is reserved for loading the user's personality configuration.
This loads the Awakening Briefing which includes:
- Selected persona identity and voice style
- Custom personality traits (Premium+ users)
- Any quirks and boundaries from the persona preset

Args:
    name: Name or ID of context to restore. Can be:
          - Context name (exact match, case-sensitive)
          - Context UUID (from list_contexts output)
          - "awakening" for personality briefing
    limit: Maximum number of memories to restore (default 20)
    ctx: MCP context (automatically provided)

Returns:
    Dict with:
    - success: Whether restoration succeeded
    - description: The cognitive handoff briefing
    - memories: List of relevant memories
    - context_id: The restored context identifier

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses that the tool is read-only (no mutations) and provides a cognitive briefing, which aligns with the readOnlyHint annotation. It adds details about the briefing content, memory limit, and the 'awakening' case, going beyond the annotations. No contradictions are present.

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

Conciseness3/5

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

The description is quite long with a detailed example, but it is well-structured with bullet points and clear sections. It could be more concise, but the length is justified by the need to explain the briefing format and special cases. The main purpose 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?

Given the tool's complexity (2 parameters, output schema), the description covers all aspects: input parameters, special cases, return values, and the nature of the briefing. It is complete and leaves no major gaps.

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

Parameters5/5

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

The description adds significant meaning to both parameters: 'name' is described with valid values (context name, UUID, 'awakening'), and 'limit' is given a default and purpose (max memories). This compensates fully for the 0% schema description coverage.

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 resumes work from a saved cognitive context, providing a narrative briefing. It distinguishes from sibling tools like 'save_context' and 'awaken' by specifying that it restores previous context, and handles a special case 'awakening' for personality, which is differentiated from the sibling 'awaken'.

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 explains when to use the tool: to continue work from a saved context. It provides a detailed example and mentions the special case for personality loading. It does not explicitly state when not to use it, but the context is clear enough, and it implicitly differentiates from siblings like 'list_contexts' and 'save_context'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.