jambavan

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.2
Disambiguation5/5
Each 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).
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.1/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jambavan MCP server](https://glama.ai/mcp/servers/beingmartinbmc/jambavan/badges/card.svg)](https://glama.ai/mcp/servers/beingmartinbmc/jambavan)

Score Badge

Copy to your README.md:

[![jambavan MCP server](https://glama.ai/mcp/servers/beingmartinbmc/jambavan/badges/score.svg)](https://glama.ai/mcp/servers/beingmartinbmc/jambavan)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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