Skip to main content
Glama

docs-mcp

by com.redpanda
OverviewDiscussionsAdmin

Server Details

Get authoritative answers about Redpanda documentation and search API references.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
97.1% over 40 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL
Repository
redpanda-data/docs-site
GitHub Stars
1

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation4/5

The tools are mostly distinct: ask_redpanda_question targets general docs, search_api_reference and list_api_reference_pages target API reference, get_api_reference_content retrieves specific API pages, and submit_documentation_feedback is clearly separate. ask_redpanda_question and search_api_reference could briefly be confused, but their descriptions and usage guidance clarify the boundary.

Naming Consistency4/5

All names use lowercase snake_case and start with an action verb such as ask, get, list, search, or submit, giving a mostly consistent verb_noun pattern. get_more_tools is the outlier because it is a generic meta-tool rather than a documentation operation, but the overall naming scheme is still predictable.

Tool Count5/5

Six tools is a well-scoped size for a documentation MCP server. The set covers search, browsing, retrieval, and feedback without being bloated, and each tool has a clear role in the documentation workflow.

Completeness4/5

The tool set covers the core documentation domain well: general docs search, API reference listing/search/retrieval, and user feedback. A minor gap is the lack of a direct way to fetch an arbitrary general documentation page by URL, but ask_redpanda_question returns relevant content sections, so agents can work around it.

Available Tools

