cortex-cloud-docs-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have unclear boundaries and overlapping purposes. The distinction between 'index_cortex_api_docs' and 'index_cortex_docs' is ambiguous, as is the difference between 'search_cortex_api_docs' and 'search_cortex_docs'. This overlap could lead to misselection by agents, especially since the descriptions don't clearly differentiate the scopes or use cases for these similar tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as 'get_index_status', 'index_cortex_api_docs', and 'search_all_docs'. This predictability makes the tool set easy to parse and understand, with no deviations in naming conventions across the six tools.
Tool Count5/5
With 6 tools, the count is well-scoped for a documentation server focused on indexing and searching. Each tool appears to serve a distinct operational role, such as checking status, indexing specific doc types, and searching across various scopes, making the set appropriately sized without being overly complex or too sparse.
Completeness4/5
The tool surface covers core workflows for indexing and searching documentation, with tools for status checks, indexing different doc types, and searching across scopes. A minor gap exists in lacking explicit update or delete operations for cached documents, but agents can likely work around this by re-indexing, so the coverage is largely complete for the server's purpose.
Average 3.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 of behavioral disclosure. It only states what the tool does at a high level ('Search across all...'), without explaining what 'all' encompasses, how results are returned, whether there are rate limits, authentication requirements, or any other behavioral characteristics. This leaves significant gaps for a search 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple search tool and front-loads the core functionality.
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 that there's an output schema (which handles return values) and only one parameter, the description's brevity is somewhat acceptable. However, for a search tool with sibling alternatives and no annotations, it should provide more context about scope ('all' vs specific documentation sets) and basic behavioral expectations to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description mentions 'Search' but provides no additional semantic context about the 'query' parameter - no examples, format expectations, search syntax, or what constitutes a valid query. This leaves the single required parameter poorly understood.
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 the action ('Search') and target resource ('across all Cortex Cloud documentation sites'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling tools like 'search_cortex_api_docs' and 'search_cortex_docs', which appear to be more specific search variants.
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 provides no guidance on when to use this tool versus its siblings. It doesn't mention alternatives, exclusions, or specific contexts where this broad search is preferred over the more targeted 'search_cortex_api_docs' or 'search_cortex_docs' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure but offers minimal information. It doesn't describe whether this is a read-only operation, what authentication might be required, how results are returned, or any rate limits. The description only states what the tool does at a high level without operational details.
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 extremely concise at just four words, with zero wasted language. It's front-loaded with the core functionality and uses efficient phrasing. Every word earns its place in communicating the basic purpose.
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 has an output schema (which should document return values) and only one parameter, the description's minimalism is somewhat acceptable. However, with no annotations and 0% schema description coverage, the description should provide more guidance about usage context and parameter expectations to be truly complete for this search functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the single 'query' parameter is completely undocumented in the schema. The description provides no additional information about what the query parameter should contain, its format, or examples of valid inputs. This leaves significant ambiguity about how to use the tool effectively.
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 the verb ('Search') and resource ('Cortex Cloud API documentation'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'search_cortex_docs' or 'search_all_docs', leaving ambiguity about scope boundaries.
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?
No guidance is provided about when to use this tool versus alternatives like 'search_cortex_docs' or 'search_all_docs'. The description offers no context about appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('Search') without detailing what type of search is performed (full-text, keyword, semantic), how results are returned, pagination behavior, authentication requirements, or rate limits. For a search tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 extremely concise at three words, with zero wasted text. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place by conveying essential purpose without redundancy or fluff.
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 moderate complexity (search functionality), lack of annotations, and presence of an output schema, the description is minimally adequate. It states what the tool does but omits critical context like search scope, result format, and differentiation from siblings. The output schema may cover return values, but behavioral and usage gaps remain significant.
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 description adds no parameter information beyond what the schema provides. With 0% schema description coverage and only one parameter ('query'), the baseline is 3 since minimal parameters reduce documentation burden. However, the description doesn't clarify what the query should contain (e.g., keywords, natural language) or search syntax, missing opportunities to add value.
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 the tool's purpose: searching Cortex Cloud documentation. It uses a specific verb ('Search') and identifies the resource ('Cortex Cloud documentation'), which distinguishes it from general documentation search tools. However, it doesn't explicitly differentiate from sibling tools like 'search_all_docs' or 'search_cortex_api_docs', which would require more specific scope clarification.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_all_docs' and 'search_cortex_api_docs' available, there's no indication of scope differences, prerequisites, or appropriate contexts. Users must infer usage from tool names alone, which is insufficient for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions 'cached' documents, implying read-only behavior, but fails to detail aspects like authentication needs, rate limits, or what 'cached' specifically entails. This leaves significant gaps in understanding the tool's operational traits.
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, efficient sentence that front-loads the core purpose without any wasted words. It is appropriately sized for a simple tool with no parameters, making it easy to parse and understand quickly.
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 simplicity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It states what the tool does but lacks details on behavioral context and usage guidelines. The presence of an output schema means return values are documented elsewhere, but the description could better address operational aspects.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable here, but it doesn't compensate for any gaps since there are none. A baseline of 4 is appropriate as no parameters exist to explain.
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 the tool's purpose with a specific verb ('Check') and resource ('documents currently cached'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_all_docs' or 'index_cortex_api_docs', which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'search_all_docs' or 'index_cortex_docs'. It lacks context about prerequisites, timing, or comparisons to sibling tools, leaving the agent to infer usage scenarios independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions this is an indexing operation but doesn't disclose behavioral traits like whether it's idempotent, how long it takes, what happens if interrupted, or what authentication/rate limits apply. The description adds minimal context beyond the basic action.
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 extremely concise (two short sentences) and front-loaded with the essential information. Every word earns its place, with no wasted text or redundancy.
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 that there's an output schema (which should describe return values) and only one parameter, the description covers the essential 'what and when' adequately. However, for an indexing operation with no annotations, it should ideally mention more about the process (e.g., that it might take time, what 'indexing' entails).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about the 'max_pages' parameter - not what it means, why it's needed, or typical values. The description doesn't mention parameters at all, leaving the single parameter completely undocumented.
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 the action ('Index') and resource ('Cortex Cloud API documentation'), making the purpose understandable. However, it doesn't differentiate this tool from its sibling 'index_cortex_docs', which appears to be a similar indexing tool for different documentation.
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 usage guidance: 'Call this first before searching.' This clearly indicates when to use this tool (as a prerequisite step) and implies alternatives (the search tools listed as siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions indexing but doesn't disclose behavioral traits such as what 'indexing' entails (e.g., fetching, parsing, storing), whether it's a one-time or recurring operation, potential rate limits, or error handling. The description is too vague to inform the agent adequately about the tool's behavior beyond the basic action.
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 extremely concise with two short sentences that are front-loaded and waste no words. Every part of the description serves a clear purpose: stating the action and providing usage guidance.
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 that there is an output schema (which handles return values), the description's minimalism is partially acceptable. However, for a tool with no annotations and a parameter that lacks description coverage, the description should provide more context about what indexing involves and the implications of the 'max_pages' parameter to be fully 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?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about parameters. However, since there is only one parameter and it has a default value, the baseline is adjusted to 3, as the schema alone provides some structure without additional semantic context from the description.
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 the action ('Index') and resource ('Cortex Cloud documentation'), making the purpose understandable. However, it doesn't differentiate this tool from its sibling 'index_cortex_api_docs', which appears to serve a similar indexing function for API documentation specifically.
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 states 'Call this first before searching,' providing clear guidance on when to use this tool in relation to other tools (like search_cortex_docs). This directly addresses the context of sibling tools and establishes a prerequisite order.
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:

[![cortex-cloud-docs-mcp-server MCP server](https://glama.ai/mcp/servers/clarkemn/cortex-cloud-docs-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/clarkemn/cortex-cloud-docs-mcp-server)

Score Badge

Copy to your README.md:

[![cortex-cloud-docs-mcp-server MCP server](https://glama.ai/mcp/servers/clarkemn/cortex-cloud-docs-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/clarkemn/cortex-cloud-docs-mcp-server)

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/clarkemn/cortex-cloud-docs-mcp-server'

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