mnema

Official

by mnema-work

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Audit: where a credential may already be recorded

audit_exposure

Read-onlyIdempotent

Scan records across all projects for credential-shaped values and report where each finding lives—never the value—so you can locate exposed secrets and rotate them.

Instructions

Show which records hold something shaped like a credential (a cloud key, an API token, a private key, a password inside a URL) across ALL trees of ALL projects in this workspace. Use it to answer "is a secret already in the record?", which writing can no longer cause but the past can: values in a recognized format never reach the chain today (replaced in a body, and REFUSING the whole write in a name), and everything recorded before that was not. It reports WHERE and never WHAT: the id, the kind, the tree, the PROJECT and the instant, plus the CLASS, never the value, so reading it cannot leak what it found. A record in a public tree is committed and clones to every machine; one in the global tree is on this disk alone; and the project says which repository to go and change a key in. The remedy is to ROTATE the credential: mnema is append-only and nothing deletes a fact. scanned is ONE COUNT PER RECORD (each project and the machine-global tree), so an empty findings says which records were read and how much of each. Two limits: it recognizes FORMATS, so an empty report means nothing recognizable rather than nothing (a password in prose has no format); and it reports what is recorded: it does not prevent a value from being read back by search or read_record, which serve the record as written. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "audit_exposure"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, non-destructive, idempotent behavior, and the description adds substantive context well beyond that: it discloses that only fields/classifications are returned, never the secret itself; that a public-tree record is committed and cloned while a global-tree record is local; that the only remedy is rotation because storage is append-only; and that detection is format-based so an empty result is not proof of absence. These are exactly the operational traits an agent needs, though the dense prose takes effort to parse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the WHERE-not-WHAT guarantee are front-loaded, which is good, but the single paragraph is long and carries stylistic emphasis (ALL-CAPS, 'REFUSING the whole write', 'ROTATE') that adds noise. The clause contrasting present writes with past records is informative but could be shorter, and the two limits at the end are buried.

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 input schema and no output schema, the description has to carry the whole burden of explaining what comes back, and it largely does: returned fields, per-record `scanned` counts, and the meaning of an empty `findings`. The main gap is that it does not describe ordering, truncation, or how large an ALL-trees scan can be.

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?

The tool takes zero parameters, so there is no parameter space to document. The description goes further than required by explaining the shape of the result (`scanned` as one count per record, `findings` carrying id, kind, tree, project, instant, and class), which compensates for the absence of an output schema.

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 and resource ('Show which records hold something shaped like a credential') and scopes it explicitly to ALL trees of ALL projects. It also distinguishes itself from the sibling tools that serve records, naming `search` and `read_record` as tools that do the opposite (serve the raw value).

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?

Frames the exact question it answers ('is a secret already in the record?') and explains why scanning the past is still necessary even though writes are now guarded. It also states a clear boundary: it reports what is recorded but does not prevent `search` or `read_record` from returning the value, so an agent knows when this tool is and is not the right check.

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