Kindly Web Search MCP Server: Full StackOverflow Threads and GitHub Issue Comments in One Tool Call
Kindly Web Search MCP Server: Web search + robust content retrieval for AI coding tools (Claude Code, Codex, Cursor, GitHub Copilot, Gemini, etc.) and AI agents (Claude Desktop, OpenClaw, Hermes, etc.). Supports Serper, Tavily, and SearXNG.
At a glance
- What is it?
- Kindly Web Search is an MCP server that wraps Serper, Tavily or SearXNG for discovery, then routes each result URL through API-specific resolvers for StackExchange, GitHub Issues, GitHub Discussions, Wikipedia and arXiv. The design bet is that agents need the answers, not just the link.
- Who is it for?
- Adopt Kindly if your agent currently finds a StackOverflow URL and then stops, or if you are already paying for Serper or Tavily and want the page content returned in the same call. Do not adopt it if you need a search engine you host and control end to end with no third-party API key, or if your retrieval targets are mostly documentation sites and blogs where a plain HTML-to-Markdown fetch is sufficient.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Kindly targets: search results that stop at the snippet
Most web search MCP servers are thin wrappers over a search API. The agent calls the tool, gets back a title, a URL and a snippet, and then has to decide whether to make a second call to fetch the page. The README illustrates this with a Google Cloud Batch GPU error: the search returns a StackOverflow question whose snippet contains the problem statement and nothing else. The answers, the workarounds, the comments are all on the page, one call away, and the agent may or may not take that call.
Kindly's stated audience is narrow and specific. It is for developers running AI coding assistants (Claude Code, Codex, Cursor, Windsurf, Antigravity) and for agent runtimes such as Claude Desktop. The README frames the whole project around one observation from the maintainers' consulting work: when a developer hits a complex bug, they want the conversation, not the link. That is a retrieval-quality argument, not a search-quality argument, and it explains why the project spends most of its complexity budget on content extraction rather than on ranking.
Two tools, and a resolver chain that picks a handler per URL
The server exposes exactly two tools. `web_search(query, num_results=3)` returns the top results with `title`, `link`, `snippet` and `page_content`. `get_content(url)` returns `page_content` alone. Both mark the content as Markdown and describe it as best-effort, which is an honest label: extraction is not guaranteed to succeed for every URL.
The mechanism that matters is what happens between the search result and that `page_content` field. According to the README, each URL is routed through a priority chain of specialized handlers before falling back to a universal HTML loader. The documented order is StackExchange first, then GitHub Issues, then GitHub Discussions, then Wikipedia, then arXiv, and finally the universal loader for everything else. StackExchange goes through the StackExchange API, GitHub Issues and Discussions go through the GitHub GraphQL API, Wikipedia goes through the MediaWiki Action API, and arXiv uses the Atom API plus PDF-to-Markdown conversion.
This is the architectural decision worth understanding. Kindly is not scraping StackOverflow HTML and hoping the answer blocks survive. It is calling the same structured APIs a developer would call by hand, which is why the README can claim full conversations with answers, comments and reactions rather than a cleaned-up article body. The trade-off is that each specialized handler is a separate integration with its own failure modes and, for GitHub, its own authentication surface. The README's table lists the HTTP client for every handler as `httpx[socks]`, so the transport layer is uniform even though the upstream APIs are not.
Provider choice is a configuration decision, not a lock-in
Discovery is pluggable. The repository description names Serper, Tavily and SearXNG; the README's feature list is broader, naming Serper, SerpBase, Tavily, SearXNG, Sofya and You.com, with intelligent fallback between them. Those two lists do not match, and the README does not document the fallback order or the conditions that trigger a fallback. If you depend on a specific provider being tried first, that is something to confirm against the source rather than the README.
SearXNG is the interesting option in that list because it is the one you can self-host, which changes the cost and privacy profile of the discovery half of the pipeline. The other named providers are commercial APIs that require keys and carry quotas. Note that self-hosting SearXNG only removes the third-party dependency for discovery. The content resolver still reaches out to StackExchange, GitHub, Wikipedia, arXiv and arbitrary web pages, so a fully air-gapped deployment is not what this is.
Proxy support is documented per handler: `HTTP_PROXY`, `HTTPS_PROXY` and `ALL_PROXY`, with both HTTP and SOCKS5 supported through `httpx[socks]`. For teams behind a corporate egress proxy, that is the difference between the tool working and not working at all, and it is covered for every row of the resolver table.
Getting it running: MCP registration and the keys you must supply
The README does not include a full installation walkthrough in the material available here, so the exact install command and the precise environment variable names for each provider key are not something I can state. What the material does establish: this is a Python project, it is an MCP server, and it is registered with a client the same way other MCP servers are. The README's suite instructions say to install three MCP servers (Serena, Kindly Web Search, Lad MCP Server) plus the tdd skill, then prompt the agent normally and append `Follow $tdd` to the request.
What you will need to configure before it is useful: a search provider credential for whichever of Serper, Tavily or another commercial provider you choose, or a running SearXNG instance if you go that route. GitHub Issues and GitHub Discussions handlers use the GitHub GraphQL API, which is an authenticated API, so expect to supply a GitHub token as well. Proxy variables (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`) are the other configuration surface the README documents explicitly.
The one-call claim is worth restating precisely, because it is the reason to install this rather than a generic search wrapper. Because `web_search` returns `page_content` alongside the snippet, the agent gets the extracted conversation in the same tool response. There is no second round trip in the happy path.
Where the resolver chain breaks down
The specialized handlers cover five target types. Everything else falls to the universal HTML loader, and the README itself calls the Markdown output best-effort. That word is doing real work. If your agent spends most of its time reading vendor documentation, changelogs and blog posts, you are living entirely in the fallback path, and the value proposition that justifies the specialized handlers does not apply to you.
The second limitation is structural rather than a bug. The resolver chain is priority-ordered by URL type, so a single page that mixes content types gets one handler. A GitHub Issue that quotes an arXiv paper gets the GitHub handler. A StackOverflow answer linking to a GitHub repository gets the StackExchange handler. The agent can call `get_content` on the linked URL separately, but that reintroduces the multi-call pattern the project exists to avoid.
Third, the provider list discrepancy noted above is a documentation gap, not a capability gap, but it matters for anyone trying to reason about reliability. Intelligent fallback sounds reassuring until you need to know what happens when your primary provider returns a rate-limit error rather than an empty result set. The README does not say.
Finally, the project is young. The repository shows no retrieved releases, and the README's own framing is that of a tool the maintainers use daily in consulting work rather than a product with a published compatibility matrix. Version pinning is the sensible posture until the release cadence is visible.
Against a plain search wrapper plus a scraper
The obvious alternative is a generic search MCP server paired with a scraping MCP server, which is the combination the README explicitly says Kindly eliminates. The difference in approach is where the structure comes from. A scraper converts HTML to Markdown and hands the result to the model; the model then has to find the accepted answer inside a page that also contains a sidebar, a cookie banner and forty comments of varying relevance. Kindly asks the upstream API for the answer objects directly, so the structure is imposed by StackExchange or GitHub rather than inferred from markup.
A second alternative is a dedicated GitHub MCP server. The README concedes this partially: Kindly "significantly reduces reliance on GitHub MCP servers by providing structured Issue content through intelligent extraction." Reduces, not replaces. If your workflow needs to write to GitHub, open pull requests, manage branches or query beyond issues and discussions, a GitHub MCP server is still the right tool. Kindly reads issues and discussions and returns them as content. That is the entire overlap.
The honest comparison is cost and control. A self-hosted SearXNG plus a local scraper has no per-call API spend and no third-party key, at the price of worse extraction on the five target types. Kindly trades money and external dependencies for extraction quality on exactly the sources developers reach for when debugging.
Licence, maintenance and what the MIT grant actually covers
The project is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It does not grant you anything with respect to the upstream services the resolver chain calls: StackExchange, GitHub, Wikipedia and arXiv each have their own terms, rate limits and, in GitHub's case, authentication requirements. Running Kindly against the GitHub GraphQL API at volume is your relationship with GitHub, not the maintainer's. Nothing here is legal advice; if you are embedding this in a commercial product, read the MIT text and the upstream API terms together.
Maintenance cost concentrates in the resolver handlers. Five of the six rows in the README's table depend on a third-party API that can change shape: the GitHub GraphQL schema, the MediaWiki Action API, the StackExchange API, the arXiv Atom feed. When one of those changes, the corresponding handler breaks while the others keep working, which is a manageable failure mode but a recurring one. The universal HTML loader is the opposite: it depends on nothing specific and therefore degrades gradually rather than breaking.
The suite framing adds a coordination cost. Kindly is one of four components in the Shelpuk agentic suite, alongside Serena, Lad MCP Server and the tdd skill, and the README's quality-improvement claim (15 to 20 percent) is attached to the suite as a whole, not to this server in isolation. If you install Kindly alone, you are not reproducing whatever measurement produced that number. Treat it as the maintainer's claim about the combined setup and nothing more.
Editorial conclusion
Adopt Kindly if your agent currently finds a StackOverflow URL and then stops, or if you are already paying for Serper or Tavily and want the page content returned in the same call. Do not adopt it if you need a search engine you host and control end to end with no third-party API key, or if your retrieval targets are mostly documentation sites and blogs where a plain HTML-to-Markdown fetch is sufficient. Before wiring it into a workflow, verify three things yourself: which provider key you will supply and whether that provider's quota covers your call volume, whether GitHub GraphQL authentication is required for the issue and discussion handlers you depend on, and what the universal HTML loader returns for your two or three most common target domains, because that fallback is what handles everything outside the five specialized resolvers.
Community notes