Skip to main content
Glama

Search Redpanda Sources

ask_redpanda_question

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_kNoMaximum number of sections to return, applied after platform filtering. Must be a positive integer.
contextYesExplain 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."
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

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully discloses key behavior: returns url and markdown content, orders by relevance, and explains that platform filtering occurs post-retrieval and can drastically reduce results. This goes well beyond basic tool intent and informs agent expectations.

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 the core purpose, then efficiently adds return format, usage, and a critical caveat. Every sentence contributes, and despite length, it remains tightly structured without redundancy.

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

Completeness5/5

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

Given no output schema, the description adequately explains return values (url + markdown content) and ordering. It also covers an important behavioral nuance with platform filtering, making it complete for an agent to effectively invoke the tool.

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 description adds meaningful semantics for the 'platform' parameter, explaining its post-filter effect and the trade-off of omitting it, which is not fully captured in the schema. The schema already covers 75% of parameters, but the platform nuance is valuable.

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 searches the official Redpanda documentation and returns relevant sections, which is a specific verb+resource. It distinguishes from sibling tools like search_api_reference by targeting general Redpanda docs versus 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 says to use this tool for all Redpanda knowledge queries, and provides detailed guidance on when to pass 'platform' versus omit it, including a concrete trade-off. This gives clear context on usage and how to adapt based on user deployment.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: general docs search, API reference search, API reference listing, API content retrieval, and meta tool discovery. The potential overlap between search_api_reference and list_api_reference_pages is resolved by their differing functions and scoping parameters.

Naming Consistency4/5

Tool names consistently use imperative verbs with underscore separators (ask, get, list, search). The naming is readable and predictable, though 'ask_redpanda_question' is slightly less conventional than the clear 'api_reference' group.

Tool Count5/5

Five tools is well-scoped for a documentation MCP server, covering search, browsing, and content retrieval without unnecessary duplication or bloat.

Completeness4/5

The server covers general doc search, API reference search, listing, and content retrieval. A dedicated general-doc page fetcher is absent, but ask_redpanda_question returns content sections directly, so the gap is minor and workable.