Choose REST when your application owns a predictable lifecycle and needs explicit request, retry, and response handling. Choose MCP when an MCP-compatible agent should discover and invoke memory tools inside its tool loop. Both can connect an agent to Northsun; the important differences are who decides when to call, which contract you pin, and how you verify the result.
What does REST give you?
REST makes the application the orchestrator. Your code decides exactly when context is recalled, what fields enter the agent prompt, when a completed interaction is submitted, and how failures are retried.
Northsun's frozen public REST surface contains three endpoints:
POST /v1/recall_and_enrichPOST /v1/calls/endGET /v1/caller/{phone_number}
That narrow contract is well suited to voice and other event-driven systems. A pre-call hook can recall context before the first useful turn. An end-of-call hook can submit the completed transcript and outcome. Your integration can enforce deadlines, neutral fallbacks, deduplication, and later verification without relying on the model to choose the lifecycle.
What does MCP give you?
MCP makes tools available inside a compatible agent client. The agent or host can inspect tool definitions and call the appropriate operation during its workflow.
The hosted Northsun endpoint exists at:
https://mcp.mnemix.ai/mcp
Source-defined authenticated tool families include the frozen caller-memory operations, contact workflows, and an evolving governed-context loop. A complete authenticated production lifecycle has not been freshly re-proved for this release. Because the MCP tool surface evolves independently from the frozen REST trio, integrations should inspect tools/list and pin the schemas they depend on.
MCP is useful when the human is already working inside a coding, chat, or workflow agent and explicit tool use is part of that environment. It reduces custom transport glue, but it does not remove the need for authentication, tool-policy decisions, error handling, or outcome verification.
Which one should a voice agent use?
Use REST by default when the voice platform or your server exposes deterministic call-start and call-end hooks. The lifecycle timing is known, and memory should not depend on whether the model decides to call a tool before speaking.
MCP can still be useful for operator tools, follow-up workflows, or an agent host that natively owns the entire interaction loop. But a tool being available does not guarantee it will be invoked at the required moment. If the first-turn deadline matters, keep orchestration outside the model unless your host proves deterministic tool execution.
Which one should a coding or chat agent use?
MCP is often the more natural fit for Claude Code, Codex, Cursor, or another compatible agent environment. It lets the agent discover memory operations alongside its other tools without building a bespoke UI.
REST remains appropriate when your application, gateway, or internal service should own context assembly. For example, a support application may fetch customer context server-side and provide a constrained packet to the chat model rather than granting the model a broad tool surface.
The choice is about orchestration and authority, not whether the agent is “voice” or “chat.”
Can one product use both?
Yes. A common architecture uses REST for deterministic lifecycle events and MCP for interactive investigation:
- REST recalls caller context at call start;
- REST writes back the completed call after hangup;
- an authenticated MCP client lets an operator or workflow agent inspect contact history later;
- both use tenant-scoped credentials and retain correlation evidence.
Avoid implementing the same write from both paths unless you have an explicit idempotency and deduplication strategy. Two transports do not create two sources of truth.
How do the contracts differ?
| Decision | REST | MCP |
|---|---|---|
| Invocation owner | Application code | Agent or MCP host |
| Public stability boundary | Frozen three-endpoint caller surface | Tool schemas evolve independently |
| Discovery | OpenAPI and docs | MCP discovery and tools/list |
| Timing control | Explicit application hook | Depends on host and tool policy |
| Best first proof | One recall/write-back/later-recall lifecycle | Authenticated discovery plus a controlled tool call |
| Failure handling | Application-owned HTTP policy | Host errors plus tool result handling |
Neither transport proves proactive Beacon delivery. Beacon and proactive salience remain design-stage.
How should you verify REST?
Run a controlled lifecycle:
- Recall a test caller with a unique session ID.
- Submit a unique observation after the interaction.
- Treat
204 No Contentas confirmation the interaction is already committed durably. - Recall again immediately — no wait is required.
- Verify the unique observation appears and retain both trace IDs.
How should you verify MCP?
- Configure the hosted URL with a tenant-scoped bearer key.
- Reload the MCP client.
- Inspect the advertised tools rather than assuming a copied list is current.
- Run a read-only lookup against a controlled test record.
- Distinguish
404empty state from401authentication failure. - If you test a write, verify it with an independent later read.
The repository contains a separate stdio MCP package, but it is not currently published on npm. Public users should use the hosted endpoint rather than documenting an npm install that does not exist.
What should you choose first?
If you own lifecycle hooks, start with the Quickstart and API reference. If the agent environment already supports MCP, use the MCP server guide and verify authenticated discovery before depending on a tool. Choose the smallest surface that lets you prove one real context loop end to end.