TradeMemory Protocol: A Persistent Memory and Audit Layer for AI Trading Agents

The gap TradeMemory fills: an agent that cannot remember its own losing trades

Execution is a solved problem in the MCP ecosystem. Servers place orders, fetch prices, and read charts. What none of them do, according to the README, is remember. An agent can buy 100 shares of AAPL and still be unable to answer what happened the last time it bought AAPL under the same conditions. Each session starts from zero, repeats the same errors, and leaves no record of why a position was opened. TradeMemory is positioned as that missing layer. It records and recalls; it does not route orders or hold funds. The intended users are narrower than the tag list suggests. The README names three: a US equity trader running a pre-flight checklist before every position, a forex EA system syncing decisions from MT5 and logging why signals were blocked as well as executed, and a compliance team that needs tamper-evident records. The compliance case is the one that changes the buying decision. Recall is a convenience; a hash chain that survives an audit is a requirement, and the README ties the motivation to MiFID II Article 17 and EU AI Act Article 14. If you are not in a jurisdiction or a fund structure where algorithmic decision documentation is demanded, the audit half of the product is overhead you are paying for in schema complexity.

Five memory layers and the OWM scoring factors behind recall

The mechanism is a write path and a read path. On the write side, one call to remember_trade fans out into five memory layers: episodic, semantic, procedural, affective, and trade records. That fan-out is automatic, which is the practical argument for using this rather than a table you wrote yourself: you do not decide per trade which layer deserves the data. On the read side, recall_memories does not return trades by recency. It scores them on five factors, which the README and the OWM framework doc name as outcome quality, context similarity, recency, confidence, and emotional state. Outcome weighting is the design choice that matters. A trade that lost money is still retrievable and still influences the agent, which is the opposite of naive retrieval where the most recent or most similar trade wins regardless of whether it worked. The affective layer is the part I would scrutinise hardest. Emotional state is a scored recall factor, and the README does not, in the material available here, specify how that state is captured or normalised. If your agent is not supplying a meaningful value for it, that factor is noise in the ranking. The repository also exposes get_behavioral_analysis and get_agent_state, which surface confidence, drawdown, streaks, and behavioural patterns, so the recall score is not the only feedback path.

Getting it running: pip, uvx, and the MCP client config

Installation is a single package. The README gives pip install tradememory-protocol. For Claude Desktop, the config block goes into claude_desktop_config.json under mcpServers, with a key named tradememory, command uvx, and args set to the list containing tradememory-protocol. Claude Code users get a one-liner: claude mcp add tradememory -- uvx tradememory-protocol. Running from source is git clone of the repository, cd into it, pip install -e ., then python -m tradememory. Docker is covered by docker compose up -d. The README also notes a REST surface of 35 or more endpoints and lists the tool categories, with 20 MCP tools in total: memory, state, planning, risk, audit, plus an evolution group covering market data fetch, pattern discovery, backtesting, strategy evolution, and a log. The risk gate is check_trade_legitimacy, described as a five-factor pre-trade check returning full, reduced, or skip. Note the maintenance-mode banner dated August 2026: bug and security reports are reviewed, but no new features and no hosted service are planned. The most recent releases are hotfixes (v0.5.5 for SPA path containment, v0.5.4 for anchoring integrity), which is consistent with that posture rather than contradicting it.

The audit chain: SHA-256 at creation, RFC 3161 anchoring, and what verification actually proves

Every decision is SHA-256 hashed at creation, per the README. The audit toolset is export_audit_trail, verify_audit_hash, verify_audit_chain, and get_daily_root. The daily root is the piece that makes bulk verification cheap: rather than re-hashing every entry, you check the root for a day. Anchoring is where the release history is informative. v0.5.3 made anchored audit the default and added decision instrumentation. v0.5.4 was an anchoring integrity hotfix five days before v0.5.5. A hotfix to the integrity of the anchoring path is exactly the kind of change you want to read the diff for before you rely on it, because the whole value proposition of anchoring is that the timestamp is not something you control. RFC 3161 anchoring gives you an external time reference; the local chain alone gives you tamper evidence against edits after the fact, but not against a wholesale rewrite of the database before anyone looked. The two properties are different and the README does not blur them, but it is easy to read the headline and assume the stronger one. The v0.5.5 SPA path containment hotfix is a reminder that the server also exposes a web surface, so the threat model is not limited to chain integrity.

