# io.github.contextq/contextq-mcp (npm · @contextq/mcp)

Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.

- Trust score: 56/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-01

## Components

- remote · `app.contextq.dev`: 39/100, [markdown](https://verifymcp.io/servers/contextq-contextq-mcp/app.md), [page](https://verifymcp.io/servers/contextq-contextq-mcp/app)
- npm · `@contextq/mcp`: 56/100 (this document), [markdown](https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp.md), [page](https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp)

## Channel facts

- Registry: `npm`
- Package: `@contextq/mcp`
- Version: `2.1.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-01.

- **Supply Chain Security**: 63/100
  - No malware found by supply-chain analysis.
  - Known CVEs could not be checked: the version this server declares is not published in its registry.
  - No install/post-install scripts declared.
  - Dependency health could not be checked: the version this server declares is not published in its registry.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5980 tokens (~249/item across 24 items; 24 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "ctx_delete" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 25 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the io.github.contextq/contextq-mcp server?

io.github.contextq/contextq-mcp runs locally as an npm package, launched with npx -y @contextq/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add contextq-contextq-mcp -- npx -y @contextq/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "contextq-contextq-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@contextq/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "contextq-contextq-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@contextq/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add contextq-contextq-mcp -- npx -y @contextq/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "contextq-contextq-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@contextq/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add contextq-contextq-mcp --command npx --arg -y --arg @contextq/mcp
```

### Hermes

```yaml
mcp_servers:
  contextq-contextq-mcp:
    command: "npx"
    args: ["-y", "@contextq/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "contextq-contextq-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@contextq/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add contextq-contextq-mcp -t stdio -c npx -a -y @contextq/mcp
```

### Other

```json
{
  "mcpServers": {
    "contextq-contextq-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@contextq/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-01 (score 56)

First indexed and scored.

## MCP tools (24)

### `ctx_save` (~445 tokens)

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.

Input parameters:

- `content` (string, required): Full content / body of the context entry
- `description` (string, required): One-line summary used for search ranking
- `lifecycle` (string): Lifecycle state of the note. Omit to let the backend default to 'working'. Use 'fleeting' for transient captures, 'evergreen' for durable knowledge, 'archived' to retire from active surfacing.
- `memoryKind` (string): Taxonomy override: 'episodic' (an event/interaction happened), 'semantic' (durable factual/reference knowledge), or 'procedural' (how-to / lesson that changes future behavior). Omit to let the backen…
- `metadata` (object): Arbitrary key-value metadata
- `name` (string, required): Short, descriptive title
- `project` (string): Optional project identifier within the workspace
- `scope` (string): Visibility scope (defaults to personal)
- `tags` (array): Tags for categorization and filtering
- `type` (string, required): Category of the context entry
- `valid_from` (string): Bi-temporal: ISO 8601 timestamp when the fact this context describes started being true. Optional.
- `valid_to` (string): Bi-temporal: ISO 8601 timestamp when the fact stopped being true. Optional; null means still valid.
- `workspace` (string, required): Workspace identifier that owns this context

### `ctx_search` (~671 tokens)

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.

Input parameters:

- `chunk_search` (boolean): When true (default), search at the chunk level so individual passages can match. When false, only whole-context fields are scored.
- `epistemicMin` (string): Epistemic floor (T358): only return contexts at or above this confidence tier (weakest->strongest: assumed < inferred < told < observed). E.g. 'told' excludes 'assumed'/'inferred' rows. Omit to searc…
- `include_archived` (boolean): When true, include lifecycle='archived' rows. Default false — archived notes are excluded from regular searches.
- `include_trace_events` (boolean): T375: when true, ALSO search episodic tool-call trace summaries ('what did I try before this worked?') and return them in a separate `traceEvents` field. Default false — this is fully additive and ne…
- `level` (string): Layered representation level. 'full' (default) keeps the stored description; 'paragraph' replaces it with a ~120-word distill; 'sentence' replaces it with a ~25-word claim. Use 'sentence' for cheap h…
- `lifecycle_boost` (boolean): When true (default), apply the evergreen/fleeting lifecycle multipliers to the ranking. Set false for legacy ts_rank * tagBoost * recencyBoost only.
- `limit` (number): Max results to return (default 20)
- `memoryKind` (string): Filter to a single taxonomy kind: 'episodic' (events/interactions), 'semantic' (durable reference knowledge), or 'procedural' (how-to / lessons). Omit to search across all kinds.
- `offset` (number): Offset for pagination
- `project` (string): Filter by project identifier
- `query` (string, required): Search query (full-text + semantic)
- `scope` (string): Filter by visibility scope
- `subjectId` (string): Filter to memories scoped to a single end-user (Mem0-parity user_id axis). Matches the subjectId used when the memory was created via ctx_remember / POST /api/memory. Omit to search across all subjec…
- `tags` (array): Filter by tags (all must match)
- `trace_session_id` (number): Scope trace-event fusion to one agent session (omit to search across the tenant's trace events). Ignored unless include_trace_events is true.
- `type` (string): Filter by context type
- `workspace` (string): Filter by workspace identifier

### `ctx_list` (~143 tokens)

List context entries with optional filters. Use this to browse existing contexts by workspace, project, type, or tag without a search query.

Input parameters:

- `limit` (number): Max results to return (default 20)
- `memoryKind` (string): Filter to a single taxonomy kind: 'episodic', 'semantic', or 'procedural'.
- `offset` (number): Offset for pagination
- `project` (string): Filter by project identifier
- `scope` (string): Filter by visibility scope
- `tag` (string): Filter by a single tag
- `type` (string): Filter by context type
- `workspace` (string): Filter by workspace identifier

### `ctx_get` (~63 tokens)

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.

Input parameters:

- `id` (number, required): The context entry ID

### `ctx_update` (~286 tokens)

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.

Input parameters:

- `archivedAt` (string|null): Set to null to unarchive, or ISO date string to archive
- `content` (string): New content body
- `description` (string): New description
- `id` (number, required): The context entry ID to update
- `lifecycle` (string): New lifecycle state (fleeting/working/evergreen/archived).
- `memoryKind` (string): Taxonomy override: 'episodic', 'semantic', or 'procedural'. Setting this locks the value against the fire-and-forget atomicity-judge LLM refinement on this write.
- `metadata` (object): Replacement metadata object
- `name` (string): New title
- `scope` (string): New visibility scope
- `tags` (array): Replacement set of tags
- `type` (string): New context type
- `valid_from` (string): Bi-temporal: ISO 8601 timestamp when the fact started being true.
- `valid_to` (string): Bi-temporal: ISO 8601 timestamp when the fact stopped being true; null to keep open.

### `ctx_delete` (~49 tokens)

Permanently delete a context entry by ID. This action cannot be undone. Use this only when you are sure the entry should be removed.

Input parameters:

- `id` (number, required): The context entry ID to delete

### `ctx_stats` (~56 tokens)

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.

### `ctx_remember` (~463 tokens)

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.

Input parameters:

- `agentSlug` (string): Optional identifier of the agent that produced/consumed this conversation. Recorded as metadata only.
- `async` (boolean): Force the async path (true) or sync path (false). Omit to let the server auto-pick — conversations longer than MEMORY_ASYNC_THRESHOLD messages (default 8) run async.
- `dryRun` (boolean): When true, run the full extract + diff pipeline but skip every DB write. Default false.
- `maxClaims` (number): Cap on claims extracted from the conversation. Default 10, hard max 25.
- `messages` (array, required): Conversation turns in chronological order.
- `project` (string): Optional project identifier within the workspace.
- `sessionId` (string): Optional conversation/session identifier. Recorded as metadata and on the audit row only.
- `subjectId` (string): End-user identity this conversation belongs to (Mem0-parity user_id). Scopes dedup and tags every created context so it can be retrieved later via ctx_search subjectId or GET /api/memory.
- `workspace` (string): Workspace identifier the extracted memories belong to. Falls back to the request's active scope when omitted.

### `ctx_health` (~80 tokens)

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.

### `agent_boot` (~760 tokens)

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.

Input parameters:

- `agent` (string, required): Stable agent slug (handle the agent boots with every run, e.g. 'claude-code')
- `agent_name` (string): Human-readable name; used only when the agent is first created
- `epistemic_min` (string): Epistemic floor (T358) for the FACTS slot: only surface facts at or above this confidence tier (weakest->strongest: assumed < inferred < told < observed). Omit for no floor.
- `full` (boolean): T506: bypass the skills diff-since-last-boot behavior and always return the full current skills match set. Default false (repeat boots of the same session return only new/changed skills).
- `goal` (string): The objective for this run — drives relevant-facts + lessons retrieval AND goal-node role inference
- `include_repo_map` (boolean): When true, include a token-budgeted repo map (entries with path+signatures) from code-indexed contexts. Only useful for workspaces indexed with contextq index. Default false.
- `project_id` (number): Project id to scope the goal-graph situation brief + role inference to (omit = no brief, classic pack)
- `repo_map_token_budget` (number): Token cap for the repo map slot (default ~2000, range 100-16000). Ignored when include_repo_map is false.
- `session_id` (number): Resume a specific session by id (otherwise the latest active/paused session for this agent)
- `token_budget` (number): Max tokens for the assembled pack (default 4000)
- `workspace` (string): Workspace slug to scope handoff + facts to

### `agent_session_start` (~184 tokens)

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.

Input parameters:

- `agent` (string, required): Stable agent slug
- `agent_name` (string): Human-readable name (used only on first creation)
- `goal` (string): The A-Z objective for this run
- `metadata` (object): Arbitrary run metadata
- `parent_session_id` (number): Id of the session this one resumes/continues
- `project` (string): Optional project slug within the workspace
- `role` (string): Optional role this session plays (frontend, backend, design, ...). Usually inferred at boot from the matched goal node instead.
- `workspace` (string): Workspace slug this run operates in

### `agent_session_end` (~119 tokens)

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.

Input parameters:

- `goal` (string): Optionally revise the goal
- `metadata` (object): Metadata to merge into the session
- `session_id` (number, required): Session id to update
- `status` (string, required): New session status

### `agent_checkpoint` (~139 tokens)

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.

Input parameters:

- `session_id` (number, required): Session id to checkpoint
- `state` (object): Working-state scratchpad (arbitrary JSON)
- `summary` (string): One-line human-readable 'where I am'
- `token_estimate` (number): Optional explicit token size of the state (auto-estimated if omitted)

### `agent_resume` (~68 tokens)

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.

Input parameters:

- `session_id` (number, required): Session id to resume

### `agent_task_upsert` (~267 tokens)

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.

Input parameters:

- `context_id` (number): Optional id of the durable context this task produced
- `goal_node_id` (number): Optional goal-graph node this task rolls up to (links session work to the project goal)
- `order_index` (number): Ordering within the session
- `parent_task_id` (number): Parent task id for a subtask
- `session_id` (number, required): Session that owns this task
- `status` (string): Task status
- `task_id` (number): Existing task id to update (omit to create)
- `title` (string): Task title (required when creating)
- `verify_cmd` (string): Command/observation that proves this task done

### `agent_task_tick` (~183 tokens)

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.

Input parameters:

- `evidence` (string): Real observed output proving the task (required to set 'verified')
- `status` (string, required): New status
- `task_id` (number, required): Task id to tick

### `agent_lesson_add` (~137 tokens)

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'.

Input parameters:

- `scope` (string): How broadly the lesson applies (default 'session')
- `session_id` (number, required): Session this lesson came from
- `try_instead` (string): What to do differently next time
- `what_failed` (string, required): What was attempted that failed
- `why` (string): Why it failed

### `agent_handoff` (~176 tokens)

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.

Input parameters:

- `complete` (boolean): Also set the session status to 'completed'
- `dry_run` (boolean): Generate without persisting the handoff context
- `project` (string): Optional project slug to narrow the handoff
- `session_id` (number, required): Session to generate a handoff for
- `since_days` (number): Look-back window in days (default 7)
- `workspace` (string): Workspace slug (falls back to the session's workspace)

### `goal_add` (~472 tokens)

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.

Input parameters:

- `brief` (object): Cold-executor brief: all six keys or omit (a partial brief is rejected). A work_item added without one gets a `hint` with the template.
- `content` (string): Long description (creates a searchable contexts row)
- `do` (string): One-sentence work order (stored as payload.do)
- `effort_weeks` (number): Estimated effort in weeks
- `external_ref` (object): External tracker ref, e.g. {jira: 'FIP-123'}
- `kind` (string): objective|milestone|goal|work_item|relay (default work_item)
- `origin` (string): greenfield|leverage|migrate|unknown
- `owner_role` (string): Role that owns this node (e.g. frontend, backend, design)
- `parent_id` (number): Parent node id (containment tree; null/omit for a root)
- `project_id` (number): Project id (optional)
- `session_id` (number): Your agent session id, recorded on the node's history row
- `size` (string): S|M|L|XL
- `status` (string): draft|not_started|ready|in_progress|blocked|done|superseded
- `target_weeks` (number): Milestone target (weeks)
- `title` (string, required): Node title (the only hard requirement)
- `verify_cmd` (string): How a leaf is proven done

### `goal_advance` (~365 tokens)

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.

Input parameters:

- `evidence` (string): Real observed output proving the node (required for a leaf -> done)
- `external_ref` (object): Shallow-merged into the node's externalRef. Never trusted as a security predicate.
- `node_id` (number, required): Node id to advance
- `note` (object): Named annotation kept under payload.notes, e.g. {name: "rechecked-2026-09-27", text: "..."}
- `order_index` (number): Manifest position
- `payload` (object): Shallow-merged into the node's payload; `{"do": "<text>"}` is the manifest `do:` line. Keys not named here survive.
- `session_id` (number): Your agent session id, recorded on the node's history row
- `status` (string, required): New status (draft|not_started|ready|in_progress|blocked|done|superseded). Always required: to edit a field below WITHOUT a status change, pass the node's CURRENT status.
- `title` (string): Rename the node (manifest task title)
- `verify_cmd` (string): Replace the node's done-when text (manifest `done-when:`). Whole-value replace, max 2000 chars.

### `goal_list` (~214 tokens)

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".

Input parameters:

- `include_done` (boolean): Include done nodes (default false)
- `kind` (string): Filter by kind
- `objective_run_id` (string): Filter to nodes stamped with one objective's run id (from goal_set_objective/goal_get/goal_decompose)
- `owner_role` (string): Filter by owning role
- `project_id` (number): Filter by project
- `status` (string): Filter by status
- `view` (string): compact (default) drops payload and brief; full returns every field

### `goal_frontier` (~142 tokens)

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.

Input parameters:

- `objective_run_id` (string): Scope to one objective's run id
- `owner_role` (string): Filter to a role's ready work
- `project_id` (number): Filter by project

### `ctx_tool_groups` (~125 tokens)

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.

### `ctx_load_tool_group` (~175 tokens)

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.

Input parameters:

- `group` (string, required): Group name from ctx_tool_groups (e.g. "pkm", "admin", "relay", "knowledge-graph"), or "all" to load every remaining ContextQ tool.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp#diagnostics

## Score history

- 2026-10-01: 56

## Common questions

### What is the io.github.contextq/contextq-mcp server?

io.github.contextq/contextq-mcp is listed in the public MCP registry as io.github.contextq/contextq-mcp. Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP. This page covers its npm package (@contextq/mcp).

### Is the io.github.contextq/contextq-mcp server safe to use?

io.github.contextq/contextq-mcp scores 56 out of 100 on VerifyMCP. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the io.github.contextq/contextq-mcp server expose?

io.github.contextq/contextq-mcp exposes 24 tools: ctx_save, ctx_search, ctx_list, ctx_get, ctx_update, and 19 more. Their descriptions and schemas cost roughly 5,782 tokens of context every time the server is loaded.

### Is the io.github.contextq/contextq-mcp server still maintained?

io.github.contextq/contextq-mcp is still listed as active in the MCP registry. We last reached this channel on 1 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the io.github.contextq/contextq-mcp server under?

io.github.contextq/contextq-mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@contextq/mcp
- Socket report: https://socket.dev/npm/package/@contextq/mcp
- Repository: https://github.com/contextq/contextq-mcp
- Website: https://contextq.dev/
- Changelog RSS feed: https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp.json
- HTML version of this page: https://verifymcp.io/servers/contextq-contextq-mcp/contextq-mcp