cognee-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ENV | No | Environment setting | local |
| LLM_API_KEY | Yes | API key for the LLM service | |
| TOKENIZERS_PARALLELISM | No | Control for tokenizers parallelism | false |
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rememberA | Store data in memory. Two modes depending on whether session_id is provided: Without session_id (permanent memory): Runs the full add + cognify pipeline to ingest data and build the knowledge graph, then the self-improvement loop (improve) unless self_improvement=False. With session_id (session memory): Stores the data in the session cache. Direct mode may also bridge it to the graph in the background; API mode uses typed cache entries and does not bridge to the graph. Omit session_id when the content should be stored as permanent graph memory. Pass either |
| recallA | Search memory with auto-routing and session awareness. When session_id is provided without datasets or search_type, searches session cache first by keyword matching. Falls through to the permanent knowledge graph if no session results match. Auto-routing picks the best search strategy when search_type is not specified. |
| forgetA | Delete data from memory. Can target a single data item, a specific dataset (by name or id), or everything the user owns. Removes data from the relational DB, graph DB, and vector DB. |
| search_toolsA | Search for tools using natural language. Returns matching tool definitions ranked by relevance, in the same format as list_tools. |
| call_toolA | Call a tool by name with the given arguments. Use this to execute tools discovered via search_tools. |
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 5 tools
Each tool has a clearly distinct purpose: remember stores, forget deletes, recall searches, call_tool executes, and search_tools finds tools. No overlap or ambiguity exists between them.
Tool names mostly follow a verb pattern, but three are single verbs (remember, forget, recall) while two are verb_noun compounds (call_tool, search_tools). This is a minor inconsistency but still predictable and readable.
Five tools is well within the ideal 3-15 range, and each tool earns its place for a memory management server, covering core operations without excess.
The tool surface covers the full memory lifecycle: ingestion (remember), retrieval (recall), and deletion (forget), plus tool discovery and execution for extensibility. No obvious gaps for the stated purpose.