このリポジトリには、Model Context Protocol (MCP)に基づいたOpenCode MCPサーバーが含まれています。これは、開発およびソフトウェアアーキテクチャのタスクにおいて、Antigravityの右腕となるアシスタントとして機能するように設計されています。
このMCPの主な目的は、OpenCodeがプロンプトを洗練させ、最終的な指示をメインモデルに送信する前に予備分析を行うことで、複雑なAntigravityタスクにおけるトークンを節約することです。
プロンプトの洗練: 曖昧なプロンプトを詳細かつ技術的な指示に変換します。
開発サポート: 効率性を重視し、バグ修正や新機能の実装を支援します。
セマンティックメモリ: 技術的なコンテキストを保存・取得し、プロンプトを充実させます。
Related MCP server: Mem0 MCP Server
開始する前に、開発環境をセットアップする必要があります。WindowsでのNode.jsバージョンの管理には、NVM (Node Version Manager) の使用を推奨します。
nvm-windows から nvm-setup.exe インストーラーをダウンロードします。
インストール手順に従います。
新しい PowerShell ターミナルを開き、推奨されるNode.jsバージョンをインストールします：
nvm install 22
nvm use 22ローカル埋め込みを生成するにはOllamaが必要です。
PowerShell を管理者として開き、以下を実行します：
winget install ollamaインストール後、ターミナルを再起動し、メモリモデルをダウンロードします：
ollama pull nomic-embed-textPowerShell でツールが準備できているか確認します：
node -v # Should return v22.x.x or higher
ollama --versionPowerShell を使用して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"
}
}
}
}注: データベースをバージョン管理したくない場合は、.gitignore に .mcp_memory/ を追加してください。
サーバーがリモートで実行されている場合は、このオプションを使用します。サーバーはSSEモードを有効にして起動する必要があります。
{
"mcpServers": {
"opencode": {
"url": "http://your-remote-server:3000/sse"
}
}
}注: リモートモードを使用する場合は、ポートとIPにアクセス可能であることを確認してください。
AntigravityがこのMCPを正しく使用するように、システムプロンプトに以下のルールを設定してください：
プロンプトの洗練: ユーザーがリクエストを送信するたびに、まず opencode:refine_prompt を使用してください。
コンテキストの充実: 洗練されたプロンプトを受け取ったら、セマンティックメモリでの追加検索が必要な技術用語があるかどうかを確認してください。
継続的学習: 複雑な機能や明白ではないバグ修正を正常に実装した後、opencode:learn_context を使用して技術的知識を永続化してください。
OpenCode MCPは以下のツールを提供します：
refine_prompt開発プロンプトを洗練させ、より明確で効率的なものにします。
引数:
prompt: (string) 洗練が必要な元のプロンプト。
learn_context将来のセマンティックメモリでの使用のために、重要な情報（設定、技術ルール、コンテキスト）を記憶します。
引数:
information: (string) 記憶する情報。
category: (string, optional) 情報のカテゴリ（例: 'preference', 'architecture', 'style'）。
サーバーは SSE (Server-Sent Events) を介したリモートアクセスをサポートしています。PowerShell でリモートモードを実行するには、以下を使用します：
$env:MCP_MODE="sse"; $env:PORT="3000"; npm startPowerShell でホットリロードを使用して開発モードでサーバーを実行するには：
npm run devPowerShell で以下を実行して、サーバーをローカルでテストできます：
node build/test-mcp.jsトークンの節約: プロンプトをローカルで洗練させることで、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.
