Skip to main content
Glama
Sign In
mnema

mnema

Official
by mnema-work
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Audit: who authorized what

audit_accountability
Read-onlyIdempotent

Shows who authorized what and which agent executed it across all project trees, with optional time, author, or agent filters.

Instructions

Show who authorized what and which agent executed it, across ALL trees of ALL projects in this workspace. Use it to answer "who did what" over the whole record: with no filter it accounts for everything (like git shortlog). Optionally narrow by a time window (from/to), a single author (who), or a single executing agent (which). The answer is ONE ACCOUNT PER PROJECT (plus the machine-global tree, which belongs to none), each with its own total and per-author breakdown (counts by kind and by executing agent) and, beside each author, foundedBeside: every tree of that record where the identity was founded after others already were, with when and which identities were there (somebody new to the record, or one person under a second key); empty when it founded first or was vouched for. There is deliberately no combined total: a count belongs to a record, and adding several projects up answers "how much have I written anywhere" under the name of "how much is in this record". Add them yourself if that is your question. A project with nothing to report is listed at zero rather than left out. 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_accountability"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoonly facts at or before this ISO-8601 instant (inclusive). A window (`from`/`to`) selects the FACTS themselves, by the instant each was recorded.
whoNoCount only facts authorized by this anchor id.
fromNoonly facts at or after this ISO-8601 instant (inclusive). A window (`from`/`to`) selects the FACTS themselves, by the instant each was recorded.
whichNoCount only facts executed by this agent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds substantive behavior beyond that — one account per project, zero-listed projects, the deliberate absence of a combined total with the rationale, and the meaning of foundedBeside. It does not discuss permissions or volume/performance characteristics, which keeps it from a 5.

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 and ordered purpose → filtering → return shape → design rationale, with zero padding sentences. It is long (roughly 170 words) and the 'add them yourself if that is your question' remark is more editorial than operational, so not a 5.

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?

There is no output schema, so the description carries the full burden of return-value explanation and does it thoroughly: per-project accounts, totals, per-author breakdowns by kind and executing agent, the foundedBeside field with its empty case, and zero-listing. An agent can act and interpret results without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 restates the three filters at a high level ('time window (from/to)', 'single author (who)', 'single executing agent (which)') but adds no semantics the schema lacks — notably it omits the schema's key point that a window selects the FACTS themselves by recording instant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Show who authorized what and which agent executed it') plus an explicit scope ('across ALL trees of ALL projects in this workspace'). The git-shortlog analogy sharply anchors the mental model. It does not name any sibling audit tool to differentiate against, so it stops short of 5.

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 a clear intended question ('who did what' over the whole record) and explains the default no-filter behavior and the three narrowing options. It never states when to pick a sibling tool instead, so the boundary with audit_timeline / audit_refs is left implicit.

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