Where it is the wrong tool: no execution, no hosted option, and a scoring factor you may not feed

Three boundaries are worth stating plainly. First, TradeMemory does not execute trades or touch money, per the README. If you want one component that decides and fills, this is not it, and wiring it to an execution server is work you own. Second, there is no hosted service and none is planned. You run it, you store the data, you back up the chain. For a compliance use case that is arguably correct, since custody of the audit record stays with you, but it means the operational burden is yours and the project will not absorb it. Third, the recall ranking depends on inputs the agent has to supply. Confidence and emotional state are scored factors. If your agent passes defaults for both, recall degrades toward context similarity plus recency, and the outcome-weighted claim becomes theoretical. The README does not document a validation that rejects empty or constant values for those fields. Before trusting recall, record a batch of trades with deliberately varied outcomes and check whether recall_memories actually surfaces the losers when you ask about the current setup. That is a test you can run in an afternoon and it is the only way to confirm the ranking works on your data.

How this differs from writing your own trade log or using a generic memory MCP server

The obvious alternative is a table plus a retrieval function of your own, or one of the general-purpose memory MCP servers that store conversation context. The difference is in what gets stored and how it is scored. A generic memory server has no notion of a trade outcome. It will happily return the most semantically similar past entry, which for a trading agent is often the wrong one: the trade you want to recall is the one that resembles the current setup and went badly. TradeMemory bakes outcome quality into the ranking and separates episodic from procedural from affective memory, so a lesson learned can be retrieved without dragging the entire episode with it. The cost of that structure is a schema you have to populate correctly. A hand-rolled log is simpler and you control every field, but you also own the hash chain, the daily root, the anchoring, and the verification endpoints. The trade is roughly: adopt TradeMemory for the audit machinery and the fan-out, and accept that the recall quality is a function of the inputs your agent provides. If your agent cannot supply confidence and context reliably, the simpler log is the better engineering choice.

Maintenance cost, licence terms, and what to check before you depend on it

The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is permissive enough for embedding in a proprietary stack, but the compliance use case cuts the other way: if you are relying on this for regulatory documentation, the licence does not give you a vendor to call. The maintainer states the project is feature-complete and in maintenance mode, with bug and security reports still reviewed. Practically, that means you should expect to read the diffs of security hotfixes yourself, because the cadence suggests they arrive as needed rather than on a schedule. The README also mentions a paid offering, statistical analysis of exported MT4/MT5 trading records, which is a separate service and not part of the open source package. Three things to verify before you commit: that your Python environment satisfies the package metadata for tradememory-protocol, that the anchoring path is configured if you intend to rely on RFC 3161 timestamps rather than the local chain, and that your audit retention and export process handles the export_audit_trail output in whatever format your reviewer expects. If none of those three can be answered, the adoption decision is premature regardless of how the recall scoring performs.

Editorial conclusion

Adopt TradeMemory if you run an MCP-capable agent or an MT5-linked EA and you need two things the execution servers do not provide: recall weighted by how past trades actually ended, and a hash chain you can hand to someone else. Do not adopt it if you need a hosted service, an actively developed feature roadmap, or a single tool that both decides and executes: the maintainer states the project is feature-complete and in maintenance mode, and the README is explicit that TradeMemory does not execute trades or touch funds. Before you commit, verify three things against your own setup: that your Python version satisfies the package metadata, that the anchoring path is configured if you intend to rely on RFC 3161 timestamps rather than the local chain alone, and that the MIT licence terms fit how you plan to redistribute or embed the server.

Official sources

1. License: MIT
2. mnemox-ai/tradememory-protocol on GitHub
3. Project website
4. README
5. Releases