Context Mode

by mksglu

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.168
Disambiguation5/5
Each tool targets a distinct operation: batch execution, single execution, file analysis, web fetching, indexing, search, stats, purge, upgrade, diagnostics, and dashboard. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow the 'ctx_' prefix with a consistent verb_noun pattern in snake_case (e.g., ctx_batch_execute, ctx_fetch_and_index, ctx_search). The naming is uniform and predictable.
Tool Count5/5
With 11 tools, the server covers execution, indexing, search, analytics, cleanup, and upgrade without being bloated. Each tool serves a clear purpose within the context-mode domain.
Completeness5/5
The tool surface covers the full lifecycle: data gathering (batch, fetch), indexing, search, execution, diagnostics, stats, and cleanup. Minor gaps like bulk export are absent but the core workflows are thoroughly covered.
Average 4.7/5 across 11 of 11 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 386 of 493 community issues answered or closed in the last 6 months
- 210 commits in the last 12 weeks
- Last stable release on June 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Elastic License 2.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, and description adds critical context: tool returns a command, doesn't directly upgrade, and requires restart. No contradiction with annotations.
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, directly addresses purpose, usage, and next steps. No unnecessary 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?
Given no parameters or output schema, description adequately explains tool's behavior and post-upgrade steps. Could add error handling, but sufficient for agent.
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?
No parameters, so schema coverage is 100%. Description doesn't need to add param info but could clarify command format. Baseline 4 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 'Upgrade context-mode to the latest version,' specifying the verb and resource. It distinguishes from siblings by focusing on upgrade, not execution or 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 explicit instructions: returns a command that must be executed via shell tool, output displayed as checklist, and user told to restart. Could mention when upgrade is not needed, but overall 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying server-side execution, plain-text output with [OK]/[FAIL]/[WARN] prefixes, and renderer-safety, which are useful behavioral traits beyond the structured fields.
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 succinct sentences: first states purpose, second adds key behavioral details. No wasted words, front-loaded with the core verb. Excellent conciseness.
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 simple tool with no parameters and no output schema, the description covers purpose, output format, safety, and server-side execution. Combined with annotations, it provides complete context for an agent to select and invoke 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?
With zero parameters, baseline is 4. The description adds no parameter info, but none is needed; it explains what the tool does without relying on schema. Schema coverage is irrelevant here.
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 diagnoses context-mode installation, a specific verb+resource. It distinguishes from sibling tools which involve execution, search, or index operations, leaving no ambiguity about its purpose.
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 implies usage: run diagnostics for installation health, with a note that no CLI execution is needed. It provides clear context but does not explicitly contrast with alternatives like ctx_upgrade or ctx_search, missing some guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds specific behavioral traits: the types of statistics returned, which provides useful context beyond the annotations. No contradiction.
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, efficient and to the point. No redundant information. Every piece of information is valuable.
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?
Given no output schema, the description comprehensively explains what the tool returns (total bytes, breakdown by tool, call counts, token usage, savings ratio). No apparent gaps.
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?
No parameters exist, so schema coverage is effectively 100%. Baseline score of 4 applies as the description adds no parameter-related info (none needed).
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 returns context consumption statistics for the current session, listing specific data points (bytes, breakdown, call counts, token usage, savings ratio). It distinguishes from sibling tools which perform different actions like execution or 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?
The description implies usage context ('for the current session') but does not explicitly state when to use this tool over alternatives or when not to use it. However, the sibling tools are sufficiently different that the purpose is clear.
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?
Description extensively discloses behavioral traits: sandbox execution, output capture via console.log, handling of large outputs with intent and auto-indexing, background process detachment, and error handling. Annotations only provide destructiveHint and openWorldHint; description adds rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (WHEN, WHEN NOT, RETURNS, EXAMPLES) and informative philosophy. However, it is somewhat lengthy and could be trimmed without losing key information, particularly the philosophical paragraph.
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?
Covers all aspects: supported languages, execution behavior, output handling, background processes, intent-based indexing, and provides concrete examples. Even without an output schema, the description fully explains what the tool returns and how to interpret results.
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?
All 6 parameters have schema descriptions, but the description adds significant meaning: for 'code' it lists print functions, for 'timeout' it explains default behavior, for 'background' it warns against setTimeout, for 'intent' it explains knowledge base integration. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs code in a sandboxed subprocess and lists supported languages. However, it does not explicitly differentiate from siblings like ctx_batch_execute or ctx_execute_file, relying on implicit distinction via usage guidelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN and WHEN NOT sections provide clear context for when to use this tool (deriving answers from data, unpredictable output, long-running processes) and when to use alternatives like Bash. Also provides examples for specific scenarios.
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?
Annotations already indicate idempotentHint=true. The description adds that the tool opens a browser URL and is a dashboard launcher, which is consistent and helpful, though it doesn't cover additional edge cases like auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Key information (action, URL, purpose, alternatives) is front-loaded and concise.
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?
Given no parameters, no output schema, and a simple browser-launch action, the description fully covers what the tool does and when to use it, with no gaps.
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 zero parameters and 100% schema coverage, the description doesn't need to add parameter details. It mentions the URL and dashboard contents, which is sufficient for a parameterless tool.
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 opens the Insight dashboard in the default browser, specifies the URL, and distinguishes itself from a Q&A engine, differentiating it from sibling tools like ctx_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (for dashboard access) and when not to use (for natural-language queries, use ctx_search instead), providing clear guidance.
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?
Annotations are minimal (readOnlyHint false, destructiveHint false, idempotentHint false, openWorldHint true). The description adds extensive behavioral context: raw bytes never enter conversation, disk caching with default TTL, 14-day cleanup, serial indexing despite parallel fetches, net latency formula, cache hit behavior, and rate-limit considerations. This fully informs the agent of side effects and performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Caching, WHEN, WHEN NOT, RETURNS, EXAMPLE) and front-loaded with core purpose. However, it is somewhat lengthy and contains minor redundancy (e.g., force: true and ttl:0 mentioned in multiple places). It could be tightened without losing information.
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?
Despite having no output schema and 6 parameters, the description covers all necessary aspects: return value (preview windows and metadata), caching behavior, concurrency model, when to use/not use, and an example. It effectively positions the tool among 11 siblings and provides enough detail for an agent to invoke it 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 description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: explains legacy vs batch shapes, concurrency cap by CPU, ordering, cache bypass via ttl:0, and source label usage. This extra context justifies a score of 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 fetches URL content, converts it to markdown or indexes JSON/plain text, persists it in a searchable knowledge base, and returns preview windows. It distinguishes from siblings like ctx_search (retrieval) and ctx_index (local content) by focusing on external web fetching and indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN and WHEN NOT sections. WHEN includes needing web content for research, multi-URL parallel fetching, caching benefits, and long-lived cache. WHEN NOT includes already having content locally (use inline index) or SPA-rendered pages needing a headless browser. This clearly guides agent decision-making.
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?
Describes key behaviors: splits by headings, preserves code blocks, persists raw chunks, no summarization/truncation, staleness detection via content hash. Beyond annotations, which only flag readOnly/destructive/idempotent hints as false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded purpose. However, the 'WHEN' list is somewhat lengthy and could be condensed without losing clarity. Still appropriate for the complexity.
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?
Given no output schema, description fully explains return value (chunk counts, source label, search call shape) and staleness behavior. Covers all parameter combinations and usage scenarios adequately.
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 covers all 10 parameters (100% coverage). Description adds value by explaining mutual exclusivity of content/path, directory-only behaviors (include, exclude, maxDepth, etc.), and provides two concrete usage examples.
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 content in a searchable knowledge base' and differentiates from sibling tools like ctx_search (retrieval) and ctx_execute_file (ephemeral content). Specific verb+resource with exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN' and 'WHEN NOT' sections list suitable content types (documentation, API refs, code) and exclusions (logs, test output). Directs to ctx_execute_file for non-indexable content, providing clear alternatives.
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?
Discloses auto-indexing, raw output not echoed, concurrency affects timeout behavior, and returns auto-indexed sections with query matches. No contradiction with annotations (destructiveHint=true is consistent with state modification).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings (WHEN, WHEN NOT, RETURNS, EXAMPLE) and front-loads core purpose. Slightly lengthy but justified for a complex tool with many options.
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?
Covers all aspects: return format, concurrency effects, timeout behavior, query scope, and examples. No missing info given the complexity and lack of output schema.
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 description adds valuable context: concurrency behavioral difference, query_scope clarification, and emphasis that queries are the only chance for inline search.
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 'Run multiple commands in ONE call' and explains auto-indexing and inline queries, distinguishing it from siblings like ctx_execute and ctx_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN' and 'WHEN NOT' sections list appropriate use cases (3+ related commands, parallel I/O) and alternatives (use sandbox for single commands, keep concurrency=1 for CPU-bound).
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?
Discloses that only console.log output enters conversation, file bytes stay sandboxed, output auto-indexing when intent is set and output >5KB, and no server-side timeout when omitted. No contradiction with annotations (destructiveHint=true is consistent with code execution).
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?
Well-structured with sections (WHEN, WHEN NOT, RETURNS, EXAMPLE). Front-loaded with one-line purpose. Every sentence adds value without redundancy.
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?
Given no output schema, the description fully explains return behavior (console.log output, indexed sections for large outputs). Covers all parameters, use cases, and edge cases. Complete for an AI agent to decide when to invoke.
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 covers all 5 parameters with descriptions. The description adds value with examples showing how to use path, language, code, and intent, and explains that FILE_CONTENT variable is automatically available. No parameter information is missing.
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 starts with a clear one-liner: 'Read a file into a sandboxed FILE_CONTENT variable and run code over it.' It distinguishes from siblings like ctx_execute by specifying file-scoped execution and from ctx_batch_execute by operating on a single file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN' and 'WHEN NOT' sections list scenarios (e.g., line count, pattern matches, large files) and alternatives (use Read for editing, use Read with offset/limit for specific lines). Provides clear decision criteria.
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?
Goes far beyond annotations by detailing the multi-strategy ranking pipeline (Porter stemmer, trigram, RRF fusion, proximity rerank, typo correction, window extraction), throttle counters, soft/hard caps, and tunable parameters. No contradiction with readOnly, idempotent, non-destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (algorithm, when/when-not, returns, configuration, examples). Slightly verbose but every sentence adds value. Front-loaded with main purpose. Minor redundancy (e.g., ranking details repeated) could be tightened.
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?
Comprehensively covers ranking algorithm, usage guidance, parameter semantics, return behavior (ranked sections with snippets), throttling, and examples. Adequate for a search tool without output schema, addressing all essential aspects.
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 context: batching queries, partial match for source, sort mode differences (relevance vs timeline), contentType filtering, and examples illustrating usage. Far exceeds schema 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?
Clearly states 'Search a unified knowledge base with a multi-strategy ranking pipeline.' The verb 'search' and resource 'unified knowledge base' are specific. The description distinguishes from sibling tools by explaining when to use this tool versus capture-then-query or inline sandbox answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'WHEN' and 'WHEN NOT' sections with concrete scenarios (e.g., recall stored content, batch questions, scope by source) and alternatives (capture-then-query, sandbox inline). Provides clear prerequisites and exclusions.
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?
The description fully discloses the destructive nature, irreversibility, and detailed contract (required confirm:true, error cases, deprecated behavior). Annotations already set destructiveHint:true, but the description adds crucial context about scope resolution and side effects.
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 well-organized with clear sections (WHEN, WHEN NOT, SCOPES, CONTRACT, RETURNS, EXAMPLE). Every sentence contributes essential information without redundancy. It is front-loaded with the destructive warning for immediate clarity.
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?
Given the tool's complexity (3 parameters, no output schema), the description covers all necessary aspects: purpose, usage guidance, behavioral contract, parameter semantics, and return format. Examples and deprecated behavior information ensure completeness.
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?
Although schema coverage is 100%, the description adds significant value by explaining the interplay between parameters, edge cases (e.g., conflicting arguments, invalid combinations), and deprecated path. Examples further clarify usage.
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: permanently delete indexed content. It uses strong verbs ('purge', 'delete', 'wipe') and resource references ('knowledge base', 'session', 'project'). It distinguishes from sibling tools by emphasizing destruction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'WHEN' and 'WHEN NOT' sections, guiding the agent on appropriate use cases and common pitfalls. It specifically mentions when to use ctx_stats instead, and instructs to ask for scope when ambiguous.
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:

[![context-mode MCP server](https://glama.ai/mcp/servers/mksglu/context-mode/badges/card.svg)](https://glama.ai/mcp/servers/mksglu/context-mode)

Score Badge

Copy to your README.md:

[![context-mode MCP server](https://glama.ai/mcp/servers/mksglu/context-mode/badges/score.svg)](https://glama.ai/mcp/servers/mksglu/context-mode)

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/mksglu/context-mode'

If you have feedback or need assistance with the MCP directory API, please join our Discord server