mnema

Official

Overview Schema Source Related Servers Discussions Admin

The rules of the record for a file about to change

rules_before_an_edit

Retrieves the project-record rules still in force for a file path before a write, returning a hook reply that guides the edit and can pause for human approval when a rule requires it.

Instructions

The HOST calls this one, as a PreToolUse hook, before a file is written: it hands the session the rules of this project’s record that are addressed at that path AND still in force, as one short text that lands beside the result of that write: each rule’s name, the address that matched, and the id you cite. You may call it yourself; what you get back is a HOOK REPLY, because that is the only shape this host reads, and {} when there is nothing to say. Where a rule of the record is linked to the path with rel: "asks-for-a-person", the reply also carries permissionDecision: "ask", and the host holds the write until a PERSON decides, citing that rule’s id. It cannot refuse, allow, or rewrite your input: none of the three is representable in what it returns. It WRITES: every asking is appended to the record as a fact citing the rule and the path you named, before the reply is composed, and the first service of a session is appended too. For the whole answer (every address whatever its state, whose file no longer exists, and the counts for each relation) ask governing_rules instead; this one is deliberately thin, because it is paid for on every edit. RECORDING IS PERMANENT: mnema is append-only and nothing deletes a fact. A record in the public scope is committed to the repository and reaches every machine that clones it (published, if that repository is public). So do NOT record credentials here. Values in a recognized format (cloud keys, API tokens, private keys, a password inside a URL) are replaced with a typed placeholder before anything is written and the reply says what was replaced, but a format mnema does not recognize is written verbatim and cannot be taken back. Do not record personal data either: an email address is replaced with and reported, and the mnid already says who wrote. Each text field holds at most 65536 bytes; a longer one is refused, not truncated.

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": {
      "path": "<path>"
    },
    "name": "rules_before_an_edit"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	The path about to be written, relative to the project root or absolute.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already declare writes (readOnlyHint=false) and non-idempotence, but the description adds substantial behavior beyond them: every asking is appended permanently, the first service of a session is appended, public-scope records are committed to the repository, secrets are replaced with typed placeholders, and permissionDecision `ask` holds the write until a person decides. It also explains that the tool cannot refuse, allow, or rewrite input. Some repetition of permanent append-only behavior makes it slightly verbose, but the disclosure is rich and consistent with 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?

The description is front-loaded with the hook context and the reply shape, then moves through the `asks-for-a-person` behavior, write semantics, alternative tool, and safety warnings. It is dense but mostly earns its length because the permanent recording and secret-redaction warnings are operationally important, though a few phrases such as “none of the three is representable in what it returns” could be tighter.

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 still explains the return value as a HOOK REPLY, the `{}` empty case, the `permissionDecision: "ask"` variant, and that each reply contains rule name, matched address, and citable id. It also covers permanent recording and secret handling, so an agent has enough context to invoke it safely. Minor omissions like pagination are irrelevant for a one-path hook.

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 coverage is 100% and the only parameter is `path`, already documented as the path about to be written, relative or absolute. The description reinforces that the path is matched against rule addresses and cited in appended facts, but it does not add syntax or format guidance beyond the schema. Baseline 3 is appropriate when the schema fully documents the only parameter.

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 verb and resource: it fetches the project record’s rules addressed at a path and still in force, as a PreToolUse hook reply before a file write. It explicitly distinguishes itself from `governing_rules`, the fuller alternative, so an agent can tell which tool to select.

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?

It clearly says the HOST calls it before a file is written, that the agent may also call it directly, and that `governing_rules` should be used for the whole answer including inactive or deleted-file rules. It also gives concrete usage exclusions: do not record credentials, do not record personal data, and text fields over 65536 bytes are refused.

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