Skip to main content
Glama
Sign In
mnema

mnema

Official
by mnema-work
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Audit: recurring shapes in the record

audit_antipatterns
Read-onlyIdempotent

Surfaces recurring patterns across all workspace projects—reopened tasks, superseded decisions, deprecated skills, and duplicate ADR labels—with event counts and skill candidate pointers; read-only.

Instructions

Show recurring shapes across ALL trees of ALL projects in this workspace: tasks reopened, decisions superseded, skills deprecated, each with the exact events that make up the count, plus the tasks reopened more than once as skill CANDIDATES (a POINTER, not an action: this creates no skill). It also reports any ADR- label that more than one decision of the SAME chain answers to, with every id that carries it: the number is frozen when a rule is recorded, so two people deciding while apart can mint the same one, and from then on citing it by label names two rules. Nothing renumbers them: refer to those by id. It reports the shapes; it does NOT judge them good or bad. Use it to spot patterns a human might act on. The answer is ONE SET OF SHAPES PER PROJECT (plus the machine-global tree, which belongs to none): these are counts, and adding several projects up would answer a question about a workspace under the name of a question about a record: a skill candidate especially, since the pattern is distilled by whoever is doing the work that kept reopening. A project with nothing recurring is listed with empty lists 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_antipatterns"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it explains important behavioral boundaries: the result is one set of shapes per project, empty projects are still listed, duplicate ADR labels are reported by id because numbers are frozen, and the skill-candidate output is only a pointer that creates no skill. It also explicitly says the tool reports but does not judge patterns, which prevents misuse.

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 description front-loads the core action and keeps all major facts relevant, especially the per-project output rule and the skill-candidate pointer caveat. It is long and occasionally dense, but the length is largely justified by the audit's non-obvious output semantics.

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?

No output schema exists, so the description carries the full burden of explaining the return shape, and it does so: per-project grouping, inclusion of the machine-global tree, empty lists for projects with no recurrence, and the exact categories reported. Together with the annotations, an agent has enough information to call and interpret this tool 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?

This tool has no parameters, so there is no parameter semantics to clarify. The baseline for a zero-parameter tool applies; the description does not need to compensate for schema gaps.

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 states a specific audit action and enumerates exactly what shapes it finds: reopened tasks, superseded decisions, deprecated skills, repeated reopenings as skill candidates, and duplicate ADR labels. It clearly distinguishes this from a generic audit by focusing on recurring structural patterns across all projects.

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?

It gives a clear use case: "Use it to spot patterns a human might act on." It does not explicitly name sibling audit tools or state when to prefer them, so it stops short of full alternative guidance, but the intended context is clear.

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