AI 코딩 에이전트를 위한 프로토콜 중립적 엔지니어링 컨텍스트 레이어. memex는 저장소의 비시간적(bitemporal) 지식 그래프(모듈, 심볼, 결정, 문제, 증거, 코드 진화)를 구축하고, Hermes MemoryProvider 또는 MCP를 통해 범위가 제한되고 출처가 보존된 컨텍스트를 노출합니다.
커밋과 파일 변경을 구조화된 엔지니어링 지식으로 변환하는 데몬이자 MCP 서버입니다. 에이전트는 작업 전에 신선도와 출처가 보존된 관련 저장소 컨텍스트를 받을 수 있으며, memex가 개인 메모리나 원시 세션 상태의 소스가 되지 않습니다.
flowchart LR
A[Your repository<br/>files + git] --> B[memex watcher<br/>tree-sitter + Gemini]
B --> C[Neo4j graph<br/>bitemporal facts]
C --> D[memex core<br/>ContextPacket selection]
D --> E[Hermes MemoryProvider<br/>automatic read-only prefetch]
D --> F[MCP fallback<br/>explicit lookup]
E --> G[AI coding agent]
F --> G
style B fill:#cfe8ff,stroke:#0066cc,color:#000
style C fill:#fff4cf,stroke:#cc9900,color:#000
style E fill:#d4f5d4,stroke:#2d8f2d,color:#000/plugin marketplace add STiFLeR7/claude-plugins
/plugin install memex-mcp@stifler-marketplaceClaude Code 세션을 다시 시작하세요.
docker compose -f docker/docker-compose.yml up -d
cat > .env <<EOF
NEO4J_URI=bolt://localhost:7687
NEO4J_USER=neo4j
NEO4J_PASSWORD=memex-local
GEMINI_API_KEY=your-key-here
EOF
npx stifler-memex-mcp init --repo .
npx stifler-memex-mcp watch --repo .
npx stifler-memex-mcp serve --repo .v0.9 Hermes 통합은 읽기 전용입니다. Hermes는 개인 메모리, 원시 세션 상태, 실행 상태를 유지합니다.
memex는 범위가 제한된 ContextPacket을 통해 저장소 엔지니어링 컨텍스트를 공급하며,
Hermes state.db, 대화 기록, 프롬프트, 도구 결과를 수집하지 않습니다.
memex 공급자를 Hermes 프로필 구성에 추가하세요:
memory:
provider: memex
plugins:
memex:
repo_path: /absolute/path/to/repository
prefetch_timeout_seconds: 7
max_items: 8
max_chars: 12000Hermes가 설치되지 않은 경우, MCP get_engineering_context 도구를 통해 동일한 컨텍스트 선택기를 사용하세요.
두 경로 모두 프로토콜 중립적인 memex 코어를 공유하며, 검색이 불가능할 때는 fail-open 방식으로 동작합니다.
채널 | 명령 |
Claude Code 마켓플레이스 |
|
npx (설치 없이) |
|
uv |
|
pip |
|
소스 |
|
공유 팀 환경(Neo4j 1개 + memex-server 1개, 인증 기본 활성화, Neo4j 포트가 호스트에 노출되지 않음)의 경우:
bash docker/bootstrap-team-env.sh
docker compose -f docker/docker-compose.team.yml up -d전체 흐름, 초기 관리자 키 캡처, 피해야 할 down -v 함정에 대해서는 docker/TEAM-DEPLOY.md를 참조하세요.
Related MCP server: memtrace
속성 | 값 |
출력 | 저장소에서 지속적으로 채워지는 Neo4j 그래프 |
저장소 | Graphiti를 통한 Neo4j. 비시간적 — 모든 엣지에 |
컨텍스트 | 범위 제한, 순위 지정, 출처 인지형 |
통합 | Hermes MemoryProvider, MCP 리소스/도구, Claude Code, Cursor, Codex, Gemini CLI |
실패 모드 | Fail-open; 에이전트 실행은 memex 없이도 계속됨 |
세분성 | 계층적 Leiden 클러스터를 통해 50~5000개 이상의 모듈로 확장 |
합성 | Gemini Flash가 커밋을 |
신뢰도 | 쿼리 시점에 계산. 두 영역 감쇠(검증된 반감기 ~139일, 검증되지 않은 것은 30일 후 오래된 것으로 간주) |
쓰기 거버넌스 | 노드 유형별 ACL, 에이전트 쓰기 시 의도 확인, 명시적 |
Goal 10 증거 | 8/8 유효한 짝지어진 실행, 치료 실패 0건, 치료 회귀 0건 |
flowchart TD
Init[memex init<br/>extract baseline] --> Watch[memex watch<br/>daemon + git hooks]
Watch -->|commit| Extract[tree-sitter extract<br/>symbols, imports, lockfile]
Extract --> Synth[Gemini Flash<br/>diff → Decision nodes]
Synth --> Write[Graphiti add_episode<br/>+ post-hoc bitemporal SET]
Write --> Decay[Scheduler<br/>nightly confidence decay]
Decay -->|stale edges| Archive[expired_at = now]
Serve[memex serve<br/>MCP stdio/HTTP] -.->|reads| Write
Agent[AI agent] -->|14 MCP tools| Serve
Serve -->|record_decision / record_problem| Write
Cluster[memex cluster<br/>Leiden over hybrid edges] -.->|every N commits| Write
style Init fill:#e8f4ff,color:#000
style Watch fill:#fff4cf,color:#000
style Synth fill:#ffe0cc,color:#000
style Serve fill:#d4f5d4,color:#00014개 도구 — 읽기 8개, 쓰기 4개, 분석 2개.
도구 | 사용 시점 |
| 세션 시작 시. 저장소 크기와 무관하게 1500토큰 미만의 클러스터 수준 브리핑 반환 |
| 함수나 클래스를 편집하기 전. 호출자, 피호출자, 연결된 결정 반환 |
| 최근 N일간의 아키텍처 결정, 선택적으로 모듈 범위 지정 가능 |
| 활성 버그와 기술 부채, 심각도순 정렬 |
| 하이브리드 검색: 의미론적 × 키워드 × 그래프 탐색 × RRF 병합 |
| 복합 신뢰도가 임계값 아래로 떨어진 엣지 |
| 커밋 SHA가 주어지면 diff를 연결된 Decision/Problem 노드와 교차 참조하고 Gemini Pro에 근거 기반 설명 요청 |
| 파일 경로가 주어지면 그래프 결합도를 기반으로 영향을 받을 가능성이 높은 모듈의 순위 목록 반환 (LLM 호출 없음) |
도구 | 사용 시점 |
| 기술적 선택을 한 후. |
| 버그나 기술 부채를 발견했을 때 |
| 추적 중인 문제가 해결되었을 때 |
| 저장된 사실이 더 이상 사실이 아닐 때 |
신뢰도는 변경되는 저장된 숫자가 아닙니다. base_confidence, 검증 상태, 마지막 강화 이후 경과 시간, 접근 횟수에서 쿼리 시점에 계산됩니다.
flowchart LR
Edge[Edge created<br/>base_confidence] --> Q{Validated by<br/>a human?}
Q -->|yes| Slow[Slow regime<br/>half-life ~139d]
Q -->|no| Fast[Fast regime<br/>stale at exactly 30d]
Slow --> Score[Composite score<br/>conf × recency × rehearsal]
Fast --> Score
Score -->|below floor| Stale[get_stale_context surfaces it]
Score -->|access| Bump[last_reinforced_at updated]
Bump --> Score
style Slow fill:#d4f5d4,color:#000
style Fast fill:#ffd4d4,color:#000속성 | 값 |
검증된 반감기 | ~139일 |
검증되지 않은 오래된 임계값 | 30일 (복합 < 0.3) |
최신성 τ | 90일 (지수 감쇠) |
복합 공식 |
|
충돌 유사도 임계값 | 0.4 (이 값 미만 + 유효성 겹침 = 충돌) |
의도 확인 임계값 | 0.85 (MCP 쓰기 유사도 검사) |
memex cluster는 하이브리드 엣지 그래프에 대해 계층적 Leiden을 실행합니다:
엣지 유형 | 가중치 |
디렉터리 동일 위치 | 1.0 |
모듈 임포트 | 2.0 |
심볼 호출 |
|
속성 | 값 |
알고리즘 | 고정 시드의 |
명명 | 모듈 docstring + 심볼 이름에 대한 TF-IDF 상위 3개, 상위 디렉터리 폴백 |
ID 고정 | 재실행 간 Jaccard ≥ 0.5 (클러스터 이름이 이름 변경에도 안정적으로 유지됨) |
사용자 재정의 |
|
컨텍스트 예산 | 저장소에 50개든 5000개든 모듈이 있어도 |
memex는 토큰 절감 지표와 인간 검토 작업을 로컬 SQLite 데이터베이스(~/.config/memex/telemetry.db)에 추적합니다.
CLI를 사용하여 언제든지 절감 효과를 조회할 수 있습니다:
memex stats또는 원시 JSON 페이로드 보기:
memex stats --json또는 특정 저장소 범위를 대상으로 지정:
memex stats --repo /path/to/repo이것은 다음의 집계를 반환합니다:
기간 요약: 호출 수, 반환된 토큰, 순수 토큰(요청된 파일 크기), 절감된 토큰, 오늘, 최근 7일, 최근 30일, 전체 기간에 걸친 토큰 절감 비율.
상위 도구: 절감된 총 토큰 기준으로 가장 가치 있는 도구.
에이전트 클라이언트: 활성 에이전트(Claude Code, Gemini CLI, Cursor, Codex) 및 토큰 절감 분포.
검증 상태: 검증된, 검증되지 않은, 확증된 노드의 총 수와 마지막 검토 이후 경과 일수.
동일한 통계는 HTTP MCP 전송을 통해서도 노출됩니다:
GET /stats?repo=/path/to/repo
Authorization: Bearer <your-key>위의 마켓플레이스 설치는 이 작업을 자동으로 수행합니다. .claude/settings.json에서 수동 연결:
{
"mcpServers": {
"memex": {
"type": "stdio",
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}~/.cursor/mcp.json에 추가:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}~/.gemini/settings.json에 추가:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}~/.codex/config.toml에 추가:
[mcp_servers.memex]
command = "npx"
args = ["-y", "stifler-memex-mcp", "serve", "--repo", "."]memex는 Claude의 네이티브 메모리 도구를 지원할 수 있습니다 — 에이전트는 세션별 그래프 프로젝션과 쓰기 가능한 스크래치 영역에서 읽습니다.
memex memory-tool serve --repo . # in-process
memex memory-tool serve --repo . --transport http # FastAPI on :7464from memex.memory_tool import MemexAsyncMemoryTool
memory_tool = MemexAsyncMemoryTool(repo_root=".")
client.beta.messages.run_tools(..., tools=[memory_tool])# | 원칙 | 핵심 약속 |
1 | 이중 시간 기반, 비파괴적 | 엣지는 삭제되지 않고 만료됩니다. |
2 | 신뢰도는 저장되지 않고 계산됩니다 | 숫자를 변경하면 조용한 드리프트가 발생합니다. 모든 읽기에서 다시 계산하세요 |
3 | 감쇠에 대한 두 가지 체제 | 검증된 사실은 천천히 감쇠하고, 검증되지 않은 사실은 접근을 통해 자리를 유지해야 합니다 |
4 | 인간 개입 |
|
5 | 쓰기 거버넌스 | 노드 유형별 ACL. |
6 | 토큰은 예산이 책정됩니다 |
|
7 | 합성은 커밋에서만 | 워처는 디바운스 창으로 일괄 처리합니다. Gemini Flash는 도구 호출의 핫 경로에 있지 않습니다 |
8 | 합성에는 Pro, 추출에는 Flash |
|
9 | 다중 저장소 인식 | 하나의 워처 + 하나의 MCP 서버로 수백 개의 저장소를 관리할 수 있습니다. |
10 | 로컬 우선 | Neo4j는 Docker에서 실행됩니다. Gemini는 유일한 외부 호출이며 커밋에서만 호출됩니다 |
사용해야 하는 경우 | 건너뛰어야 하는 경우 |
수 주 또는 수 개월 프로젝트 | 일회성 스크립트, 임시 프로토타입 |
여러 에이전트(Claude, Cursor, Codex)에서 작업하며 공유 컨텍스트를 원할 때 | 단일 에이전트와 단일 작업만 수행할 때 |
시간이 지남에 따라 아키텍처 결정이 내려지고 이를 기억해야 할 때 | 전체 프로젝트가 단일 200k 토큰 컨텍스트 창에 들어갈 때 |
어떤 세션에서든 "X에 대해 무엇을 결정했는지" 질의하고 싶을 때 | 저장소가 이미 프롬프트에 붙여넣을 수 있을 만큼 작을 때 |
여러 개발자가 동일한 코드베이스에서 AI 에이전트를 사용할 때 |
|
memex/
├── memex/
│ ├── extractor/ tree-sitter + lockfile parsers
│ ├── graph/ Neo4j writes, confidence, archive, cluster engine
│ ├── synthesizer/ Gemini Flash → Decision nodes
│ ├── mcp_server/ 14 MCP tools (read + write + analytic)
│ ├── memory_tool/ Anthropic memory_20250818 adapter
│ ├── watcher/ daemon + git hooks
│ └── cli.py init / watch / serve / review / graph / cluster
├── tests/ unit, integration, and objective evaluation suites
├── docker/ Neo4j compose
├── npm/ npx wrapper (publishes as stifler-memex-mcp)
└── Dockerfile introspection-only image for MCP directory sandboxes명령어 | 기능 |
| 기준 그래프 상태 추출, 첫 번째 클러스터 패스 실행 |
| 파일 + git 이벤트를 수신하고 Neo4j에 쓰는 데몬 |
| MCP 서버 실행 (stdio, HTTP 또는 둘 다) |
| 인간 검증을 위해 가장 낮은 신뢰도 결정을 탐색하는 TUI |
| 클러스터 오버레이가 포함된 자체 포함 D3 포스 레이아웃 |
| 하이브리드 엣지 그래프에서 Leiden 실행; Jaccard ≥ 0.5로 클러스터 ID 고정 |
| 그래프 프로젝션으로 Anthropic의 |
| 컨텍스트 토큰 절약 및 텔레메트리 통계 표시 |
MIT. LICENSE 참조.
Hill Patel (@STiFLeR7)
Hill Patel (@STiFLeR7) — 아키텍트, 관리자
Nirvaan Lagishetty (@Nirvaan05) — 주요 기여자, 관리자
이슈 또는 PR을 열어주세요. uv sync --all-extras가 개발 도구 체인을 설치합니다.
오프라인 스위트는 uv run pytest -m "not integration"으로 실행하고, PR을 열기 전에 uv run ruff check .를 실행하세요. 버전 업데이트는 pyproject.toml,
npm/package.json, server.json, 팀 Docker 이미지 태그를 함께 업데이트해야 합니다.
v0.9 릴리스 기록은 CHANGELOG.md에 있으며, 아키텍처 및
평가 증거는 docs/architecture/v0.9/에 있습니다.
Vannevar Bush, 1945: "개인용 미래 장치를 생각해 보십시오. 일종의 기계화된 개인 파일이자 도서관입니다. 이름이 필요하며, 임의로 하나를 만들자면 memex가 적당할 것입니다."
Cross-references a git commit's diff with linked Decision/Problem nodes and returns a grounded Markdown explanation synthesised by Gemini Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| commit_sha | Yes | The git commit SHA to explain (short or full). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the explanation is synthesized by Gemini Pro, indicating AI generation. It also implies a read-only operation, though not explicitly stated. No contradictions with annotations (none provided).
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, well-constructed sentence that conveys all essential information without wasted words. It is front-loaded with the core action and outcome.
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 simple two-parameter schema (both described) and no output schema, the description adequately covers what the tool does and returns. It does not mention error cases or prerequisites, but for a tool of this complexity, it is largely complete.
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%, so the schema already describes both parameters. The description adds 'cross-references a git commit's diff' which hints at the commit_sha usage, but it does not significantly augment the schema descriptions. 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 ('cross-references', 'returns'), the resource ('a git commit's diff with linked Decision/Problem nodes'), and the output ('grounded Markdown explanation'). This distinguishes it from sibling tools like get_open_problems or get_recent_decisions.
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 the tool is used to explain a git commit by linking to decisions/problems, but it does not explicitly state when to use it versus alternatives or when not to use it. The sibling tools provide some differentiation, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ranked, token-capped briefing of the most important context for this codebase. Use this at the START of a session to efficiently prime your understanding without overloading your context window. The briefing includes cluster summaries, recent high-confidence decisions, and active problems.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository path (uses default if omitted) | |
| scope | No | Optional module/directory scope to focus the briefing | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| max_tokens | No | Maximum token budget for the briefing (default: 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the briefing includes 'cluster summaries, recent high-confidence decisions, and active problems', but omits details on ranking logic, token-capping behavior (e.g., truncation), or any side effects. The description provides some behavior but not comprehensive 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 three sentences, efficiently front-loaded with the main action and purpose. No superfluous words; every sentence provides essential information (what, when, what includes). Excellent conciseness and 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 4 parameters and no output schema, the description covers primary use and content but lacks details on return format, edge cases (e.g., empty context), and token-capping behavior. It is moderately complete but leaves gaps that an agent might need to infer.
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%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it clarifies the project parameter as an alternative to repo, but does not elaborate on format or usage details for scope or max_tokens. The description adds marginal value, thus score 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 the tool returns a ranked, token-capped briefing of important context, specifying the verb and resource. It distinguishes from siblings by recommending use at session start and listing included content types (cluster summaries, decisions, problems), differentiating from tools like get_recent_decisions or get_open_problems.
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?
Explicitly says 'Use this at the START of a session to efficiently prime your understanding', providing clear usage context. It does not explicitly state when not to use or mention alternatives, but the sibling tools imply specialization, so the guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a bounded, provenance-aware engineering ContextPacket projection using the shared memex selector.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository path to scope results. | |
| query | Yes | The engineering task or question to contextualize. | |
| top_k | No | Maximum number of context items (1-8, default: 8). | |
| project | No | Project ID to scope results. | |
| task_id | No | Optional engineering task identifier for traceability. | |
| session_id | No | Optional execution session identifier for traceability. | |
| allow_historical | No | Include explicitly superseded historical knowledge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'bounded' and 'provenance-aware,' but does not explain what bounds are applied (e.g., share of results, time window), what provenance means for the caller, or any side effects (though likely read-only). It also fails to mention how historical data is handled despite an allow_historical parameter.
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 is front-loaded with jargon ('bounded', 'provenance-aware', 'shared memex selector') that obscures rather than clarifies. The sentence is short but not efficiently structured for an agent that needs to understand what the tool does and when to use it.
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 tool with 7 parameters, no output schema, and no annotations, the description is severely under-specified. It does not explain what the ContextPacket contains, how to interpret the results, what 'bounded' means in practice, or how parameters like top_k and allow_historical affect outcomes. An agent cannot reliably call this tool correctly based on the provided definition 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 seven parameters have schema descriptions providing baseline documentation, so the description does not need to explain them. However, it adds no extra guidance beyond the schema—for example, it does not clarify how 'query' should be phrased or how scope parameters (repo, project) interact. The description meets the minimum bar but does not enhance parameter understanding.
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 identifies a specific resource ('engineering ContextPacket projection') and a clear action ('Returns'), but it relies on opaque internal jargon like 'shared memex selector' and does not differentiate this tool from siblings such as search_context or get_project_context. An agent can infer it returns engineering context, but not how it differs from those alternatives.
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 given for when to use this tool versus its many siblings. It does not mention alternatives, exclusions, or any decision criteria such as 'use search_context when...' or 'use this for broader engineering context.' The agent is left to guess which of the 13 related tools to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns currently open technical problems and TODOs sorted by severity as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| module | No | Optional relative path to filter problems by module. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses read-only behavior and sorting but does not mention permissions, rate limits, or response format details beyond Markdown string.
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 front-loads purpose and is free of waste. However, it could benefit from slightly more structure 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?
For a simple tool with no required parameters and no output schema, the description covers the basic function but leaves open questions about result limits, pagination, and exact output structure.
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%, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as per guidelines.
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 open technical problems and TODOs as a Markdown string, sorted by severity. It uses a specific verb ('returns') and resource, and distinguishes from sibling tools like record_problem or resolve_problem.
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 retrieving problems but does not explicitly contrast with sibling tools like search_context or get_context_briefing. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a compressed briefing of the project as a Markdown string: active modules, recent decisions, and open problems.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| scope | No | Optional relative path to filter the briefing (e.g. 'src/auth'). | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only operation and describes the output format, but does not explicitly state read-only behavior, permissions, or side effects. Adequate but minimal.
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 output. No wasted words.
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 optional parameters and lack of output schema, the description adequately covers the returned components (active modules, recent decisions, open problems). It provides sufficient context for an agent to understand the tool's utility.
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%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema's own descriptions. Baseline score of 3 applies.
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 returns a compressed briefing of the project as a Markdown string, listing three components. However, it does not differentiate itself from the sibling tool 'get_context_briefing', which may have similar functionality.
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. Sibling tools like get_open_problems and get_recent_decisions exist for individual components, but the description does not hint at any use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns architectural and technical decisions from the past N days as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (default: 30). | |
| repo | No | Optional absolute path to the repository to scope results. | |
| module | No | Optional relative path to filter decisions by affected module. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
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 states the return format but omits critical details such as whether the tool requires a initialized repository, how it handles missing data, or performance characteristics. The description implies a read operation but does not explicitly confirm non-destructiveness or auth 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?
The description is a single sentence that is front-loaded with the core purpose. It has no unnecessary words and conveys exactly what the tool does.
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 4 optional parameters and no output schema, the description is somewhat minimal. While the parameter schema provides details, the description could elaborate on usage, such as the relationship between repo and project parameters or return formatting. It is adequate but has gaps for an agent to use effectively without schema inspection.
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%, so the schema already explains each parameter (days, repo, module, project). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 architectural and technical decisions from the past N days as a Markdown string. It uses a specific verb (returns) and resource (decisions), and its purpose is distinct from siblings like record_decision which is for recording, not retrieving.
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. The description does not specify prerequisites, use cases, or when not to use it. There is no mention of siblings or contrasting tools, leaving the agent to infer usage from purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns relationships that have decayed in confidence and may be outdated as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| threshold | No | Confidence threshold below which edges are considered stale (0.0-1.0, default: 0.5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the return format but does not explain whether the operation is read-only, whether it blocks, what happens with no stale relationships, or any side effects. This is insufficient for a tool that returns dynamic confidence-based data.
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, concise and front-loaded with the core purpose. However, it is arguably too terse - a second sentence about key usage details would improve without harming conciseness.
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 3 optional parameters, no output schema, and no annotations, the description is insufficiently complete. It does not clarify the Markdown output structure, pagination, or what 'stale' means operationally. Compared to siblings like 'get_context_briefing', it lacks necessary detail for correct invocation.
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 input schema already documents all 3 parameters with descriptions (100% coverage). The tool description adds no additional meaning or context for the parameters. Baseline 3 is appropriate since the schema covers the burden, but the description could clarify how 'repo' and 'project' interact or the interpretation of 'threshold'.
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 action ('returns'), the resource ('relationships that have decayed in confidence'), and the output format ('as a Markdown string'). It clearly distinguishes from siblings like 'get_context_briefing' that provide general context. However, 'may be outdated' is ambiguous - it could be more precise about the confidence decay mechanism.
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 'search_context' or 'invalidate_edge'. The description does not mention prerequisites, scenarios, or when not to use it. For a tool with many siblings, this omission leaves the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns detailed information about a specific function or class as a Markdown string including callers/callees.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Optional relative path to disambiguate symbols with the same name. | |
| repo | No | Optional absolute path to the repository to scope results. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| symbol_name | Yes | The name of the function or class to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the output format (Markdown with callers/callees). It does not disclose whether it is read-only, required permissions, side effects, or performance considerations.
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 clear sentence with no redundant words. It is front-loaded with the purpose and conveys the key information 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?
Given the schema fully describes parameters and the tool has no output schema, the description is reasonably complete. It could benefit from mentioning authentication or scope, but it adequately covers the main purpose and output format.
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 input schema has 100% coverage with clear descriptions for all four parameters. The description does not add additional meaning beyond the schema, but it connects to the output by mentioning callers/callees. 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 tool returns detailed information about a specific function or class, explicitly mentioning it includes callers/callees and output as Markdown. It distinguishes from siblings like 'search_context' which is broader in scope.
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 does not provide guidance on when to use this tool versus alternatives like 'search_context' or 'get_project_context'. There is no mention of prerequisites, exclusions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly invalidates a graph edge when it is discovered to be stale or incorrect. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| reason | Yes | The reason for invalidating this relationship. | |
| edge_id | Yes | The unique ID of the edge to invalidate. |
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 states it invalidates an edge and returns a status, but it does not explain what 'invalidate' entails (e.g., effects on queries, reversibility, side effects). The description is too brief for full 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 very concise with two sentences, no wasted words. However, it could be slightly more informative about behavior without being verbose.
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 mutation tool with 3 parameters and no output schema, the description covers the basic purpose and return type. However, it lacks details on when to use this vs. deletion, prerequisites, or implications, making it minimally adequate.
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 parameters are described in the schema (100% coverage), so the description does not add new meaning. The baseline score of 3 applies, as no extra parameter details are provided 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 clearly states the tool's action (invalidates a graph edge), the condition (stale or incorrect), and the return type (status string). It distinguishes well from sibling tools that focus on reading, explaining, or recording.
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 specifies when to use the tool ('when discovered to be stale or incorrect'), providing clear context. While it does not explicitly name alternatives, the condition implies a specific scenario that differs from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ranked Markdown list of modules likely affected by changes to a file, based on graph coupling (calls + imports + decision links). No LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| file_path | Yes | Relative path of the file whose change-impact you want predicted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the output format, algorithm basis (calls + imports + decision links), and lack of LLM call, but lacks details on prerequisites, edge cases, or performance 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?
Single sentence is clear and front-loaded with key information. Could be slightly more concise but does not waste words.
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?
No output schema, but description explains output format and algorithm. Missing details on what 'modules' means and ranking criteria, but sufficient for a simple tool. Reasonably complete given context.
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 has 100% description coverage for both parameters. Description adds no extra meaning beyond reinforcing that 'file_path' is the file to analyze and 'repo' is optional. 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 tool returns a ranked Markdown list of affected modules based on graph coupling. It specifies the verb 'returns', the resource 'modules', and the mechanism, distinguishing it from siblings like 'explain_change' or 'get_symbol_context'.
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 mentions 'No LLM call' implying fast deterministic output, but does not explicitly indicate when to use this tool over alternatives like 'explain_change' or 'get_symbol_context'. No usage scenarios or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Decision node in the graph. Call this when making or discovering architectural choices. Returns a status string. Phase 9: pass corroborates= to reinforce, supersedes= to replace, or force=true to bypass duplicate detection.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| text | Yes | The decision text (min 10 chars). Not required when only corroborating. | |
| force | No | Phase 9: skip intent-confirmation similarity check and always write a sibling decision. | |
| module | No | Optional relative path to the affected module. | |
| symbol | No | Optional name of the affected symbol. | |
| rationale | No | Optional reasoning behind the decision. | |
| supersedes | No | Phase 9: id of an existing Decision this one replaces. A new node is created with supersedes=<id> and the old node's outgoing edges are expired. | |
| corroborates | No | Phase 9: id of an existing Decision to reinforce. No new node is created; the existing node's last_reinforced_at is bumped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses creation behavior, return type (status string), and special Phase 9 behaviors (bumping, expiring edges, bypassing duplicate detection). No annotations provided, so description carries burden adequately.
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?
Three concise, well-structured sentences: purpose, context, and Phase 9 details. No wasted words.
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?
Covers key behaviors and Phase 9 use cases for 8 parameters without output schema. Could mention prerequisites or status values, but adequate for decision recording.
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?
Adds meaning beyond schema by explaining interplay of corroborates, supersedes, and force in Phase 9. However, description contradicts schema by stating text is not required when corroborating, while schema marks text as required.
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?
Clearly states it creates a Decision node in the graph and is for architectural choices. Distinguishes from sibling tools like record_problem by focusing on decisions.
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?
Provides explicit when-to-use ('when making or discovering architectural choices') and details Phase 9 options (corroborates, supersedes, force). Lacks explicit alternatives but context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Problem node in the graph. Call this when discovering bugs or technical debt. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| text | Yes | The problem description (min 10 chars). | |
| module | No | Optional relative path to the affected module. | |
| severity | No | Problem severity: critical, high, medium, low (default: medium). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions creation and return string but lacks detail on side effects, authentication needs, or rate limits. Adequate for a simple creation tool.
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-load purpose and usage; no redundant words. Highly 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?
Covers core purpose and return type, but lacks details about output format, duplicate handling, or validation constraints. Adequate but not comprehensive.
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% with each parameter documented. Description adds minimal extra value beyond schema, but 'Returns a status string' is useful. 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?
Explicitly states the action 'Creates a Problem node in the graph' and when to call it ('discovering bugs or technical debt'). Clearly distinguishes from siblings like resolve_problem.
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?
Provides clear guidance on when to use ('when discovering bugs or technical debt'), but does not explicitly mention when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a Problem as closed and records the resolution. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| problem_id | Yes | The unique ID or name of the problem node. | |
| resolution_text | Yes | Explanation of how the problem was resolved (min 10 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only notes it is a state-changing operation returning a status string. Lacks details on side effects, permissions, idempotency, or reversibility.
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, front-loaded sentence with 12 words, no redundancy or filler.
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?
Lacks usage context, behavioral details, and specific return value information. For a tool with 3 params and no annotations, more context is needed for effective use.
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 already describes all parameters, but description adds context that problem_id and resolution_text are for closing and recording resolution, offering limited added value over 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?
Description clearly states the action ('marks as closed and records resolution') on a specific resource ('Problem'), distinguishing from siblings like record_problem and get_open_problems.
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 provided on when to use this tool vs alternatives (e.g., record_problem for creating new problems, get_open_problems for listing). Agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic + keyword + graph traversal search across all node types. Use for broad discovery. Returns a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| query | Yes | The search query. | |
| top_k | No | Maximum number of results (1-20, default: 8). | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs multiple search methods and returns a Markdown string. It could add details about rate limits, performance characteristics, or side effects, but the provided information is adequate for understanding 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?
Two concise sentences: first clearly defines the tool's action and scope, second gives a usage hint and output format. No unnecessary words, perfectly front-loaded with key information.
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 annotations, no output schema, and 4 parameters with full schema coverage, the description adequately covers the tool's purpose, search methods, and return type. It could mention result format structure or limitations, but it is largely complete for a search 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 100%, so the schema already documents all parameters thoroughly. The description adds little beyond the schema, only mentioning the output type. Baseline 3 is appropriate as the description does not detract but does not enhance parameter understanding.
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 'semantic + keyword + graph traversal search across all node types', which is a specific verb+resource combo and distinguishes from sibling tools like 'get_symbol_context' or 'get_context_briefing' that focus on 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?
It says 'Use for broad discovery', providing clear context for when to use this tool over alternatives. However, it does not explicitly state when not to use it or name specific alternatives, which would be helpful for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are largely distinct: each getter targets a specific aspect (decisions, problems, project, symbol, stale context, engineering context), and write/action tools are clearly separate (record, resolve, invalidate, explain, predict). Minor overlap exists between get_project_context and get_context_briefing, both providing project summaries, but they differ in focus and usage timing.
All tool names follow a consistent verb_noun pattern in snake_case (get_recent_decisions, record_decision, resolve_problem, invalidate_edge, explain_change, predict_impact). The verb clearly indicates the action, and nouns describe the target resource, making the naming predictable and uniform.
14 tools is well within the expected range for a knowledge/context management server. Each tool addresses a distinct operation (retrieval, recording, mutations, analysis) without redundancy, and the count feels appropriate for the scope of the domain.
The surface covers key lifecycle operations: decision recording (with supersede/force), problem creation and resolution, edge invalidation, context retrieval via multiple projections, search, and analytical tools. Minor gaps include no explicit update tool for decisions or problems (though supersede covers decision updates), but agents can work around with existing tools.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/STiFLeR7/memex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
