This server acts as a command interface to the Wuniq Knowledge Engine via a single run tool. Since the Wuniq desktop app is not currently installed, it only returns installation guidance directing the user to wuniq.com.
When the Wuniq desktop app is installed, available commands include:
open list – Discover Wuniq projects visible to the engine
open <path> – Open a specific project to load its knowledge context
read – Read a .wuniq sidecar file to retrieve stored decisions, constraints, and intent for a code file
sync – Synchronize and update Wuniq knowledge after making code changes
record – Record a decision
Current state: The run tool accepts any command string but returns only installation guidance until the desktop app is installed.
Wuniq is free. This MCP package requires the Wuniq desktop app, currently available for Windows and Linux. Download it only through the official, trusted links at wuniq.com. Do not use third-party mirrors.
Wuniq is a knowledge engine for AI-assisted work. It stores decisions, constraints, intent, and human reasoning in .wuniq files beside your project files, so any MCP-compatible AI can read and maintain the knowledge exactly where the work lives.
Wuniq is local-first: no account, no cloud storage, and no telemetry.
This repository contains the small, open-source MCP launcher published as @wuniq/mcp, the manifest submitted to the official MCP Registry, and thin wrappers for Claude, Codex, Antigravity, and Gemini CLI that all start the same launcher.
The launcher has zero dependencies. It connects your MCP client to the MCP server included with the installed Wuniq desktop app:
MCP-compatible AI or IDE
|
v
npx @wuniq/mcp
|
v
Installed Wuniq desktop app
|
v
Local projects and .wuniq knowledgeThe Wuniq Knowledge Engine itself is not contained in this repository and is not distributed through npm. The MIT license in this repository applies only to the launcher.
Related MCP server: Projectmem
Install the free Wuniq desktop app using an official download link from wuniq.com.
Add Wuniq from your IDE's MCP registry gallery, where supported, or configure it manually:
{
"mcpServers": {
"wuniq": {
"command": "npx",
"args": ["-y", "@wuniq/mcp"]
}
}
}Already have the app installed? You can also point your MCP configuration directly to the wuniq-mcp command placed on your PATH by the official Wuniq installation. Both methods connect to the same local engine.
Per-IDE instructions and current platform availability are maintained at wuniq.com.
OpenCode uses a project-level opencode.json file. Add Wuniq under its mcp key, keeping any providers, permissions, or other MCP servers already present:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"wuniq": {
"type": "local",
"command": ["npx", "-y", "@wuniq/mcp"],
"enabled": true,
"timeout": 30000
}
}
}Then add the Wuniq workflow to the project's AGENTS.md without removing any existing instructions:
# Wuniq KE (Knowledge Engine)
At the start of every session, run `open list` using the Wuniq MCP tool. If it returns projects, `open` each one. If the list is empty, proceed normally — the user may open projects later from the Wuniq UI. Never assume the working directory is a Wuniq project; the working directory may be a container folder holding multiple projects. Only open paths that `open list` explicitly returns.
Before working on any code file, `read` its Wuniq sidecar for context. After changing code, run `sync`.This route was validated on Windows with OpenCode Desktop 1.18.4, Wuniq 1.15.1, and @wuniq/mcp 1.0.1. MCP connection and the open, read, and sync calls worked correctly. Models vary in how reliably they act on AGENTS.md without prompting, so open list can always be requested explicitly.
See the full Wuniq + OpenCode integration guide for verification, Linux instructions, Precise mode, and troubleshooting.
The repository root is also a Claude plugin. It does not contain a second MCP server: .mcp.json starts the published @wuniq/mcp launcher, which connects Claude to the MCP server inside the installed Wuniq app.
The plugin includes one compact skill that teaches Claude the safe Wuniq workflow: discover visible projects first, read their context before working, preserve confirmed decisions, and synchronize after changes. It does not pre-approve tools or elevate permissions.
Before marketplace submission, the plugin can be checked and loaded locally with Claude Code:
claude plugin validate --strict .
claude --plugin-dir .The same repository is also a Codex plugin. Its .codex-plugin/plugin.json reuses the same skill and .mcp.json; it starts @wuniq/mcp locally and does not create a hosted service or upload project data.
Add the public Wuniq marketplace from Codex:
codex plugin marketplace add Wuniq/wuniq-mcp --ref mainThen open the Plugins directory in the ChatGPT desktop app, select the Wuniq marketplace, and install Wuniq. Start a new Codex session after installation so the skill and MCP server are loaded.
ChatGPT on the web cannot run this local stdio MCP server. Wuniq's full integration is therefore for local Codex clients: the ChatGPT desktop app, Codex CLI, and the Codex IDE extension.
The repository root is a native Antigravity plugin. Its mcp_config.json starts the published @wuniq/mcp launcher, while skills/wuniq/SKILL.md supplies the safe Wuniq workflow. It does not contain a second MCP server or upload project data.
Install it in Antigravity CLI from the public repository:
agy plugin install https://github.com/Wuniq/wuniq-mcpIn Antigravity 2.0, Wuniq can also be configured as a custom MCP server with the same npx -y @wuniq/mcp command while its MCP Store listing is under review.
The repository root is also a Gemini CLI extension. Its gemini-extension.json starts the same published @wuniq/mcp launcher, while skills/wuniq/SKILL.md supplies the safe Wuniq workflow as an Agent Skill. It does not contain a second MCP server or upload project data.
Install it directly from the public repository:
gemini extensions install https://github.com/Wuniq/wuniq-mcpRestart Gemini CLI after installation so the extension and its MCP tools are loaded.
Google has transitioned personal, Pro, and Ultra users from Gemini CLI to Antigravity CLI. The Gemini CLI extension remains available for supported Enterprise, Google Cloud, and API-based environments.
"Open the Wuniq projects visible to you and summarize the important context for this task."
"Before changing the authentication module, read its Wuniq context and preserve the constraints already decided."
"Record the decision we just made, implement the change, and run Wuniq sync when you finish."
The Wuniq app is missing: install it only from the official links at wuniq.com, then start a new Claude, Codex, Antigravity, or Gemini CLI session.
open list returns no projects: open the intended project in the Wuniq desktop interface and ask your AI client to try again.
The launcher cannot start: confirm that Node.js and npx are available, or use the direct per-client setup documented at wuniq.com.
The launcher passes the MCP client's standard input and output directly to the MCP server included with the installed app. If Wuniq is not installed, it exposes only a minimal MCP response explaining how to obtain the official app.
It does not configure IDEs, contain Wuniq product logic, upload project data, or provide a second Knowledge Engine.
Only install Wuniq through links published on wuniq.com. Do not use third-party mirrors or repackaged installers.
To report a security issue, use this repository's private vulnerability reporting instead of opening a public issue. See SECURITY.md.
The MCP launcher and the Claude, Codex, Antigravity, and Gemini CLI wrappers in this repository are licensed under the MIT License. The Wuniq desktop app and Knowledge Engine are separate software and are not covered by this repository's license.
Run a Wuniq Knowledge Engine command to discover projects or read and maintain local .wuniq knowledge. Use it for open, read, search, graph, new, edit, relation, sync, or help; use native tools for ordinary project files. Supply one shell-like string: start with open list and use help for exact syntax. Read commands do not mutate; writes may create, update, move, or delete .wuniq context, and sync reconciles it. Returns plain text. Local-only: no account, remote authentication, or rate limit. Requires the free desktop app; otherwise returns installation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Complete Wuniq command string, including quoted paths and flags when required. Examples: open list; read "auth.py"; search text "token"; edit set "auth.py" --section "_description" --content "..."; sync. Use help <topic> when unsure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description elaborates that writes may create, update, move, or delete .wuniq context. It also discloses return format (plain text), local-only nature, no auth/rate limits, and desktop app requirement, adding significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads purpose, then covers usage, behavior, and prerequisites. Every sentence contributes meaning, and it is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter, no output schema) and presence of annotations, the description fully covers purpose, usage, behavioral details, return type, and dependencies (desktop app). It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'command' parameter with examples and constraints. The description adds value by explaining the command string nature and syntax guidance, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs Wuniq Knowledge Engine commands for specific operations (discover, read, maintain, etc.) and distinguishes it from native tools for ordinary project files, providing a specific verb+resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (for Wuniq commands) and when not (use native tools for ordinary project files), provides examples, and advises using 'help <topic>' for syntax. Also clarifies read commands are non-mutating while writes may mutate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3run4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / command / descriptionPrevious value: -"Command to execute."New value: +"Complete Wuniq command string, including quoted paths and flags when required. Examples: open list; read \"auth.py\"; search text \"token\"; edit set \"auth.py\" --section \"_description\" --content \"...\"; sync. Use help <topic> when unsure."Input schema / properties / command / examplesAdded value: +[
+ "open list",
+ "read \"auth.py\"",
+ "sync"
+]Input schema / properties / command / minLengthAdded value: +1v1.0.2runScored across 1 tool
The single 'run' tool is overloaded with many distinct commands (open, read, search, graph, new, edit, relation, sync, help), making it ambiguous what it does and when to use it versus native tools. Agents may struggle to determine the correct command or differentiate from other tools.
With only one tool named 'run', there is no pattern to evaluate. The name is overly generic and does not reflect any domain-specific convention.
A single tool for a knowledge engine that supports multiple diverse operations is far too few. Typically, such a domain would require separate tools for each operation (e.g., search, read, create) to avoid overloading and improve clarity.
While the tool claims to cover many actions, it is monolithic and may be incomplete for complex workflows. The description also defers 'ordinary project files' to native tools, creating potential gaps and reliance on external tools.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Shared memory for AI coding agents. Save once, reuse from Cursor, Claude Code, Codex.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Give your AI agent persistent, governed memory for every project. At task start it recalls the approved decisions, conventions, risks and architecture (semantic search, ranked by importance); at close it proposes what was learned as typed memories that you review and approve — governance, not a notes dump. Agents propose, humans govern: edits go back to pending and deletion is human-only by design. Connect Claude Code, Cursor, Claude Desktop or any MCP client in two minutes with just your API key — hosted (nothing to install) or locally via `uvx solucortex-mcp`. Built by SoluAI and dogfooded daily: SoluCortex is developed using its own living memory.
