Этот репозиторий содержит MCP-сервер OpenCode, сервер на основе Model Context Protocol (MCP), разработанный для работы в качестве помощника для Antigravity в задачах разработки и архитектуры программного обеспечения.
Основная цель этого MCP — экономия токенов в сложных задачах Antigravity за счет того, что OpenCode может уточнять промпты и выполнять предварительный анализ перед отправкой финальных инструкций основной модели.
Уточнение промптов: Преобразует расплывчатые промпты в подробные и технические инструкции.
Поддержка разработки: Помогает в исправлении ошибок и реализации новых функций с упором на эффективность.
Семантическая память: Хранит и извлекает технический контекст для обогащения промптов.
Related MCP server: Mem0 MCP Server
Перед началом работы необходимо настроить среду разработки. Мы рекомендуем использовать NVM (Node Version Manager) для управления версиями Node.js в Windows.
Загрузите установщик nvm-setup.exe с nvm-windows.
Следуйте инструкциям по установке.
Откройте новый терминал PowerShell и установите рекомендуемую версию Node.js:
nvm install 22
nvm use 22Ollama требуется для генерации локальных эмбеддингов.
Откройте PowerShell от имени администратора и выполните:
winget install ollamaПосле установки перезапустите терминал и загрузите модель памяти:
ollama pull nomic-embed-textПроверьте готовность инструментов в PowerShell:
node -v # Should return v22.x.x or higher
ollama --versionВыполните следующие шаги для настройки MCP-сервера OpenCode с помощью PowerShell:
Клонируйте репозиторий:
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 для сохранения технических знаний.
MCP OpenCode предоставляет следующие инструменты:
refine_promptУточняет промпт для разработки, чтобы сделать его более четким и эффективным.
Аргументы:
prompt: (строка) Исходный промпт, требующий уточнения.
learn_contextЗапоминает важную информацию (предпочтения, технические правила, контекст) для будущего использования в семантической памяти.
Аргументы:
information: (строка) Информация, которую нужно запомнить.
category: (строка, необязательно) Категория информации (например, '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Экономия токенов: Уточняя промпты локально, мы снижаем нагрузку на контекст, отправляемый в 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.
