Jambavan is a Model Context Protocol (MCP) server that gives AI coding models live codebase awareness, durable memory, and surgical editing tools — without making any external LLM calls.
Session Initialization (jambavan_awaken): Bootstrap a session by loading the operating protocol and recent project memories in one call.
Code Indexing & Context (jambavan_index, jambavan_watch, jambavan_context, jambavan_diagnostics): Build and incrementally update an AST-aware SQLite index using tree-sitter parsers. Retrieve ranked, token-budgeted snippets relevant to a query (~44–87% fewer tokens than reading full files). Watch files for incremental re-indexing.
Code Graph (jambavan_graph_report, jambavan_graph_query, jambavan_graph_path): Build a lightweight inferred graph of callers, callees, imports, and mentions. Query for neighbors via BFS or find the shortest path between two symbols.
Durable Memory (jambavan_memory_store/search/recall/mine_session/invalidate/delete/status): Store decisions and facts as human-readable markdown with YAML frontmatter. BM25 full-text search, session transcript mining, and memory invalidation — no external database or embeddings needed.
Token Compression (jambavan_sankshipta): Deterministically compress prose/prompts while preserving code, paths, and versions verbatim. Can write back in-place with a backup.
Efficient-Dev Discipline (jambavan_vibhishana_niti, jambavan_rin_mochan): Activate YAGNI-first, minimal-diff coding rules at configurable intensity levels (lite/full/ultra). Audit // rin: technical debt markers into a structured ledger.
File & Shell Tools (read_file, search, list_files, write_file, patch_file, bash): Read files (with optional line ranges), regex search via ripgrep, and list directories — always available, confined to the project root. Write/patch files and run sandboxed shell commands are opt-in via JAMBAVAN_ALLOW_WRITE=1 and JAMBAVAN_ALLOW_BASH=1. Secret-looking files (.env, *.pem, etc.) are blocked by default.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jambavan awaken and load project memories"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Jambavan is a local-first Model Context Protocol server. It gives coding agents persistent, repository-aware context: an AST-backed symbol index, durable project decisions, a ledger of dead ends already tried, and branch review context.
No LLM calls. No telemetry. No code upload. Source-mutating and shell tools are off unless you turn them on.
claude mcp add jambavan -- npx -y jambavanRestart or reload the MCP host after registration. Then call the active MCP server in this order:
jambavan_doctor {}If it reports source: cwd-fallback, bind the repository and awaken in one call:
jambavan_awaken { "root": "/absolute/path/to/repository" }Otherwise awaken without a root:
jambavan_awaken {}After either awaken call, index, watch, and request useful context:
jambavan_index {}
jambavan_watch { "action": "start" }
jambavan_context { "query": "buildReviewPack" }The root-bearing jambavan_awaken call already performs the awaken step, so do not call it twice. A tool-input root can later be re-pointed to another repository inside the original fallback directory; roots fixed by JAMBAVAN_ROOT, MCP roots/list, or a project cwd cannot be re-pointed.
jambavan_doctor above inspects the active MCP process, including its resolved root, tool count, loaded index, and watcher. npx jambavan doctor is a separate, short-lived shell process: it is useful for launch-environment and parser checks, but it cannot report the active MCP server's in-memory index or watcher.
Related MCP server: reflens
Jambavan uses stdio MCP, so the same npx -y jambavan command works with any compatible host. Documented setup paths are:
Host | Registration |
Claude Code |
|
Codex CLI |
|
Cursor |
|
Continue |
|
Other stdio MCP clients | command |
The index supports TypeScript, TSX, JavaScript, JSX, Python, Go, Rust, and Java. Supported extensions are .ts, .tsx, .mts, .cts, .js, .jsx, .mjs, .py, .go, .rs, and .java.
This historical aggregate was produced with Jambavan v2.0.0 against react/react at commit 9ceb1e7: 4,615 files, 20,595 symbols, Node 24 on macOS arm64.
Result | |
Context tokens vs reading every matching file | 9,207 instead of 261,816 — 96% less |
Cold index | 8.5 s (552 files/s) |
Unchanged re-index | 1.2 s (7.2x faster) |
Context retrieval | 1.2–3.6 ms per query |
Tool schema your host pays for every request | 20 tools, 3,423 tokens (down from 38 tools / 5,680 in 1.x) |
Re-run the same pinned methodology from a clean temporary directory:
WORKDIR="$(mktemp -d)"
git clone --branch v2.0.0 --depth 1 https://github.com/beingmartinbmc/jambavan.git "$WORKDIR/jambavan"
git init "$WORKDIR/react"
git -C "$WORKDIR/react" remote add origin https://github.com/react/react.git
git -C "$WORKDIR/react" fetch --depth 1 origin 9ceb1e7
git -C "$WORKDIR/react" checkout --detach FETCH_HEAD
cd "$WORKDIR/jambavan"
npm ci
npm run build
JAMBAVAN_ROOT="$WORKDIR/react" node dist/benchmark.jsThis re-runs the code and inputs; it does not recreate the original machine or timing conditions, so exact timings can differ. The historical aggregate says five auto-derived queries, but only four per-query rows survive in the React proof card. Those four rows do not sum to the aggregate, and the missing raw row is not reconstructed. The surviving rows still show the non-uniform result: one saved 99%, another only 42% because its matches lived in tiny fixture files. This is a retrieval benchmark; it measures token cost and latency, not task correctness.
Without an index or saved memory, rediscovering a project costs work proportional to the area searched: O(n) files opened, every session, forever. Jambavan persists that work. Index refresh still discovers and hashes candidate files in O(n files), but reparses only files whose content changed.
In the Ramayana, before Hanuman's leap to Lanka, Jambavan reminds him of the strength he already possesses. This project borrows that metaphor narrowly: it restores access to knowledge that was already indexed or stored. It does not make a model smarter.
The remaining Sanskrit names are descriptive: mool kaaran means root cause, praman means evidence, yukti means strategy, vibhaajan means decomposition, Vibhishana Niti means disciplined counsel or rules, rin mochan means debt release, and sankshipta means concise or compressed.
The installers attempt to register Jambavan only for hosts they can detect. Claude Code and Codex use their CLIs; Cursor requires an existing ~/.cursor directory and valid JSON if the config already exists. Continue requires an existing ~/.continue directory; the installer creates config.yaml only when it is absent and otherwise prints an entry for you to merge. A detected host can still reject registration, so review the installer result.
On macOS, Linux, WSL, or Git Bash:
curl -fsSL https://raw.githubusercontent.com/beingmartinbmc/jambavan/main/install.sh | bashOn Windows, in PowerShell 5.1+:
irm https://raw.githubusercontent.com/beingmartinbmc/jambavan/main/install.ps1 | iexNeeds Node >=20.19.0 <27. The scripts are designed to skip undetected hosts and preserve unrelated MCP entries, but registration remains conditional on each host and existing config being usable. As with any internet shell script, read it before piping it into a shell.
Same MCP command everywhere: npx -y jambavan.
Host | Setup |
Claude Code |
|
Codex CLI |
|
Cursor | add to |
Continue | add to |
Any MCP client | command: |
Cursor (~/.cursor/mcp.json global, or .cursor/mcp.json per project)
{
"mcpServers": {
"jambavan": { "command": "npx", "args": ["-y", "jambavan"] }
}
}Continue (~/.continue/config.yaml)
name: Local config
version: 1.0.0
schema: v1
mcpServers:
- name: Jambavan
command: npx
args:
- -y
- jambavanRestart or reload the host after any config change, then follow the 60-second quick start, beginning with the MCP jambavan_doctor. Continue exposes MCP tools only in Agent mode.
Check installed and published versions:
npx jambavan --version
npm view jambavan versionTo uninstall, run claude mcp remove jambavan or codex mcp remove jambavan; for Cursor and Continue, delete the jambavan entry. Repository indexes under <repo>/.jambavan/ and memory/failure documents under ~/.jambavan/memory/ are left intact.
Jambavan advertises 20 tools by default. JAMBAVAN_ALLOW_WRITE=1 adds write_file, patch_file, and jambavan_compress_prompt for 23; JAMBAVAN_ALLOW_BASH=1 adds bash for 21; enabling both advertises up to 24. Every advertised tool costs your host model tokens on every request whether or not it is called, so the default surface stays small.
Group | Tools | What the agent gets |
Sight |
| AST-backed symbol index, token-budgeted context with bounded extracted call neighbors, optional heuristic test references and recent diff, live watching, and root health. |
Bridge |
| Code-graph report, query, and shortest path in one tool, plus changed-symbol inbound impact and heuristic test-file associations. |
Memory |
| Rootless local Markdown memory, logical collections, and explicit read-only MemPalace federation. |
Failure memory |
| Structured failure records plus an exact-command repeat guard in the opt-in |
Review |
| Bounded branch review context: touched symbols, extracted caller candidates, heuristic test references, |
Debt |
| Harvests every deliberate-shortcut |
Compression |
| Deterministic prose shortening with protected spans for code, URLs, paths, versions, and env vars. Write-gated. |
Awakening |
| Session protocol: what exists, when to use it, and this project's recent memories. |
Hands |
| Guarded project-root file, search, and shell tools. Mutating and shell tools are disabled unless enabled. |
The discipline protocols are static text with no repository access, so they ship as MCP prompts rather than tools — they cost nothing per request and appear as slash commands in hosts that support them.
Prompt | Use it |
| Before debugging. Enforces observe → compare → hypothesize → fix; escalates at 3+ failed attempts. |
| Before claiming tests pass, a build succeeds, or a bug is fixed. Demands fresh evidence. |
| Before multi-step work. Scales the plan to task size. |
| When sub-units are genuinely independent. |
| Vibhishana Niti: YAGNI first, stdlib before dependencies, shortest working diff. |
Restart or reload the host after registration or config changes.
jambavan_doctor {} to inspect the active MCP root, gates, storage, index, and watcher.
If the source is cwd-fallback, call jambavan_awaken { "root": "/absolute/path/to/repository" }; otherwise call jambavan_awaken {}.
jambavan_index {} then jambavan_watch { "action": "start" }.
jambavan_context { "query": "<identifier or focused question>" } before touching unfamiliar code.
root_cause / verify_gate / strategy_plan when debugging, claiming completion, or planning.
Run the smallest relevant check.
jambavan_memory_store { "title": "...", "body": "...", "collection": "decisions" } to persist durable context.
jambavan_failure_store to record dead ends with root cause and do-not-retry advice.
jambavan_session_handoff {} to hand off; pass text to import one back.
jambavan_context returns focused spans instead of whole files. This is an illustrative output shape, not captured output from the current repository:
# Jambavan Context: "review pack"
Symbols: 12 included, 18 dropped (budget: 8000 tokens)
## src/tools/review-pack.ts: buildReviewPack
kind: function · score: 0.92
Uses git diff to list touched files, maps symbols from the index, adds callers via graph,
heuristic test references via test-map, and risk flags for rin debt / missing tests / failures.jambavan_review_pack { "base": "main" } turns a branch into reviewer-oriented context. This example is illustrative:
# Jambavan Review Pack
Base: main
Touched files: src/mcp/server.ts, src/mcp/tool-aliases.ts
src/mcp/server.ts
- touched symbols: startServer, handleToolCall
- callers: dist/index.js -> startServer
- heuristic test references: test/tool-aliases.test.ts
- risk flags: write-gated tool alias; verify disabled-tool listingjambavan_failure_search { "query": "timeout" } surfaces a prior dead end before another retry. This example is illustrative:
FailureRecord: flaky auth test timeout
Root cause: unawaited promise in token refresh mock.
Do not retry: increasing the test timeout; it hid the race.
Next check: run the focused auth test with fake timers enabled.Code indexes and caches stay in the active repository's .jambavan/; memory and failure documents live in ~/.jambavan/memory by default. Both generated-state roots get a nested .gitignore with *. These operational writes still happen when source mutation is disabled.
Source-mutating and shell tools are not advertised unless you opt in:
Tool(s) | Enable with |
|
|
|
|
Direct path arguments to file, search, and list tools, plus the bash working directory, are confined to JAMBAVAN_ROOT or the detected project root. The same guard refuses known secret-file basenames, extensions, and immediate parent directories unless JAMBAVAN_ALLOW_SECRETS=1. This is a direct-path guard, not content scanning, and it does not stop an enabled shell command from reading files.
bash uses a minimal no-color environment and blocks a few obvious footguns such as rm -rf /, git reset --hard, git clean -fx, and blind curl | sh. It redacts and stores failed-command records locally; once the same unresolved command fails unchanged again, a do-not-retry record can block another exact retry unless retry_known_failure=true. These checks are not a security boundary. Treat the tool like a local shell and sandbox the workspace if you need isolation.
MemPalace is never contacted during ordinary recall, context enrichment, or awakening — only when a memory read explicitly sets provider. See memory docs.
Env var | Default | Description |
| auto-detect | Project root to index and serve |
| Git-derived | Validated clone-independent scope override |
|
| Override for the root-independent OKF archive |
|
| Executable for explicit read-only MemPalace calls |
|
| Max approximate |
|
| Default |
| off | Registers |
| off | Registers |
| off | Disables direct-path project-root containment |
| off | Allows direct paths matching the secret-file guard |
| off | Passes full host env to |
|
| Global cap on tool output |
|
| Max file size |
2.0 renamed the Sanskrit tool names to English and merged near-duplicate tools, cutting the advertised surface from 38 tools to 20 and the tools/list schema your host pays for on every request from 5,680 tokens to 3,423. Every old name still works — retired names are resolved internally, they are just no longer advertised, and tool-check fails the build if any of them stops dispatching.
Was | Now |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This repo is also a Claude Code plugin marketplace:
/plugin marketplace add beingmartinbmc/jambavan
/plugin install jambavan@jambavanHost setup: Claude Code · Cursor · Codex CLI · Continue
Read CONTRIBUTING.md before proposing a change. Use the issue forms for bugs and focused feature requests, and report vulnerabilities privately through SECURITY.md.
npm run docs-check && npm run lint && npm test && npm run coverageReturn the Jambavan operating protocol: recall memory, index/watch code, retrieve context before edits, patch surgically, run checks, and store durable decisions. Call once at the start of every host session. Includes recent project memories by default.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Existing absolute directory inside the current fallback root. Re-points a previous tool-input root (needed by hosts that share one server across workspaces); cannot override an env, client-roots, or cwd-project binding. | |
| include_memories | No | Include recent memories for this project scope (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool returns a protocol and includes recent project memories, implying a read-only operation. However, it does not explicitly disclose whether the tool has side effects, permissions required, or any destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with purpose, and every sentence adds value. No redundant or filler content.
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?
Despite no output schema, the description explains what the tool returns (operating protocol and included memories). The list of components aligns with sibling tool names, aiding agent understanding. A minor gap is the lack of explicit return structure or 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?
Schema coverage is 100% and both parameters are described in the schema. The description adds no semantics beyond the schema, confirming the default for include_memories. Per guidelines, a baseline of 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 that the tool returns the Jambavan operating protocol and specifies its components (recall memory, index/watch code, etc.). It distinguishes itself from sibling tools by serving as an initialization call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Call once at the start of every host session,' providing clear when-to-use guidance. However, it does not mention when not to use or suggest alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Jambavan index for code symbols and snippets most relevant to a query. Returns a ranked, token-budgeted context block of matching functions, classes, and types. Inject this block into your prompt to give the model precise, token-efficient codebase knowledge. Much cheaper than reading whole files — only the relevant symbol bodies are returned. Automatically includes top project-memory matches and a bounded set of extracted callers/callees under the same token budget. Options: compress_prose shrinks comments for extra budget; include_diff adds recent git changes; include_tests shows heuristic test associations/references, not execution coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max lexical symbols before token-budget truncation; up to 6 extracted structural neighbors may be added (default: 30) | |
| query | Yes | Natural-language or identifier query — e.g. "auth middleware", "UserService.login" | |
| include_diff | No | Include recent git changes for each symbol (default: false) | |
| include_tests | No | Include associated test file info for each symbol (default: false) | |
| compress_prose | No | Compress comments/docstrings in results for more symbol density (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: returns ranked/token-budgeted context, automatically includes project-memory matches and bounded callers/callees, and clarifies that include_tests shows 'heuristic test associations/references, not execution coverage.' It also explains the effect of each option.
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-organized paragraph that front-loads the primary action, then covers output, usage advantage, automatic behaviors, and options. Every sentence earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description provides comprehensive coverage: purpose, return type (context block), usage directive, cost comparison, automatic inclusion behavior, and option distinctions. It gives an agent enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds meaning by explaining the automatic inclusion of callers/callees under the same token budget, which informs the behavior of the 'limit' parameter. It also summarizes each boolean option, providing contextual understanding 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 function with a specific verb and resource: 'Search the Jambavan index for code symbols and snippets most relevant to a query.' It distinguishes itself from siblings by focusing on producing a token-budgeted context block for injection, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear usage context: 'Inject this block into your prompt' and emphasizes cost efficiency over 'reading whole files.' However, it does not explicitly name alternative tools or provide when-not-to-use scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Harvest every rin marker (lines marked with a ceiling and upgrade path) from the project into a debt ledger. Groups findings by file and flags any marker with no upgrade trigger — those are the ones that silently rot. Read-only. Call before a release or refactor sprint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses read-only behavior and explains the process (scan, group, flag). It does not cover auth needs or rate limits, but the tool is simple and read-only, so the transparency is good.
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 sentences, front-loaded with the primary action. 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?
For a zero-parameter tool with no output schema, the description is complete: it explains the purpose, grouping, flagging, read-only nature, and use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description does not add parameter details, but none are needed. Baseline for 0 parameters is 4.
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 harvests 'rin markers' from the project into a debt ledger, groups by file, and flags untriggered markers. The verb 'harvest' and resource 'rin marker' are specific, distinguishing it from siblings like read_file or jambavan_index.
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 'Call before a release or refactor sprint,' providing clear context. Does not mention when not to use or alternatives, but the sibling tools suggest this is specialized, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot environment health check: root detection source, tree-sitter vs regex parser backends, write/bash tool gates, token budget, memory dir writability, .gitignore/CI presence, and index/watcher status. Call this first when something feels off (e.g. context results look like the wrong project) — it catches the most common cause: the MCP host resolving the wrong project root.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_report | No | Return a copy-ready redacted GitHub issue URL/body without posting it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what the tool checks but does not disclose whether it is read-only, any side effects, required permissions, or output format. It only mentions the optional parameter but not the return structure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the specific checks and then providing usage guidance. No unnecessary words; every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists what the tool checks but does not explain the output format, return values, or error conditions. Since there is no output schema, this is a gap. The optional parameter 'issue_report' is mentioned in schema but not in description, leaving ambiguity about output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage (100%) for the single parameter 'issue_report', with a clear description. The description adds no additional parameter information, so a baseline of 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 explicitly states it performs a 'one-shot environment health check' and lists specific items checked (root detection, parser backends, gates, token budget, etc.). This clearly distinguishes it from sibling tools like jambavan_index, jambavan_context, etc., which have more specific 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 provides explicit guidance: 'Call this first when something feels off (e.g. context results look like the wrong project).' This gives clear context but does not explicitly mention when not to use it or list alternatives, though the purpose implies it's a diagnostic first step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search past failure records for a command, error, or symptom. Call BEFORE retrying a failing command to check if it was already diagnosed. Returns structured failure records with status and resolution info.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 5). | |
| query | Yes | Command name, error text, or symptom to search for. | |
| scope | No | Restrict to this scope. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only search by stating 'Search past failure records' and mentions the return type ('structured failure records with status and resolution info'). However, it does not disclose details like search semantics (case sensitivity, real-time vs cached), authentication needs, or rate limits. More specific behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, each serving a distinct purpose: first introduces the tool's function, second provides a usage guideline. No excessive words, and the key information is front-loaded.
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 3 parameters with full schema description and no output schema, the description provides adequate context for usage. It explains the purpose and return type ('structured failure records with status and resolution info'). However, it could clarify the scope parameter's meaning in context (e.g., what scopes are typical) and whether the search is across sessions.
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 extra meaning beyond the schema; it simply restates the query purpose ('command, error, or symptom') without elaborating on 'limit' or 'scope' behavior.
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 (search), resource (past failure records), and scope (command, error, or symptom). It also provides a usage context ('Call BEFORE retrying a failing command'), which helps distinguish it from siblings like jambavan_failure_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Call BEFORE retrying a failing command to check if it was already diagnosed'). It does not list alternatives or when not to use, but the given scenario is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a structured failure record in the memory palace. Use after a command/approach fails to prevent repeating the same mistake in future sessions. Stores: command, symptom, attempted fix, root cause, resolution, status, and advice on what NOT to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Memory scope / project name. Defaults to project scope derived from project root. | |
| status | No | Current status. Default: unresolved. | |
| command | Yes | The command or action that failed. | |
| symptom | Yes | What went wrong (error message, behavior). | |
| next_path | No | Suggested next approach if unresolved. | |
| resolution | No | What actually fixed it (if resolved). | |
| root_cause | No | Why it failed (if known). | |
| do_not_retry | No | What specifically should NOT be tried again. | |
| attempted_fix | No | What was tried to fix it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists stored fields but does not mention idempotency, overwrite behavior, or authorization requirements. This is adequate but not thorough for a mutation 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?
The description is two sentences, front-loading the purpose and listing fields efficiently. There is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 2 required, and no output schema, the description covers the purpose and fields. It lacks details on return values or error handling, which would be helpful for completeness, but the description is still functional.
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 descriptions for all 9 parameters. The description enumerates the fields but adds minimal new meaning beyond the schema, consistent with baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'store a structured failure record' with a specific verb and resource. It distinguishes from siblings like jambavan_failure_search by focusing on storage after failure.
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 says 'use after a command/approach fails to prevent repeating the same mistake', providing clear usage context. It lacks explicit when-not-to-use or comparison to similar store tools, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate the code graph built from the current index. Call jambavan_index first. action=report lists hub nodes and edge-confidence notes; action=query finds matching nodes and their BFS neighbors; action=path finds the shortest route between two symbols. Action is inferred from the arguments when omitted. Ambiguous same-name edges are excluded unless include_inferred=true.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | action=path: end symbol/file. | |
| from | No | action=path: start symbol/file. | |
| query | No | action=query: symbol/file text to find. | |
| action | No | Inferred from arguments when omitted. | |
| budget | No | action=query: max output tokens (default: 2000). | |
| direction | No | action=query: traverse callers, callees, or both (default: both). | |
| max_nodes | No | action=report: max hub nodes (default: 10). | |
| symbol_limit | No | Max indexed symbols to graph (default: 5000; higher costs more). | |
| include_inferred | No | Include ambiguous same-name inferred edges (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the inferred action behavior and ambiguous-edge exclusion, but does not mention mutability, authorization needs, or rate limits. For a read-navigation tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with every sentence adding essential information: purpose, prerequisite, action breakdown, inference rule, and edge behavior. Front-loaded with core function, no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema), the description covers the three actions and their general effects, but lacks detail on return format, pagination, or error conditions. It meets minimal completeness but could be more 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% (baseline 3). The description adds value by explaining how the action parameter is inferred from arguments and by linking parameters to specific actions (e.g., budget for query, max_nodes for report). This synergy improves understanding beyond the schema alone.
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 navigates a code graph built from the current index, specifying three distinct actions (report, query, path) with concrete outcomes. This differentiates it from sibling tools like jambavan_index (which builds the index) and jambavan_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?
It explicitly instructs to call jambavan_index first, providing a clear prerequisite. However, it lacks explicit when-not-to-use guidance or direct comparisons to alternative sibling tools, which would strengthen usage clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze changed symbols against inbound extracted graph edges and test associations/references. Reports bounded transitive callers, test associations/references, and explicit graph incompleteness. Use before a risky refactor or PR review; call jambavan_index first.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base ref for the three-dot branch diff (auto-detects main/master and origin variants). | |
| max_depth | No | Inbound caller traversal depth, 1-5 (default: 2). | |
| include_worktree | No | Include staged, unstaged, and untracked changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It goes beyond a simple 'analyze' by specifying exactly what it reports (bounded transitive callers, test associations/references, explicit graph incompleteness) and flags a dependency on jambavan_index. This gives the agent a good sense of expected behavior, though it stops short of detailing side effects or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by usage guidance. Every word earns its place, and the structure makes the key information easy to scan.
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 moderate complexity and no output schema, the description does a good job of summarizing the tool's return focus (callers, tests, incompleteness) and prerequisites. It could be more explicit about output format or error behavior when jambavan_index hasn't been run, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description doesn't add much parameter-specific detail beyond what the schema already provides, though the term 'changed symbols' aligns with the base and include_worktree parameters. It doesn't introduce new semantic value.
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 a specific verb ('Analyze') with a defined resource ('changed symbols against inbound extracted graph edges and test associations/references'). It also distinguishes itself from sibling tools by detailing its unique outputs: bounded transitive callers, test associations/references, and explicit graph incompleteness.
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 context for when to use ('before a risky refactor or PR review') and a prerequisite ('call jambavan_index first'). It doesn't mention alternatives or when not to use, but the guidance is clear enough to be actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or refresh the Jambavan codebase index. Parses source files with a tree-sitter AST extractor and stores symbols in a local SQLite database. Run once per project, then incrementally on file changes. Returns indexing statistics (files processed, symbols extracted, duration).
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Existing absolute directory inside the current fallback root. Re-points a previous tool-input root (needed by hosts that share one server across workspaces); cannot override an env, client-roots, or cwd-project binding. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool parses files, stores in SQLite, and returns statistics. It mentions incremental updates, which is good for an indexing tool. Lacks details on error handling or permissions, but acceptable.
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 sentences, front-loaded with the primary action. Every sentence adds value: purpose, method, usage pattern, return value. No superfluous text.
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 an indexing tool with no output schema, the description adequately describes return values (statistics). It doesn't discuss resumption or cancellation, but the context is complete enough for an agent to use effectively.
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 a single optional parameter 'root', which is already well-documented in the schema. The tool description adds no additional semantics beyond the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Build or refresh the Jambavan codebase index', using a specific verb+resource. It distinguishes from sibling tools like jambavan_awaken or jambavan_graph by focusing solely on indexing.
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 context: 'Run once per project, then incrementally on file changes.' This tells the agent when to invoke the tool. It does not explicitly list alternatives or exclusions, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retire a memory. mode=invalidate (the default) marks it superseded but keeps the document for temporal history; mode=delete permanently removes it. Provide id for one memory, or scope with delete_scope: true to wipe a scope.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | OKF concept ID, e.g. "general/old-decision". | |
| mode | No | Defaults to invalidate, which is reversible. Pass delete only to destroy the document. | |
| scope | No | Scope to wipe (requires delete_scope: true). | |
| reason | No | Reason appended to the body when mode=invalidate. | |
| delete_scope | No | Set true to delete all memories in scope. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behaviors. It discloses mode defaults, effects on document retention, but lacks side effects, auth needs, or rate limits.
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 efficient sentences, front-loaded with main action, 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 main behaviors for a forget action, but missing return value or confirmation. Adequate given parameters and no output schema.
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%, description adds meaning by explaining mode effects, scope usage, and reason context. Adds value beyond 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?
Clearly states it's for 'retiring a memory' with specific verbs (invalidate/delete) and resource (memory). Distinguishes from sibling tools like store, read, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use invalidate (reversible, keeps history) vs delete (permanent), and mentions delete_scope for wiping a scope. Could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mine durable facts, decisions, TODOs, and constraints from a pasted session transcript or log. Stores each extracted item as an OKF memory in the requested scope. This is deterministic text mining — no summarization or external service.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Session transcript, notes, or log text to mine. | |
| scope | No | Memory scope / project name. Defaults to the active project, or "global" without a root. | |
| source | No | Optional source label, e.g. session id or file path. | |
| collection | No | Logical collection. Defaults to "general". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs deterministic text mining and stores results as OKF memories, but does not mention side effects, idempotency, or permissions. The description is truthful but lacks depth on behavioral traits like whether it overwrites existing memories.
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 with no unnecessary words. The first sentence immediately conveys the action and output. The second adds key clarifying detail (deterministic, no external service). Perfectly front-loaded and 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?
The description covers the core action and deterministic nature, but lacks information about return values, error cases, or what happens after storage (e.g., confirmation). With no output schema, more detail on the outcome would improve completeness. 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 description coverage is 100%, so the baseline is 3. The description adds context ('from a pasted session transcript or log') but does not significantly extend beyond the schema's parameter descriptions. No additional semantics beyond what the schema already provides.
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 purpose: 'Mine durable facts, decisions, TODOs, and constraints from a pasted session transcript or log.' It uses a specific verb ('Mine') and resource ('session transcript or log'), and distinguishes from siblings by emphasizing deterministic text mining versus summarization or external services.
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 when deterministic fact extraction is needed (explicitly noting 'no summarization or external service'), but does not explicitly state when not to use it or provide alternatives. Siblings like jambavan_memory_store or jambavan_memory_recall exist, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read stored memories. Pass id to fetch one document, query to BM25-search, or neither to recall the most recent. Set provider=mempalace for explicit read-only MemPalace access, or provider=all for separate provider sections; ordinary reads never start MemPalace. Jambavan scope/collection map to MemPalace wing/room.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Fetch one memory by OKF concept ID, e.g. "project/why-graphql". | |
| limit | No | Max results (default: 10 for search, 20 for recall). | |
| query | No | BM25 search query. Ignored when id is set. | |
| scope | No | Restrict to this scope. Omit to read across scopes. | |
| provider | No | Defaults to jambavan. | |
| collection | No | Restrict to one logical collection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral aspects: it explains that setting provider=mempalace gives explicit read-only access, that ordinary reads don't trigger MemPalace, and that scope/collection map to MemPalace wing/room. It also discloses the BM25 search mechanism and default limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence establishes the core purpose and modes; the second adds provider and mapping details. Every word contributes meaning, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers usage and behavior well. However, it omits any description of the return format or structure, which would be helpful since no output schema is provided.
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%, but the description adds significant value beyond the schema by explaining the three usage modes, the interaction of provider settings, and the mapping of scope/collection to MemPalace concepts. This enriches the agent's understanding of parameter behavior.
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 'Read stored memories' and details three distinct modes: by id, by query (BM25 search), or by recalling the most recent. This specificity distinguishes it from sibling tools like jambavan_memory_store (write) and jambavan_memory_forget (delete).
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 provides explicit guidance on when to use each mode (id, query, or none) and explains provider options with their implications (e.g., 'ordinary reads never start MemPalace'). It lacks direct comparison to sibling tools like jambavan_memory_status, but the instructions are clear for the primary use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show active Jambavan counts by scope and collection by default. Set provider=mempalace or provider=all to explicitly include read-only MemPalace status and taxonomy.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Show Jambavan, MemPalace, or both in separate sections. Defaults to jambavan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies read-only by mentioning 'read-only MemPalace status', but does not explicitly state safety or side effects. Adequate but not comprehensive.
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, concise and front-loaded with key information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the output as counts and status. However, more detail on format or structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for provider. The description adds that it defaults to jambavan and explains each enum value's effect, enhancing clarity 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 shows active Jambavan counts by scope and collection, with an option to include MemPalace status. It distinguishes itself from sibling tools like jambavan_memory_read and jambavan_memory_store by focusing on status/counts.
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 compared to alternatives. It explains default behavior and how to include MemPalace, but lacks explicit context or scenarios for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a memory as an Open Knowledge Format (OKF) concept document. Memories are markdown files with YAML frontmatter — human-readable and portable. Each memory has a title, body (markdown), optional tags, and a scope (e.g. project name). Memories with the same title in the same scope are overwritten (idempotent). Returns the OKF concept ID (scope/slug) of the stored document.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Full markdown content to store verbatim. | |
| tags | No | Optional tags for filtering. | |
| type | No | OKF concept type. Defaults to "Memory". | |
| scope | No | Scope / project name. Defaults to the active project, or "global" without a root. | |
| title | Yes | Short label for this memory. | |
| source | No | Optional: source file or session identifier. | |
| collection | No | Logical collection within the scope. Defaults from type. | |
| supersedes | No | Optional OKF concept ID this memory replaces. | |
| description | No | One-line summary (used in index.md). Defaults to title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency, return value, and format. No annotations exist, so description carries full burden. Lacks details on side effects (e.g., does it trigger indexing?), error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main purpose, each sentence adds essential information. No superfluous text.
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 behavior (write, idempotent, return ID), format, and parameter defaults. Does not explain return value structure beyond ID, but acceptable for a store tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds value by explaining scope defaults, idempotency, and portability beyond the schema's field descriptions.
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 tool persists a memory as an OKF concept document, with specifics on format (markdown + YAML) and idempotency. It distinguishes from sibling read-only memory tools like jambavan_memory_get or jambavan_memory_recall.
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?
Implies usage for storing or updating memories, including overwrite behavior. However, it does not explicitly state when not to use it (e.g., for read operations) or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble a review pack for the current branch vs a base branch: touched files, the symbols changed or deleted in them, their callers (via the knowledge graph), related test associations/references, past failure records mentioning the same files, and risk flags (open rin debt, no matching test association). Call before opening/updating a PR, or whenever asked "what changed" / "review this branch". Requires jambavan_index to have been run at least once for symbol/caller/test/risk analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base ref to diff against (three-dot diff from merge-base to HEAD). Auto-detects main/master/origin variants if omitted. | |
| max_files | No | Max touched files to analyze in depth (default: 20). | |
| include_worktree | No | Also include staged, unstaged, and untracked working-tree changes (default: false). |
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 states the tool depends on a prior jambavan_index run, uses the knowledge graph, references past failure records, and flags risks like open debt and missing test associations. This is substantive context. It does not explicitly say whether the operation is read-only, but 'Assemble' strongly implies a non-mutating analysis. No contradictions with annotations since none exist.
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, front-loaded with the primary purpose, then usage guidance, then a prerequisite. Every sentence earns its place, with no filler or redundancy. It is concise yet comprehensive enough to convey the tool's role and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (no output schema, no annotations), so the description must explain what the tool does and what it returns. It does this by listing the review pack's components in the first sentence and adding usage context. It lacks details about the exact output format (e.g., structured object vs text), but the enumerated contents give an agent enough understanding to invoke and interpret the result. A small improvement would be to state explicitly how the pack is returned, but the current description is fairly 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?
All three parameters (base, max_files, include_worktree) have descriptions in the input schema, achieving 100% schema description coverage. The tool description adds no additional parameter-level semantics beyond what the schema already provides, such as auto-detection behavior or defaults. A baseline score of 3 is appropriate when the schema handles parameter documentation.
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 uses a specific verb ('Assemble') and resource ('a review pack for the current branch vs a base branch'), then enumerates exactly what the pack contains (touched files, symbols, callers, test associations, failure records, risk flags). This clearly distinguishes it from sibling tools like jambavan_impact or jambavan_context by framing it around PR review and 'what changed' scenarios.
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 provides explicit usage timing: 'Call before opening/updating a PR, or whenever asked what changed / review this branch.' It also states a prerequisite (jambavan_index must have been run). However, it does not name alternative tools for when NOT to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move session context between sessions, hosts, or people as one self-contained markdown document containing recent memories, rin debt markers, and git status. Omit text to export; pass text to import it back (idempotent — re-importing creates no duplicates).
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Handoff markdown to import. Omit to export instead. | |
| scope | No | Memory scope. Defaults to project scope. | |
| share_safe | No | Export: redact local paths/secrets and omit git-sensitive data (default: false). | |
| include_git | No | Export: include git status/recent commits (default: true). | |
| include_rin | No | Export: include rin debt markers (default: true). | |
| max_memories | No | Export: max memories to include (default: 15). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: idempotency, inclusion of memories/rin/git status, and share_safe redaction. It is transparent about the dual-mode operation, though could detail return value format.
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, each earning its place: first defines core functionality, second explains the bidirectional nature with idempotency. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is fairly complete, covering inputs and behavior. However, it does not describe the return value for import (e.g., success status) or export format details, which would be helpful.
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 baseline 3. The description adds value by explaining the dual mode (omit text to export, pass text to import), which is not obvious from parameter descriptions alone. It also clarifies share_safe and other flags.
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 tool moves session context as a markdown document, with clear verb 'move' and resource 'session context'. It distinguishes itself from siblings like jambavan_memory_store by focusing on session handoff with export/import modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains export vs import modes and idempotency, providing clear usage context. However, it does not explicitly mention when not to use or compare to alternatives like jambavan_memory_store, which would be helpful given many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control the live file watcher that keeps the index in sync as you edit code. Actions: "start" — begin watching (index must exist first); "stop" — stop watching; "status" — show watcher state. While running, supported non-ignored source-file changes trigger incremental re-indexing (no full rescan). Use "start" after jambavan_index, then forget about it — the index stays fresh automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | "start" | "stop" | "status" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that changes trigger incremental re-indexing (not full rescan) and lists each action's behavior. Lacks details on error conditions or required permissions, but overall satisfactory.
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 sentences, front-loaded with purpose, followed by actions and usage tips. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers main use cases and behavior. Could mention failure modes or status output details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single param 'action', so baseline is 3. The description adds value by explaining each enum value's behavior and prerequisites (e.g., 'start' requires index to exist).
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 controls a live file watcher to keep index in sync, with three specific actions (start, stop, status). It distinguishes from sibling tools like jambavan_index by focusing on watching changes rather than initial indexing.
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 explicitly advises using 'start' after jambavan_index and mentions that incremental re-indexing occurs automatically. While it doesn't list when not to use the tool, it provides sufficient context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List project files in a directory. Paths are confined to the project root unless JAMBAVAN_ALLOW_OUTSIDE_ROOT=1.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path (default: project root) | |
| pattern | No | Substring filter, e.g. ".ts" | |
| recursive | No | List recursively (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Adds the behavioral trait of root confinement, but lacks details on error handling, output format, or performance.
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, zero wasted words. Efficiently conveys the core purpose and a key constraint.
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?
Adequate for a simple listing tool with 3 self-explanatory params, but lacks output schema and details on result format or pagination.
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% (all 3 parameters have descriptions). Description adds no additional parameter semantics beyond what the schema already provides.
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 action 'list' and the resource 'project files in a directory'. It is specific and distinguishes from sibling tools like read_file and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a constraint ('paths confined to project root unless env var set') but no guidance on when to use this tool vs alternatives like jambavan_sankshipta or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a project file. Paths are confined to the project root unless JAMBAVAN_ALLOW_OUTSIDE_ROOT=1.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project-relative or absolute file path | |
| end_line | No | Optional: 1-based end line | |
| start_line | No | Optional: 1-based start line |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses path confinement behavior and environment variable override, but lacks details on encoding, binary handling, or size limits.
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 with clear front-loading of purpose. No redundant 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?
Lacks output schema; description does not explain return format (e.g., content as string, lines). Also missing error conditions. Adequate but could be more 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 description coverage is 100%, so description adds no extra meaning beyond the schema. Baseline score of 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?
Description clearly states 'Read the contents of a project file', specifying a specific verb and resource. It distinguishes from siblings like list_files and search by implying content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives. The description implies usage for reading file contents but lacks when-not or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search project files using ripgrep, with grep fallback. Fast regex search. Paths are confined to the project root unless JAMBAVAN_ALLOW_OUTSIDE_ROOT=1.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory or file to search in (default: project root) | |
| pattern | Yes | Regex pattern to search | |
| max_results | No | Max matching lines to return (default: 50) | |
| file_pattern | No | Glob to filter files, e.g. "*.ts" | |
| case_sensitive | No | Case sensitive search (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description discloses fast regex search, grep fallback, and path restrictions. No contradiction, but could mention result format 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?
Two sentences, front-loaded with core purpose, zero waste. Achieves high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and annotations, but description covers core functionality, fallback, and constraints. Could describe return structure (e.g., matching lines and paths) but 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?
Schema coverage is 100% with parameter descriptions. Description adds default values (max_results: 50) and default path (project root), supplementing schema well.
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 'Search project files using ripgrep, with grep fallback' - specific verb and resource, distinguishes from sibling tools (e.g., list_files, memory_search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides path confinement rule and environment variable override, guiding usage. Does not explicitly state when not to use or compare to alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.1debt_ledgerdecompose_taskdev_rulesjambavan_awaken1 field changedInput schema / properties / root / descriptionPrevious value: -"Existing absolute directory inside the current unresolved fallback root. Cannot override an already fixed env, client-roots, cwd-project, or tool-input binding."New value: +"Existing absolute directory inside the current fallback root. Re-points a previous tool-input root (needed by hosts that share one server across workspaces); cannot override an env, client-roots, or cwd-project binding."jambavan_debt_ledgerjambavan_diagnosticsjambavan_failure_searchjambavan_failure_storejambavan_graphjambavan_graph_pathjambavan_graph_queryjambavan_graph_reportjambavan_index1 field changedInput schema / properties / root / descriptionPrevious value: -"Existing absolute directory inside the current unresolved fallback root. Cannot override an already fixed env, client-roots, cwd-project, or tool-input binding."New value: +"Existing absolute directory inside the current fallback root. Re-points a previous tool-input root (needed by hosts that share one server across workspaces); cannot override an env, client-roots, or cwd-project binding."jambavan_memory_forgetjambavan_memory_getjambavan_memory_invalidatejambavan_memory_readjambavan_memory_recalljambavan_memory_statusjambavan_rin_mochanjambavan_session_exportjambavan_session_handoffjambavan_session_importjambavan_vibhishana_nitiread_filestrategy_planv1.1.0jambavan_failure_searchjambavan_failure_storejambavan_memory_deletejambavan_memory_getjambavan_memory_mine_session2 fields changedInput schema / properties / collectionAdded value: +{
+ "description": "Logical collection. Defaults to \"general\".",
+ "type": "string"
+}Input schema / properties / scope / descriptionPrevious value: -"Memory scope / project name. Defaults to \"general\"."New value: +"Memory scope / project name. Defaults to the active project, or \"global\" without a root."jambavan_memory_recall2 fields changedInput schema / properties / collectionAdded value: +{
+ "description": "Restrict recall to one logical collection.",
+ "type": "string"
+}Input schema / properties / providerAdded value: +{
+ "description": "Recall from Jambavan, MemPalace, or both in separate sections. Defaults to jambavan.",
+ "enum": [
+ "jambavan",
+ "mempalace",
+ "all"
+ ],
+ "type": "string"
+}jambavan_memory_searchjambavan_memory_statusjambavan_memory_store2 fields changedInput schema / properties / collectionAdded value: +{
+ "description": "Logical collection within the scope. Defaults from type.",
+ "type": "string"
+}Input schema / properties / scope / descriptionPrevious value: -"Scope / project name. Defaults to \"general\"."New value: +"Scope / project name. Defaults to the active project, or \"global\" without a root."jambavan_mool_kaaranjambavan_pramanjambavan_vibhaajanjambavan_yuktiread_fileroot_causeverify_gatev0.6.1jambavan_awaken1 field changedInput schema / properties / rootAdded value: +{
+ "description": "Existing absolute directory inside the current unresolved fallback root. Cannot override an already fixed env, client-roots, cwd-project, or tool-input binding.",
+ "type": "string"
+}jambavan_context1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max symbols to return before token-budget truncation (default: 30)"New value: +"Max lexical symbols before token-budget truncation; up to 6 extracted structural neighbors may be added (default: 30)"jambavan_doctor1 field changedInput schema / properties / issue_reportAdded value: +{
+ "description": "Return a copy-ready redacted GitHub issue URL/body without posting it.",
+ "type": "boolean"
+}jambavan_graph_path2 fields changedInput schema / properties / include_inferredAdded value: +{
+ "description": "Include ambiguous same-name inferred edges (default: false).",
+ "type": "boolean"
+}Input schema / properties / symbol_limit / descriptionPrevious value: -"Max indexed symbols to graph (default: 5000; higher values cost more)."New value: +"Max symbols in the query-focused graph neighborhood (default: 5000)."jambavan_graph_query3 fields changedInput schema / properties / directionAdded value: +{
+ "description": "Traverse callers, callees, or both (default: both).",
+ "enum": [
+ "inbound",
+ "outbound",
+ "both"
+ ],
+ "type": "string"
+}Input schema / properties / include_inferredAdded value: +{
+ "description": "Include ambiguous same-name inferred edges (default: false).",
+ "type": "boolean"
+}Input schema / properties / symbol_limit / descriptionPrevious value: -"Max indexed symbols to graph (default: 5000; higher values cost more)."New value: +"Max symbols in the query-focused graph neighborhood (default: 5000)."jambavan_graph_report1 field changedInput schema / properties / include_inferredAdded value: +{
+ "description": "Include ambiguous same-name inferred edges (default: false).",
+ "type": "boolean"
+}jambavan_impactjambavan_index1 field changedInput schema / properties / rootAdded value: +{
+ "description": "Existing absolute directory inside the current unresolved fallback root. Cannot override an already fixed env, client-roots, cwd-project, or tool-input binding.",
+ "type": "string"
+}jambavan_memory_recall1 field changedInput schema / properties / scope / descriptionPrevious value: -"Scope to recall. Omit for all memories."New value: +"Scope to recall. Omit to search across scopes."jambavan_review_pack1 field changedInput schema / properties / include_worktreeAdded value: +{
+ "description": "Also include staged, unstaged, and untracked working-tree changes (default: false).",
+ "type": "boolean"
+}jambavan_session_export1 field changedInput schema / properties / share_safeAdded value: +{
+ "description": "Redact local paths/secrets and omit git-sensitive data for sharing (default: false).",
+ "type": "boolean"
+}v0.5.4debt_ledgerdecompose_taskdev_rulesroot_causestrategy_planverify_gatev0.5.2jambavan_doctorjambavan_review_packv0.5.0jambavan_mool_kaaranjambavan_pramanjambavan_vibhaajanjambavan_yuktiv0.4.0jambavan_context3 fields changedInput schema / properties / compress_proseAdded value: +{
+ "description": "Compress comments/docstrings in results for more symbol density (default: false)",
+ "type": "boolean"
+}Input schema / properties / include_diffAdded value: +{
+ "description": "Include recent git changes for each symbol (default: false)",
+ "type": "boolean"
+}Input schema / properties / include_testsAdded value: +{
+ "description": "Include associated test file info for each symbol (default: false)",
+ "type": "boolean"
+}jambavan_failure_searchjambavan_failure_storejambavan_session_exportjambavan_session_importjambavan_sankshiptav0.3.0jambavan_awakenjambavan_contextjambavan_diagnosticsjambavan_graph_pathjambavan_graph_queryjambavan_graph_reportjambavan_indexjambavan_memory_deletejambavan_memory_invalidatejambavan_memory_mine_sessionjambavan_memory_recalljambavan_memory_searchjambavan_memory_statusjambavan_memory_storejambavan_rin_mochanjambavan_sankshiptajambavan_vibhishana_nitijambavan_watchlist_filesread_filesearchEach tool has a distinct purpose: file operations, indexing, context retrieval, memory management, failure tracking, graph navigation, etc. There is no overlap that would cause confusion; even similar tools like jambavan_context and read_file serve different needs (symbol snippets vs. full file).
Most tools follow the 'jambavan_verb_noun' pattern, but three tools (read_file, search, list_files) lack the prefix. This split is the only inconsistency; the naming within each group is predictable and descriptive.
With 20 tools, the count is well-scoped for a comprehensive code intelligence and memory system. Each tool earns its place, covering indexing, context, memory, failure tracking, graph analysis, and more without redundancy.
The tool surface is thoroughly complete for its domain: basic file operations, index management, context retrieval, memory CRUD plus mining, failure recording, session handoff, review packs, and impact analysis. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP memory server. One memory your agents share — across models, devices and apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/beingmartinbmc/jambavan'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
