TradeMemory Protocol: a decision audit trail and memory layer for AI trading agents

The gap TradeMemory Protocol fills: agents that cannot remember their own trades

An MCP-connected trading agent can place an order, pull a quote, and read a chart. Ask it what happened the last time it bought the same instrument under the same conditions and it has nothing to draw on. The context window ends, the session restarts, and the agent repeats the same mistake with the same confidence. TradeMemory Protocol is built for that specific gap. The README frames it bluntly: every MCP server handles execution, none handle memory. The project records each decision, attaches the outcome once it is known, and makes both retrievable later through the same tool interface the agent already speaks. The intended users are named in the README: a US equity trader running a pre-flight checklist before each position, a forex EA system syncing decisions from MT5, and a compliance team that needs tamper-evident records. All three share one property. They make decisions through an AI agent and need a record of those decisions that survives the session. The project does not touch money or execute orders, which the README states directly. That boundary is the point: it is a memory and audit component, not a broker integration.

Five memory layers, outcome-weighted recall, and the SHA-256 chain

The mechanism has four stages. Recall happens before a trade: the agent retrieves past trades scored by outcome quality, context similarity, recency, confidence, and emotional state. The project calls this the OWM Framework, documented in docs/OWM_FRAMEWORK.md, and the weighting is the interesting design choice. A trade that lost money is not discarded; it is weighted by how it turned out, so recall surfaces the decisions that actually mattered rather than the most recent ones. Record happens after a trade: a single call to remember_trade writes across five layers, which the README lists as episodic, semantic, procedural, affective, and trade records. Splitting memory this way lets one call feed both a factual record and a behavioural profile. Reflect runs on a daily, weekly, or monthly cadence and looks for behavioural drift, strategy decay, and recurring mistakes. Audit hashes every decision with SHA-256 at creation time, and the v0.5.3 release notes describe anchored audit as the default, with RFC 3161 anchoring referenced in the project description. Two verification tools exist for the chain: verify_audit_hash for a single record and verify_audit_chain for the sequence. The v0.5.4 release was an anchoring integrity hotfix, which tells you the anchoring path had a real defect that was fixed in July 2026.

Installing tradememory-protocol and recording a first trade

The package is on PyPI and requires Python 3.10 or newer according to pyproject.toml. Install it with pip:

pip install tradememory-protocol

The README then shows registration with Claude Desktop by adding an entry to claude_desktop_config.json. The server is launched through uvx, so uv must be available on the machine running the client:

{
  "mcpServers": {
    "tradememory": {
      "command": "uvx",
      "args": ["tradememory-protocol"]
    }
  }
}

After restarting the client, the twenty MCP tools should appear in the tool list. The README's first real use is a plain instruction to the model, not a tool call: tell Claude to record an AAPL long at $195 with the reasoning attached. That maps to the remember_trade tool. For Claude Code the README gives a one-line registration instead:

claude mcp add tradememory -- uvx tradememory-protocol

Running from source is also documented: clone the repository, install in editable mode, and start the module. The Dockerfile uses python:3.11-slim and sets the entrypoint to tradememory-protocol, so a container build needs no extra arguments. Note that docker-compose.yml in the repository root is a development database stack, not the server: it starts a timescale/timescaledb-ha:pg18 container named tradememory-db on port 5432 with user, password, and database all set to tradememory. If you only want the MCP server, pip and uvx are enough.

Where TradeMemory Protocol is the wrong tool

The project is in maintenance mode. The README's own status note, dated August 2026, says it is feature-complete, that bug and security reports are still reviewed, and that no new features or hosted service are planned. The last push was on 2026-09-08, and the most recent release, v0.5.5, was a security hotfix for SPA path containment. A team that needs a vendor to add capabilities on request should look elsewhere. There is also a hard functional boundary. TradeMemory does not execute trades and does not touch funds, so it cannot be the only integration an agent has with a broker. If your problem is order routing or market data, this is the wrong layer. The repository carries a LIMITATIONS.md file, and the README links to it, but the README itself does not enumerate the limitations, so anyone evaluating the project for regulated use should read that file before, not after, building on top of it. Two more constraints are visible in the packaging. The base install is SQLite-backed by default; the postgres extra pulls in SQLAlchemy, asyncpg, and Alembic for a PostgreSQL deployment, which is a separate operational commitment. And the optional MT5 integration requires MetaTrader5, which requirements.txt leaves commented out and notes is needed for mt5_sync.py only. Windows-only MetaTrader5 installs are a real constraint if your EA runs anywhere else.

TradeMemory Protocol versus a general agent-memory store

The obvious alternative is a general-purpose memory layer for agents, such as a vector store plus a summarisation step that persists conversation state between sessions. The difference is in what gets scored. A general memory store retrieves by similarity to the current query. TradeMemory retrieves by outcome quality as well, which means a losing trade with a distinctive context can outrank a winning trade with a common one. That is the whole reason the OWM Framework exists, and it is not something a plain embedding index gives you without custom scoring code. The second difference is the audit chain. A general store keeps records; it does not hash each one at creation and let you verify the sequence later. If your requirement is a regulator asking for a verifiable decision record, a vector store answers a different question. The trade-off runs the other way too. A general memory store is indifferent to domain, so it works for any agent, while TradeMemory's five layers and its risk tools such as check_trade_legitimacy are shaped around trading decisions specifically. If your agent is not making trading decisions, most of the twenty tools do nothing for you.

Licence, upgrade cost, and the paid service next to the free package

The licence is MIT, declared in pyproject.toml and in the LICENSE file at the repository root. That permits commercial use and modification, and there is no copyleft obligation on your own code. This is not legal advice; read LICENSE and TERMS.md yourself if the audit trail is going into a regulated workflow. Upgrade cost is low in the sense that the package is a normal pip dependency pinned by version, and the release history shows small patch increments: v0.5.3 added anchored audit by default and decision instrumentation, v0.5.4 was an anchoring integrity hotfix, and v0.5.5 was a security hotfix. That cadence means an upgrade can change default behaviour, as v0.5.3 did by turning anchoring on. Pin the version and read CHANGELOG.md before moving. The paid offering is separate and narrower than the package: the maintainer sells statistical analysis of your own MT4/MT5 trading history, a descriptive-statistics report covering where losses concentrate and how position sizing changes after losses. The protocol itself is free and self-hosted. Nothing in the README suggests the paid report is required for the software to function.

Editorial conclusion

Adopt TradeMemory Protocol if you already run an AI agent or an MT5 EA that makes trading decisions and you need those decisions recorded and recallable, especially if someone downstream will ask why a position was taken. Do not adopt it expecting trade execution, price feeds, or a hosted service: the README states the project is in maintenance mode with no new features or hosted offering planned, and the package installs as a local MCP server or REST API. Before committing, read LIMITATIONS.md, confirm whether you need the postgres extra for concurrent writes, and run verify_audit_chain against your own exported records so you know what a valid chain looks like on your machine.

Frequently asked questions

Official sources

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