docs-mcp
Server Details
Get authoritative answers to questions about Redpanda.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- redpanda-data/docs-site
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: general documentation search, API reference browsing (list, search, get content), and a meta-tool for discovering additional capabilities. No overlapping functions.
All tool names follow a consistent verb_noun pattern with underscores (ask, get, list, search). The naming style is uniform and predictable.
With 5 tools, the server is well-scoped for a documentation-focused MCP. Each tool addresses a necessary aspect without redundancy or bloat.
Covers general documentation queries and API reference lifecycle (search, list, get content). Minor gap: no explicit tool to browse or list general documentation pages beyond asking questions, but the core needs are met.
Available Tools
5 toolsask_redpanda_questionSearch Redpanda SourcesAInspect
Search the official Redpanda documentation and return the most relevant sections from it for a user query. Each returned section includes the url and its actual content in markdown. Use this tool for all queries that require Redpanda knowledge. Results are ordered by relevance, with the most relevant result returned first.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| question | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses ordering by relevance and output format (url, markdown content). Missing limitations like rate limits, authentication, or error handling; adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence gives purpose and output format, second sentence provides usage guidance and ordering info. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description covers basic functionality and output format but omits details like default behavior of 'top_k', error cases, and the required 'context' parameter's intent. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%); only 'context' has a description in schema. The tool description adds no parameter-level information, not even mentioning 'top_k' or explaining how 'question' is used. Fails to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches official Redpanda documentation and returns relevant sections with url and content. It differentiates from sibling tools which focus on API reference. Verb (search) and resource (Redpanda documentation) are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool for all queries that require Redpanda knowledge', giving clear when-to-use guidance. However, it does not exclude cases better handled by sibling tools (e.g., API reference), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_reference_contentGet API Reference ContentAInspect
Retrieve full content of API reference pages by URL. Returns complete endpoint details including parameters, request/response schemas, and examples.
Use this after finding pages via list_api_reference_pages or search_api_reference. Pass the URLs from those results directly.
Returns up to 10 pages per request. URLs must be from docs.redpanda.com/api/doc/*.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Page URLs to retrieve (max 10). Use URLs from list_api_reference_pages or search_api_reference results. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses behavioral traits: returns up to 10 pages, URLs must be from docs.redpanda.com/api/doc/*, and describes the output content (parameters, schemas, examples). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the main purpose, and each sentence adds necessary information without redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return content (complete endpoint details, schemas, examples) and usage constraints (max 10 pages, URL domain). It also references sibling tools for context, making it complete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds minor value by repeating the max 10 limit and providing usage guidance for 'urls', but the schema already defines 'maxItems' and the 'context' parameter has a detailed schema description. The description adds little beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full content of API reference pages by URL, specifying it returns endpoint details including parameters, schemas, and examples. It distinguishes from siblings by instructing to use this after finding pages via list_api_reference_pages or search_api_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Use this after finding pages via list_api_reference_pages or search_api_reference') and provides a constraint ('Returns up to 10 pages per request'). It lacks explicit 'when not to use' statements but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_more_toolsAInspect
Check for additional tools whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | A description of your goal and what kind of tool would help accomplish it. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'check', implying read-only, but does not explicitly confirm non-destructive behavior or describe side effects. Could be more transparent about what calling the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with the key action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It lacks hints about the return format or how the results will be presented, but the purpose and usage are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the context parameter well, but the tool description adds valuable context on when to use it and what kind of description to provide, complementing the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check for additional tools' which is a specific verb-resource pair. It distinguishes from sibling tools that are about asking questions or retrieving reference content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'whenever your task might benefit from specialized capabilities - even if existing tools could work as a fallback', providing clear context. Does not mention explicit alternatives but implies when to consider it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_api_reference_pagesList API Reference PagesAInspect
List pages in Redpanda API reference documentation. Returns endpoints, schemas, and topic pages with URL, title, type, and description.
SCOPING (important for accurate results):
api="all" or omit: Lists all available APIs
api="admin": Cluster management operations (brokers, partitions, configs, users)
api="cloud-controlplane": Redpanda Cloud resource management (clusters, networks, namespaces)
api="cloud-dataplane": Cloud cluster data operations (topics, ACLs, connectors)
api="http-proxy": Kafka operations over HTTP (produce, consume, offsets)
api="schema-registry": Schema management (register, retrieve, compatibility)
Use this to browse API structure. For general Redpanda docs, use ask_redpanda_question instead.
| Name | Required | Description | Default |
|---|---|---|---|
| api | No | Which API to list: "all" or omit for overview of all APIs, or a specific API name (admin, cloud-controlplane, cloud-dataplane, http-proxy, schema-registry) | |
| url | No | Specific URL path to list children of (optional, defaults to API root) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently explains the tool returns a list of pages with specified fields and how the 'api' parameter affects results. However, it does not explicitly state that the operation is read-only or mention any rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise summary followed by a clear scoping section. Every sentence adds necessary context without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields (URL, title, type, description). It covers all parameters fully. However, it does not mention if results are paginated or if there are limits on the number of pages returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by detailing each possible value for the 'api' parameter, clarifying that 'url' is optional, and explaining the 'context' parameter's purpose. This goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pages from Redpanda API reference documentation, specifying it returns endpoints, schemas, and topic pages with URL, title, type, and description. It distinguishes from sibling tools like 'ask_redpanda_question' and 'search_api_reference' by focusing on browsing API structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit scoping guidelines for the 'api' parameter, explaining the meaning of each value. It also advises using 'ask_redpanda_question' for general Redpanda docs, offering 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.
search_api_referenceSearch API ReferenceAInspect
Search Redpanda API reference documentation by keyword. Returns up to 20 matching endpoints, schemas, or topics with URL, title, and text excerpts.
SCOPING (important for accurate results):
api="all" or omit: Search across ALL APIs at once - useful when unsure which API contains the endpoint
api="admin": Search only cluster management (brokers, partitions, configs, users, maintenance)
api="cloud-controlplane": Search only Cloud resource management (clusters, networks, namespaces)
api="cloud-dataplane": Search only Cloud data operations (topics, ACLs, connectors)
api="http-proxy": Search only HTTP Proxy (produce, consume, offsets over HTTP)
api="schema-registry": Search only Schema Registry (register, retrieve, compatibility)
WHEN TO USE WHICH:
User asks "broker endpoints" → api="admin" (brokers are cluster management)
User asks "create topic API" → api="all" (topics exist in admin AND cloud-dataplane)
User asks "Cloud cluster API" → api="cloud-controlplane"
User asks about Redpanda APIs generally → api="all" or omit
For general Redpanda questions (not API-specific), use ask_redpanda_question instead.
| Name | Required | Description | Default |
|---|---|---|---|
| api | No | Scope: "all" or omit to search all APIs, or specific API name (admin, cloud-controlplane, cloud-dataplane, http-proxy, schema-registry) | |
| type | No | Filter by type: operation (endpoints), schema (data types), topic (guides), authentication, webhook | |
| query | Yes | Search keywords (e.g., "broker", "create topic", "ACL") | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return limit ('up to 20') and return format (URL, title, text excerpts). It explains scoping behavior but does not mention rate limits or authentication requirements, though these are not critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections 'SCOPING' and 'WHEN TO USE WHICH'. Front-loaded with main purpose. Some redundancy in repeating api values, but overall clear and organized. Not overly verbose for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (2 required) and no output schema, the description thoroughly covers input semantics. It differentiates from sibling tools and provides usage examples. Missing some output details but adequate for a search tool. The instructions for 'context' parameter are particularly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds significant value: lists all api values with use cases, explains 'type' filter options, gives query examples, and provides detailed instructions for the 'context' parameter including word count, perspective, and example. This far exceeds schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Redpanda API reference documentation by keyword' specifying the verb (search) and resource (API reference documentation). It distinguishes itself from sibling tools like ask_redpanda_question by noting 'For general Redpanda questions (not API-specific), use ask_redpanda_question instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with a dedicated 'WHEN TO USE WHICH' section and examples like 'User asks "broker endpoints" → api="admin"'. Also explicitly states when to use the sibling tool ask_redpanda_question. The 'SCOPING' section explains context for each api value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!