What an MCP memory server actually does
MCP, the Model Context Protocol, is the open standard several AI coding tools use to reach external capabilities. An MCP memory server is one of those capabilities: a service your agent calls, over MCP, to save something durable and get it back later, instead of losing it when the session ends.
thinqOS runs one of these servers at app.thinqos.com/mcp. It is not a demo endpoint; it is the same server Claude Code and Codex use once you connect them. The tool your agent calls to read memory is recall_mind. What comes back is not a raw transcript search; it is the relevant slice of your Mind: beliefs, preferences and lessons, each with a source, so you can tell what the agent is trusting and why.
A real call, not a spec description
This is the actual request that reaches the server, taken from the connect guide most people follow first:
curl -X POST https://app.thinqos.com/mcp \ -H "Authorization: Bearer $THINQOS_API_KEY" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"recall_mind","arguments":{"query":"deployment approval"}}}'
That returns Mind context for the query, over standard MCP JSON-RPC. No plugin required to test it; any MCP-aware client, or curl, can make this call once it holds a valid key.
Writing is different from reading
Storing a memory goes through a separate REST endpoint, not MCP, and that split is deliberate rather than an oversight: an API key is refused on identity-resolving REST reads, so recall for a key holder runs over MCP instead. Writing a fact returns extraction_status: "pending" immediately; the fact is not yet a searchable belief. Extraction runs asynchronously and recall will not surface it until that status reaches "done". A successful write is not yet a learned belief, and a memory server that hides that distinction is hiding the part most worth knowing.
Two kinds of retrieval, not one search box
A question about a general preference needs different evidence than a request for an exact identifier from three weeks ago. thinqOS keeps both paths open: semantic search over related meaning, and lexical search over exact words and identifiers, so recall_mind is not forced to pick one at the cost of the other. Measure misses and latency on your own queries rather than trusting a demo; a retrieval call returning 200 is not evidence it found the fact you needed.
What makes it a Mind and not a key-value store
The simplest MCP memory servers store a blob of text per key. thinqOS stores an owned claim: who holds it, where it came from, how confident the system is, and whether it has been corrected. That matters when two agents, or two people, hold different views of the same fact; a flat store cannot represent that disagreement, and a Mind can.
Before you depend on it
thinqOS is in private preview, and the same caution that applies to any early server applies here: test the specific call your workflow needs, on your own account, before building around it. Confirm a write actually reaches extraction_status "done", confirm recall_mind returns it afterward, and check what happens when you correct or delete a stored fact. A tool that reports success is a reason to verify, not a substitute for verifying.
The access model matters as much as the protocol. An MCP memory server that returns whatever it holds, to whoever asks, is not one you want near real work. thinqOS scopes recall to the identity that owns the Mind being queried; review the trust page before connecting anything beyond a test account.