Skip to main content
Glama

query_memory_store

Read-onlyIdempotent

Retrieve semantic triples, causal reasoning chains, and entity similarity clusters from local agent memory to recall past decisions and trace dependencies without modifying stored knowledge.

Instructions

Queries semantic triples, causal reasoning graphs, and MinHash entity clusters from the local agent memory store, distinguishing from 'manage_memory_store' and 'search_codebase' by retrieving episodic reasoning relations rather than modifying memory records or searching repository code.

Parameters:

  • query (str, required): Entity name, concept, or search query to look up in the memory store.

  • query_mode (str, optional, default='semantic'): Query strategy: 'semantic' for triple & relation lookup, 'causal_chain' for temporal cause-and-effect traces, 'minhash' for sub-microsecond entity similarity clusters.

  • project_root (str, optional, default='.'): Workspace root where memory store is located (default: current directory).

Behavior:

  • Read-only: Queries persistent memory store without altering stored knowledge.

  • Idempotent: Returns consistent knowledge relations for identical queries.

  • 100% Offline: Local graph and MinHash index lookup without network traffic.

  • Auth & Rate Limits: Zero authentication or cloud credentials required; query latency <10ms.

  • Error Handling: Returns empty graph notice if the queried entity does not exist in the codebook.

Usage Guidelines:

  • When to use: Recall past agent decisions, query knowledge graph entity relations, or trace causal dependency chains across reasoning sessions.

  • When NOT to use: Do not use for modifying, compressing, or deleting memory stores (use 'manage_memory_store' instead); do not use for searching source code in the repository (use 'search_codebase' instead).

Returns: Markdown report with extracted semantic triples, graph relationships, or causal inference chains.

Input Schema

NameRequiredDescriptionDefault
queryYesEntity name, concept, or search query to look up in the memory store.
query_modeNoQuery strategy: 'semantic' for triple & relation lookup, 'causal_chain' for temporal cause-and-effect traces, 'minhash' for sub-microsecond entity similarity clusters.semantic
project_rootNoWorkspace root where memory store is located (default: current directory)..

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv7.3.2
  2. Removedv7.0.1
  3. Addedv7.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, closed-world, non-destructive, but the description adds genuine context beyond them: offline operation, zero auth/cloud credentials, <10ms latency, and the empty-graph error behavior for missing entities. That is substantive disclosure an agent cannot get from the annotations alone.

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 purpose and sibling differentiation, then segmented into Behavior, Usage Guidelines, and Returns. Slightly long because the Behavior bullets partially echo the annotations (read-only, idempotent), but overall efficient and well organized.

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?

For a 3-param read-only query tool with full schema coverage, annotations, and an output schema, the description covers scope, alternatives, safety, latency, offline behavior, and error semantics. Nothing an agent needs to call it correctly is missing.

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 all three parameters are already documented, and the description's parameter list largely restates the schema text including defaults and mode meanings. Baseline 3 applies since the schema does the heavy lifting and the description adds little beyond it.

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?

States a specific verb (queries) and specific resources (semantic triples, causal reasoning graphs, MinHash entity clusters) and explicitly distinguishes itself from 'manage_memory_store' and 'search_codebase'. An agent can route to it without opening a schema.

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?

Provides an explicit 'When to use' list and a 'When NOT to use' list that names both alternatives and the conditions selecting them. Nothing is left to inference.

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