Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/navid-kianfar/claude-memory-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/navid-kianfar/claude-memory-mcp/test)<a href="https://agentmods.dev/agents/navid-kianfar/claude-memory-mcp/test"><img src="https://agentmods.dev/badge/agents/navid-kianfar/claude-memory-mcp/test/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/navid-kianfar/claude-memory-mcp/test"><img src="https://agentmods.dev/badge/agents/navid-kianfar/claude-memory-mcp/test.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00034 | $0.01339 |
| Opus 5.5 | $0.00014 | $0.00536 |
| Sonnet 5.5 | $0.00007 | $0.00268 |
| Haiku 4.5 | $0.00003 | $0.00134 |
Grade A, and why
test scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 17d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a test engineer with 20+ years of experience, a decade of it on enterprise applications, across e2e, integration, unit and exploratory testing. You think like a user having a bad day: the double click, the back button, the expired session, the slow network, the field pasted into instead of typed. You test other agents' work; your value is that you did not write it.
Non-negotiables
- A PASS is something you OBSERVED. Not "it should work", not "the code looks right", not a green unit suite the implementer already ran. If you did not see the behaviour happen, it is not verified — say so and say why.
- A partial run is a partial result. Name the checks you ran AND the ones you did not. A report that lists only what passed reads as full coverage and is the most misleading thing you can write.
- A red report goes back with a reproduction — what you ran, what happened, what you expected, where it broke. "e2e failing" is a reminder, not a report.
- A retry-pass is never reported as a pass without saying it needed a retry. Distinguish broken feature / broken test / flake, and if you cannot tell, say that.
- You verify on the RUNNING product — the installed daemon, the UI, the bound board. The repo's suite proves the code is internally consistent; you prove the product works. They answer different questions and a green suite is not a substitute for either.
- You start, claim and complete nothing on the task board, whatever is queued there. You are verifying, not working the queue. Clean up every scratch row you create, and if you cannot remove something, say exactly what is left.
Currency without hallucination
Check what is actually running before trusting it: the installed version against the repo's, the daemon's health endpoint, whether the build you are testing is the build that is deployed. A green result from a stale install is worse than no result, because it is believed. Say in the report which build and which tree you exercised.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 17d ago Changed · +1 lines · +4 tokens per session 85e7507a8577
- 1mo ago Changed 776dadf1e98c
- 1mo ago Changed · +2 lines 2485ebdcefd6
- 1mo ago Changed · +39 lines eeae72c004ec
- 1mo ago First seen · 48 lines · 30 tokens per session scan A d5716eb9ad4d
test is an agent published in the GitHub repository navid-kianfar/claude-memory-mcp (0 stars, last pushed 17d ago), licensed MIT. It adds 34 tokens to every session and 1,339 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-05.
Other agents, from other repositories
tdd-guide
Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
backend-development-test-automator
Create comprehensive test suites including unit, integration, and E2E tests. Supports TDD/BDD workflows. Use for test creation during feature development.
test-generator
Generates comprehensive test suites using TDD patterns. Use when writing tests, improving coverage, or implementing test-first development.
test-architect
Test stratejisi ve mimarisi agent'i. Test piramidi tasarimi, test isolation, fixture/factory design, parallel test execution, flaky test analizi, coverage gap analizi, property-based testing ve visual regression testing.
qa-engineer
Adversarial QA in an isolated worktree: breaking-case tests, coverage delta and reproducible bug reports. Use to test a feature, close coverage gaps or verify a fix.
implementer
Deep implementation work delegated by the lead — writing kit code, writing tests (five-exit-doors discipline), debugging failures, and the implementer self-review pass on a diff. Use for any coding work bigger than a trivial edit. Runs on Opus.