Skip to main content
Glama

read_key

List and rank the memories stored under one key, returning canonical key, aliases, and scored memory handles. Pass a query to rank handles by content relevance and pick the right memory to read.

Instructions

List the memories stored under one key (concept), ranked. Returns the canonical key, its aliases, and hub metadata plus ranked memory IDs, metadata, and validity — never memory content. Pass a focused query for the missing fact and the active namespace when known: handles are then ranked by content relevance, which is essential for hubs. Each memory's score is content_relevance × link_weight × depth_factor × freshness_factor when query is passed (link_weight × depth_factor × freshness_factor otherwise); content_relevance is normalized lexical relevance or reranker relevance, never body-vector cosine; scores are only meaningful within this one key's ranking. Call read_memory(memory_id, via_key_id=key_id, namespace) on the selected handle to inspect the fact and reinforce the path; reading does not confirm that its content is current. Use limit/offset to page without flooding context.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "key_id": "<key_id>"
    },
    "name": "read_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
key_idYes
offsetNo
namespaceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.29.0
  2. Removedv0.17.1
  3. First observedv0.14.8

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does disclose key traits: what is never returned ('never memory content'), the exact scoring formula, that scores are only meaningful within one key's ranking, and that reading does not establish content currency. It leaves out permission/auth requirements and any rate or pagination limits beyond the limit/offset hint.

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?

The response contract is front-loaded in the first sentence, but the piece is one dense paragraph with inline formula notation that is heavy for a selection-time read. Every sentence is informative, yet the scoring algebra could be terser or deferred.

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?

Despite no output schema and no annotations, the description specifies the return shape, the meaning of scores, and the follow-up call pattern, which is enough for an agent to invoke it correctly. Minor gaps remain around permissions and how ranking behaves with no query beyond the factor substitution shown.

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% for 5 parameters, so the description must compensate, and it largely does: it explains query's effect on ranking, when to pass namespace, and that limit/offset page results 'without flooding context.' key_id is only implicitly characterized as the concept key rather than defined in detail, so it is not quite complete.

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 precise verb+resource+scope: 'List the memories stored under one key (concept), ranked,' and enumerates the returned fields (canonical key, aliases, hub metadata, ranked memory IDs). It distinguishes itself from read_memory by clarifying read_key returns handles and 'never memory content,' while read_memory inspects the fact.

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 clear conditional guidance: pass a focused query and the active namespace when known, then call read_memory on the selected handle to inspect the fact. It also warns that 'reading does not confirm that its content is current,' implying confirm_memory. It does not, however, explicitly exclude the other list/recall siblings (recall, browse_keys), so routing is not fully disambiguated.

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