Which integrations are available for this server?

Allows searching and retrieving memories from Cognia that contain GitHub repositories, issues, and pull requests. Allows searching and retrieving memories from Cognia that contain Jira issues and projects. Allows searching and retrieving memories from Cognia that contain Linear issues and projects. Allows searching and retrieving memories from Cognia that contain Notion pages and databases. Allows searching and retrieving memories from Cognia that contain Slack messages and files.

How do I use @cogniahq/mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@cogniahq/mcp search for the decision on database migration" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@cogniahq/mcp

Official

by cogniahq

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@cogniahq/mcp

npm License: MIT Node

End-to-end encrypted memory for Claude Desktop, Cursor, Zed, Cline, and any MCP-compatible client. Bring your own OpenAI key. Open source under MIT.

npx -y @cogniahq/mcp init YOUR_COGNIA_API_KEY

That prints the config block you paste into Claude Desktop, Cursor, or Zed. Restart the client and your AI assistant can query your Cognia workspace as a native tool.

What this is

A Model Context Protocol server that exposes your Cognia memory to any MCP client. Your assistant can search, retrieve, and act against decisions, notes, documents, and integrations you've connected to Cognia (Slack, Notion, Linear, Jira, GitHub, Drive, and more).

It is the client-side surface. The backend it talks to is end-to-end encrypted at rest with per-org keypairs (libsodium Argon2id); the database holds only ciphertext. With BYOK enabled, your prompts and embeddings go to your OpenAI account on your contract, not ours. Threat model is public at https://cogniahq.tech/security.

Related MCP server: Cairn

Tools exposed

Tool	What it does
`cognia_search`	Hybrid (dense + sparse BM25) search with cross-encoder reranking
`cognia_get_memory`	Fetch the full content of a single memory by id
`cognia_list_memories`	Paginated chronological listing, optional substring filter
`cognia_action_plan`	Draft an integration action (e.g. create a calendar event)
`cognia_action_execute`	Execute a previously drafted action

Mutating actions are drafted first by default. Execution is a separate tool call so the assistant cannot silently change your external systems.

Install

Claude Desktop

// ~/Library/Application Support/Claude/claude_desktop_config.json  (macOS)
// %APPDATA%\Claude\claude_desktop_config.json                       (Windows)
{
  "mcpServers": {
    "cognia": {
      "command": "npx",
      "args": ["-y", "@cogniahq/mcp"],
      "env": { "COGNIA_API_KEY": "ck_live_..." }
    }
  }
}

Cursor

// ~/.cursor/mcp.json  (or .cursor/mcp.json in your repo for project-scoped)
{
  "mcpServers": {
    "cognia": {
      "command": "npx",
      "args": ["-y", "@cogniahq/mcp"],
      "env": { "COGNIA_API_KEY": "ck_live_..." }
    }
  }
}

Zed

// ~/.config/zed/settings.json
{
  "context_servers": {
    "cognia": {
      "command": { "path": "npx", "args": ["-y", "@cogniahq/mcp"] },
      "env": { "COGNIA_API_KEY": "ck_live_..." }
    }
  }
}

Restart your client. Your assistant now has Cognia tools.

Don't want to remember the JSON? Run npx -y @cogniahq/mcp init and it prints all three blocks with your API key inlined.

Getting an API key

Sign up at https://cogniahq.tech (free up to 5 seats, no card)
Open Settings → API keys
Create a key. Copy the ck_live_... value (shown once)

Environment variables

Variable	Required	Default
`COGNIA_API_KEY`	yes	—
`COGNIA_BASE_URL`	no	`https://api.cogniahq.tech`
`COGNIA_TIMEOUT_MS`	no	`30000`

Use as a TypeScript client

The same package also exports a typed REST client if you want to build against the Cognia API without the MCP transport.

import { CogniaClient } from '@cogniahq/mcp/client'

const cognia = new CogniaClient({ apiKey: process.env.COGNIA_API_KEY! })

const hits = await cognia.search.query({ query: 'postgres migration decision', limit: 5 })
for (const hit of hits) {
  console.log(hit.title, hit.snippet)
}

Full surface: cognia.memories.list / iterate / retrieve / update / delete, cognia.search.query, cognia.actions.plan / retrieve / execute. Built-in retry with exponential backoff and Retry-After support.

