이 저장소에는 개발 및 소프트웨어 아키텍처 작업에서 Antigravity의 보조 도구 역할을 하도록 설계된 Model Context Protocol (MCP) 기반 서버인 OpenCode MCP 서버가 포함되어 있습니다.
이 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.
