Skip to main content
Glama

workspace_recall

Read-only

Recall prior work and project checkpoints to continue from where you left off. Searches memory for relevant context without exposing full sessions or local paths.

Instructions

Recall prior work when the user says continue a named project, where did we leave off, or 예전에/어디까지 했지/이어서 하자. The user need not say AI Workspace. Use factual topic keywords; if the topic is missing, resolve it from current conversation or ask. Search recent and refined memory, checking freshness. Only when operator-enabled, fall back to bounded redacted Cold excerpts. No full sessions or local paths returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/no-destructive/no-open-world, and the description adds real value beyond them: freshness-checked search of recent and refined memory, an operator-gated fallback to bounded redacted Cold excerpts, and an explicit output limitation (no full sessions or local paths). Terms like 'Cold excerpts' are internal jargon that reduce clarity slightly.

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?

A single dense paragraph that front-loads the trigger conditions and packs fallback/limitation details without filler. Some clauses are run-on and jargon-heavy, but every sentence roughly earns its place.

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?

An output schema exists, so return values need not be described; the description instead covers triggers, search behavior, operator gating, and output limits. It is nearly complete for a single-optional-parameter recall tool, with only sibling routing left implicit.

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 0%, so the description must carry the burden, and it does provide guidance: use factual topic keywords and resolve a missing topic from the conversation or by asking. It stops short of format/examples for the query value.

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 clear verb+resource (recall prior work) and enumerates concrete trigger utterances the user might make, including Korean phrases. It does not explicitly differentiate itself from sibling tools like workspace_checkpoint or search_local, so it falls just short of 5.

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?

Gives strong when-to-use context via quoted user phrasings ('continue a named project', 'where did we leave off') and notes the user need not say 'AI Workspace'. However, it names no explicit alternative or exclusion, leaving sibling selection to inference.

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