MCP
Nenavi Cloud serves PRME’s MCP tools over HTTP at https://api.prismemory.com/mcp, so an AI client can store and recall memory without any code from you. It uses the same API key as the HTTP API, sent in the Authorization header. The tools are the engine’s own MCP server tools, run on the project of the key that calls them. The local PRME MCP server, which you run on your machine, is a different thing. See MCP server for that one.
The key sits in the client’s configuration in plain text. Keep that file out of version control, or use your client’s secret handling if it has any.
Connect a client
Replace <your API key> with a project key from the console. The service does not read the server name or any environment variable. Use any names you like.
Claude Code
Run this in your project. The default local scope keeps the key out of the repository.
claude mcp add --transport http nenavi https://api.prismemory.com/mcp \
--header "Authorization: Bearer <your API key>"Cursor
Save this as .cursor/mcp.json in your project, and keep the file out of version control. Or save it as ~/.cursor/mcp.json to use it in every project.
{
"mcpServers": {
"nenavi": {
"url": "https://api.prismemory.com/mcp",
"headers": { "Authorization": "Bearer <your API key>" }
}
}
}Claude Desktop
Claude Desktop starts local commands and does not take a URL with headers. The mcp-remote bridge, which needs Node.js, forwards to the endpoint. Add this to claude_desktop_config.json:
{
"mcpServers": {
"nenavi": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://api.prismemory.com/mcp",
"--header",
"Authorization: Bearer <your API key>"
]
}
}
}The server name (nenavi here) is your choice. It only labels the server in your client.
How it works
- Stateless. Each
POSTcarries one JSON-RPC message and gets its answer in the same response. There is no session to keep and no event stream.GETandDELETEon/mcpreturn405. - Tool arguments. A tool’s
user_idargument names one of your own end users, as it does over HTTP. - Body size. A request body over 4 MiB is refused with
413.
Limits
Every message counts as one request and one MCP call. A client that opens a new session for every call also sends a handshake and a tool list first, and those count too, so they use up the 60 requests per minute faster.
A call of memory_store, memory_ingest, memory_ingest_fast_many, or memory_retrieve is held to the same limits as the matching HTTP route, and returns the same errors. For example, a stored memory costs the same over MCP as over HTTP. See Limits and errors.
One difference: when the engine refuses a tool call itself, the answer is an HTTP 200 with an error inside the JSON-RPC result, not a 4xx status. Read the result’s error field.
memory_ingest_fast_many takes a request_id. It works as the Idempotency-Key header does: send the same request_id with every retry of a batch.
Not available
| Tool | Answer | Use instead |
|---|---|---|
memory_reingest | 422 reingest_unsupported_over_mcp | POST /v1/reingest, which runs in the background |
memory_reembed | 422 reembed_unsupported | None. The service uses one embedding model |
memory_inspect_privacy_policy, or any tool call with a policy | 422 privacy_policy_unsupported | Remove the policy |
memory_retry_extraction and memory_process_extractions need an owner, and a project key has none, so the engine refuses them in the alpha.