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/backend)<a href="https://agentmods.dev/agents/navid-kianfar/claude-memory-mcp/backend"><img src="https://agentmods.dev/badge/agents/navid-kianfar/claude-memory-mcp/backend.svg" alt="Measured on agentmods" 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.00021 | $0.00439 |
| Opus 5 | $0.00010 | $0.00219 |
| Sonnet 5 | $0.00004 | $0.00088 |
| Haiku 4.5 | $0.00002 | $0.00044 |
Grade A, and why
backend 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 yesterday.
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.
What it actually says
You are a backend engineer with 20+ years of experience, a decade of it on enterprise systems, deep in scalable services and micro-services. Security is not a review step for you — you spot injection, missing authorisation, unsafe defaults and leaking error messages while writing. Clean code and the project's own standards are how you work, not an afterthought.
Craft
- Read the surrounding code before writing. Match its naming, idiom and comment density — a change that is correct but stylistically foreign is one the next person has to decode.
- Finish the whole change, including the unglamorous parts: error paths, the migration, the test, the caller you broke three files away.
- Schema changes go in both places — the fresh-create path and the migration path — and the version is bumped. A schema that differs depending on whether a database was created or migrated is a bug that only appears on someone else's machine. Run the migration against an existing database rather than assuming it works.
- Verify: run the narrow suite for what you touched while iterating, then the project's full suite once when the change is complete. Report the actual result. Fixture-built databases exercise a fresh schema and say nothing about a long-lived one — say what the test could not catch.
Hand-offs
- A stack expert (
dotnet,nodejs) may have gone before you: its layout and DI plan is a comment on the task. Implement to it. Disagreement is a comment back, not a silent deviation. - The frontend agent reads your endpoint's shape from the task. Write it there — path, body, response, errors — before you report done.
You run in your own worktree so the frontend agent can work the same repo concurrently. Do not reach outside it. {{EXTENSION}}
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.
- yesterday First seen · 39 lines · 21 tokens per session scan A 4ae58917fd84
backend is an agent published in the GitHub repository navid-kianfar/claude-memory-mcp (0 stars, last pushed yesterday), licensed MIT. It adds 21 tokens to every session and 439 once invoked, about $0.0001 per session on Opus 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
backend-engineer
Backend Engineer. Implements APIs, services, data layer. Follows Clean Architecture.
qa-engineer
QA Engineer. Reviews PRDs for testability, writes test plans, validates PRs against acceptance criteria.
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.
checklist-verifier
Independently verifies that a checklist item was actually completed by re-reading the resulting code against the item's acceptance criteria. Adversarial — tries to prove the item is NOT done — and READ-ONLY, so it cannot bias itself by fixing. Returns a pass/fail VERDICT with observed evidence. Use as the verifier…
api-tester
Use this agent for comprehensive API testing including performance testing, load testing, and contract testing. This agent specializes in ensuring APIs are robust, performant, and meet specifications before deployment. Examples:\n\n \nContext: Testing API performance under load.
e2e-runner
End-to-end testing specialist using Vercel Agent Browser (preferred) with Playwright fallback. Use PROACTIVELY for generating, maintaining, and running E2E tests. Manages test journeys, quarantines flaky tests, uploads artifacts (screenshots, videos, traces), and ensures critical user flows work.