Work architected at Fifth9
Cortex memory.
A connection beyond one session.
Give an AI tool a way to retain useful context and recover it later. Cortex MCP provides a connection interface to memory, with discovery, sign-in and scoped operations kept distinct.
Scope: Development endpoint reported; authenticated tool use not demonstrated by this review.
Status · 3 November 2026 review snapshotA separate platform review reported responding development health, discovery and sign-in metadata, plus refusal of a request without a token. It identified five tools in the deployed definition and seventeen in newer source. A complete authenticated client session and tool calls were not independently demonstrated by that review.
From a tool to remembered context
Discover. Connect.
Request scoped memory.
Discovery describes the resource and its sign-in service. An authenticated client can then request memory operations through the intended interface.
Detailed diagram and text
Connection responsibilities, with separate evidence
MCP client
A compatible AI tool requests access to the memory resource.
Discovery
Resource metadata identifies the sign-in service and memory permissions.
Sign-in service
Published metadata describes the authorisation flow.
Memory MCP tools
Request storage, recall, removal, conversation append or a health check.
Cortex memory
Retain and retrieve records with their applicable access scope.
Interface responsibilities, not a successful sign-in or tool-call trace. Health and metadata responses establish narrower facts than usable authenticated memory.
Illustrative use
Keep a decision.
Recover its conditions.
A team records why a daily reporting cycle was sufficient. A later tool could retrieve that decision when freshness requirements change, then help someone examine whether the old reasoning still applies.
“Bring back the decision and the conditions behind it.”
This is the intended use, not a reported customer result. Storing and retrieving a record does not by itself prove better decisions or learning.
Technical reading
What is exposed—and what was checked?
Reported observations, implemented interfaces and complete user journeys carry different evidence.
Discovery and the connection contract
The review reported protected-resource metadata at the development memory discovery endpoint. It named the identity service and memory:read and memory:write permissions. The identity metadata described authorisation-code sign-in with PKCE, registration, refresh and revocation.
These are advertised interfaces. Metadata responses and refusal of an unauthenticated request do not establish a complete OAuth journey, client compatibility or isolation between users. The review did not independently complete sign-in followed by memory tool calls. Consult the development setup instructions for the source connection procedure; those instructions are not a verified client walkthrough on this page.
Five reported deployed definitions; seventeen in newer code
The 3 November review identified five tools in the deployed version’s definition: memory.remember, memory.recall, memory.forget, memory.chat.append and memory.health. This count came from the version’s definition file, not an authenticated tool-list and execution session.
The newer inspected source defines seventeen tools. The additional definitions cover export, pins, archive, recovery, candidate procedures, search, entity lookup and connection management. Definitions show intended callable interfaces; they do not establish that those newer operations are exposed or effective on the reported endpoint.
Connection management and continuity
The review reported a connection-status response describing a ready control plane and a one-time grant arrangement. Agent-managed connection tools exist in the newer source but were not part of the five-tool deployed definition. Client and proxy packages were also described as source-only work.
Keeping records outside a particular model supports continuity across tools and sessions. It does not guarantee that every client interprets a recalled record correctly. Access scope, retained meaning, correction and the task’s actual outcome still need examination.
Development scope and evaluation
The reported endpoint is a development deployment, not a production service offer or availability commitment. The review identified older deployed builds than the inspected source. This page has not repeated runtime probes or exercised sign-in, tool execution, retention or recovery.
A useful evaluation would follow one authorised client through storage and later recall, check isolation and correction under the intended scope, and compare task usefulness with a baseline. Those checks should report failures and costs as well as successful responses. Historical notes about deployment and tool counts remain dated snapshots.
Continue exploring