Provides local semantic embeddings using models from Hugging Face (e.g., Xenova/all-MiniLM-L6-v2) for memory search and injection.
Allows optional integration with OpenAI-compatible APIs for conversational compaction, using an API key for summarization.
Stores all runtime data (compaction records, semantic memories, project brain state, file index) in a SQLite database for persistence and consistency.
Enables scanning of Unity project files to build a file index for Project Brain, supporting querying and resuming work across sessions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infinite Context Keeper compact the current conversation for later recall"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Infinite Context Keeper is a Model Context Protocol (MCP) server. It exposes tools for context usage estimation (tiktoken-style counting), conversation compaction (metadata in SQLite), and durable memory with semantic search and injection using local embeddings (@xenova/transformers, stored in SQLite). Compaction output is stored both as SQLite compaction records and, when embeddings are enabled, as semantic memories so future sessions can retrieve old summaries by meaning. Memory stores share one opened DatabaseSync connection from startup for consistency and to avoid SQLite file-lock issues. @xenova/transformers and sqlite-vec load lazily when embeddings are first needed (or stay unloaded if embeddings are disabled), which reduces startup time and memory. It also includes a Project Brain layer: milestones, tasks, decisions, knowledge, and a Unity-oriented file index in the same database, plus MCP tools to query and resume work across sessions. project_resume builds its recall query from project goals, incomplete tasks, recent compaction, and next-step keywords so cold starts recover the active work more reliably. Retrieved memory injection blocks are marked as untrusted reference context, not higher-priority instructions. When supported by the runtime, sqlite-vec (vec0) accelerates semantic memory KNN search; otherwise the server falls back to in-process cosine similarity.
npm: infinite-context · source: infinite-context-keeper-node
The capabilities this project was built for—long-lived context, compaction, durable semantic memory, and structured “resume the project” recall—now substantially overlap the product goals that OpenAI Codex supports out of the box. Because that overlap covers what this repo set out to solve, no further updates are planned for this project. The published package and source remain available as-is for anyone who still wants a self-hosted MCP path.
Node.js 22.5+ (uses node:sqlite)
sqlite-vec (optional, recommended): Node 23.5+ with DatabaseSync(..., { allowExtension: true }) so the bundled sqlite-vec extension loads; on older Node or if loading fails, semantic search still works via JavaScript cosine on stored embeddings. The extension is not loaded at process start unless and until the semantic path needs it (lazy).
When embeddings are enabled, the first use of the embedder may download models (e.g. Xenova/all-MiniLM-L6-v2) into the Hugging Face cache (loading is lazy, not at server boot).
Optional: OpenAI-compatible API key for compaction
Recommended (avoids global npm permission issues):
npx -y infinite-contextGlobal install:
npm install -g infinite-context
infinite-contextEACCES)On MacBooks and other Macs, npm install -g often fails with EACCES when npm’s global prefix (for example /usr/local) is owned by root or not writable by your user. Prefer npx so you do not need a global install.
To use a global CLI without sudo, install npm’s global packages under your home directory:
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
# Then add this line to ~/.zshrc or ~/.bash_profile and restart the shell:
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g infinite-contextUsing sudo works but can leave root-owned files under the global prefix and cause more permission errors later; use it only if the approaches above are not possible:
sudo npm install -g infinite-context
sudo infinite-contextBy default, runtime data goes under ./data relative to the process current working directory (SQLite file e.g. ./data/infinite_context_keeper.sqlite). MCP hosts should set cwd to the project (for example Cursor’s "${workspaceFolder}"), or set ICK_DATA_DIR / YAML data_dir to an absolute path so the database is created in a predictable, writable place.
Check help/version:
npx -y infinite-context --help
npx -y infinite-context --versionFrom a git checkout: npm install && npm run build, then node dist/index.js. CLI aliases: infinite-context and infinite-context-keeper.
If local embeddings fail to start (for example errors loading native helpers used by @xenova/transformers), reinstall dependencies on the same machine and architecture (rm -rf node_modules && npm install) so optional native modules match your Mac (Apple Silicon vs Intel).
Defaults ship in config/default.yaml (relative to the package root when installed from npm).
Point ICK_SETTINGS_YAML at your own YAML (absolute path) for per-project overrides.
Any setting can be overridden with ICK_ + SNAKE_UPPER env vars (e.g. ICK_OPENAI_API_KEY).
default_project_id in YAML or ICK_DEFAULT_PROJECT_ID selects the default project_id for Project Brain tools when the tool omits project_id (default string: default).
ICK_DATA_DIR or YAML data_dir sets the directory for SQLite and runtime files. Use an absolute path when the process cwd is unpredictable (recommended for some MCP configs); otherwise ./data is resolved from cwd.
embedding_enabled in YAML or ICK_EMBEDDING_ENABLED — when false, semantic tools (save_memory, semantic_search_memory, inject_relevant_memories, memory_search, etc.) return an error stating that embeddings are disabled; search_and_inject_memory falls back to simple text chunking without semantic ranking; injected context blocks omit semantic-memory sections.
Diagnostics: get_server_info — runtime snapshot: package version (from npm metadata), Node version, OS/arch, resolved data_dir, embedding_enabled, configured embedding model name, sqlite_vec_active, whether the embedder pipeline has been loaded (embedder_loaded), default_project_id, and whether ICK_SETTINGS_YAML was set.
Context & memory: get_context_usage, trigger_compaction, save_memory, semantic_search_memory, inject_relevant_memories, search_and_inject_memory, list_memories, delete_memory. trigger_compaction writes normal compaction records and also upserts semantic summary/key-facts memories when embeddings are enabled.
Project Brain: project_get_status, project_create_milestone, task_break_down, task_update, unity_scan_project, memory_search, project_resume (structured state, Unity file index, recent compaction, incomplete-task-aware semantic recall, and a markdown inject_block for cold starts).
Danger / maintenance: reset_entire_database — irrecoverably deletes all user rows in infinite_context_keeper.sqlite (memories, compaction tables, semantic_memories and optional sqlite-vec side tables, Project Brain tables, project_files). The MCP tool runs only when confirm is exactly DELETE_ALL_DATA. It does not remove on-disk session archive folders under data_dir; delete those separately if needed.
Tool list responses are de-duplicated by tool name on the server side.
semantic_search_memory and memory_search responses include sqlite_vec_knn: true when sqlite-vec is loaded and semantic rows use the vec0 KNN path; false when the server uses the JavaScript cosine fallback.
SQLite uses PRAGMA user_version for schema versioning so future releases can apply ordered migrations instead of relying only on CREATE TABLE IF NOT EXISTS.
Memory injection blocks intentionally include a safety boundary: retrieved memories are prior-session notes and should be treated as reference material, not instructions that override the current user, developer, or system messages.
For multi-session execution on the same project, paste and use the block below in Cursor Rules, AGENTS.md, or a system prompt.
You are a long-running agent that actively uses the "Infinite Context" MCP.
The project goal is defined in goal.md.
The core principle is "do not stop after the first task"; if at least one task remains, you must continue with the next one.
Rules:
1. At the start of every session, you must inspect the current state through Infinite Context.
- Use **project_resume(project_id?, session_id?)** first to gather Project Brain summary, `inject_block`, recent compaction, and top semantic chunks.
- Use **project_get_status(project_id?)** to check milestones, tasks, and index status.
- Use list_memories(project_id, session_id) to review recent compaction metadata and summary flow.
- Use semantic_search_memory, **memory_search**, and inject_relevant_memories to find "in-progress work", "blockers", "next steps", and prior decisions/knowledge.
- If needed, use search_and_inject_memory(task_description, project_id, session_id) to get an injection block tailored to this session's goal.
- Use get_context_usage(max_tokens, …) regularly to monitor context usage.
2. Enforce the work loop. (Critical)
- Always run in this cycle: "select next incomplete task -> execute -> verify -> save memory -> select next task".
- Never stop while incomplete tasks exist.
- "report-only then stop" is forbidden; complete real changes/verification/recording, then immediately move to the next task.
- Stopping is allowed only when all goals and tasks defined in goal.md are complete.
3. Run forced handoff at 75% context usage. (Critical)
- If usage ratio from get_context_usage reaches 75% or higher, start handoff immediately.
- With save_memory, store these fields in structured form: current progress, completed/incomplete tasks, failure causes, next action, restart checklist.
- Call trigger_compaction(project_id, session_id, conversation_text or messages, with custom_instruction explicitly saying "preserve project goals, goal.md essentials, and incomplete tasks").
- Add/sync remaining work in Infinite Context, then continue in a new session (new window) using project_resume.
- Right after handoff, the new session must read saved next_steps and resume from the next incomplete task immediately.
4. Recording rules during execution:
- Always follow goal.md.
- Save important decisions, progress, and failure/retry outcomes with save_memory(key, content, project_id, session_id, optional metadata).
- Keep milestone/task DB state in sync using **project_create_milestone**, **task_break_down** (re-call with tasks array), and **task_update**.
- In Unity workspaces, refresh file index with **unity_scan_project**.
5. Mandatory steps before session end:
- Save next_steps as an actionable checklist via save_memory.
- Include keywords so the next session can immediately continue via semantic_search_memory or search_and_inject_memory.
- Do not repeat already-compacted content; continue briefly based on Keeper summaries/memories.
6. Deliverable report format (Required):
- **Code changes**: modified/created files and key logic
- **Why this changed**: necessity and technical rationale
- **Test/verification results**: actual logs/outputs checked
- **Next step proposal**: immediately executable follow-up task
Now read goal.md, analyze the full project goal, and do not stop at only the first task; continue executing as far as completion is possible in sequence.
If all work is complete, define new goals or tasks, persist them in Infinite Context (milestones/tasks/memories), and repeat the work loop.MIT (see package.json).
Derived from git history:
0.1.9 — Compaction summaries/key facts are also saved as semantic memories; project_resume recall is anchored on incomplete tasks, recent compaction, and next-step keywords; injection blocks now mark retrieved memories as untrusted reference context; SQLite schema versioning starts with PRAGMA user_version.
0.1.8 — Shared SQLite connection for memory stores; lazy loading of transformers / sqlite-vec; get_server_info diagnostic tool; degradation when embedding_enabled is false; MCP server version field reads the installed package version (not a hardcoded constant).
0.1.7 — CLI --help / --version for the infinite-context binary.
0.1.6 — reset_entire_database maintenance tool (confirm: DELETE_ALL_DATA).
0.1.5 — delete_memory tool.
0.1.4+ — README updates; MCP tool list de-duplicated by name on the server.
More detail — Cursor / Claude mcp.json samples and the Python vs Node comparison table are in the 한국어 section below.
Related MCP server: local-memory-mcp
Infinite Context Keeper는 Model Context Protocol(MCP) 서버입니다. 대화 컨텍스트 사용량 조회, compaction, 장기 메모 저장·시맨틱 검색·주입을 도구로 제공합니다. compaction 결과는 SQLite compaction 레코드로 저장될 뿐 아니라, 임베딩이 켜져 있으면 시맨틱 메모리에도 저장되어 다음 세션에서 오래된 요약을 의미 기반으로 다시 찾을 수 있습니다. compaction 메타와 시맨틱 메모는 같은 SQLite DB에 두며, 메모리 스토어는 시작 시 열린 DatabaseSync 하나를 공유해 잠금·일관성 문제를 줄입니다. 시맨틱 행은 semantic_memories와 로컬 임베딩(@xenova/transformers) 으로 저장하며, @xenova/transformers·sqlite-vec 는 첫 필요 시점에 지연 로드(임베딩이 꺼져 있으면 로드 생략)되어 기동 시간·메모리를 줄입니다. Project Brain으로 projects / milestones / tasks / decisions / knowledge / project_files(Unity 스캔 인덱스) 등을 같은 DB에서 관리하고, 세션 재개용 project_resume 등 MCP 도구로 읽고 갱신할 수 있습니다. project_resume은 프로젝트 목표, 미완료 태스크, 최근 compaction, next-step 키워드를 검색 앵커로 사용해 새 세션 복구 품질을 높입니다. 검색된 메모리 주입 블록은 현재 지시를 덮어쓰는 명령이 아니라 신뢰하지 않는 참고 컨텍스트로 표시됩니다. 런타임이 허용하면 sqlite-vec(vec0) 으로 시맨틱 메모 KNN 검색을 가속하고, 아니면 JS 코사인으로 폴백합니다.
npm: infinite-context
이 저장소가 처음 지향하던 기능(장기 컨텍스트, compaction, 시맨틱 메모리, 구조화된 프로젝트 재개 등)은 OpenAI Codex가 제품 목표로 제공하는 방향과 실질적으로 같습니다. 그 목표가 Codex 쪽에서 이미 다루어지므로 이 프로젝트는 추가 업데이트를 진행하지 않을 예정입니다. npm에 올라간 패키지와 소스는 그대로 두어, 자체 호스팅 MCP가 필요한 경우에만 참고용으로 사용할 수 있습니다.
Node.js 22.5+ (node:sqlite 사용)
sqlite-vec(선택·권장): Node **23.5+**에서 확장 로드가 되면 시맨틱 KNN에 사용합니다. 아니면 JS 코사인입니다. 확장은 기동 직후가 아니라 필요할 때 지연 로드됩니다.
임베딩이 켜져 있을 때, 첫 사용 시 Hugging Face 캐시로 Xenova/all-MiniLM-L6-v2 등이 내려받아질 수 있음(서버 부팅 시가 아니라 지연 로드)
(선택) compaction LLM: OpenAI 호환 API 키
권장: 전역 설치 없이 실행(맥에서 EACCES 회피에 유리):
npx -y infinite-context전역 CLI:
npm install -g infinite-contextEACCES)맥북 등 macOS에서는 npm 전역 prefix(예: /usr/local)가 현재 사용자에게 쓰기 불가면 npm install -g가 EACCES로 실패합니다. 가능하면 npx로만 실행하는 것을 권장합니다.
sudo 없이 전역 CLI를 쓰려면 홈 디렉터리 아래에 전역 패키지를 두고 PATH만 잡습니다:
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
# 아래 한 줄을 ~/.zshrc 또는 ~/.bash_profile에 넣은 뒤 셸을 다시 여세요:
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g infinite-contextsudo npm install -g는 동작할 수 있으나 전역 디렉터리에 root 소유 파일이 남아 이후에도 권한 문제가 반복되기 쉽습니다. 위 방법이 어려울 때만 사용하세요:
sudo npm install -g infinite-context
sudo infinite-context기본값 ./data는 프로세스 시작 시 현재 작업 디렉터리(cwd) 기준입니다(SQLite 예: ./data/infinite_context_keeper.sqlite). Cursor 등 MCP에서는 cwd를 프로젝트로 지정(예: "${workspaceFolder}")하거나, ICK_DATA_DIR 또는 YAML **data_dir**에 절대 경로를 두어 예측 가능한 위치에 DB가 생기게 하세요.
도움말/버전 확인:
npx -y infinite-context --help
npx -y infinite-context --version로컬 클론에서 @xenova/transformers 관련 네이티브 모듈 오류가 나면, 같은 맥·같은 아키텍처에서 node_modules를 다시 설치하세요(rm -rf node_modules && npm install).
git clone https://github.com/sujkh85/infinite-context-keeper-node.git
cd infinite-context-keeper-node
npm install
npm run build기본값: 패키지에 포함된 config/default.yaml (npm 사용 시 패키지 루트 기준)
사용자 YAML: 환경변수 **ICK_SETTINGS_YAML**에 파일 절대 경로 (프로젝트별 설정에 권장)
예시 키: 저장소의 config/config.example.yaml 참고
개별 설정은 환경변수 ICK_ 접두사 + YAML 필드명의 스네이크 대문자(예: openai_api_key → ICK_OPENAI_API_KEY)로 덮어쓸 수 있습니다.
데이터 디렉터리: 환경변수 ICK_DATA_DIR 또는 YAML **data_dir**로 SQLite·런타임 파일 위치를 지정합니다. MCP 등에서 cwd가 매번 달라질 수 있으면 절대 경로를 권장합니다. 생략 시 ./data는 프로세스 cwd 기준으로 해석됩니다.
임베딩 끄기: YAML embedding_enabled: false 또는 ICK_EMBEDDING_ENABLED=0 이면 시맨틱 전용 도구(save_memory, semantic_search_memory 등)는 비활성 안내 오류를 반환하고, search_and_inject_memory 는 시맨틱 순위 없이 텍스트 청크 위주로 동작하며, 컨텍스트 주입에서 시맨틱 메모 구간은 생략됩니다.
Project Brain 기본 프로젝트: YAML의 default_project_id 또는 환경변수 **ICK_DEFAULT_PROJECT_ID**로, 도구 인자에서 project_id를 생략했을 때 쓸 ID를 지정합니다(기본값 문자열 default).
전역 설치했다면:
infinite-context전역 설치 없이:
npx -y infinite-context맥에서 전역 설치·권한 문제는 위 「설치 (npm)」 절의 macOS·EACCES·데이터 경로 안내를 참고하세요.
런타임 데이터는 기본적으로 ./data(cwd 기준)에 저장되며, SQLite 파일도 같은 위치에 생성됩니다(예: ./data/infinite_context_keeper.sqlite).
(infinite-context-keeper 별칭도 동일 진입점입니다.)
소스 빌드 후:
node dist/index.jsnpm 패키지로 등록:
claude mcp add --transport stdio --scope project infinite-context -- \
npx -y infinite-context.mcp.json / Cursor MCP 예시(npm).
최소 설정 — 패키지에 포함된 config/default.yaml만 쓰고, 환경 변수는 생략합니다. compaction에 OpenAI 호환 키가 필요하면 아래 확장 예시처럼 ICK_OPENAI_API_KEY만 추가하면 됩니다.
{
"mcpServers": {
"infinite-context": {
"type": "stdio",
"command": "npx",
"args": ["-y", "infinite-context"]
}
}
}SQLite·data_dir 기본값(./data)이 현재 작업 디렉터리 기준이므로, 데이터를 워크스페이스에 두고 싶다면 cwd만 더 넣습니다.
{
"mcpServers": {
"infinite-context": {
"type": "stdio",
"command": "npx",
"args": ["-y", "infinite-context"],
"cwd": "${workspaceFolder}"
}
}
}프로젝트 YAML·API 키까지 지정 — 워크스페이스의 설정 파일과 호스트 환경의 키를 넘길 때:
{
"mcpServers": {
"infinite-context": {
"type": "stdio",
"command": "npx",
"args": ["-y", "infinite-context"],
"cwd": "${workspaceFolder}",
"env": {
"ICK_SETTINGS_YAML": "${workspaceFolder}/config/config.example.yaml",
"ICK_OPENAI_API_KEY": "${env:ICK_OPENAI_API_KEY}"
}
}
}
}로컬 dist를 쓰려면 command/args를 node와 ${workspaceFolder}/dist/index.js로 바꾸면 됩니다.
진단: get_server_info — 패키지 버전·Node·OS/arch·해석된 data_dir·embedding_enabled·임베딩 모델명·sqlite-vec 활성·임베더 로드 여부·default_project_id·ICK_SETTINGS_YAML 설정 여부 등.
컨텍스트·메모리: get_context_usage, trigger_compaction, save_memory, semantic_search_memory, inject_relevant_memories, search_and_inject_memory, list_memories, delete_memory. trigger_compaction은 일반 compaction 레코드와 함께, 임베딩이 켜져 있으면 summary/key_facts를 시맨틱 메모리에도 upsert합니다.
Project Brain: project_get_status, project_create_milestone, task_break_down, task_update, unity_scan_project, memory_search, project_resume. project_resume은 구조화 상태, Unity 파일 인덱스, 최근 compaction, 미완료 태스크 기반 시맨틱 검색 결과, 새 세션용 inject_block을 함께 반환합니다.
위험·유지보수: reset_entire_database — infinite_context_keeper.sqlite 안의 사용자 데이터 행을 전부 삭제합니다(복구 불가). 대상: 메모·컴팩션 메타·시맨틱 메모(및 sqlite-vec 보조 테이블)·Project Brain·Unity 인덱스 등. MCP에서는 confirm이 정확히 DELETE_ALL_DATA 일 때만 실행됩니다. data_dir 아래 세션 아카이브 폴더는 SQLite 밖이라 이 도구로 지우지 않습니다. 필요하면 파일 시스템에서 별도 삭제하세요.
도구 목록 응답은 서버에서 tool name 기준으로 중복 제거해서 반환합니다.
도구 | 요약 |
| 런타임 진단(버전, Node, data_dir, embedding·sqlite-vec·임베더 상태 등) |
| 프로젝트·마일스톤·태스크·최근 결정/지식·인덱스된 Unity 파일 수 요약 |
| 마일스톤 추가( |
|
|
| 태스크 상태·노트(설명에 타임스탬프)· |
| Unity 루트 스캔 후 |
| 시맨틱 메모 + 결정/지식 텍스트 혼합 검색 |
| 새 세션용 |
|
|
| 로컬 SQLite 전 테이블 사용자 데이터 삭제(복구 불가). 인자 |
semantic_search_memory / memory_search 응답의 sqlite_vec_knn: 시맨틱 행에 대해 sqlite-vec KNN 경로가 켜졌는지 여부입니다.
SQLite는 PRAGMA user_version으로 스키마 버전을 기록합니다. 앞으로는 단순 CREATE TABLE IF NOT EXISTS에만 의존하지 않고 릴리즈별 순차 마이그레이션을 적용할 수 있습니다.
메모리 주입 블록에는 안전 경계가 포함됩니다. 검색된 메모리는 과거 세션 노트이므로 현재 user/developer/system 지시보다 우선하지 않는 참고 자료로 취급해야 합니다.
여러 채팅 세션에 걸쳐 같은 프로젝트를 이어갈 때, Cursor Rules·AGENTS.md·시스템 프롬프트 등에 아래 지침을 붙여 두면 Infinite Context Keeper MCP로 진행 상황·결정·다음 할 일을 DB에 남기고, 새 세션에서 다시 주입할 수 있습니다.project_id·session_id는 프로젝트마다 고정 문자열으로 쓰는 것을 권장합니다(예: project_id: "my-app", session_id: "main").
아래 블록은 저장소에 실제로 노출된 도구 이름과 맞춰 두었습니다.
너는 "Infinite Context" MCP를 적극적으로 사용하는 장기 실행 에이전트다.
프로젝트 목표는 goal.md 파일에 정의되어 있다.
핵심 원칙은 "첫 작업 후 종료 금지"이며, 남은 작업이 1개라도 있으면 반드시 다음 작업을 계속 수행한다.
규칙:
1. 매 세션 시작 시 반드시 Infinite Context로 현재 상태를 파악한다.
- **project_resume(project_id?, session_id?)** 로 Project Brain 요약, `inject_block`, 최근 compaction, 시맨틱 상위 청크를 우선 수집한다.
- **project_get_status(project_id?)** 로 마일스톤, 태스크, 인덱스 상태를 확인한다.
- list_memories(project_id, session_id)로 최근 compaction 메타 및 요약 흐름을 확인한다.
- semantic_search_memory, **memory_search**, inject_relevant_memories로 "진행 중 작업", "블로커", "다음 단계", 과거 결정/지식을 검색한다.
- 필요 시 search_and_inject_memory(task_description, project_id, session_id)로 이번 세션 목적에 맞는 주입 블록을 받는다.
- get_context_usage(max_tokens, …)로 컨텍스트 사용량을 수시 확인한다.
2. 작업 루프를 강제한다. (중요)
- 항상 "다음 미완료 태스크 선택 -> 실행 -> 검증 -> 메모리 저장 -> 다음 태스크 선택" 순환으로 동작한다.
- 미완료 태스크가 존재하면 절대 종료하지 않는다.
- "보고만 하고 종료"는 금지하며, 실제 변경/검증/기록까지 완료한 뒤 즉시 다음 태스크로 넘어간다.
- 종료는 goal.md 상의 목표와 태스크가 모두 완료된 경우에만 허용된다.
3. 컨텍스트 75% 도달 시 강제 handoff 절차를 수행한다. (중요)
- get_context_usage 기준 사용 비율이 75% 이상이면 즉시 handoff 준비를 시작한다.
- save_memory로 반드시 아래 항목을 구조화해 저장한다: 현재 진행 상태, 완료/미완료 태스크, 실패 원인, 다음 액션, 재시작 체크리스트.
- trigger_compaction(project_id, session_id, conversation_text 또는 messages, custom_instruction에 "프로젝트 목표와 goal 핵심, 미완료 태스크를 보존" 명시)을 호출한다.
- Infinite Context에 남은 일을 추가/동기화한 뒤, 새 세션(새 창)에서 project_resume으로 이어서 작업한다.
- handoff 직후 새 세션은 저장된 next_steps를 즉시 읽고 다음 미완료 태스크부터 재개한다.
4. 작업 수행 중 기록 규칙:
- goal.md를 항상 준수한다.
- 중요한 결정, 진행 상황, 실패/재시도 결과를 save_memory(key, content, project_id, session_id, metadata 선택)로 저장한다.
- 마일스톤/태스크는 **project_create_milestone**, **task_break_down**(tasks 배열로 재호출), **task_update**로 DB 상태와 동기화한다.
- Unity 워크스페이스면 **unity_scan_project**로 파일 인덱스를 갱신한다.
5. 세션 종료 직전 필수 처리:
- save_memory로 next_steps를 실행 가능한 체크리스트 형태로 남긴다.
- 다음 세션이 semantic_search_memory 또는 search_and_inject_memory로 즉시 이어질 수 있게 키워드를 포함한다.
- 이전 세션에서 정리된 내용은 반복하지 말고, Keeper 요약/메모를 전제로 짧게 이어간다.
6. 산출물 보고 형식(필수):
- **코드 변경**: 수정/생성 파일 및 주요 로직
- **변경 이유 요약**: 필요성 및 기술적 근거
- **테스트/검증 결과**: 실제 확인 로그/출력
- **다음 단계 제안**: 연속 실행 가능한 다음 작업
지금 goal.md를 읽고 전체 목표를 분석한 뒤, 첫 번째 작업만 제시하지 말고 완료 가능한 범위까지 연속적으로 작업을 수행하라.
만약 작업이 모두 완료되면 다시 목표나 task를 만들어서 infinite-context에 저장하고 작업을 다시 반복한다.항목 | Python | Node |
시맨틱 저장 | Chroma + sentence-transformers | SQLite |
MCP 런타임 | FastMCP |
|
토큰 추정 | tiktoken |
|
프로젝트 상태 | (구현에 따름) | SQLite: Project Brain 테이블 + |
0.1.9 — Compaction summary/key_facts를 시맨틱 메모리에도 저장; project_resume 검색을 미완료 태스크·최근 compaction·next-step 키워드 중심으로 강화; 검색 메모리 주입 블록을 신뢰하지 않는 참고 컨텍스트로 표시; SQLite PRAGMA user_version 스키마 버전 도입.
0.1.8 — SQLite 연결 공유; transformers/sqlite-vec 지연 로드; get_server_info; embedding_enabled: false 시 단계적 비활성화; MCP 서버 버전을 패키지에서 읽음.
0.1.7 — CLI --help / --version.
0.1.6 — reset_entire_database (confirm: DELETE_ALL_DATA).
0.1.5 — delete_memory.
0.1.4 이후 — README 정리·서버 측 도구 목록 이름 기준 중복 제거.
MIT (package.json 기준).
save_memory로 저장한 semantic_memories 항목을 삭제합니다. id 직접 삭제 또는 (project_id+session_id+key) 기준 삭제를 지원합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | semantic_memories의 id(sha256 doc id) | |
| key | No | save_memory에 사용한 key | |
| project_id | Yes | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions deletion modes but fails to disclose side effects (e.g., irreversibility, behavior on conflicts or missing items) or return value. This is insufficient for a deletion operation.
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?
Two sentences, no wasted words. First sentence states the main action, second sentence details the modes. Perfectly front-loaded and concise.
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?
The description is adequate for a simple list operation but lacks details on error handling, behavior on multiple matches, and prerequisites. Given no output schema and no annotations, more completeness would be beneficial.
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 50%, with project_id and session_id lacking descriptions. The description adds context by explaining that project_id, session_id, and key are used together for triple-based deletion, but does not clarify the relationship between id and the triple or what happens when both are provided.
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 that the tool deletes semantic memory items and specifies two deletion modes: by id or by (project_id+session_id+key). This is specific and distinguishes it from sibling tools like list_memories and memory_search.
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 explains when to use each deletion mode but does not provide explicit guidance on when not to use the tool or alternatives. It implies usage context by referencing save_memory but lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MCP 호스트가 넘기는 used_tokens·대화 본문·tool 결과 문자열을 tiktoken으로 합산해 컨텍스트 사용량을 추정합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| max_tokens | Yes | 컨텍스트 윈도우 최대 토큰 | |
| session_id | No | default | |
| used_tokens | No | ||
| conversation_text | No | ||
| tool_results_text | No | ||
| system_prompt_text | No | ||
| text_for_estimate | No | ||
| encoding_model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the basic behavior (summing inputs with tiktoken), but lacks details on return format, error handling, or side effects. Since no annotations are provided, the description should be more explicit.
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 that directly states the tool's purpose. It contains no filler or redundancy.
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?
With 8 parameters, no output schema, and no annotations, the description is too brief to provide complete context. It omits details on return values, parameter interactions, and edge cases, making it insufficient for an agent to reliably invoke the tool.
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 description coverage is only 13%, yet the description only mentions three of eight parameters (used_tokens, conversation_text, tool_results_text). The roles of max_tokens, session_id, system_prompt_text, text_for_estimate, and encoding_model are not explained, leaving significant gaps.
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 tool estimates context usage using tiktoken by summing specific inputs (used_tokens, conversation text, tool results). It distinguishes itself from sibling tools, which are all unrelated (memory, project, etc.).
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 alternatives is provided. The description only explains what the tool does, not when it is appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
런타임 진단: 패키지·Node 버전, 해석된 data_dir, embedding_enabled, sqlite-vec 활성 여부, 임베딩 파이프라인 로드 여부 등.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly identifies the tool as read-only diagnostic, but does not mention any behavioral traits beyond the returned data (e.g., no side effects, no permissions required).
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 single Korean sentence is concise and lists key items efficiently. However, breaking into structures like bullet points could improve readability for an AI agent.
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 parameters and no output schema, the description lists the returned information adequately. However, it could be more complete by specifying the format or providing an example output.
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?
The tool has zero parameters, so schema coverage is 100%. The description need not add parameter info, and none is needed. Baseline of 4 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 tool provides runtime diagnostics, listing specific items like package/Node versions, data_dir, embedding settings, etc. This distinguishes it from sibling tools which focus on memory or project management.
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 implies use when diagnostic info is needed, but provides no explicit guidance on when to use this tool versus alternatives, nor any scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_search_memory와 동일 스코프로 검색 후 tiktoken 예산 내 마크다운 블록을 만듭니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| project_id | No | default | |
| session_id | No | ||
| limit | No | ||
| max_inject_tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'tiktoken budget' and 'markdown block' but does not disclose side effects, read-only nature, or auth requirements. The comparison to semantic_search_memory is vague. Score 2 for minimal behavioral disclosure.
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 concise (single sentence) and front-loaded with the sibling comparison. However, it lacks structure and relies on external knowledge. Score 3 for reasonable conciseness but limited informativeness.
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?
With 5 parameters, no output schema, and no annotations, the description is too brief. It does not explain the output format, error handling, or budget enforcement. Score 2 for insufficient 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 0%, yet the description only implicitly references max_inject_tokens via 'tiktoken budget'. Other parameters (query, project_id, session_id, limit) are not explained. Score 2 for insufficient parameter description.
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?
Description states it searches with same scope as semantic_search_memory and creates a markdown block within a token budget. The verb-resource pair is clear enough, but the tool's scope relative to siblings is not fully defined. Score 4 for clear but not fully self-contained 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?
No explicit guidance on when to use this tool vs siblings. With tools like memory_search, semantic_search_memory, and search_and_inject_memory, the description fails to differentiate usage contexts. Score 2 for missing usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SQLite에 저장된 compaction 요약 등의 메타를 나열합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| session_id | No | ||
| tag | No | ||
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'lists metadata' without mentioning read-only nature, side effects, or error handling.
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?
Single sentence is concise but lacks structure. It does not front-load key details like filtering or ordering.
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?
With 5 parameters and no output schema, the description is too sparse. It fails to explain return format, pagination, or how parameters affect results.
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 description coverage is 0% and the description does not explain any parameter. With 5 parameters, the agent gets no help on what each parameter does.
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 it lists metadata like compaction summaries from SQLite. It distinguishes from siblings like memory_search and semantic_search_memory because those are search tools, not listing.
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 alternatives. No context on prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
시맨틱 메모리(semantic_memories) + 결정/지식 테이블 텍스트에 로컬 임베딩 코사인 랭킹을 합쳐 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| project_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral traits. It only describes the search algorithm but omits safety profile (e.g., read-only or destructive), authorization needs, or side effects. The combination of two sources is mentioned but not the implications.
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 short sentence, which is concise but not well-structured. It provides minimal information in a compact form, but every word is not necessary given the lack of clarity.
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 the three parameters, no output schema, and no annotations, the description is severely incomplete. It lacks return value details, usage context, limitations, and integration with sibling tools. The agent cannot infer correct usage from this description alone.
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?
All three parameters have no descriptions in the schema (0% coverage). The description does not explain what 'query', 'project_id', or 'limit' mean or how they affect the search. It adds no semantic value beyond the schema.
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 specifies the verb 'search' and the resources 'semantic memories' and 'decision/knowledge table text', and includes the technique 'local embedding cosine ranking'. It distinguishes from siblings like 'semantic_search_memory' by mentioning the combination of two sources, but does not explicitly differentiate.
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 is provided on when to use this tool versus alternatives like 'semantic_search_memory' or 'search_and_inject_memory'. There is no mention of when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project Brain: 마일스톤을 추가합니다(자동 order_num).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | ||
| title | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the auto order number. There is no mention of side effects, required permissions, or what happens when optional parameters like project_id are omitted. No annotations exist to compensate.
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 sentence with no unnecessary words. It is concise but lacks structural elements like heading or context. Still efficient for its brevity.
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 the simplicity of the tool, the description is minimal but does not explain what a milestone is, how the tool integrates with the project system, or clarify the optional project_id parameter. It leaves gaps for an agent to decide when to use it.
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?
With 0% schema coverage, the description does not explain any parameter (project_id, title, description). The only extra info is 'auto order_num' which is not parameter-specific. The description fails to add meaning beyond the bare schema.
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 tool adds a milestone and mentions auto-assignment of order number. It is specific enough to understand the action, though it does not distinguish from siblings like task_break_down or project_get_status.
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 is provided on when to use this tool vs alternatives. There is no mention of prerequisites or restrictions, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project Brain: 프로젝트 메타, 마일스톤·태스크, 최근 결정/지식, Unity 파일 인덱스 건수를 한 번에 조회합니다. project_id 생략 시 default_project_id.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | 생략 시 설정의 default_project_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a query operation but does not disclose potential side effects, permission requirements, or rate limits. The name suggests read-only, but this is not explicitly stated.
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 sentence that efficiently conveys the tool's purpose and parameter behavior without redundancy. Every part earns its place.
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?
The description lists the components of the returned information (meta, milestones/tasks, decisions/knowledge, Unity file counts), but does not detail the format or structure. With no output schema, some further context on return value would improve 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 description coverage is 100% for the only parameter, and the tool description repeats the same information about default behavior. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
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?
Description clearly states it retrieves project meta, milestones/tasks, recent decisions/knowledge, and Unity file index counts. The verb '조회' (query) and resource 'Project Brain' are specific, and the tool distinguishes itself from siblings like project_create_milestone or project_resume by focusing on status retrieval.
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 implies usage for getting an overview of project status and notes the default project_id behavior, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
새 세션 시작 시 호출: 프로젝트 브레인 요약 마크다운(inject_block) + 구조화 JSON + 최근 compaction 스니펫 + 시맨틱 상위 청크.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | ||
| session_id | No | compaction 스니펫용 | default |
| top_semantic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes actions (injects block, provides snippets), but does not disclose whether the tool is read-only, destructive, or requires specific permissions. The lack of annotations and behavioral detail reduces transparency.
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, dense sentence that packs key information efficiently. It is front-loaded with the usage context and lists the outputs without unnecessary words. However, it could be restructured for slightly better readability.
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 multiple sibling tools, the description adequately explains the tool's purpose for session resumption but does not clarify return values or side effects. An agent would understand when to call it but might miss details on how to process the outputs.
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 description coverage is low (33%), and the description compensates partially by linking session_id to compaction snippets and top_semantic to semantic chunks. However, project_id is not explained, and inject_block is mentioned in the description but not in the schema. The description adds moderate value but is incomplete.
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 tool is called when starting a new session and lists the specific outputs: project brain summary markdown, structured JSON, recent compaction snippet, and semantic top chunks. This distinguishes it from siblings like inject_relevant_memories or memory_search, which have narrower scopes.
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 explicitly states '새 세션 시작 시 호출' (called when starting a new session), providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
로컬 infinite_context_keeper.sqlite의 사용자 데이터 전부 삭제(메모·시맨틱·프로젝트 브레인·컴팩션·Unity 인덱스 등). 되돌릴 수 없음. confirm을 정확히 보내야 실행됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | 반드시 문자열 "DELETE_ALL_DATA" (따옴표 없이 그대로) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the destructive nature, irreversibility, and the need for exact confirm. It lists what data is affected, which is good, though it could mention scope or success/failure response.
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 two sentences, front-loading the critical verb and resource, then stating irreversibility and condition. Every sentence earns its place with no redundancy.
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 the tool's destructive simplicity and one parameter, the description covers the essential aspects: what is deleted, irreversibility, and execution condition. It is missing mentions of recovery or errors, but is adequate for the scope.
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 description coverage is 100% for the confirm parameter. The description adds value by specifying the exact required string and noting without quotes, which reinforces the schema enum. This goes beyond the baseline of 3.
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 it deletes all user data from a specific local database, listing what is included (memo, semantic, project brain, compaction, Unity index). This distinguishes it from siblings like delete_memory which targets individual items.
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 implies use for complete reset by noting irreversibility and the confirm requirement. It does not explicitly state when not to use or compare with alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
시맨틱 메모리에 project_id·session_id 스코프로 저장합니다. 동일 key는 upsert됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| content | Yes | ||
| project_id | Yes | ||
| session_id | Yes | ||
| metadata | No | ||
| importance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior by noting the upsert behavior for duplicate keys, but it does not explain side effects, permissions, or how metadata/importance are handled during upserts.
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 sentence that conveys the core action efficiently, but it lacks structure and front-loads scope information before the key action.
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 the tool's complexity (6 parameters, nested objects, no output schema), the description is far too minimal; it omits return values, error conditions, and detailed upsert behavior, leaving significant gaps.
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 0% and the description adds no meaning to any of the 6 parameters beyond mentioning project_id and session_id as scope; it does not explain key, content, metadata, or importance.
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 'save', the resource 'semantic memory', and the scope 'project_id/session_id', and mentions upsert behavior, effectively distinguishing it from siblings like delete or list.
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 is provided on when to use this tool versus alternatives like memory_search or inject_relevant_memories, nor are there any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
새 세션/compaction 직후 컨텍스트 상단 주입 블록을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | ||
| project_id | Yes | ||
| session_id | Yes | ||
| top_k | No | ||
| max_inject_tokens | No | ||
| fill_from_project | No | ||
| include_recent_compaction_in_query | No | ||
| injection_mode | No | manual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states 'returns' but the tool name includes 'inject', creating ambiguity about whether it modifies state. No behavioral traits (e.g., side effects, permissions, rate limits) are disclosed.
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 sentence, which is concise, but it sacrifices substance. It is front-loaded with key terms but lacks the detail needed for effective use.
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 8 parameters, a complex behavior (search and inject), and no output schema or annotations, the description is entirely inadequate. It does not explain inputs, outputs, or behavior, leaving the agent without essential information.
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 description coverage is 0%, and the description provides no information about any of the 8 parameters. The agent has no clue what parameters like 'task_description', 'injection_mode', or 'fill_from_project' mean or how to use them.
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 states 'returns a context top injection block immediately after a new session/compaction' but does not clearly explain what the tool does. The verb 'returns' is vague, and the resource 'context top injection block' is not defined. It fails to distinguish from sibling tools like inject_relevant_memories.
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 is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it. The sibling tool 'inject_relevant_memories' likely serves a similar purpose, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
관련 메모리 청크를 반환합니다. sqlite-vec(vec0) KNN이 켜지면 DB 내 벡터 인덱스로 검색하고, 아니면 JS 코사인으로 폴백합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| project_id | Yes | ||
| limit | No | ||
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important runtime behavior: vector index (sqlite-vec) vs. JS cosine fallback. But with no annotations, it omits other traits like idempotency, error handling, or permission requirements.
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?
Two short sentences, no filler. Purpose and key behavioral detail front-loaded. Could benefit from structured sections but remains efficient.
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?
Missing critical context: no output schema, no explanation of return format, no human-friendly description of what a 'memory chunk' contains. Does not mention optional session_id filtering or limit semantics.
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 0% and description adds zero information about any parameter (query, project_id, limit, session_id). The agent must rely entirely on parameter names and types, which are insufficient.
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 tool returns relevant memory chunks using semantic search (vector index or cosine fallback), distinguishing it from non-semantic siblings like memory_search. However, it doesn't explicitly contrast with search_and_inject_memory, and the Korean text may be less accessible.
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 siblings (e.g., memory_search, search_and_inject_memory). No prerequisites, context, or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project Brain: 마일스톤을 세부 태스크로 나눕니다. tasks가 비어 있으면 마일스톤 정보와 함께 모델이 tasks 배열을 채워 재호출하도록 안내합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| milestone_id | Yes | ||
| complexity_level | No | 참고용(저장되지 않음). LLM이 분해 난이도에 맞춰 tasks 개수·세분화를 조절. | |
| tasks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: the tasks array can be empty and then must be filled by the model, and complexity_level is not saved. This adds context beyond the basic function.
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?
Two sentences, front-loaded with the core purpose, and every word adds value. No fluff.
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?
The description covers the main usage and a key behavioral pattern, but it does not mention return values or prerequisites (e.g., milestone must exist). Given no output schema, this is a gap for 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?
The description explains the complexity_level parameter's role (reference only, not saved) and the tasks array's behavior, adding meaning beyond the schema which only has a terse description for complexity_level. Schema coverage is 33%, so the description compensates.
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 'break down' and resource 'milestones into detailed tasks', distinguishing it from sibling tools like project_create_milestone or task_update. It also provides a specific behavioral detail about the tasks array.
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 explains when to use the tool (to break down milestones) and gives a guideline on how to fill the tasks array if empty. However, it does not explicitly exclude alternative scenarios or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project Brain: 태스크 상태·노트(설명에 타임스탬프 부가)·누적 actual_hours 갱신.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| status | No | todo / in_progress / done 등 | |
| note | No | ||
| hours_spent | No | actual_hours에 가산 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It partially reveals that notes get a timestamp and hours_spent adds to cumulative actual_hours, but omits whether updates are destructive, if status values are restricted, or if any other side effects occur.
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 that front-loads the context 'Project Brain'. It is efficient with no wasted words, though it could be slightly more structured with line breaks for clarity.
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 the absence of annotations and output schema, and with only 50% parameter coverage, the description is insufficiently complete. It does not cover return values, error cases, or prerequisites, making it inadequate for a mutation tool in a complex system.
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 description coverage is 50%, with status and hours_spent having basic descriptions. The description adds value by explaining the note parameter gets a timestamp appended, which is not in the schema. However, the required 'id' parameter remains undocumented in both schema and description.
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 tool updates task status, note (with timestamp appended), and cumulative actual hours. The verb 'update' combined with specific resources (status, note, hours) provides a precise purpose, distinguishing it from sibling tools like task_break_down.
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 offers no guidance on when to use this tool versus alternatives. It lacks explicit context for usage, such as prerequisites or conditions for updating, which is needed given the variety of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarization_start_ratio(기본 75%) 이상일 때만 실행하도록 context_percentage 또는 used_tokens+max_tokens로 검증합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| session_id | Yes | ||
| conversation_text | No | ||
| messages | No | ||
| mode | No | hierarchical | |
| custom_instruction | No | ||
| max_tokens | No | ||
| used_tokens | No | ||
| context_percentage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions a condition using parameters but does not disclose what the tool does when invoked (e.g., whether it mutates data, triggers async processes, or returns a result). This is insufficient transparency.
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 sentence in Korean, but it is not concise in conveying the tool's action or usage. The structure is unclear and fails to front-load the purpose.
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 9 parameters, no output schema, and no schema descriptions, the description is highly incomplete. It does not explain the tool's return value, side effects, or how to use the many optional parameters.
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 description coverage is 0%, and the description does not explain any parameter. It drops parameter names ('context_percentage', 'used_tokens', 'max_tokens') but provides no semantics, leaving the agent without understanding of how to fill these fields.
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 states a verification condition but does not clearly state the tool's primary action. '검증합니다' (verify) suggests checking, while the tool name implies triggering compaction. The purpose is ambiguous.
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 alternatives like get_context_usage. The condition for execution is mentioned but not in a way that helps an agent choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unity 프로젝트 루트(기본: process.cwd)를 스캔해 project_files 테이블을 갱신합니다. Assets가 있으면 그 하위 위주로 .cs 등 인덱싱.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | ||
| unity_project_root | No | Unity 프로젝트 절대/상대 경로 | |
| max_files | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions table updates and indexing but omits side effects, permission requirements, whether it runs synchronously, or if it overwrites existing data. The agent has limited insight into safety or impact.
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 concise (two sentences) and front-loaded with the primary action. However, a slightly more structured format (e.g., listing key behaviors) could improve scannability for an AI agent.
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 the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain return values, error conditions, or post-conditions, leaving critical gaps for an agent to understand the tool's full behavior.
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 low (33%) and only unity_project_root has a description. The tool description adds context about default root and indexing but does not explain project_id or max_files semantics. The agent must infer their meaning or usage.
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 tool scans a Unity project root, updates the project_files table, and indexes .cs files, focusing on the Assets subdirectory. This is specific and distinct from all sibling tools, which deal with memory and project management.
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 alternatives. There is no mention of prerequisites, scenarios for scanning, or situations where it might not be appropriate. Sibling tools are unrelated, so differentiation is minimal.
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. Dates show when Glama detected each change.
v0.1.10delete_memoryget_context_usageget_server_infoinject_relevant_memorieslist_memoriesmemory_searchproject_create_milestoneproject_get_statusproject_resumereset_entire_databasesave_memorysearch_and_inject_memorysemantic_search_memorytask_break_downtask_updatetrigger_compactionunity_scan_projectSeveral tools focus on searching or injecting memories (inject_relevant_memories, semantic_search_memory, memory_search, search_and_inject_memory), with subtle differences that could confuse an agent. Other tools like project management and scanning are distinct, reducing overall ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (e.g., delete_memory, project_create_milestone, trigger_compaction). No mixing of styles or unpredictable variations.
With 17 tools, the server covers memory, project brain, compaction, and Unity scanning. The count is slightly high but still well-scoped for its domain, avoiding bloat.
The tool surface covers core CRUD for memories, project lifecycle (create, update, status), compaction, and scanning. Minor gaps like a dedicated get_memory by ID are mitigated by upsert and search capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud-hosted MCP server for durable AI memory
Persistent memory for AI agents — log and recall conversation context over MCP.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sujkh85/infinite-context-keeper-node'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
