Skip to main content

AutoSearch Channel Research Final Playbook

Date: 2026-04-19 Coverage: mcpmarket.com research + hands-on testing + TikHub paid API integration Positioning: This is the final master guide. The previously scattered docs (mcp-channel-research.md / mcp-test-plan.md / mcp-test-results.md / mcp-no-cookie-inventory.md / mcp-final-summary.md / tikhub-smoke-test.md) are consolidated here. All future channel decisions should start from this document.

TL;DR

Three-tier conclusion:
  1. Free and usable without cookies: Sogou WeChat, open-websearch (4 engines), Paper Search MCP (21 academic sources), PullPush (Reddit history), direct RSS reads, Jina Reader (some sites), and 13 official APIs.
  2. 5 of 8 hard targets were unblocked through paid TikHub: Xiaohongshu, Weibo, Zhihu, Twitter/X, and Douyin. The remaining 3 (flaky Weibo upstream, Instagram/LinkedIn parameters not fully tuned) were not fully solved in this round.
  3. Final architecture: AutoSearch uses BYOK (users provide their own TikHub key) and declares dependencies with requires: [env:TIKHUB_API_KEY]. The base URL is read from an env var so environments can switch cleanly.
Cost anchor: TikHub measured average cost is **0.0036/request.1000researchgradecallscostabout0.0036/request**. 1000 research-grade calls cost about 3.6/month.

A. Hands-On PASS in This Round (9)

B. Official APIs Known to Work (13, Integrated in AutoSearch or One-Line Integration)

C. New Categories Found on mcpmarket (AutoSearch Gaps) (11)

D. Existing Channel Reinforcements (8)


Part 2: Hard-Target Breakthrough Matrix

🔴 Integrated (Paid TikHub, 5/8)

⚠️ Not Fully Solved in This Round (3/8)

🟢 Truly Impossible Without Cookies

Facebook / Instagram public personal pages / Xiaohongshu private-account content / Twitter private accounts: even TikHub requires account support. These are not core to the research scenario, so do not invest for now.

Part 3: TikHub Field Notes

