Este repositorio contiene el Servidor MCP OpenCode, un servidor basado en el Model Context Protocol (MCP) diseñado para actuar como asistente de mano derecha para Antigravity en tareas de desarrollo y arquitectura de software.
El objetivo principal de este MCP es ahorrar tokens en tareas complejas de Antigravity permitiendo que OpenCode refine los prompts y realice un análisis preliminar antes de enviar las instrucciones finales al modelo principal.
Refinamiento de Prompts: Transforma prompts vagos en instrucciones detalladas y técnicas.
Soporte de Desarrollo: Asiste en la corrección de errores y la implementación de nuevas funcionalidades con un enfoque en la eficiencia.
Memoria Semántica: Almacena y recupera contexto técnico para enriquecer los prompts.
Related MCP server: Mem0 MCP Server
Antes de comenzar, necesitas configurar el entorno de desarrollo. Recomendamos usar NVM (Node Version Manager) para gestionar las versiones de Node.js en Windows.
Descarga el instalador nvm-setup.exe desde nvm-windows.
Sigue las instrucciones de instalación.
Abre una nueva terminal de PowerShell e instala la versión recomendada de Node.js:
nvm install 22
nvm use 22Ollama es necesario para generar embeddings locales.
Abre PowerShell como Administrador y ejecuta:
winget install ollamaDespués de la instalación, reinicia la terminal y descarga el modelo de memoria:
ollama pull nomic-embed-textComprueba si las herramientas están listas en PowerShell:
node -v # Should return v22.x.x or higher
ollama --versionSigue los pasos a continuación para configurar el Servidor MCP OpenCode usando PowerShell:
Clonar el repositorio:
git clone <repository-url>
cd open-code-as-mcpInstalar dependencias:
npm installCompilar el proyecto:
npm run buildPara integrar este servidor MCP con Antigravity, debes elegir entre el modo Local (ejecutándose en la misma máquina) o el modo Remoto (ejecutándose en un servidor/nube).
Usa esta opción si el servidor está en la misma máquina que el cliente.
La memoria se compartirá entre todos los proyectos y se almacenará en la carpeta del servidor.
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"]
}
}
}Para que cada proyecto tenga su propia memoria aislada dentro de la carpeta .mcp_memory del proyecto:
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"],
"env": {
"MCP_MEMORY_PATH": ".mcp_memory/vectors"
}
}
}
}Nota: Asegúrate de añadir .mcp_memory/ a tu .gitignore si no deseas versionar la base de datos.
Usa esta opción si el servidor se está ejecutando de forma remota. El servidor debe iniciarse con el modo SSE activo.
{
"mcpServers": {
"opencode": {
"url": "http://your-remote-server:3000/sse"
}
}
}Nota: Asegúrate de que el puerto y la IP sean accesibles si usas el modo remoto.
Para asegurar que Antigravity use este MCP correctamente, configura las siguientes reglas en tu System Prompt:
Refinamiento de Prompts: Siempre que el usuario envíe una solicitud, usa primero opencode:refine_prompt.
Enriquecimiento de Contexto: Al recibir el prompt refinado, valida si hay términos técnicos que requieran una búsqueda adicional en la memoria semántica.
Aprendizaje Continuo: Después de implementar con éxito una funcionalidad compleja o una corrección de errores no obvia, usa opencode:learn_context para persistir el conocimiento técnico.
El MCP de OpenCode proporciona las siguientes herramientas:
refine_promptRefina un prompt de desarrollo para hacerlo más claro y eficiente.
Argumentos:
prompt: (string) El prompt original que necesita refinamiento.
learn_contextMemoriza información importante (preferencia, regla técnica, contexto) para su uso futuro en la memoria semántica.
Argumentos:
information: (string) La información a recordar.
category: (string, opcional) Categoría de la información (ej. 'preference', 'architecture', 'style').
El servidor admite acceso remoto a través de SSE (Server-Sent Events). Para ejecutar en modo remoto en PowerShell, usa:
$env:MCP_MODE="sse"; $env:PORT="3000"; npm startPara ejecutar el servidor en modo de desarrollo con recarga en caliente en PowerShell:
npm run devPuedes probar el servidor localmente ejecutando en PowerShell:
node build/test-mcp.jsAhorro de Tokens: Al refinar los prompts localmente, reducimos la carga de contexto enviada a Antigravity.
Contexto Enriquecido: OpenCode puede acceder a archivos locales y proporcionar un contexto más rico para Antigravity.
Agilidad: Respuestas rápidas para tareas de refinamiento.
Desarrollado con el soporte de 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.
