Skip to main content
Glama

@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/mcp

Client configuration

Two environment variables are required in every client:

Variable

Description

CONTEXT_API_URL

Base URL of your ContextQ server (e.g. https://ctx.example.com)

CONTEXT_API_KEY

API key sent as Authorization: Bearer on every request

Optional:

Variable

Description

CONTEXT_MCP_TOOL_PROFILE

default (default if unset) loads a curated ~24-tool set at connection, well under most hosts' comfortable tool-list budget; full loads all ~89 tools from the start. On default, the rest stay reachable via the ctx_tool_groups (list) / ctx_load_tool_group (load) tools without reconnecting -- see docs/mcp-tools.md "Discoverability under ToolSearch deferral"

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/mcp

Cursor

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_URL and 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_KEY is sent as an Authorization: Bearer header 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

ctx_dream

Clusters a workspace's contexts via vector similarity, then runs one LLM synthesis call per cluster.

ctx_evolve

Runs LLM judging over up to 20 nearest-neighbor contexts to decide links/archival.

ctx_ingest

Fetches/parses a source and runs LLM claim extraction + kNN diffing. Large or URL-sourced ingests already return { jobId, statusUrl } and expect polling via ctx_ingest_status — but small inline ingests still run synchronously and can take several seconds.

ctx_regenerate_mocs

Re-clusters all of a tenant's contexts and runs one LLM synthesis call per cluster (admin scope).

ctx_memory_review_run

Samples older contexts and asks the LLM to verdict each one (superadmin scope).

ctx_bulk_update

Applies a lifecycle/archive patch to up to 200 context ids in one call — bounded, but still slower than a single-row update.

ctx_audit_cleanup_run

Deletes up to 5000 activity_logs rows in one pass (superadmin scope).

ctx_snapshot_create / ctx_fork_world / ctx_diff_world

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 out

Treat 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/mcp@2.x

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 tools
agent_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_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

    A3.9/5.0

    Scored across 24 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count3/5

    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.

    Completeness5/5

    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

    ActivitySlowing
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers