redis-docs-mcp

Redis Docs MCP

The redis-docs server exposes the redis.io documentation over MCP as search, fetch, and ask. Those tools carry their own descriptions, and on when to call each one they are accurate — start with search, fetch what you need, keep ask for questions that span several areas. This skill covers what they get wrong or leave out.

When to apply

• You are about to look something up through these tools.
• A result did not look like what the tool description promised.
• A search came back empty, or ask was rate-limited or declined to answer.

Reach for the sibling Redis skills first where they cover the topic — they carry curated guidance that raw docs pages do not. Use these tools to verify specifics and fill gaps.

1. Ids address sections, not pages

The tool descriptions say search returns "pages" and fetch returns "one Redis documentation page". The index is per section, and ids come in four shapes:

What follows from this:

• Repeated urls in one result set are not duplicates. Several hits often share a page url while carrying distinct ids — they are different sections of the same page. Tell them apart by their snippets, not their urls.
• #sec:wN ordinals are index windows. They come back in relevance order, not w0, w1, w2. Don't try to reassemble a page out of snippets; fetch the section you actually need.
• Never construct an id. Valid ids come from a search result or an ask result's sources[].id. Guessing happens to work for commands/<name> and fails on everything with sections.
• Snippets are truncated prefixes of the body, not summaries. When one cuts off mid-word right at the interesting part, fetch on that id is guaranteed to contain the continuation — no need to re-search with different words.
• Cite the page url and name the section in prose. #sec:w1 is an index address, not a web anchor. Ids with a named anchor (#sec:<name>, or #sec:<name>-wN) return a url with a usable fragment; bare #sec:wN ids don't.