Build from source

git clone https://github.com/cogniahq/cognia-mcp.git
cd cognia-mcp
npm install
npm run build
node dist/cli.js --help

Why open source

If you ship an MCP server that touches company knowledge, your security team will want to read it before approving the install. So we open-sourced ours. The encrypted backend, search pipeline, and admin console stay closed. The surface that runs on your machine is right here.

The integrations SDK and a small cognia memory CLI will follow on the same MIT terms.

License

MIT. See LICENSE.

Available Tools

5 tools

cognia_action_executeB

Execute a previously drafted Cognia action by action_run_id. This may mutate external systems such as Google Calendar.

ParametersJSON Schema

Name	Required	Description	Default
`actionRunId`	Yes

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions 'may mutate external systems such as Google Calendar,' which is a useful behavioral disclosure. However, it omits details on idempotency, error handling, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first stating purpose, the second adding behavioral context. No waste, but could have included more essential details without overloading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, and no annotations, the description covers the basic purpose and side effects. However, it lacks result details and usage context, making it somewhat incomplete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It adds meaning by linking actionRunId to 'previously drafted action,' but does not explain format, source, or validation rules beyond the schema's type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes a previously drafted action by its ID, using specific verb and resource. It implicitly differentiates from sibling tools like action_plan (planning) and get_memory (retrieval), but does not explicitly distinguish usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use or not use this tool vs alternatives like cognia_action_plan. It implies use after drafting, but lacks explicit context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cognia_action_planA

Plan a Cognia integration action, such as listing, creating, updating, or deleting Google Calendar events. Returns an action_run_id. Mutating drafts require execution before external systems change unless executionPolicy is auto_execute and the API key permits it.

ParametersJSON Schema

Name	Required	Description
`prompt`	No	Natural-language action request.
`actionName`	No	Optional explicit action name.
`arguments`	No	Optional explicit action arguments.
`executionPolicy`	No	Defaults to draft_first.
`timeZone`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the full transparency burden. It discloses that mutating drafts require execution and explains the auto_execute behavior, which adds important behavioral context beyond the bare schema. However, it omits details like rate limits, auth requirements, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences with no fluff. It front-loads the purpose with examples, then gives return value and behavior. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters and no output schema. The description explains the return value (action_run_id) and the draft/execution model, but lacks details on how parameters interact, error cases, or typical usage patterns. Some gaps remain for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so baseline is 3. The description adds some semantic value for the executionPolicy parameter by explaining its effect, but does not significantly enhance understanding of other parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool plans a Cognia integration action, with explicit examples like listing, creating, updating, or deleting Google Calendar events. It distinguishes from sibling tools by mentioning the action_run_id and executionPolicy, indicating it creates a draft for later execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some guidance on when to use auto_execute vs draft_first, but does not explicitly contrast with sibling tools like cognia_action_execute or specify scenarios to avoid this tool. The guidance is implied but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cognia_get_memoryA

Fetch the full content of a single memory by id. Use after cognia_search when you need more than the snippet.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The memory id (uuid).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It states it fetches 'full content' and implies a read-only operation. For a simple retrieval tool, this is sufficient, though it could mention lack of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, then immediate usage guidance. Every sentence serves a purpose with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description covers essential aspects: what it does and when to use. It could mention the return format briefly, but 'full content' suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for the single parameter 'id' ('The memory id (uuid).'). The description adds no additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Fetch the full content of a single memory by id', using a specific verb and resource. This distinguishes it from siblings like cognia_search which returns snippets, and cognia_list_memories which lists many.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after cognia_search when you need more than the snippet', providing a clear when-to-use instruction and directly naming the alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cognia_list_memoriesA

Paginated chronological listing of memories. Useful for browsing recent activity. Use cognia_search for semantic queries.

ParametersJSON Schema

