Dieses Repository enthält den OpenCode MCP-Server, einen Server basierend auf dem Model Context Protocol (MCP), der als Assistent für Antigravity bei Entwicklungs- und Softwarearchitekturaufgaben fungiert.
Das Hauptziel dieses MCP ist es, bei komplexen Antigravity-Aufgaben Token zu sparen, indem OpenCode Prompts verfeinern und eine vorläufige Analyse durchführen kann, bevor die endgültigen Anweisungen an das Hauptmodell gesendet werden.
Prompt-Verfeinerung: Wandelt vage Prompts in detaillierte und technische Anweisungen um.
Entwicklungsunterstützung: Unterstützt bei der Fehlerbehebung und der Implementierung neuer Funktionen mit Fokus auf Effizienz.
Semantisches Gedächtnis: Speichert und ruft technischen Kontext ab, um Prompts anzureichern.
Related MCP server: Mem0 MCP Server
Bevor Sie beginnen, müssen Sie die Entwicklungsumgebung einrichten. Wir empfehlen die Verwendung von NVM (Node Version Manager), um Node.js-Versionen unter Windows zu verwalten.
Laden Sie den nvm-setup.exe-Installer von nvm-windows herunter.
Befolgen Sie die Installationsanweisungen.
Öffnen Sie ein neues PowerShell-Terminal und installieren Sie die empfohlene Node.js-Version:
nvm install 22
nvm use 22Ollama wird benötigt, um lokale Embeddings zu generieren.
Öffnen Sie PowerShell als Administrator und führen Sie Folgendes aus:
winget install ollamaStarten Sie nach der Installation das Terminal neu und laden Sie das Speichermodell herunter:
ollama pull nomic-embed-textÜberprüfen Sie in PowerShell, ob die Tools bereit sind:
node -v # Should return v22.x.x or higher
ollama --versionBefolgen Sie die unten stehenden Schritte, um den OpenCode MCP-Server über PowerShell zu konfigurieren:
Repository klonen:
git clone <repository-url>
cd open-code-as-mcpAbhängigkeiten installieren:
npm installProjekt erstellen:
npm run buildUm diesen MCP-Server in Antigravity zu integrieren, müssen Sie zwischen dem lokalen Modus (Ausführung auf demselben Rechner) oder dem Remote-Modus (Ausführung auf einem Server/in der Cloud) wählen.
Verwenden Sie diese Option, wenn sich der Server auf demselben Rechner wie der Client befindet.
Das Gedächtnis wird über alle Projekte hinweg geteilt und im Server-Ordner gespeichert.
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"]
}
}
}Damit jedes Projekt sein eigenes isoliertes Gedächtnis im .mcp_memory-Ordner des Projekts hat:
{
"mcpServers": {
"opencode": {
"command": "node",
"args": ["D:/IA/MCP/open-code-as-mcp/build/index.js"],
"env": {
"MCP_MEMORY_PATH": ".mcp_memory/vectors"
}
}
}
}Hinweis: Stellen Sie sicher, dass Sie .mcp_memory/ zu Ihrer .gitignore hinzufügen, wenn Sie die Datenbank nicht versionieren möchten.
Verwenden Sie diese Option, wenn der Server remote ausgeführt wird. Der Server muss mit aktivem SSE-Modus gestartet werden.
{
"mcpServers": {
"opencode": {
"url": "http://your-remote-server:3000/sse"
}
}
}Hinweis: Stellen Sie sicher, dass Port und IP zugänglich sind, wenn Sie den Remote-Modus verwenden.
Um sicherzustellen, dass Antigravity diesen MCP korrekt verwendet, konfigurieren Sie die folgenden Regeln in Ihrem System-Prompt:
Prompt-Verfeinerung: Wann immer der Benutzer eine Anfrage sendet, verwenden Sie zuerst opencode:refine_prompt.
Kontextanreicherung: Überprüfen Sie nach Erhalt des verfeinerten Prompts, ob technische Begriffe vorhanden sind, die eine zusätzliche Suche im semantischen Gedächtnis erfordern.
Kontinuierliches Lernen: Verwenden Sie nach der erfolgreichen Implementierung einer komplexen Funktion oder einer nicht offensichtlichen Fehlerbehebung opencode:learn_context, um technisches Wissen dauerhaft zu speichern.
Der OpenCode MCP bietet die folgenden Tools:
refine_promptVerfeinert einen Entwicklungsprompt, um ihn klarer und effizienter zu machen.
Argumente:
prompt: (string) Der ursprüngliche Prompt, der verfeinert werden muss.
learn_contextSpeichert wichtige Informationen (Präferenzen, technische Regeln, Kontext) für die zukünftige Verwendung im semantischen Gedächtnis.
Argumente:
information: (string) Die zu speichernde Information.
category: (string, optional) Informationskategorie (z. B. 'preference', 'architecture', 'style').
Der Server unterstützt den Remote-Zugriff über SSE (Server-Sent Events). Um den Remote-Modus in PowerShell auszuführen, verwenden Sie:
$env:MCP_MODE="sse"; $env:PORT="3000"; npm startUm den Server im Entwicklungsmodus mit Hot-Reload in PowerShell auszuführen:
npm run devSie können den Server lokal testen, indem Sie ihn in PowerShell ausführen:
node build/test-mcp.jsToken-Einsparungen: Durch die lokale Verfeinerung von Prompts reduzieren wir die Kontextlast, die an Antigravity gesendet wird.
Angereicherter Kontext: OpenCode kann auf lokale Dateien zugreifen und einen reichhaltigeren Kontext für Antigravity bereitstellen.
Agilität: Schnelle Antworten bei Verfeinerungsaufgaben.
Entwickelt mit Unterstützung von 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.