Basic Information

  • Homepage: https://tikhub.io · API base: https://api.tikhub.io/api/v1/
  • Auth: Authorization: Bearer $TIKHUB_API_KEY
  • OpenAPI spec: GET https://api.tikhub.io/openapi.json (1058 endpoints)
  • Billing: pay-per-request, average **0.0036/request(officialmarketingsaysstartsat0.0036/request** (official marketing says starts at 0.001; measured cost is 3-4x higher)
  • Free quota: Daily check-in gives a small amount of free credit

Platform Coverage (Confirmed Working)

16 platforms, 1000+ tools:

Key Pitfalls (In the Order Encountered)

  1. Registration requires email verification. Without verification, every endpoint returns 403 “email not verified”.
  2. The free tier covers only some endpoints. Xiaohongshu/Weibo/Twitter/Douyin all return 402 (Payment Required) until paid balance is > 0. Zhihu and Bilibili are covered by the free tier.
  3. Do not use web_v3 for Xiaohongshu. /xiaohongshu/web_v3/fetch_search_notes returns 400. Use the older /xiaohongshu/web/search_notes.
  4. Do not use app/v3 for Douyin. /douyin/app/v3/fetch_video_search_result returns 400. Use /douyin/web/fetch_video_search_result_v2; data is under data.business_data[i].data (two nested layers).
  5. Weibo endpoints are unstable across versions. web_v2/fetch_realtime_search returns 400; app/fetch_search_all returns 422; web/fetch_search returns 200 but cards fluctuates.
  6. 400 = upstream scraping failure, not necessarily bad parameters. TikHub’s 400 body says “please check docs and parameters”, but in practice TikHub itself failed to scrape the target site. This kind of 400 is not billed (Only pay for successful requests).
  7. Twitter structure is already flattened. data.timeline is a list, not the original GraphQL-style nested instructions structure. Iterate it directly. Fields: screen_name / text / favorites / views / retweets / replies / created_at / tweet_id / lang.

🚨 Security Note: The Key Is Echoed in Error Responses

TikHub 400 / 403 / 422 response bodies echo the full request headers, including auth information. Integration must:
Tests must include: assert exception string does not contain “Bearer”.

MCP vs API Choice

TikHub officially provides 4 transports: Stdio / SSE / Streamable HTTP / Curl(API). For AutoSearch: choose direct Curl/API calls, not MCP. Reasons:
  • AutoSearch is a Python plugin installed with pip install. Using MCP would require users to additionally install Node.js + mcp-remote + the TikHub MCP server (3 dependencies)
  • AutoSearch channels are already “tools”; calling MCP from inside a tool is tool-calling-a-tool, and JSON-RPC over stdio adds a useless serialization layer
  • Enabling the full TikHub MCP exposes 1000+ tool schemas and injects roughly 400K tokens into Claude context, which is untenable
  • Even selecting only the 6 hard-target platforms still exposes ~470 tools (~190K tokens), which is still not ideal
Good fit for Stdio MCP: ad hoc calls where a user in a Claude Code session wants to directly search Xiaohongshu, and this is for the user to install TikHub MCP themselves; it is unrelated to AutoSearch.

Part 4: Final AutoSearch Integration Architecture

BYOK (Bring Your Own Key) Is the Only Reasonable Plan

Do not:
  • ❌ Hardcode a TikHub key into the release build (a pip package exposes plaintext)
  • ❌ Share one key across all users (violates ToS and drains the balance)
Do:
  • ✅ Users register and top up at tikhub.io themselves
  • export TIKHUB_API_KEY=<your-key>, and AutoSearch reads the env var
  • ✅ SKILL.md declares requires: [env:TIKHUB_API_KEY]; without a key, the channel is automatically marked unavailable while other channels continue running

Channel Structure (Validated by Pilot)

fallback_chain order: [via_tikhub, api_search, api_answer_detail] — prefer TikHub when a key is present; fall back to the original path when no key exists.

Leave Room for a Future Proxy

tikhub_client.py reads the base URL from an env var:
If the upstream needs to be changed later, such as to a self-hosted proxy or mirror, users only need to change two env vars with zero code changes:

5 Channels Pending Integration (Priority Order)

After the pilot is validated, have Codex write the remaining 4 adapters in parallel from the same template. Each should be < 50 lines.

Appendix

A. Test Command Quick Reference (Copy-Paste Ready)

  • mcpmarket.com — research source for this round
  • tikhub.io — paid platform API
  • github.com/Aas-ee/open-webSearch — 8-engine free SERP
  • github.com/openags/paper-search-mcp — 21 academic sources
  • github.com/jacklenzotti/pullpush-mcp — Reddit history
  • r.jina.ai — free URL -> markdown via Jina Reader
Consolidated into this playbook, so you no longer need to read them day to day:
  • mcp-channel-research.md — initial research
  • mcp-channel-test-plan.md — test plan
  • mcp-test-results.md — first round of hands-on tests
  • mcp-no-cookie-inventory.md — no-cookie inventory
  • mcp-final-summary.md — phase summary
  • tikhub-smoke-test.md — detailed TikHub smoke test
Keep them archived for traceability, but in daily use, this playbook + tikhub-smoke-test.md is enough.

D. Cost Ledger (As of 2026-04-19)

  • TikHub: $0.053 (19 smoke requests)
  • Other: $0 (all free options)

Maintenance rule: When a new channel is integrated or a new hard target is unblocked, update the corresponding table in this playbook to keep it as the single source of truth.
This deeper mcpmarket.com pass found 12 fully no-key and no-cookie categories missed earlier. Ranked by research value:

🟡 Integrate As Needed

🟢 Basic Utilities (Occasional Use)

mcpmarket Has No Coverage for These Categories

  • Toutiao / Baijiahao / NetEase Hao (Chinese news aggregators)
  • Reuters / TechCrunch / Bloomberg (professional news, RSS only)
  • Coursera / edX / Khan Academy / MOOC
  • Chinese government open data (National Bureau of Statistics, customs)
  • ESPN / sports data
  • Air quality / environmental data / real-time carbon emissions
These can only be covered through RSS + Exa site:, or by waiting for future mcpmarket additions.

2026-04-19 Hands-On Verification (5 Core MCPs)

Smoke tests were run against the underlying APIs for the 5 most important MCPs for “basic facts / trends / AI Hub / metatools.” All passed: Key clarification: Public APIs Directory MCP (zazencodes/public-apis-mcp) does not depend on the now-dead api.publicapis.org at all. Its data is built-in JSON (1426 entries), and the embedding index is built locally (.npz file). So even though the old API domain now fails DNS resolution, the MCP works correctly. Pitfall warning — Google Trends: pytrends is an unofficial simulated-request library. Google occasionally changes cookie/token mechanics and breaks it. Integration must include retries + error tolerance and must not treat it as a hard dependency. It is much more fragile than the other 4 official APIs. Integration recommendation (lightest path): The first 4 can all be called directly through Python httpx against HTTP APIs; there is no need to start an MCP process. Public APIs Directory can have its index.json copied into AutoSearch and parsed locally. A 1426-row JSON file is small, and embeddings can be computed locally. This keeps AutoSearch free of new external process dependencies.

Updated AutoSearch Priority After the Scan

On top of the 6 “strongly recommended” basics in Part 1 section C, add 3 highest-priority items:
  1. FRED + World Bank (macroeconomic signals, no key and no cookie in one step)
  2. Public APIs Directory (metatool; lets AutoSearch automatically discover new channels)
  3. Open Library (foundation for academic/publishing research)
In total, AutoSearch should now add 9 channels to become the “only full-coverage research system in the market”:
All are 🟢 zero-key and zero-cookie. The implementation cost is small and the payoff is high. First integration batch (4 already verified): Wikipedia, Wikidata, Hugging Face, Public APIs Directory — Codex can write channel adapters immediately, each < 30 lines of Python + httpx code. Second integration batch (5 not yet smoke-tested): Google Trends, Google Patents, CVE/NVD, FRED, Open Library — proceed by research-scenario priority, and run a smoke test against the underlying API before each integration.