Skip to main content
Glama
xChuCx
by xChuCx

memory.fetch_context

Retrieve a budgeted, ranked Markdown context pack from project memory files, prioritizing relevant sections for the current task. Use it before reading source files to bootstrap with conventions and state.

Instructions

Return a budgeted, ranked Markdown context pack assembled from the project's .agent-memory/ files. Call this before reading source files manually; the pack contains current task state, conventions, and any sections relevant to the query. An empty query returns the bootstrap pack (local current state + conventions + index summary).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNosearch query; empty returns the bootstrap pack
scopeNopaths or module names to prioritize via substring match
budgetNoapproximate character budget for the returned pack; 0 uses manifest default
includeNocontext categories to include (advisory in M2; M3 enforces)
exclude_archiveNoif true, archive/ files are skipped entirely; defaults to false

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextYesthe Markdown context pack
omittedNocandidates that were dropped (budget exhausted, parse error, etc.)
included_filesYesper-file provenance for everything in the pack
context_metadataYes
suggested_next_queriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • addedOutput schema / properties / context_metadata / properties / pack_digest
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / context_metadata / properties / read_nonce
      Added value: +{
      +  "type": "string"
      +}
  2. Changed4 schema fields changedv0.5.1
    • addedOutput schema / properties / included_files / items / properties / origin
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / included_files / items / properties / store
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / omitted / items / properties / origin
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / omitted / items / properties / store
      Added value: +{
      +  "type": "string"
      +}
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It describes the output format (budgeted, ranked Markdown), the source location, and the bootstrap behavior, but does not explicitly state that it is read-only or whether there are side effects (though implied). It also omits any potential limitations or failure modes.

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?

The description is two sentences, front-loaded with the core purpose, and contains no filler. Every sentence adds value: the first states what it returns, the second explains when to use it and the bootstrap behavior.

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?

With 5 parameters fully documented in the schema and an output schema present, the description provides sufficient context for correct usage. It explains the main behavior and the bootstrap case. It does not cover all edge cases (e.g., error handling or interactions with siblings) but these are not critical for a fetch tool.

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%, so the baseline is 3. The description only reiterates the empty-query behavior already present in the query parameter's schema description and provides no additional insight into scope, budget, include, or exclude_archive parameters.

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 states a specific verb ('Return') and a specific resource ('.agent-memory/ files'), and clarifies it produces a budgeted, ranked Markdown context pack. This clearly distinguishes it from the sibling tools memory.status and memory.propose_update, which are about status and updates, respectively.

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?

It gives an explicit directive: 'Call this before reading source files manually,' which provides clear when-to-use guidance. It also notes the empty-query bootstrap behavior. It does not explicitly mention exclusions or name the siblings, but the alternative (manual reading) is implicit and sufficient.

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