本仓库包含 OpenCode MCP 服务器，这是一个基于 模型上下文协议 (MCP) 的服务器，旨在作为 Antigravity 在开发和软件架构任务中的得力助手。
此 MCP 的主要目标是通过允许 OpenCode 在将最终指令发送给主模型之前优化提示词并进行初步分析，从而在复杂的 Antigravity 任务中节省 Token。
提示词优化：将模糊的提示词转换为详细且技术性的指令。
开发支持：协助修复错误并实现新功能，重点在于效率。
语义记忆：存储并检索技术上下文以丰富提示词。
Related MCP server: Mem0 MCP Server
在开始之前，您需要设置开发环境。我们建议使用 NVM (Node Version Manager) 来管理 Windows 上的 Node.js 版本。
从 nvm-windows 下载 nvm-setup.exe 安装程序。
按照安装说明进行操作。
打开一个新的 PowerShell 终端并安装推荐的 Node.js 版本：
nvm install 22
nvm use 22需要 Ollama 来生成本地嵌入。
以管理员身份打开 PowerShell 并运行：
winget install ollama安装完成后，重启终端并下载记忆模型：
ollama pull nomic-embed-text在 PowerShell 中检查工具是否就绪：
node -v # Should return v22.x.x or higher
ollama --version按照以下步骤使用 PowerShell 配置 OpenCode MCP 服务器：
克隆仓库：
git clone <repository-url>
cd open-code-as-mcp安装依赖：
npm install构建项目：
npm run build要将此 MCP 服务器与 Antigravity 集成，您必须在 本地 模式（在同一台机器上运行）或 远程 模式（在服务器/云端运行）之间进行选择。
如果服务器与客户端在同一台机器上，请使用此选项。
记忆将在所有项目之间共享，并存储在服务器文件夹中。
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"]
}
}
}为了让每个项目在项目内部的 .mcp_memory 文件夹中拥有自己独立的记忆：
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"],
"env": {
"MCP_MEMORY_PATH": ".mcp_memory/vectors"
}
}
}
}注意：如果您不想对数据库进行版本控制，请务必将 .mcp_memory/ 添加到您的 .gitignore 中。
如果服务器在远程运行，请使用此选项。服务器必须在激活 SSE 模式的情况下启动。
{
"mcpServers": {
"opencode": {
"url": "http://your-remote-server:3000/sse"
}
}
}注意：如果使用远程模式，请确保端口和 IP 是可访问的。
为确保 Antigravity 正确使用此 MCP，请在您的 系统提示词 (System Prompt) 中配置以下规则：
提示词优化：每当用户发送请求时，首先使用 opencode:refine_prompt。
上下文丰富：收到优化后的提示词后，验证是否有需要额外在语义记忆中查找的技术术语。
持续学习：在成功实现复杂功能或修复非显而易见的错误后，使用 opencode:learn_context 来持久化技术知识。
OpenCode MCP 提供以下工具：
refine_prompt优化开发提示词，使其更清晰、更高效。
参数：
prompt: (string) 需要优化的原始提示词。
learn_context记忆重要信息（偏好、技术规则、上下文），以便将来在语义记忆中使用。
参数：
information: (string) 需要记忆的信息。
category: (string, 可选) 信息类别（例如：'preference', 'architecture', 'style'）。
服务器支持通过 SSE (Server-Sent Events) 进行远程访问。要在 PowerShell 中以远程模式运行，请使用：
$env:MCP_MODE="sse"; $env:PORT="3000"; npm start要在 PowerShell 中以热重载模式运行开发服务器：
npm run dev您可以通过在 PowerShell 中运行来在本地测试服务器：
node build/test-mcp.js节省 Token：通过在本地优化提示词，我们减少了发送给 Antigravity 的上下文负载。
丰富的上下文：OpenCode 可以访问本地文件，并为 Antigravity 提供更丰富的上下文。
敏捷性：针对优化任务的快速响应。
在 Gemini CLI 的支持下开发。
Memorizes important information (preference, technical rule, context) for future use.
| Name | Required | Description | Default |
|---|---|---|---|
| information | Yes | The information to be remembered. | |
| category | No | Information category (e.g., 'preference', 'architecture', 'style'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It says 'memorizes... for future use' but lacks details on persistence, scope, or retrieval, leaving significant ambiguity about the tool's behavior.
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, concise sentence with no redundant words. Every part serves to define the tool's purpose efficiently.
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?
For a simple tool with two parameters and no output schema, the description covers the core functionality. However, it lacks context about when to prefer this over the sibling tool, which slightly reduces completeness.
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% (both parameters have descriptions). The description adds minimal value beyond the schema, citing examples like 'preference, technical rule, context', which weakly maps to the 'category' parameter. Baseline 3 is appropriate.
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 verb 'memorizes' and the resource 'important information', listing examples like preferences and technical rules. It effectively distinguishes from the sibling tool 'refine_prompt' which has a different purpose.
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?
The description gives no guidance on when to use this tool versus alternatives, nor does it specify when not to use it. It only implies usage for storing information without context about trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refines a prompt using semantic memory to make it more contextual and efficient.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The original prompt that needs refinement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'using semantic memory' but does not explain side effects (e.g., memory updates), performance implications, or whether the operation is read-only or modifying. This leaves the agent uncertain about expectations.
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, efficient sentence that starts with the verb. No unnecessary words or structure.
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 no output schema and simple input, the description should explain what 'refinement' means and how semantic memory is used. It does not specify the output format or any side effects, leaving the agent without enough context to invoke the tool correctly.
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% for the single parameter, so baseline is 3. The description does not add any meaning beyond the schema's description of 'The original prompt that needs refinement.' No additional constraints, formats, or examples are given.
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 verb 'refines' and the resource 'prompt', and uses 'semantic memory' to add specificity. It distinguishes from sibling 'learn_context' by focusing on prompt refinement rather than context learning.
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?
No guidance on when to use this tool versus 'learn_context' or other alternatives. The description implies it is for making prompts more contextual and efficient, but does not specify prerequisites, exclusions, or when refinement is appropriate.
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.0learn_contextrefine_promptScored across 2 tools
The two tools have clearly distinct purposes: one stores information and the other uses it to refine prompts. There is no overlap or ambiguity.
Both tool names follow the verb_noun pattern consistently ('learn_context' and 'refine_prompt'), making them predictable and easy to understand.
With only 2 tools, the server feels thin for its scope. While the core functionality is covered, a typical server would include more tools (e.g., for updating or deleting context).
The server covers the basic workflow of storing and using context for prompt refinement. However, it lacks operations to update or delete learned context, which is a minor gap.
Project memory, semantic code search, and grounded agent context.
InfoLang semantic memory MCP — investigate, memorize, and recall compressed agent context.
Persistent long-term memory for AI agents: semantic search, knowledge graph, and task canvas.
Persistent AI memory with semantic search, conflict detection, and ticketing.
