@contextq/mcp
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@@contextq/mcp search my ContextQ memories for notes on the auth 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.
@contextq/mcp
MCP server for ContextQ -- exposes the ContextQ knowledge-management API (89 tools: save, search, ingest, goal graphs, agent sessions, relays, and more) as Model Context Protocol tools. A curated ~24-tool default set loads at connection to keep the token cost of tools/list low; the rest load on demand or via CONTEXT_MCP_TOOL_PROFILE=full -- see below.
npx -y @contextq/mcpClient configuration
Two environment variables are required in every client:
Variable | Description |
| Base URL of your ContextQ server (e.g. |
| API key sent as |
Optional:
Variable | Description |
|
|
Setup paths: Claude Code and Claude Desktop have automated setup via the contextq init CLI command. Cursor, Windsurf, and Cline require manual config file editing — see docs/mcp-setup.md for the full reference.
Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"contextq": {
"command": "npx",
"args": ["-y", "@contextq/mcp"],
"env": {
"CONTEXT_API_KEY": "sk_live_YOUR_API_KEY",
"CONTEXT_API_URL": "https://ctx.example.com"
}
}
}
}Claude Code
claude mcp add contextq \
-e CONTEXT_API_KEY=sk_live_YOUR_API_KEY \
-e CONTEXT_API_URL=https://ctx.example.com \
-- npx -y @contextq/mcpCursor
Add to your Cursor MCP config (.cursor/mcp.json or Settings > MCP):
{
"mcpServers": {
"contextq": {
"command": "npx",
"args": ["-y", "@contextq/mcp"],
"env": {
"CONTEXT_API_KEY": "sk_live_YOUR_API_KEY",
"CONTEXT_API_URL": "https://ctx.example.com"
}
}
}
}Windsurf
STATUS (2026-06-02): Windsurf was rebranded as Devin Desktop and Cascade was end-of-lifed (2026-07-01). If you have an existing Windsurf install, the configuration below still applies, but new installations should use Devin Desktop instead. Devin Desktop uses the same MCP config format under .devin/mcp.json.
Add to your Windsurf MCP config (.windsurf/mcp.json):
{
"mcpServers": {
"contextq": {
"command": "npx",
"args": ["-y", "@contextq/mcp"],
"env": {
"CONTEXT_API_KEY": "sk_live_YOUR_API_KEY",
"CONTEXT_API_URL": "https://ctx.example.com"
}
}
}
}Related MCP server: Agent Construct
What data is sent and tenant isolation
Only the requests your agent makes are sent. The MCP server is a stateless proxy -- it forwards each tool call to the ContextQ API via
CONTEXT_API_URLand returns the response. No telemetry, no background sync, no usage tracking beyond what your ContextQ server logs.Tenant-scoped API keys. Every ContextQ API key is bound to a single tenant. All
/api/*endpoints enforce tenant isolation -- an API key can only access the tenant it was issued for. Cross-tenant data leaks are impossible at the API layer.Per-request auth. Your
CONTEXT_API_KEYis sent as anAuthorization: Bearerheader on every call. It never appears in tool names, argument schemas, or responses returned to the LLM.
Client timeout configuration
A handful of ContextQ tools run LLM calls, kNN scans, or bulk DB operations server-side and can legitimately take longer than a typical MCP client's default request timeout. If your client aborts before the server responds, you will see a timeout error that looks like a broken tool — it usually isn't. Configure a longer per-server timeout for this MCP server rather than assuming the tool is hung.
Slow-class tools (recommend a longer timeout, e.g. 120000-180000 ms depending on workspace size):
Tool | Why it's slow |
| Clusters a workspace's contexts via vector similarity, then runs one LLM synthesis call per cluster. |
| Runs LLM judging over up to 20 nearest-neighbor contexts to decide links/archival. |
| Fetches/parses a source and runs LLM claim extraction + kNN diffing. Large or URL-sourced ingests already return |
| Re-clusters all of a tenant's contexts and runs one LLM synthesis call per cluster (admin scope). |
| Samples older contexts and asks the LLM to verdict each one (superadmin scope). |
| Applies a lifecycle/archive patch to up to 200 context ids in one call — bounded, but still slower than a single-row update. |
| Deletes up to 5000 |
| Clone or diff a workspace's full memory state (contexts, links, goal graph) — cost scales with workspace size. |
Everything else (ctx_search, ctx_get, ctx_save, ctx_list, agent_*, goal_*, relay_*, etc.) is ordinary CRUD/search and should complete well within a default client timeout.
These numbers are starting points, not guarantees — actual latency depends on your ContextQ server's hardware, workspace size, and configured LLM/embedding provider. Measure against your own deployment before tuning tighter.
.mcp.json per-server request_timeout_ms
Most MCP clients that support .mcp.json (including Claude Code) accept a per-server request_timeout_ms to override the client's default request timeout for every tool call on that server:
{
"mcpServers": {
"contextq": {
"command": "npx",
"args": ["-y", "@contextq/mcp"],
"env": {
"CONTEXT_API_KEY": "sk_live_YOUR_API_KEY",
"CONTEXT_API_URL": "https://ctx.example.com"
},
"request_timeout_ms": 120000
}
}
}request_timeout_ms applies per server, not per tool — if you regularly call slow-class tools, size it for the slowest one you expect to hit, not the average. Claude Code 2.1.206 fixed a bug where this field was silently ignored (a 60s default was applied regardless); confirm your Claude Code version is at least 2.1.206 if the setting doesn't seem to take effect.
Claude Code idle timeout
Independently of request_timeout_ms, Claude Code (2.1.187+) also enforces CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT — an idle-abort timeout (default around 5 minutes) that fires if an MCP tool call produces no activity for that long. Set it in your shell environment (not .mcp.json) when calling slow-class tools against a large workspace:
export CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT=300000 # milliseconds; raise if ctx_dream/ctx_ingest still time outTreat both settings as recommendations, not guarantees, of how long any given call will take.
API version compatibility
The 99-tool surface exposed by this MCP server is a direct projection of the ContextQ API (24 loaded by default, the rest via CONTEXT_MCP_TOOL_PROFILE=full or on-demand -- see "Client configuration" above). The tool count and signatures drift with the server. Pin compatible versions:
MCP package | ContextQ server API |
| ContextQ v2.x (99 tools) |
When upgrading your ContextQ server, check the changelog and bump the MCP package to the matching major version. A version mismatch may surface unknown tools or break call signatures.
License
MIT
Available Tools
24 toolsagent_bootAInspect
Boot an autonomous agent: ONE token-budgeted call returning everything needed to start or resume work. Call this FIRST in any agent run. Returns {agent, session:{...,role}, resume:{checkpoint_summary, open_tasks}, handoff:{tldr, source}, lessons:[], facts:[], brief, skills:[], skills_full, repo_map, siblings:[], budget:{limit, used, dropped}, client}. If a non-terminal session exists for this agent (or session_id is given), resume tells you exactly where you left off; handoff is the best-ranked latest handoff (a hand-written wrap SEED first). goal drives the facts, lessons AND skills retrieval. skills are parametrized procedures distilled from verified past runs matching the goal ({context_id, name, description, success_count, similarity}) -- check them BEFORE re-deriving a solution. On a session's later boots skills holds only new or changed entries and skills_full is false (empty then means nothing new, not no skills); pass full:true for the complete set. With project_id you also get a goal-graph brief {north_star, role, lane, next, blocked_on, blocking, done} and the session role is inferred from the matched goal node. With include_repo_map:true on a code-indexed workspace, repo_map carries top-ranked file signatures to answer "where is X handled" without grepping. siblings lists other active sessions in this workspace (last ~60 min, max 5) so you can coordinate via relay_* before touching shared resources. Slots fill resume > handoff > lessons > facts > brief; overflow is reported in budget.dropped. Trigger: resume or catch up on tracked work ("hôm trước tới đâu", "tiếp gì", "tóm lại đang làm gì", "what's next", "resume", "where did we leave off", "catch me up"). Skip for unrelated casual questions.
Inputs: agent (required), full, goal, workspace, +7 more.
agent_checkpointAInspect
Snapshot the agent's working state so a restart/crash can resume from exactly here. state is an arbitrary JSON scratchpad (cursor, partial results, plan, open files). summary is a 1-line 'where I am'. Returns the checkpoint with its monotonic seq. Call periodically after each chunk of progress.
Inputs: session_id (required), state, summary, token_estimate.
agent_handoffAInspect
Generate a handoff document for the session's workspace at run end (wraps the dream handoff generator — LLM-synthesized TL;DR + in-progress + next-steps + open-questions). Links the handoff context back to the session. Pass complete=true to also mark the session completed. Requires an LLM provider configured on the server.
Inputs: session_id (required), dry_run, project, complete, +2 more.
agent_lesson_addAInspect
Record a lesson learned during a run so the agent doesn't repeat the failure. Embedded for goal-relevant recall at the next agent_boot. Mirrors the vibe-loop '## Lessons' log. scope controls breadth: 'session' (this run), 'agent' (this agent always), or 'workspace'.
Inputs: session_id (required), what_failed (required), why, scope, +1 more.
agent_resumeAInspect
Read the resume bundle for a session WITHOUT booting fresh: latest checkpoint, open tasks (pending/in_progress/blocked), and goal-relevant lessons. Use when you already know the session_id and just need to reload where you left off.
Inputs: session_id (required).
agent_session_endAInspect
End or update an agent session's status. Use status='completed' when the goal is met, 'paused' to suspend (resume later from the checkpoint), 'stalled' when the vibe-loop stall detector trips, or 'abandoned' to drop the run. Setting completed/abandoned stamps ended_at.
Inputs: status (required), session_id (required), goal, metadata.
agent_session_startAInspect
Start a new agent session (a run with a goal). Returns the created session including its id. Use when beginning a fresh task that you want to track and resume. Pass parent_session_id to chain a resumed run to its predecessor.
Inputs: agent (required), goal, role, project, +4 more.
agent_task_tickAInspect
Flip a task's status. Setting status='verified' REQUIRES non-empty evidence (real observed output: test result, HTTP status, exit code) — the no-self-certification rule. Returns 400 if you try to verify without evidence. Use this as each checklist item is proven. Trigger: user reports finishing a piece of tracked work ("xong rồi", "xong X", "done X", "done", "mark done", "finished X") — tick the matching session-scoped checklist item here (use goal_advance instead for a board-level task). Only call when it maps to a tracked item; ignore unrelated casual chatter.
Inputs: status (required), task_id (required), evidence.
agent_task_upsertAInspect
Create or update one checklist item in a session's task tree. Omit task_id to create; pass task_id to update. verify_cmd names HOW the item is proven done (the agent must run it before ticking). Use parent_task_id for subtasks. This productizes the vibe goal-file checklist. Trigger: call at the START of a tracked piece of work to record a checklist item (session-scoped — for a task meant to persist across sessions use goal_add on the board instead). Only call when the work is actually being tracked; ignore unrelated casual chat.
Inputs: session_id (required), title, status, task_id, +5 more.
ctx_deleteAInspect
Permanently delete a context entry by ID. This action cannot be undone. Use this only when you are sure the entry should be removed.
Inputs: id (required).
ctx_getAInspect
Get a single context entry by its ID. Use this when you already know the exact context ID you want to read. Response includes lifecycle, atomic, quality_score, valid_from, and valid_to alongside the standard fields.
Inputs: id (required).
ctx_healthAInspect
Run the deep health probe and return the full report. Probes DB, Elasticsearch, embedding provider, LLM provider, and scheduler states. 30-second in-memory cache on the server. Returns {status, components, schedulers, queue} - status is ok|degraded|fail. Useful for ad-hoc prod health checks from MCP clients.
Inputs: no named parameters.
ctx_listAInspect
List context entries with optional filters. Use this to browse existing contexts by workspace, project, type, or tag without a search query.
Inputs: tag, type, limit, scope, +4 more.
ctx_load_tool_groupAInspect
Load one additional group of ContextQ tools into this session (group names come from ctx_tool_groups) so they become callable without reconnecting. Pass "all" to load every remaining ContextQ tool at once. Some MCP clients need to refresh their tool list to actually see newly loaded tools in the model's context -- if a loaded tool still doesn't show up, call it directly by name anyway (ContextQ accepts a tool call for any known tool name regardless of what tools/list currently returns), or restart this server with the environment variable CONTEXT_MCP_TOOL_PROFILE=full to get every tool from the start.
Inputs: group (required).
ctx_rememberAInspect
Extract durable memories from a raw multi-turn conversation and save them as deduped atomic contexts. Turn-aware sibling of ctx_ingest: the server builds a speaker-attributed transcript, extracts only durable facts/preferences via LLM (skipping chit-chat), and runs the claims through the SAME kNN-dedup + diff + create/update/archive pipeline ctx_ingest uses. Pass subjectId to scope memories to a single end-user of your application (Mem0-parity user_id) — dedup then only considers that subject's own prior memories, and every created context is tagged with that subjectId so ctx_search (subjectId param) and GET /api/memory can retrieve it later. Set dryRun=true to preview without persisting.
Long conversations run async — the response is { jobId, statusUrl } and you must poll ctx_ingest_status (or GET /api/ingest-jobs/:id) until status='succeeded' or 'failed'. Short conversations return the full result inline. Pass async=true/false to force a path explicitly.
Inputs: messages (required), async, dryRun, project, +5 more.
ctx_saveAInspect
Save a new context entry (reference doc, feedback, project note, incident report, lesson learned, or user profile). Use this when you want to persist knowledge for future retrieval. Optional lifecycle/valid_from/valid_to flag the note's maturity and bi-temporal validity. Response includes atomic, quality_score, and lifecycle once the backend judge has run. Trigger: user asks you to remember/save something ("nhớ cái này", "lưu lại", "ghi nhớ giúp", "remember this", "save this", "note this down") — call whenever work-relevant info should persist across sessions. Only call when the request is actually about tracked work/memory; ignore unrelated casual chat.
Inputs: name (required), type (required), content (required), workspace (required), +9 more.
ctx_searchAInspect
Search / recall saved knowledge and memories using hybrid full-text + semantic search ranked by relevance — the default tool for 'what do I know about X' or 'did I already save this'. Use this when you need to find, remember, or look up existing knowledge by keyword or phrase. Set chunk_search=false to disable per-chunk passage matching, lifecycle_boost=false for legacy ranking, or include_archived=true to surface retired notes. Results may include lifecycle, quality_score, and matched_chunk per hit.
Inputs: query (required), tags, type, level, +13 more.
ctx_statsAInspect
Get aggregate statistics: total context count, breakdown by workspace, type, tag, recently updated entries, and orphan_rate (notes with no tags and no inbound references). Use this for an overview of what is stored and to spot disconnected knowledge.
Inputs: no named parameters.
ctx_tool_groupsAInspect
List additional groups of ContextQ tools not loaded in this session by default -- code-graph lookup, admin/audit, relay handoff, world-model snapshots, saved searches, knowledge-graph traversal, bulk import/ingest, and more. Search here first if a ContextQ tool you expect (a saved search, a relay, a snapshot, a code reference) is missing from your current tool list. Returns each group's name, one-line purpose, member tool names, and how many of them are already loaded, plus how to load a group with ctx_load_tool_group.
Inputs: no named parameters.
ctx_updateAInspect
Update an existing context entry. Only the provided fields are changed; omitted fields remain unchanged. Use this to correct, append to, reclassify, or retire (archive) an existing entry. Optional lifecycle/valid_from/valid_to update note maturity and bi-temporal validity.
Inputs: id (required), name, tags, type, +9 more.
goal_addAInspect
Add a node to the goal graph. Progressive elaboration: only title is required -- omit parent_id to create a root node (a vague node is created status='draft'); fill the rest as reality reveals it. kind: objective|milestone|goal|work_item|relay. owner_role/status/origin are free strings. Trigger: when a user (including a non-technical one) asks you to remember or hand off a piece of work for later ("thêm việc", "thêm task", "todo", "add a task", "add to the board"), create a node here with a valid status (draft is fine if details are vague) — this is how a casual request becomes a durable tracked task. Only call when the request is genuinely about work to track; ignore unrelated casual questions.
Inputs: title (required), do, kind, size, +12 more.
goal_advanceAInspect
Advance a node's status. A leaf moving to 'done' REQUIRES non-empty evidence (real observed output) — the no-self-certification rule. Parent status rolls up automatically from children. Trigger: when the user reports finishing a tracked piece of work ("xong rồi", "xong X", "done X", "done", "mark done", "finished X"), advance the matching board node's status here. Only call when the report maps to a tracked board item; ignore unrelated casual chatter.
Inputs: status (required), node_id (required), note, title, +6 more.
goal_frontierAInspect
The ready-frontier: nodes (optionally for a role, or scoped to one objective_run_id) whose ALL blocking dependencies are done and that aren't done yet — i.e. 'what can I start NOW'. Returns GoalNode[] with depsIn/depsOut ([{nodeId, kind}]). A node whose externalRef.blocker is set is waiting on a person or an external event, not on a dependency: treat it as not runnable.
Inputs: owner_role, project_id, objective_run_id.
goal_listAInspect
List goal nodes, filtered. Use to read the graph (your lane, a status column, all milestones, or one objective's whole run via objective_run_id). Returns a COMPACT view by default (id, title, status, kind, externalRef.local_id/priority, blocked, depsIn/depsOut) and omits done nodes unless include_done is true or a status filter is given; call goal_get for one node's full payload, or pass view="full".
Inputs: kind, view, status, owner_role, +3 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 24 tools
Most tools have clearly distinct purposes (ctx_save vs ctx_search vs ctx_get vs ctx_list), and the context CRUD tools are well separated. However, there is a notable cluster of session/keyboard-overlapping tools: agent_checkpoint and agent_resume both expose session state, agent_task_upsert and goal_add both handle tasks, and agent_task_tick and goal_advance both flip task status. The descriptions do clarify the session-scoped vs board-level distinction, but a less attentive agent could still misselect.
The set uses a consistent snake_case convention throughout (ctx_save, agent_boot, goal_add). There is a minor inconsistency in grouping prefixes: context tools use ctx_, agent tools use agent_, and goal tools use goal_ without the agent_ prefix, but all follow a verb_noun or verb_noun_qualifier pattern. The only deviation is a few compound names like agent_task_upsert and ctx_load_tool_group that are slightly more verbose, which is acceptable.
24 tools is at the upper end of the reasonable range and borderline heavy for the core purpose of context/memory management. The set is further expanded by meta-tools (ctx_tool_groups, ctx_load_tool_group) that hint at even more tools behind a loading mechanism, making the actual surface feel bloated. A leaner consolidation of session and goal tools could improve usability.
The surface provides comprehensive coverage for its domain: full CRUD on context entries (save/search/list/get/update/delete), statistics, health checks, memory extraction, agent session lifecycle (start/end/boot/resume/checkpoint/handoff), task management, and goal graph operations. There are no obvious gaps for the stated purpose, and the tool-group mechanism offers a path to additional features without cluttering the default set.
Maintenance
Related MCP Connectors
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Host any HTTP API as MCP tools with a tamper-evident cross-agent settlement ledger.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Related MCP Servers
- AlicenseAqualityCmaintenanceA Model Context Protocol server that exposes a MeshCore node and the mesh reachable through it as a clean, high-signal interface for AI agents or tools.3013 npm2MIT
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.MIT

MemoryOS MCP Serverofficial
AlicenseCqualityBmaintenanceEnables agent runtimes, IDEs, and local AI tools to access and manage MemoryOS tenant memory, domain schemas, and cross-agent universal memory through Model Context Protocol tools.26MIT- AlicenseAqualityCmaintenanceProvides a Model Context Protocol server with tools for knowledge base search, retrieval, and addition, plus system time, resources, and prompts. Supports stdio and Streamable HTTP transports for local and shared deployments.4MIT