The memex server provides AI coding agents with persistent, bitemporal graph-based memory of a codebase, enabling context-aware assistance across sessions and agents.
Read & Discovery
get_project_context / get_context_briefing — Get a compressed, token-budgeted briefing of active modules, recent decisions, and open problems
get_symbol_context — Look up detailed info about a specific function or class, including callers, callees, and linked decisions
get_recent_decisions — Retrieve architectural/technical decisions from the past N days, optionally filtered by module
get_open_problems — List active bugs and tech debt sorted by severity, optionally scoped to a module
search_context — Run hybrid semantic + keyword + graph traversal search across all node types
get_stale_context — Surface relationships whose confidence has decayed and may be outdated
Analysis & Impact
explain_change — Cross-reference a git commit diff with linked Decision/Problem nodes to generate a grounded explanation
predict_impact — Get a ranked list of modules likely affected by changes to a given file, based on graph coupling (no LLM call)
Write & Governance
record_decision — Create a Decision node for an architectural choice; supports corroboration, supersession, and duplicate-bypass
record_problem — Log a bug or tech debt as a Problem node with a severity level (critical/high/medium/low)
resolve_problem — Mark a tracked problem as closed with a resolution explanation
invalidate_edge — Explicitly expire a graph edge when a stored fact is no longer true
Serves as the storage backend for the temporal knowledge graph, enabling bitemporal fact management with confidence decay and hierarchical clustering of repository modules.
A protocol-neutral engineering-context layer for AI coding agents. memex builds a bitemporal knowledge graph of your repository — modules, symbols, decisions, problems, evidence, and code evolution — and exposes bounded, provenance-aware context through Hermes MemoryProvider or MCP.
A daemon and MCP server that turns commits and file changes into structured engineering knowledge. Agents can receive relevant repository context before a task, with freshness and provenance preserved, without making memex a source of personal memory or raw session state.
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-marketplaceRestart your Claude Code session.
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 .The v0.9 Hermes integration is read-only. Hermes retains personal memory, raw
session state, and execution state. memex supplies repository engineering
context through a bounded ContextPacket; it does not ingest Hermes
state.db, transcripts, prompts, or tool results.
Add the memex provider to Hermes' profile configuration:
memory:
provider: memex
plugins:
memex:
repo_path: /absolute/path/to/repository
prefetch_timeout_seconds: 7
max_items: 8
max_chars: 12000If Hermes is not installed, use the same context selector through the MCP
get_engineering_context tool. Both paths share the protocol-neutral memex
core and fail open when retrieval is unavailable.
Channel | Command |
Claude Code marketplace |
|
npx (no install) |
|
uv |
|
pip |
|
source |
|
For a shared team setup (one Neo4j + one memex-server, auth on by default, Neo4j's ports never exposed to the host):
bash docker/bootstrap-team-env.sh
docker compose -f docker/docker-compose.team.yml up -dSee docker/TEAM-DEPLOY.md for the full flow, capturing the
initial admin key, and the down -v footgun to avoid.
Related MCP server: memtrace
Property | Value |
Output | A Neo4j graph populated continuously from your repo |
Storage | Neo4j via Graphiti. Bitemporal — every edge has |
Context | Bounded, ranked, provenance-aware |
Integrations | Hermes MemoryProvider, MCP resources/tools, Claude Code, Cursor, Codex, Gemini CLI |
Failure mode | Fail-open; agent execution continues without memex |
Granularity | Scales from 50 to 5000+ modules via hierarchical Leiden clusters |
Synthesis | Gemini Flash distills commits into |
Confidence | Computed at query time. Two-regime decay (validated half-life ~139d, unvalidated stale at 30d) |
Write governance | Per-node-type ACL, intent-confirmation on agent writes, explicit |
Goal 10 evidence | 8/8 valid paired runs, 0 treatment failures, 0 treatment regressions |
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 tools — eight read, four write, two analytic.
Tool | When |
| Session start. Returns a cluster-level briefing under 1500 tokens regardless of repo size |
| Before editing a function or class. Returns callers, callees, linked decisions |
| Last N days of architectural decisions, optionally module-scoped |
| Active bugs and tech debt, sorted by severity |
| Hybrid search: semantic × keyword × graph traversal × RRF merge |
| Edges whose composite confidence dropped below threshold |
| Given a commit SHA, cross-references the diff with linked Decision/Problem nodes and asks Gemini Pro for a grounded explanation |
| Given a file path, returns a ranked list of modules likely affected based on graph coupling (no LLM call) |
Tool | When |
| After making a technical choice. Supports |
| When discovering a bug or piece of tech debt |
| When a tracked problem is fixed |
| When a stored fact is no longer true |
Confidence is not a stored number that mutates. It is computed at query time from base_confidence, validation status, time since last reinforcement, and access count.
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:#000Property | Value |
Validated half-life | ~139 days |
Unvalidated stale threshold | 30 days (composite < 0.3) |
Recency τ | 90 days (exponential decay) |
Composite formula |
|
Conflict similarity threshold | 0.4 (below this + overlapping validity = conflict) |
Intent-confirmation threshold | 0.85 (MCP write similarity check) |
memex cluster runs hierarchical Leiden over a hybrid edge graph:
Edge type | Weight |
Directory co-location | 1.0 |
Module imports | 2.0 |
Symbol calls |
|
Property | Value |
Algorithm |
|
Naming | TF-IDF top-3 over module docstrings + symbol names, parent-dir fallback |
ID pinning | Jaccard ≥ 0.5 across reruns (cluster names stay stable through renames) |
User overrides |
|
Context budget |
|
memex tracks token reduction metrics and human review actions locally in a SQLite database (~/.config/memex/telemetry.db).
You can query your savings at any time using the CLI:
memex statsOr view the raw JSON payload:
memex stats --jsonOr target a specific repository scope:
memex stats --repo /path/to/repoThis returns an aggregation of:
Period Summaries: Calls, tokens returned, naive tokens (size of files requested), tokens saved, and token reduction percentage across today, last 7 days, last 30 days, and lifetime.
Top Tools: The most valuable tools sorted by total tokens saved.
Agent Clients: Active agents (Claude Code, Gemini CLI, Cursor, Codex) and their token saving distribution.
Validation Health: Total validated, unvalidated, and corroborated nodes, along with the elapsed days since the last review.
The same statistics are exposed via the HTTP MCP transport:
GET /stats?repo=/path/to/repo
Authorization: Bearer <your-key>Marketplace install above does this for you. Manual wiring in .claude/settings.json:
{
"mcpServers": {
"memex": {
"type": "stdio",
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Add to ~/.gemini/settings.json:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Add to ~/.codex/config.toml:
[mcp_servers.memex]
command = "npx"
args = ["-y", "stifler-memex-mcp", "serve", "--repo", "."]memex can back Claude's native memory tool — agents read from a per-session graph projection plus a writable scratch zone.
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])# | Principle | The bet |
1 | Bitemporal, never destructive | Edges are expired, not deleted. |
2 | Confidence is computed, not stored | Mutating a number invites silent drift. Recompute every read |
3 | Two regimes for decay | Validated facts decay slowly; unvalidated facts must earn their place by being accessed |
4 | Human in the loop |
|
5 | Write governance | Per-node-type ACL. |
6 | Tokens are budgeted |
|
7 | Synthesis only on commits | The watcher batches by debounce window. Gemini Flash is not in the hot path of a tool call |
8 | Pro for synthesis, Flash for extraction |
|
9 | Multi-repo aware | One watcher + one MCP server can manage hundreds of repos. |
10 | Local-first | Neo4j runs in your Docker. Gemini is the only outbound call, and only on commits |
Use it when | Skip it when |
Multi-week or multi-month project | One-shot script, throwaway prototype |
You work across multiple agents (Claude, Cursor, Codex) and want shared context | You only ever pair with one agent on one task |
Architectural decisions are made over time and need to be remembered | The whole project fits in a single 200k-token context window |
You want to query "what did we decide about X" from any session | Your repo is already small enough to paste into the prompt |
Multiple developers using AI agents on the same codebase | Solo work where you never |
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 sandboxesCommand | What it does |
| Extract baseline graph state, run first cluster pass |
| Daemon that listens for file + git events and writes to Neo4j |
| Run the MCP server (stdio, HTTP, or both) |
| TUI that walks lowest-confidence decisions for human validation |
| Self-contained D3 force layout with cluster overlays |
| Run Leiden over the hybrid edge graph; pin cluster IDs by Jaccard ≥ 0.5 |
| Back Anthropic's |
| Show context token savings and telemetry stats |
MIT. See LICENSE.
Hill Patel (@STiFLeR7)
Hill Patel (@STiFLeR7) — architect, maintainer
Nirvaan Lagishetty (@Nirvaan05) — lead contributor, maintainer
Open an issue or PR. uv sync --all-extras installs the development toolchain.
Run uv run pytest -m "not integration" for the offline suite and uv run ruff check . before opening a PR. Version bumps must update pyproject.toml,
npm/package.json, server.json, and the team Docker image tag together.
The v0.9 release record is in CHANGELOG.md, with the
architecture and evaluation evidence under docs/architecture/v0.9/.
Vannevar Bush, 1945: "Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and to coin one at random, memex will do."
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
