Skip to main content
Glama

ctxstore — memory that follows you across models

Get Fact by Key

get_fact
Read-onlyIdempotent

Retrieve a fact by its exact key — deterministic, never misses. Use get_fact for self-notes: get_fact(key='agent::self-note:opening') or get_fact(key='agent::self-note:closing'). search_facts misses self-notes because their embedding similarity scores below other identity facts — get_fact(key=) is the only reliable retrieval path. Also use for inter-agent handoffs when the exact key is known. Returns the current (non-deprecated) version of the fact.

Input Schema

NameRequiredDescriptionDefault
keyYesExact fact key (e.g. 'sprint:bootstrap-namespace:review-emily_dev')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: retrieval is deterministic ('never misses') and returns only the current, non-deprecated version of the fact. That version-filtering behavior is not derivable from the annotations.

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 the core purpose before the usage rationale. It is slightly dense with repeated examples, but every sentence carries information an agent needs to invoke it correctly, so little is wasted.

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 no output schema, the description compensates by stating what is returned ('the current non-deprecated version'). It fully covers how and when to retrieve. Minor omission is whether a miss returns null vs an error, but overall it is complete for a single-key lookup.

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%, so baseline is 3, but the description adds meaning beyond the schema's generic example by giving concrete key formats ('agent:<name>:self-note:opening') and stressing that the key must be an EXACT match for the deterministic path to work.

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 and resource ('Retrieve a fact by its exact key') and immediately distinguishes itself from the two closest siblings, search_facts and get_fact_history, by emphasizing exact-key retrieval. The agent can tell this apart from its siblings without opening any 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?

Explicitly names when to use it (self-notes, inter-agent handoffs when the exact key is known) and when the alternative fails ('search_facts misses self-notes because their embedding similarity scores below other identity facts'). It even supplies the exact key patterns to call with, leaving nothing to inference.

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.