mnema

Official

by mnema-work

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Which recorded rules govern this path

governing_rules

Read-onlyIdempotent

Find which project decisions and patterns govern a file path before editing, listed most specific first. Use the returned rule ID to cite the decision you follow.

Instructions

Show which rules of THIS project’s record are addressed at a path: a decision or a pattern linked to it with rel: "governs", most specific first. Use it before changing a file, to find the decisions that already apply to it; the id it returns is what you cite when you follow one. An address is a PREFIX by path segment: a rule on src/collate governs src/collate/fold.ts and does NOT govern src/collate_test.rb. Every answer carries three counts, zeroes included: how many rules cover this path, how many address this project at all, and how many address something the working tree no longer holds: a rule whose file was moved or deleted has stopped governing, and the third count is how you find out. It reports each rule’s state and decides nothing: it refuses nothing, blocks nothing, and does not judge whether a rule still holds. Addresses come from THIS project only, because an address is relative to a project root. A relative path is resolved against the project root, not a working directory. 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": {
      "path": "<path>"
    },
    "name": "governing_rules"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Well beyond the annotations, it explains prefix-vs-substring matching, that only this project's addresses count because addresses are root-relative, that a relative path resolves against the project root rather than a working directory, and that three counts are always returned including zeroes. The staleness statement — a rule whose file was moved or deleted stops governing, and the third count is how you learn that — is genuine behavioral disclosure an agent could not infer from 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?

Purpose is front-loaded in the first sentence and the paragraph proceeds from matching semantics to the returned counts to scope restrictions. It is long for one parameter, and a few passages restate structured data ('Read-only' repeats readOnlyHint; the construction 'it refuses nothing, blocks nothing, and does not judge' says one thing three ways). Still, nearly every sentence carries non-obvious information.

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 a single parameter and no output schema, the description has to carry the return-shape burden, and it does so credibly: per-rule state, a citable id, and three named counts including the stale-rule count. Beyond that it only sketches the list contents, but for a read-only lookup this is sufficient for an agent to call it correctly and interpret the answer.

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% with a single parameter, so the baseline is 3; the description adds real meaning by defining how the path is matched (by path segment prefix, not substring), how relative paths are resolved (against the project root, not a working directory), and that paths are project-relative. That is exactly the disambiguation the schema's one-line parameter note lacks.

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?

Starts with a specific verb plus resource — 'Show which rules ... are addressed at a path' — and scopes it to THIS project's record and to `rel: "governs"` links. The prefix semantics (a rule on `src/collate` governs `src/collate/fold.ts`) make the operation concrete. It does not, however, contrast itself with the adjacent `rules_before_an_edit` sibling, whose name suggests overlapping intent.

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 trigger — 'Use it before changing a file, to find the decisions that already apply to it' — and adds a follow-on rule about citing the returned id. It states what the tool will not do (refuses, blocks, judges nothing), which usefully prevents misuse. What's missing is explicit routing to alternatives when the agent's need is not file-change-related.

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