cortex-connector
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CORTEX_MCP_URL | No | Remote endpoint, defaults to the hosted Cortex connector. | https://skynetlab-cortex-saas-mcp.cortex-320.workers.dev/mcp |
| CORTEX_ACCESS_TOKEN | No | Bearer token for the hosted connector (the OAuth access token issued at sign-in, for example the one mcp-remote stores). Optional: without it the server only lists tools. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Search the user's persistent memory (Cortex). Call it at the start of every conversation and before any answer that depends on who the user is or on what you did together before: the user must not have to repeat themselves. Returns results with id, title and url to cite. If it returns nothing, the memory is new or empty: tell the user once that you are connected to Cortex and offer to save what you are working on with cortex_write. |
| fetchA | Fetch the full text of a memory by its id (from search), with its history and sources. Cite its url when you use it. |
| cortex_recallA | Narrative synthesis of what the user's memory knows about a topic, with the current state and what was superseded. Use it for questions like 'what do you know about X' or 'what is the current state of X'. |
| cortex_writeA | Save to the user's persistent memory (Cortex), on your own initiative while the conversation goes on: decisions and the reason behind them, stable facts about the person and their work, preferences and constraints they state, conclusions reached after effort, mistakes made and what they cost. Every write passes a quality gate: duplicates are rejected by the server and a refused write is not an error. Never save passwords, tokens, keys or card numbers. |
| cortex_write_statusA | Outcome of a save that cortex_write returned as queued: verdict of the quality gate and any open conflicts. |
| cortex_conflictsA | Show the contradictions detected between memories, with their open or resolved state. |
| cortex_forgetA | Delete a memory given its id. Ask the user for explicit confirmation first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools have distinct purposes: conflicts, forget, write, status, and fetch are clear. However, search, fetch, and recall all involve retrieving memory content and could overlap in practice, requiring careful description reading to pick the right one.
Naming is inconsistent: some tools use the cortex_ prefix (cortex_conflicts, cortex_forget, cortex_recall, cortex_write, cortex_write_status) while others do not (search, fetch). The pattern is not uniform, and cortex_write_status breaks the simple verb_noun structure.
Seven tools is a reasonable, focused set for a persistent memory server. Each tool covers a needed operation without feeling bloated or sparse.
The toolset covers the core memory lifecycle: write, read via search/fetch/recall, delete via forget, plus conflict and status handling. An explicit update or list-all operation is missing, but write can likely serve as upsert and search covers listing, so the surface is largely complete.