Skip to main content
Glama
event4u-app

@event4u/agent-config

Official
by event4u-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

memory_lookup

Read-only

Retrieve engineering-memory entries by type and optional path to surface prior incidents, ownership, and patterns before editing security-sensitive or historically buggy files.

Instructions

Retrieve engineering-memory entries for one or more memory types, optionally narrowed to specific anchor paths. Use before editing a security-sensitive or historically buggy file to surface prior incidents, ownership, and patterns tied to it. WORKFLOW: call with detail:"index" FIRST — each row carries id, title and tokens_estimate (the cost of fetching it) — then fetch full bodies via memory_get ONLY for the ids you will actually use, batching multiple ids into one call. Reads agents/memory/<type>/*.yml plus the agents/memory/intake/*.jsonl signal log. Read-only. Returns the v1 retrieval envelope: a status field plus per-type slices carrying the matched entries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keysNoOptional anchor paths or globs to match entries against (e.g. a file you are about to edit).
limitNoMaximum entries to return per type. Defaults to 5.
typesYesMemory types to scan, e.g. `historical-patterns`, `incident-learnings`, `ownership`. At least one required.
detailNo'index' returns compact priced rows (id, title, tokens_estimate) instead of full bodies — call this first, then memory_get the ids you need. 'full' (default) returns complete entries.full
token_budgetNoOptional token budget. When set, entries are rendered as one-line compact rows (id, type, confidence, `line`) and the row set is hard-cut at token_budget × 4 chars; omitted hits appear as a top-level `truncation` hint naming a concrete next step. Absent → the envelope is unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv8.8.0
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "full",
+  "description": "'index' returns compact priced rows (id, title, tokens_estimate) instead of full bodies — call this first, then memory_get the ids you need. 'full' (default) returns complete entries.",
+  "enum": [
+    "index",
+    "full"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / token_budget
      Added value: +{
+  "description": "Optional token budget. When set, entries are rendered as one-line compact rows (id, type, confidence, `line`) and the row set is hard-cut at token_budget × 4 chars; omitted hits appear as a top-level `truncation` hint naming a concrete next step. Absent → the envelope is unchanged.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed1 schema field changedv6.1.0
    • removedInput schema / properties / with_package
      Removed value: -{
-  "default": false,
-  "description": "When true, also include memory shipped with the agent-config package, not just the consumer project's own.",
-  "type": "boolean"
-}
  3. Changed4 schema fields changedv1.0.2
    • addedInput schema / properties / keys / description
      Added value: +"Optional anchor paths or globs to match entries against (e.g. a file you are about to edit)."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum entries to return per type. Defaults to 5."
    • addedInput schema / properties / types / description
      Added value: +"Memory types to scan, e.g. `historical-patterns`, `incident-learnings`, `ownership`. At least one required."
    • addedInput schema / properties / with_package / description
      Added value: +"When true, also include memory shipped with the agent-config package, not just the consumer project's own."
  4. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses the tool's read-only nature, which aligns with the readOnlyHint annotation but goes beyond it by naming the exact data sources ('Reads `agents/memory/<type>/*.yml` plus the `agents/memory/intake/*.jsonl` signal log') and describing the return envelope ('a `status` field plus per-type `slices`'). This provides valuable context about side effects, data scope, and output structure not present in annotations.

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 front-loaded with the primary purpose, followed by usage context, workflow, data sources, and return format. Every sentence contributes value, and the 'WORKFLOW:' label provides clear structure. Despite its length, it is appropriately sized for the tool's complexity, with zero redundant information.

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?

With no output schema, the description takes responsibility for explaining return values, and it does so ('Returns the v1 retrieval envelope: a `status` field plus per-type `slices` carrying the matched entries'). It also covers the `detail` modes and token_budget behavior indirectly through the schema. Considering the tool's complexity and the rich schema, the description is complete enough for an agent to use correctly.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the strategic use of the `detail` parameter ('call with detail:"index" FIRST') and the purpose of `keys` ('anchor paths to match entries against'). While it doesn't add new meaning for every parameter, the workflow guidance enhances understanding of how to use the parameters effectively.

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 opens with a specific verb and resource: 'Retrieve engineering-memory entries for one or more memory types, optionally narrowed to specific anchor paths.' It clearly distinguishes itself from sibling tools like memory_get by explaining its role as a lookup that returns indexes and summaries, with memory_get for full bodies.

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?

The description explicitly tells when to use the tool: 'Use before editing a security-sensitive or historically buggy file...' It also provides a step-by-step workflow ('call with detail:"index" FIRST... then fetch full bodies via memory_get') and names the alternative tool (memory_get) for fetching full entries. This is explicit guidance about when and how to use it.

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

Deploy Server

Other Tools