Skip to main content
Glama
Sign In
mnema

mnema

Official
by mnema-work
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Audit: what an entity is connected to

audit_refs
Read-onlyIdempotent

Trace everything tied to one entity across all projects: observations, incoming and outgoing links, and supersede chains. Follow a single hop or full lineage, and verify linked file paths against the working tree.

Instructions

Show what one entity is connected to across ALL trees of ALL projects in this workspace: the observations about it, the links into and out of it, the decision that superseded it. Use it after search to pull on a thread: "what else is tied to this?". By default it is the NEIGHBOURHOOD (one hop, either direction); set direction to "out" (what it points at) or "in" (what points at it) with a larger depth to follow a lineage, such as a decision’s supersede chain. direction: "in" is how you answer "have I already applied this in my other projects?": the things that point at it are in THEIR records, and every edge says which project asserts it. A far end no visible tree holds comes back marked unresolved (that is legitimate, not an error), and the answer says when the depth cut it. Give it a PATH a link ends in and the answer also carries file: whether that file exists in the working tree today and the SHA-256 of its bytes. Read-only.

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": {
      "id": "<id>"
    },
    "name": "audit_refs"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe entity id to walk from (from `search`).
depthNoHow many hops (default 1, max 10).
directionNoWhich way to follow edges; omitted, both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so this dimension only needed added context – and the description supplies a lot: default hop count, that unresolved far ends are legitimate rather than errors, that truncation by depth is reported, that edges are annotated with the asserting project, and that path-terminated links also yield file existence plus SHA-256. None of that is inferable 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 scope in the first clause, then progressively narrower guidance, which is the right ordering for an agent skimming. It is on the long side for a 3-parameter tool, and phrases like 'pull on a thread' and 'what else is tied to this?' are atmospheric rather than informative, though they cost little.

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 carries the burden of return-value expectations, and it does so for the non-obvious cases: unresolved far ends, depth-cut notices, per-edge project attribution, and the extra `file` data. The general shape of a normal result isn't spelled out, but for a read-only traversal tool that is a minor gap.

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 the baseline is 3; the description earns above that by explaining what `direction` values actually select semantically (out = what it points at, in = what points at it, with a cross-project use case) and by tying `depth` to lineage-following rather than just 'number of hops'. It doesn't add anything about `id` beyond the schema, which keeps it from a 5.

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 ('Show what one entity is connected to across ALL trees of ALL projects') and enumerates exactly what comes back: observations, inbound/outbound links, superseding decision. That scope distinguishes it cleanly from the sibling graph tools like audit_timeline or read_record.

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 positions it after `search` ('use it after search to pull on a thread') and gives concrete conditional recipes: default one-hop neighbourhood, `direction: "out"` or `"in"` with larger `depth` to follow a lineage or a supersede chain. It even names the exact question `direction: "in"` answers ('have I already applied this in my other projects?'), which is about as directive as guidance gets.

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