Context Mode

Server Quality Checklist

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

Latest release: v1.0.169
Disambiguation4/5
Tools are largely distinct: execution (ctx_execute, ctx_execute_file, ctx_batch_execute), indexing (ctx_index, ctx_fetch_and_index), retrieval (ctx_search), and admin (ctx_stats, ctx_doctor, ctx_upgrade, ctx_purge, ctx_insight) form clear groups. The main ambiguity is between ctx_execute and ctx_execute_file (both run code, one inline vs. over a file), but descriptions and parameters make the distinction clear.
Naming Consistency4/5
All tools share the ctx_ prefix and snake_case, following an imperative verb pattern (ctx_execute, ctx_search, ctx_purge). Minor deviations like ctx_execute_file (noun modifier) and ctx_fetch_and_index (two verbs) are still readable and consistent with the overall style.
Tool Count5/5
11 tools is well-scoped for a server that handles sandboxed code execution, knowledge-base indexing/search, batch processing, and lifecycle administration. Each tool serves a distinct function without redundancy, and the count sits comfortably in the ideal 3-15 range.
Completeness5/5
The surface covers the full workflow: ingest (ctx_index, ctx_fetch_and_index), process (ctx_execute, ctx_execute_file, ctx_batch_execute), retrieve (ctx_search), monitor (ctx_stats), and maintain (ctx_purge, ctx_upgrade, ctx_doctor, ctx_insight). The only theoretical gap is fine-grained single-item deletion, but ctx_purge's scoped delete handles that adequately.
Average 4.7/5 across 11 of 11 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 177 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is sandboxed and that 'file bytes stay in the sandbox', implying safe, non-destructive execution. However, annotations declare destructiveHint=true and readOnlyHint=false, which contradicts this safety implication. Per the rule, this is an annotation contradiction and scores 1.
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 front-loaded with a clear purpose, uses structured sections (WHEN, WHEN NOT, RETURNS, EXAMPLE) for scannability, and includes relevant examples. It is long but every section earns its place; no filler or tautology.
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?
Even without an output schema, the description explains return behavior ('Only what your code prints'), large-output auto-indexing, and the memory rationale. Combined with thorough usage guidance and examples, it is nearly complete for a tool of this complexity, only undermined by the annotation contradiction.
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 is 3, but the description adds significant value: it explains the FILE_CONTENT variable, clarifies that only console.log output is returned, details the intent param's auto-indexing behavior, and provides concrete examples for code and path. This goes beyond the schema's terse 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?
The description uses a specific verb+resource pattern: 'Read a file into a sandboxed FILE_CONTENT variable and run code over it.' It also explicitly distinguishes itself from sibling ctx_execute by saying 'Same principle as ctx_execute, scoped to one named file via the FILE_CONTENT variable.' This clearly differentiates it from alternatives.
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 includes explicit 'WHEN' and 'WHEN NOT' sections, listing specific scenarios for use and alternatives such as Read, ctx_execute, and ctx_search. It names exact tools and conditions, making the choice logic unambiguous.
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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral detail by listing exactly what statistics are returned (total bytes, breakdown by tool, call counts, estimated token usage, context savings ratio), which goes beyond the annotations and helps the agent understand the tool's output.
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-structured sentence that front-loads the core purpose ('Returns context consumption statistics') and then enumerates the specific stats in a compact list. No filler or redundant information is present.
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?
The tool is simple (no parameters, no output schema), and the description fully covers its scope, behavior, and return values. It lists the types of statistics provided, which is sufficient for an agent to understand what it will receive. Annotations cover safety traits, so no further information gaps exist.
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, so the description does not need to explain parameter meanings. The schema coverage is trivially 100% with an empty properties object. Per the rubric, baseline for 0 parameters is 4, and the description adequately complements the schema by explaining what the tool reports without needing 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 clearly states the tool returns context consumption statistics for the current session, with a specific verb ('Returns'), resource ('context consumption statistics'), and scope ('current session'). This distinguishes it from siblings like ctx_execute or ctx_search, which perform actions or queries rather than reporting statistics.
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?
Usage is implied rather than explicitly stated. The description tells what it does but does not provide explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives. While the purpose makes its use case obvious, there is no direct comparison with sibling tools or contextual exclusions.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by stating that all checks run server-side, returns a plain-text report with specific prefixes, and that no CLI execution is needed—useful behavioral context beyond the 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?
The description is concise: two sentences that immediately state the purpose and then add key details about execution and output. No filler or 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 no-parameter diagnostic tool, the description covers purpose, execution model, and output format. It does not enumerate the specific checks run, but given the simplicity and the presence of key behavior details, it is sufficiently complete 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?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameters, and there is nothing more needed for parameter semantics.
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 identifies the tool as a diagnostic for context-mode installation with a specific verb ('Diagnose') and resource. It distinguishes itself from the sibling tools by focusing on installation health reporting rather than execution, search, or index management.
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 clear context for when to use this tool: to diagnose context-mode installation issues. It also implies that it is a server-side alternative to CLI methods, but it does not explicitly name alternative tools or exclusions, so it stops short of full guidance.
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?
The description discloses key behavior beyond annotations: it returns a shell command rather than performing the upgrade directly, and it mandates a restart. This adds context to the readOnlyHint=false and idempotentHint=true annotations, though it could elaborate on potential side effects or prerequisites. 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?
The description is three sentences with no wasted words. It front-loads the purpose, then gives essential execution instructions, and closes with a necessary user-facing step. Every sentence contributes value.
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 and no output schema, the description adequately covers the tool's behavior and required follow-up actions. It could mention what the returned command actually does or any prerequisites, but the core workflow is clear.
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 baseline is 4. The description correctly avoids discussing parameters, as there are none to explain, and the empty schema already conveys this.
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 states 'Upgrade context-mode to the latest version' with a specific verb and resource, clearly distinguishing it from siblings like ctx_execute, ctx_search, and ctx_purge. The purpose is unambiguous and directly tied to the tool name and title.
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 execution guidance: the returned command must be run via a shell tool, output displayed as a checklist, and the user told to restart. However, it does not explicitly discuss when to use this tool versus alternatives or when not to use it, 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?
The annotations already declare idempotentHint=true and destructiveHint=false, and the description adds that it opens a browser (openWorldHint context) and clarifies it's a launcher rather than a data-returning tool. It also details the dashboard contents, which is useful behavioral context beyond the safety flags.
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 with a clear hierarchy: the core action, the dashboard's analytics content, and the alternative for queries. Every sentence adds distinct value without redundancy, and the most important information (opens dashboard) is front-loaded.
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 side-effecting launcher with no parameters and no output schema, the description covers the primary action, the domain of the dashboard, and the correct alternative for a different use case. Given the annotations cover safety and the schema is empty, this is fully complete.
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 schema has zero parameters, and the rubric sets a baseline of 4 for no-parameter tools. The description adds no unnecessary parameter details, which is appropriate since there are none.
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+resource: 'Opens the context-mode Insight dashboard in your default browser,' and immediately distinguishes it from a Q&A engine by noting it's a launcher, not a query tool. It also clearly maps to sibling differentiation by pointing to ctx_search for natural-language queries.
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?
It explicitly states the tool's scope ('dashboard launcher for the hosted analytics layer, not a Q&A engine') and provides an explicit alternative: 'For natural-language queries over your indexed content, use ctx_search.' This gives the agent clear when-to-use and when-not-to-use 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?
The description discloses significant behavioral context beyond annotations: auto-indexing side effects, that raw output is not echoed in full, concurrency>1 switches to per-command timeouts, and concurrency=1 preserves shared-budget cascading-skip behavior. These details are not present in the annotations or schema and are critical for correct use.
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 WHEN, WHEN NOT, RETURNS, and EXAMPLE sections, and it is appropriately detailed for a complex tool. However, concurrency guidance is repeated in multiple sections (WHEN, WHEN NOT, RETURNS), making it slightly less concise than ideal.
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?
With no output schema, the description compensates by explaining return values (auto-indexed section list, top matches per query) and the non-echoing of raw output. It covers when to use, when not, behavioral nuances, and provides a concrete example, making it complete for reliable invocation.
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 is 3. The description adds practical semantics for concurrency and queries, such as 'Use 4-8 for I/O-bound batches; keep at 1 for CPU work' and per-command vs shared timeout behavior. This adds value beyond the 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?
The description opens with 'Run multiple commands in ONE call' and clearly states that outputs are auto-indexed and queries return matching sections inline. This distinguishes it from sibling tools like ctx_execute (single command) and ctx_search (follow-up search), establishing a specific verb+resource+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?
The WHEN and WHEN NOT sections provide explicit guidance: use for 3+ related commands, gathering+querying in one round trip, or I/O-bound parallelization; avoid for single commands (use sandbox directly) or CPU/stateful commands (keep concurrency at 1). This clearly states when to use versus 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?
The description discloses that only console.log output returns, uncaught errors go to stderr, and intent auto-indexes outputs over ~5KB into the knowledge base, returning only section titles+previews. It also details background detachment behavior and warns against self-close timers, all beyond the annotations' destructive/openWorld 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?
The description is long but structured with WHEN/WHEN NOT/RETURNS/EXAMPLE sections; every sentence earns its place. The 'Think-in-Code' philosophy paragraph is slightly verbose but illuminates the core trade-off, and the concrete example demonstrates usage. Not maximally concise, but justified for a complex tool.
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 lacking an output schema, the description covers return behavior, error handling, background mode, intent indexing, and common usage examples. For a six-parameter arbitrary-code-execution tool, this is complete enough for correct selection and invocation.
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% (all six parameters described), so baseline is 3. The description adds meaningful context for `background` (detach on timeout, no self-close timers), `intent` (auto-index threshold and retrieval via ctx_search), and provides examples illustrating language/code usage, elevating it above baseline.
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 opens with a clear verb+resource: 'Run code in a sandboxed subprocess' and lists supported languages. It distinguishes from siblings by explicitly naming the sandbox execution model and contrasting with Bash, making the purpose unmistakable.
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 WHEN section lists five concrete scenarios (derive answers from data, unpredictable output, offload compute, background processes, large output intent) and the WHEN NOT section names alternatives (Bash for simple commands, file mutations/navigation). This is explicit, actionable guidance with 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?
Beyond the four annotation hints, the description discloses meaningful behavior: content is not summarized or truncated, raw chunks persist in storage, and returned metadata excludes raw content. It also explains that when path is provided a content hash enables staleness detection, and that directory indexing is a bounded recursive walk.
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 front-loaded with a two-sentence summary of the tool's essence, followed by clearly labeled WHEN/WHEN NOT/RETURNS/EXAMPLE sections. Each section adds unique information without filler, making the length justified by the tool's 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?
No output schema exists, so the description compensates by explicitly stating RETURNS: chunk counts, source label, and the exact ctx_search call shape. It also covers edge cases like path-vs-content, directory walking bounds, and staleness flags, making the description self-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?
Input schema covers all 10 parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds context by clarifying that content never enters context when using path and that path triggers hash-based staleness detection, plus two concrete examples showing how to call the 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 opens with a specific verb and resource: 'Store content in a searchable knowledge base (BM25 over FTS5).' It clearly distinguishes itself from siblings by specifying it splits markdown by headings, preserves code blocks, and stores raw chunks for later retrieval, with the explicit contrast to ctx_execute_file in WHEN NOT.
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 WHEN section enumerates concrete use cases (Context7 docs, API references, MCP tool lists, skill prompts) and the WHEN NOT section explicitly excludes log files/test output and directs to ctx_execute_file. It also names ctx_search as the retrieval counterpart, giving 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?
The description discloses significant non-obvious behaviors: raw page bytes never enter the conversation, disk caching with TTL, 14-day cleanup, serial FTS5 writes, concurrency cap, and rate-limit implications. These go well beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.) and add critical operational detail.
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 long but exceptionally well-structured with clear sections (WHEN, WHEN NOT, RETURNS, EXAMPLE). It front-loads the core purpose and each section conveys distinct, essential information 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?
The description covers caching behavior, return values (preview windows, indexing metadata), concurrency latency, cache-hit behavior, and even operational constraints like rate limits. Despite no output schema, it paints a complete picture for an agent to use the tool effectively.
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?
Even though schema coverage is 100%, the description enriches parameter understanding by explaining ttl:0 is equivalent to force:true, how concurrency interacts with indexing (serial writes, net latency), and when to lower concurrency due to rate limits. The example clarifies batch usage with requests and concurrency.
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 precisely states what the tool does: 'Fetches URL content, converts HTML to markdown... persists it in a searchable knowledge base, and returns a small preview window per source.' It also distinguishes from siblings by referencing ctx_search for on-demand retrieval and an inline index tool for local content.
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 guidance: use for web content that should not enter conversation, multi-URL research, and caching; avoid when content is already local or the page is SPA-rendered. It names the inline index tool as an alternative for local content.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses irreversible deletion, confirm:true requirement, error cases for ambiguous/invalid scopes, deprecated bare-confirm behavior, and the return summary. This gives the agent a rich behavioral contract without contradicting the 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?
The description is organized with clear sections (DESTRUCTIVE, WHEN, WHEN NOT, SCOPES, CONTRACT, RETURNS, EXAMPLE), making it scannable and front-loaded with the most critical warning. Every line conveys necessary behavioral or usage information with no filler.
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 highly destructive tool with no output schema, the description fully covers return values, error conditions, deprecated paths, and scope-specific effects. It addresses all three parameters and even includes examples, making it complete for an agent 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already fully documents each parameter, the description adds critical meaning: exactly one scope must be passed, sessionId cannot be combined with scope:'project', scope:'session' requires sessionId, and confirm:false cancels. It also provides two valid example invocations, which materially improves correct 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 opens with 'DESTRUCTIVE: permanently delete indexed content. Cannot be undone,' which clearly identifies the action, resource, and severity. It also distinguishes the two scopes (session vs project), making the tool's purpose unmistakable relative to its siblings.
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, including concrete user phrasing triggers and instructions to ask for a scope if ambiguous. It even recommends an alternative tool (ctx_stats) for memory/performance concerns, giving clear guidance on when not to purge.
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 already declare readOnly/idempotent/destructive hints. The description adds extensive behavioral detail: stemming and trigram matching, Reciprocal Rank Fusion, proximity rerank, typo correction, snippet windowing, unified KB scope, staleness flagging, and throttle behavior with tunable environment variables. 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?
Although lengthy, the description is tightly organized into clear sections (WHEN, WHEN NOT, RETURNS, EXAMPLES) and every sentence delivers operational value. It is front-loaded with the core search mechanism and uses headers to aid scanning, making the length justified and structurally clean.
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?
No output schema exists, but the description compensates fully: it explains per-query ranked sections, window-extracted snippets, throttle counters and caps, common source labels, and references ctx_stats for live counts. With five parameters and complex ranking behavior, the description leaves no significant gaps for an agent to invoke correctly.
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 enriches param meaning: source permits partial match, sort 'timeline' vs 'relevance' differences, contentType examples ('code' vs 'prose'), and the recommendation to pass 2-4 terms per query. Examples show usage of queries, source, sort, contentType, and limit in context.
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 opens with 'Search a unified knowledge base with a multi-strategy ranking pipeline,' using a specific verb ('search') and resource ('unified knowledge base'). It clearly distinguishes from siblings by referencing stored content from ctx_index, ctx_fetch_and_index, and ctx_batch_execute, plus auto-captured session memory, which no other sibling covers.
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?
Provides explicit WHEN and WHEN NOT sections. It states when to use the tool (recalling stored content, batching related questions, scoping by source, timeline sort) and when not to (data never stored, one-off ad-hoc questions best handled with sandbox code). This is textbook differentiation from alternatives.
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/Everflow-Utilities/context-mode/badges/card.svg)](https://glama.ai/mcp/servers/Everflow-Utilities/context-mode)

Score Badge

Copy to your README.md:

[![context-mode MCP server](https://glama.ai/mcp/servers/Everflow-Utilities/context-mode/badges/score.svg)](https://glama.ai/mcp/servers/Everflow-Utilities/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/Everflow-Utilities/context-mode'

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