Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Verified Repo Memory Store memory: Use env variables for DB credentials (config.ts:20-25)"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stale-proof repository memory with citations + just-in-time verification + TTL (repo-scoped).
An MCP server providing "safe memory" for AI coding agents. Memories are scoped per repository, backed by code citations, and verified just-in-time so an agent never receives stale information when the underlying code has changed.
Run via npx:
npx -y @cognitivemyriad/vrm-local --repo /path/to/repo(Alternatively, run from source: npm ci && npm run build && node build/index.js --repo /path/to/repo)
Related MCP server: Verified Repo Memory MCP
vrm_store: Store a new memory with file citations.
vrm_search: Search for candidate memories by keywords.
vrm_retrieve: JIT-verify candidates and return only valid memories. (Main tool for agents)
vrm_list: List memories by status (valid, stale, missing).
vrm_forget: Manually delete a memory.
Store: Input:
{
"subject": "API version sync",
"fact": "When changing API version, update client/server/docs together.",
"citations": [{ "path": "src/api.ts", "startLine": 10, "endLine": 15 }]
}Output:
{
"stored": true,
"memoryId": "uuid-...",
"expiresAt": "2026-03-21T00:00:00Z"
}Retrieve: Input:
{ "query": "API version" }Output:
{
"query": "API version",
"valid": [ ... ],
"stats": { "verified": 1, "validCount": 1 }
}graph TD
A[Agent] -->|Store Fact + Citation| B(Verified Repo Memory)
B --> C{Save to Disk}
C -->|Hash Code Snippet| D[(memories.json)]
A -->|Retrieve Fact| B
B --> E{JIT Verification}
E -->|Check File Hash| F{Unchanged or Relocated?}
F -->|Yes| G[Return VALID Memory]
F -->|No| H[Return STALE/MISSING]Citations: Every fact is linked to a file path and a line range. The exact code snippet is hashed and saved.
JIT Verification: Before returning a memory to the agent in vrm_retrieve, the server checks the physical file. If the snippet has moved, it relocates the citation. If it has been changed or deleted, the memory is marked STALE/MISSING and omitted from the results.
TTL (Time-To-Live): Memories expire automatically (default 28 days) unless they are successfully retrieved and utilized, which extends their life.
Data is strictly repo-scoped and saved in:
<repoRoot>/.verified-repo-memory
This includes memories.json and a fingerprint/metadata file to prevent accidental cross-repo pollution. Add this directory to your .gitignore.
No Network Transmissions: This is a stdio local-only server without HTTP calls.
Path Security: Disallows any path traversal (../) out of the repository root, as well as accessing .git/ or .verified-repo-memory/.
No Stdout Pollution: Strict logging only to stderr.
Secret Scan: Built-in heuristic secret scanning to reject memories that look like API keys/private keys (can be disabled via --no-secret-scan).
To add this server to the Claude Desktop app, edit your configuration file:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following configuration:
{
"mcpServers": {
"verified-repo-memory": {
"command": "npx",
"args": [
"-y",
"@cognitivemyriad/vrm-local",
"--repo",
"/absolute/path/to/your/repo"
]
}
}
}To add this server to Claude Code using stdio transport:
claude mcp add mcp-verified-repo-memory --transport stdio -- npx -y @cognitivemyriad/vrm-localNote for Windows users: You may need to prepend cmd /c to the command:
claude mcp add mcp-verified-repo-memory --transport stdio -- cmd /c npx -y @cognitivemyriad/vrm-localThis section explains how to publish the package to NPM and register it with the Anthropic MCP Registry so that it becomes publicly available.
NPM (Node Package Manager) is the package distribution platform. Publishing here allows anyone to install your tool with a single command.
An NPM account (free)
Two-factor authentication (2FA) enabled on your NPM account
Node.js installed on your machine
1. Log in to NPM from the terminal:
npm loginA browser window will open. Sign in with your NPM account. When prompted, enter your 2FA code from your authenticator app.
2. Publish the package:
npm publish --access publicThis command does the following:
Compiles TypeScript → JavaScript (npm run build)
Creates a .tgz archive of the compiled files
Uploads the archive to https://registry.npmjs.org/
3. Verify the publication:
Visit https://www.npmjs.com/package/@cognitivemyriad/vrm-local in your browser. Your package page should appear.
Note: If you need to re-publish, you must increment the version number in
package.jsonandserver.jsonfirst (npm version patch). NPM does not allow overwriting existing versions.
The MCP Registry is Anthropic's official directory of MCP servers. Registering here allows Claude Desktop, Claude Code, and other MCP clients to discover and install your server.
Important: The NPM package must be published first (Step 1). The MCP Registry validates that the NPM package exists before accepting the registration.
A GitHub account (used for authentication only)
The mcp-publisher CLI tool
# macOS (Homebrew)
brew install nicholasgriffintn/tap/mcp-publisher
# Or via npx (no install required)
npx @anthropic-ai/mcp-publisher1. Log in to the MCP Registry via GitHub:
mcp-publisher login githubA browser window will open. Authorize the application with your GitHub account.
2. Publish to the MCP Registry:
mcp-publisher publishThis command reads server.json in the current directory and registers the server with the MCP Registry. The registry will:
Validate the server.json schema
Check that the NPM package exists and is accessible
Register the server metadata (name, description, version, environment variables)
3. Verify the registration:
Visit https://registry.modelcontextprotocol.io and search for your server name.
Note: Once a version is published to the MCP Registry, it is immutable and cannot be changed. To publish updates, increment the version in both
package.jsonandserver.json, publish to NPM first, then runmcp-publisher publishagain.
When releasing a new version, always update the version number in all three locations:
# 1. Bump version in package.json
npm version patch # 0.1.2 → 0.1.3
# 2. Update server.json (both top-level and packages[].version)
# Edit server.json manually to match the new version
# 3. Publish
npm publish --access public
mcp-publisher publishFile | Field | Must Match |
|
| ✅ |
|
| ✅ |
|
| ✅ |
Manually delete a memory by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| memoryId | Yes | ||
| hardDelete | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only states 'delete' without disclosing implications such as whether deletion is permanent, what 'hardDelete' means, whether deletion is reversible, or what happens to associated memory. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an unexplained 'hardDelete' parameter, the description is too brief to fully prepare an agent. It does not mention return values, deletion permanence, or any side effects, leaving important gaps for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'memoryId' via 'by ID' but completely ignores the 'hardDelete' parameter, which is crucial for understanding whether deletion is soft or permanent. Half the parameters are semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the specific verb 'delete' with the resource 'memory' and identifies the key mechanism ('by ID'). It effectively distinguishes this tool from its siblings (store, search, retrieve, list) by centering on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Manually' provides context that this tool is for user-initiated deletion, likely contrasting with automatic memory management. However, it does not explicitly mention when not to use this tool or alternatives, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories by status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | all | |
| verify | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides none: no mention of side effects, read-only nature, required permissions, pagination behavior, or the effect of the 'verify' parameter. The description adds no behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded and free of fluff. However, it is under-specified, omitting essential information about parameters and behavior. It reads as a vague label rather than a concise, complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (limit, status, verify), no annotations, and no output schema, the description is severely inadequate. It does not explain the meaning of statuses, the behavior of 'verify', or default limits. An AI agent would lack enough context to invoke the tool accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. It only mentions 'status' without explaining its enum values (all, valid, stale, missing) or the purpose of 'limit' and 'verify'. The description adds minimal meaning beyond the schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List memories by status' clearly identifies the action (list) and resource (memories), with status as a filter. It is not a tautology and distinguishes from siblings like vrm_retrieve (which likely fetches a single memory) and vrm_search (which likely searches by content), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention contexts in which listing by status is appropriate, nor does it contrast with vrm_search or vrm_retrieve. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JIT-verify candidates and return valid memories.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| touch | No | ||
| includeStale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions 'JIT-verify' and 'valid memories' but does not state whether the operation is read-only, whether it has side effects (e.g., the 'touch' parameter suggests updating last access time), or what happens to invalid candidates. This is a significant transparency gap for a tool that may mutate state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified, sacrificing necessary context for brevity. It could be expanded with relevant behavioral details while still remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no annotations, and no output schema, the description is insufficiently complete. It does not cover return value format, error behavior, side effects, or the meaning of key terms like 'candidates' and 'valid'. It leaves the agent with significant uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the four parameters (query, limit, touch, includeStale). It does not explain what 'candidates' refers to or how parameters influence the JIT verification. The description is entirely unhelpful for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'verify' and resource 'memories', suggesting a retrieval/validation operation. However, 'candidates' is undefined and the purpose is vague, lacking clarity on what inputs are expected or how verification works. It does not clearly distinguish from siblings like vrm_search or vrm_list, as 'retrieve' with 'verify' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or mentions of sibling tools. The context is entirely implied by the tool name, which is insufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for candidates (no JIT verification, fast).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| includeExpired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does reveal a meaningful behavioral trait: no JIT verification, implying results may be cached/stale but fast. However, it doesn't explain what JIT verification means for result freshness or mention any other side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with the core action front-loaded. The phrase 'no JIT verification, fast' is efficient but somewhat cryptic; no filler, though the jargon could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter search tool with no annotations and no output schema, the description is too sparse. It leaves out expected result format, default behaviors (limit=20, includeExpired=false), and what distinguishes a verified vs unverified search. The qualifier adds some color but not enough context for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-specific explanation. It doesn't mention that limit controls result count, includeExpired includes expired candidates, or how query is matched, so it fails to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb+resource 'search for candidates,' which clearly tells the agent what the tool does. It doesn't explicitly contrast with sibling tools like vrm_list, but the operation is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The parenthetical '(no JIT verification, fast)' hints at a performance trade-off but does not tell the agent when to prefer this over vrm_list or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a memory with file citations. Snippets are auto-extracted.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | ||
| tags | No | ||
| reason | No | ||
| subject | Yes | ||
| ttlDays | No | ||
| citations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It adds one useful detail (snippets are auto-extracted) but does not mention permissions, irreversibility, TTL behavior, conflict handling, or what the function returns. For a mutation tool with 6 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and key feature. No wasted words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and no output schema, yet the description provides almost no context about what a memory is, how citations work, what snippet extraction means, or what the caller should expect. This level of sparsity is inadequate for an agent to invoke the tool intelligently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only vaguely references 'file citations' but does not explain subject, fact, tags, reason, or ttlDays. The raw schema provides types and constraints but no semantic guidance, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (store), the resource (a memory), and the key differentiator (file citations with auto-extracted snippets). It stands apart from sibling tools like vrm_search and vrm_list which are read operations, and vrm_forget which is a delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'store' and the context of sibling tools imply that this is the write operation vs. read/search operations, but the description does not explicitly state when to use this tool or when to prefer alternatives. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4vrm_forgetvrm_listvrm_retrievevrm_searchvrm_storeScored across 5 tools
Each tool targets a distinct action: store (add), search (find candidates quickly), retrieve (verify and return valid memories), list (enumerate by status), forget (delete). The boundaries are clear, especially with the verification distinction between search and retrieve.
All tool names follow the consistent pattern 'vrm_' prefix plus an imperative verb (store, search, retrieve, list, forget). This is a uniform, predictable convention that makes the tool set easy to navigate.
With exactly 5 tools, the server covers the core memory lifecycle (create, read, list, delete) without bloat. Each tool earns its place, and the scope is well-matched to the stated purpose.
The set covers the essential operations for a memory store: add, search, retrieve, list, and forget. However, there is no update operation, and retrieval is tied to verification rather than direct ID lookup, which could be a minor gap for some workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Shared debugging memory for AI coding agents
One shared brain for your AI coding agents: team memory, agent Q&A, tasks, and file claims.
Project memory, semantic code search, and grounded agent context.