Name	Required	Description
`cursor`	No	Opaque pagination cursor from a prior response.
`limit`	No	Page size, default 50.
`q`	No	Optional substring filter on title / content (case-insensitive).

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description accurately conveys read-only, paginated, chronological behavior. Mentions cursor, limit, and optional substring filter. Does not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. Front-loaded with the tool's primary purpose and usage differentiation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters and no output schema, the description adequately covers pagination, ordering, and filtering. Missing details on the return format, but sufficient for a listing tool with sibling differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by explaining cursor from prior response, default limit of 50, and case-insensitive substring filter (q). This goes beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it is a paginated chronological listing of memories, useful for browsing recent activity. Explicitly distinguishes from cognia_search for semantic queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: 'Use cognia_search for semantic queries.' Also implies use for browsing recent activity, helping the agent decide when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cognia_searchA

Hybrid (dense + sparse BM25) search across the user's Cognia memories with cross-encoder reranking. Use this whenever the user asks about anything in their workspace, documents, or browsing history.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The natural-language search query.
`limit`	No	Max results to return (1-50). Default 10.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full behavioral burden. It mentions hybrid search and reranking, but does not disclose any potential side effects, authentication needs, or rate limits. For a read-like tool, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words; the most critical information (search type and usage context) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a simple search tool: it explains the hybrid nature, reranking, and when to use it. Lack of output schema is acceptable since description covers behavior. Minor gap: no mention of return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters (query and limit) with descriptions. The tool description adds context about search type but no additional parameter details beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs hybrid search across Cognia memories and explicitly mentions workspace, documents, and browsing history, distinguishing it from sibling tools like cognia_get_memory and cognia_list_memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this whenever the user asks about anything in their workspace, documents, or browsing history,' which tells when to use it, though it doesn't mention alternatives for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 19, 2026
- First observedcognia_action_execute
- First observedcognia_action_plan
- First observedcognia_get_memory
- First observedcognia_list_memories
- First observedcognia_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: action planning vs execution, and memory retrieval via different methods (get by ID, list chronologically, search semantically). No overlap.

Naming Consistency4/5

All tools share the 'cognia_' prefix, but naming patterns vary: two use 'domain_verb' (action_execute, action_plan), two use 'verb_noun' (get_memory, list_memories), and one uses just a verb (cognia_search). Also singular/plural inconsistency (memory vs memories).

Tool Count5/5

With 5 tools covering two distinct domains (actions and memories), the count is well-scoped and not overwhelming or too sparse.

Completeness3/5

The actions domain covers plan and execute but lacks listing, updating, or canceling actions. The memory domain allows reading (get, list, search) but no create, update, or delete operations, leaving notable gaps for a full lifecycle.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpOAuth
ai.zine
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Knowledge & Memory RAG Systems Autonomous Agents
2
XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
19212
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42
Airbyte AgentsOAuth
io.github.airbytehq
Let AI agents query data and act across all your business apps via MCP.
Data Platforms AI & Machine Learning RAG Systems
2

Related MCP Servers

Memory Engine MCP
Knowledge & Memory AI & Machine Learning
SimoneB79
A
license
Not graded
quality
A
maintenance
Enables AI assistants to have a living memory with atomic knowledge storage, multi-factor recall, organic decay, automatic learning, and graph traversal via MCP.
Updated 6 days ago (2026-08-31 08:16 UTC)
1
MIT
Cairn
Knowledge & Memory Note Taking Search
johnmontejano
A
license
Not graded
quality
B
maintenance
Enables AI tools to query a user's private, locally stored memories (notes, documents) with source citations, using the MCP protocol.
Updated a month ago (2026-08-09 08:44 UTC)
15
MIT
Knowledge MCP
RAG Systems Cloud Storage Communication
chanthr
A
license
Not graded
quality
C
maintenance
Exposes your Google Drive, Slack, GitHub, and Railway to MCP clients with semantic search, per-user permissions, and optional OAuth, allowing natural-language access to your private data and infrastructure.
Updated a month ago (2026-08-10 03:09 UTC)
18
MIT
jalipata-mcp-memory
Knowledge & Memory
alfianyusufabdullah
A
license
A
quality
B
maintenance
Provides persistent, multi-tenant knowledge graph memory for MCP-capable AI tools, allowing them to recall and store entities, observations, and relations across sessions with keyword search.
Updated 25 days ago (2026-08-12 04:55 UTC)
10
30
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cogniahq/cognia-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@cogniahq/mcp

What this is

Tools exposed

Install

Claude Desktop

Cursor

Zed

Getting an API key

Environment variables

Use as a TypeScript client

Build from source

Why open source

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API