6 tools
ask_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. If you know the user's deployment platform, pass "platform" so results from the other platform's docs are excluded. Note that "platform" filters the sections already retrieved rather than re-running the search, so it can return substantially fewer sections: on a broker-level question where most matches come from the other platform's docs, it can cut a 15-section response to 1 or 2. Omit "platform" if you would rather have more context and judge platform relevance yourself from each section's url. If you know which Redpanda version the user runs, pass "version" (use 'current' for the latest release; its release number is also accepted). Unlike "platform", "version" is applied during retrieval, so it does not shrink the result set: it stops the same page being returned once per indexed version, which is otherwise most of the response. Version-neutral docs (Cloud, Connect, Agentic Data Plane, API reference) are always included. Omitting "version" searches the latest release.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_kNoMaximum number of sections to return, applied after platform filtering. Must be a positive integer.
contextNoOptional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets.
versionNoDocs version to search, written as the docs URLs spell it (23.3, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 26.1, current). Use 'current' for the latest release; a release number newer than every listed one is also read as the latest release. Applied at retrieval, so unlike "platform" it does not shrink the result set: every section returned is from this version, plus version-neutral docs (Cloud, Connect, Agentic Data Plane, API reference), which are always included. Omit to search the latest release. Any other value is rejected with the list of valid versions.
platformNoThe user's deployment platform. 'cloud' excludes Self-Managed sections; 'self-managed' excludes Redpanda Cloud sections. Platform-neutral docs (Connect, API reference, labs) are always kept. Applied after retrieval, so it shrinks the result set rather than finding more of the right platform's pages. Omit to search all docs.
questionYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it excels. It discloses that 'platform' filters already-retrieved sections (post-retrieval), which can significantly reduce the result set, and that 'version' is applied during retrieval and does not shrink results. It also explains that version-neutral docs are always included and that results are ordered by relevance. This level of behavioral detail is beyond what the schema provides and is essential for correct invocation.

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 moderately long but every sentence earns its place. It front-loads the purpose and then systematically explains the two optional parameters with their trade-offs. The structure is logical and scannable, with no redundant or filler content. The length is justified by the need to convey complex filtering behavior.

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 has 5 parameters (1 required), no output schema, and no annotations, the description covers all essential aspects: what it does, how results are ordered, the effect of each filtering parameter, and what is always included. It also addresses the trade-offs of omitting parameters. An agent has enough information to call this tool correctly without needing additional context.

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 schema already describes each parameter with 80% coverage, the description adds critical semantic nuances. For 'platform', it explains the filtering is applied after retrieval, affecting result count, and suggests omitting it for more context. For 'version', it clarifies the application timing and that it doesn't shrink results. These insights go well beyond the schema's static descriptions and materially help an agent choose parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search'), the resource ('official Redpanda documentation'), and the outcome ('return the most relevant sections'). It also specifies the return format (URL and content in markdown). It distinguishes itself from sibling tools by focusing on general docs rather than API reference, which is evident from the context even though it doesn't name alternatives explicitly.

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 'Use this tool for all queries that require Redpanda knowledge', which is a direct usage directive. It provides detailed guidance on when to pass 'platform' (when you know the deployment platform) and when to omit it (for more context), and similarly for 'version' (when you know the version, with clarification that it doesn't shrink results). It also explains the trade-offs clearly, so an agent knows exactly when to use this tool and how to tailor parameters.

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/*.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYesPage URLs to retrieve (max 10). Use URLs from list_api_reference_pages or search_api_reference results.
contextNoOptional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets.

TDQS

A4.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Retrieve', 'Returns') but does not explicitly state side effects, permissions, or error behaviors. It lacks detail on what happens if URLs are invalid or if limits are exceeded.

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 and well-structured, with three short sentences covering purpose, usage guidance, and constraints. No redundant or vague phrasing.

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 retrieval tool, the description provides sufficient context: what it returns (endpoint details, schemas, examples), how to use it (after list/search), and resource limits. The lack of an output schema is acceptable given the straightforward purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters. The description adds value beyond the schema by explaining the URLs parameter's source (results from sibling tools) and max limit (10), and the optional context parameter's content requirements and exclusion of sensitive data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieve' and the resource 'full content of API reference pages by URL'. It explicitly distinguishes itself from sibling tools by instructing to use it after 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Use this after finding pages via list_api_reference_pages or search_api_reference. Pass the URLs from those results directly.' It also gives operational constraints (max 10 pages, URL domain restriction).

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesA description of your goal and what kind of tool would help accomplish it.

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It states the action ('Check for additional tools') but does not disclose what the tool returns or any side effects. The behavior is fairly self-explanatory for a discovery tool, but the output format is 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 a single sentence, front-loaded with the action, and contains no unnecessary words. It is appropriately sized for the tool's simplicity.

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?

For a simple tool with one parameter and no output schema, the description explains when to use it but does not mention the return value or any further details. This leaves a moderate gap in understanding the tool's full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully covers the one parameter 'context' with a clear description (100% coverage), so the tool description adds no additional parameter semantics. Baseline 3 applies per the rules.

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 action ('Check for additional tools') and specifies the purpose ('whenever your task might benefit from specialized capabilities'). It distinguishes itself from sibling tools that handle API reference queries, like search_api_reference or get_api_reference_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?

It explicitly states when to use the tool ('whenever your task might benefit from specialized capabilities') and even encourages use when existing tools could work ('even if existing tools could work as a fallback'). This provides a clear decision rule for the agent.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
apiNoWhich 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)
urlNoSpecific URL path to list children of (optional, defaults to API root)
contextNoOptional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It uses non-destructive language ('List', 'Returns') and describes browsing, implying a read-only operation. It does not explicitly state the absence of side effects, but no side effects are suggested.

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 a separate SCOPING section and uses concise sentences. It is somewhat lengthy but remains on-topic and easy to scan, aiding comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions the output fields (URL, title, type, description) and provides usage context, including the context parameter guidance. It does not address error handling or pagination, but for a simple listing function this is acceptable and sufficiently complete.

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 three parameters (api, url, context) have schema descriptions, and the description adds a scoping section that elaborates on the api parameter values. This significantly enhances understanding beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists pages in Redpapi API reference documentation and specifies what it returns (endpoints, schemas, topic pages with URL, title, type, description). It also contrasts with ask_redpanda_question, making its purpose distinct from a key sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this to browse API structure' and contrasts with ask_redpanda_question ('For general Redpanda docs, use ask_redpanda_question instead'). It also provides detailed scoping for the api parameter. However, it does not explicitly differentiate from search_api_reference or get_api_reference_content, leaving some ambiguity.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
apiNoScope: "all" or omit to search all APIs, or specific API name (admin, cloud-controlplane, cloud-dataplane, http-proxy, schema-registry)
typeNoFilter by type: operation (endpoints), schema (data types), topic (guides), authentication, webhook
queryYesSearch keywords (e.g., "broker", "create topic", "ACL")
contextNoOptional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets.

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are empty, so the description carries the burden. It discloses the search nature and result limit ('Returns up to 20'), but does not explicitly state it is read-only or mention any side effects. However, for a search tool this is largely implied, and no misleading claims are present.

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-structured with clear sections (SCOPING, WHEN TO USE WHICH) and avoids unnecessary verbosity. Each sentence serves a purpose, and the formatting improves readability.

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 provides sufficient context for an agent to decide when and how to use the tool, including scope options, example queries, and sibling-tool differentiation. It also hints at output format, covering the essential operational context.

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 four parameters have descriptive schema entries, and the description adds extra context for the 'api' parameter with concrete examples and conditions. This goes beyond the schema's basic 'Scope' note, fully clarifying parameter 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: 'Search Redpanda API reference documentation by keyword.' It also specifies the output (returns up to 20 matching endpoints, schemas, or topics) and explicitly differentiates from sibling tool ask_redpanda_question by directing general questions elsewhere.

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 scoping guidance with examples (e.g., 'broker endpoints' → api='admin') and a clear rule for when to use ask_redpanda_question instead. This gives agents direct criteria for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_documentation_feedbackSubmit Documentation FeedbackAInspect

Send feedback about the Redpanda documentation or products directly to the Redpanda team.

If the user hits a bug, a documentation gap, incorrect or missing information, or expresses frustration while using Redpanda, ASK whether they'd like to send feedback to the Redpanda team. Only call this tool once the user agrees — never submit feedback without their consent. When telling the user what will be sent, note that their work email and company domain are attached so the team can follow up. Summarize their feedback clearly and include the relevant documentation page URL or context when you know it.

This tool requires the user to be signed in with a Redpanda Cloud account, because feedback the team cannot reply to is not useful. If the call is refused with authentication_required, the MCP connection itself is unauthenticated: tell the user to reconnect this server so their client runs its sign-in flow (signing in at https://docs.redpanda.com/login in their default browser first makes that hop quicker), and do not retry the tool until they have. Signing in on the docs website alone does not authenticate this connection.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextNoOptional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets.
categoryNoThe type of feedback.
feedbackYesThe user feedback to submit, in clear prose. Summarize the bug, gap, or request.
page_urlNoThe documentation page URL the feedback relates to, if known.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses side effects (feedback sent to Redpanda team, work email and company domain attached), the sign-in requirement, and the exact behavior on auth failure. This is strong transparency for a tool with no annotation coverage.

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: purpose first, then consent and content guidance, then authentication handling. It is longer than minimal, but each sentence carries operational value; the auth section is detailed but necessary for correct failure recovery.

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 4-parameter submission tool with no output schema and no annotations, the description is complete: it covers consent, content, authentication prerequisites, and error handling. An agent has everything needed to decide when to call, what to submit, and how to recover from auth failures.

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 the baseline is 3. The description adds meaningful guidance by telling the agent to summarize feedback clearly and include the relevant documentation page URL or context, which clarifies how the feedback and page_url parameters should be populated beyond their 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 states a specific action ('Send feedback... directly to the Redpanda team') with a clear resource and recipient. It is distinct from the sibling reference and Q&A tools, which are read/answer oriented rather than submission-oriented.

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 gives explicit when-to-use triggers (bug, documentation gap, incorrect/missing information, frustration), requires asking the user and obtaining consent, and explicitly forbids calling without consent. It also provides concrete handling for the authentication_required failure, including reconnecting instructions and when not to retry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedask_redpanda_question1 field changed
      • addedInput schema / properties / version
        Added value: +{
+  "description": "Docs version to search, written as the docs URLs spell it (23.3, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 26.1, current). Use 'current' for the latest release; a release number newer than every listed one is also read as the latest release. Applied at retrieval, so unlike \"platform\" it does not shrink the result set: every section returned is from this version, plus version-neutral docs (Cloud, Connect, Agentic Data Plane, API reference), which are always included. Omit to search the latest release. Any other value is rejected with the list of valid versions.",
+  "type": "string"
+}
  2. 5 tool updates
    • Changedask_redpanda_question3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Optional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets."
      • changedInput schema / required
        Previous value: -[
-  "question",
-  "context"
-]New value: +[
+  "question"
+]
    • Changedget_api_reference_content3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Optional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets."
      • changedInput schema / required
        Previous value: -[
-  "urls",
-  "context"
-]New value: +[
+  "urls"
+]
    • Changedlist_api_reference_pages3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Optional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets."
      • removedInput schema / required
        Removed value: -[
-  "context"
-]
    • Changedsearch_api_reference3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Optional. In one concise sentence (third person), describe what the user is trying to accomplish with this request. Do not include credentials, tokens, personal data, or verbatim secrets."
      • changedInput schema / required
        Previous value: -[
-  "query",
-  "context"
-]New value: +[
+  "query"
+]
    • Addedsubmit_documentation_feedback
  3. 1 tool update
    • Changedask_redpanda_question4 fields changed
      • addedInput schema / properties / platform
        Added value: +{
+  "description": "The user's deployment platform. 'cloud' excludes Self-Managed sections; 'self-managed' excludes Redpanda Cloud sections. Platform-neutral docs (Connect, API reference, labs) are always kept. Applied after retrieval, so it shrinks the result set rather than finding more of the right platform's pages. Omit to search all docs.",
+  "enum": [
+    "cloud",
+    "self-managed"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / top_k / description
        Added value: +"Maximum number of sections to return, applied after platform filtering. Must be a positive integer."
      • addedInput schema / properties / top_k / exclusiveMinimum
        Added value: +0
      • changedInput schema / properties / top_k / type
        Previous value: -"number"New value: +"integer"
  4. 5 tool updates
    • Changedask_redpanda_question3 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / context
        Added value: +{
+  "description": "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.\"",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "question"
-]New value: +[
+  "question",
+  "context"
+]
    • Addedget_api_reference_content
    • Addedget_more_tools
    • Addedlist_api_reference_pages
    • Addedsearch_api_reference
  5. 1 tool update
    • First observedask_redpanda_question

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources