anysite-mcp

Anysite MCP — usage guide

The anysite MCP exposes hundreds of data sources through six universal meta-tools (plus the crm_* family, see Working with CRM). This skill is the map: how to call them, which sources cover which GTM need, and how to not waste credits.

The six meta-tools

Rules that prevent 90% of failures

1. Always discover before execute. Endpoint names and params are not guessable, and a wrong source name returns the full source list — a wrong guess self-corrects for free. execute takes the endpoint NAME exactly as discover returns it (products_reviews), never a REST path segment (reviews) — resolution is an exact-match lookup.
2. Never guess identifiers. LinkedIn aliases, URNs, Crunchbase aliases, Greenhouse board tokens are unpredictable. Resolve them through the search endpoint of the same source first.
3. Re-use the cache — it outlives the session. execute returns a cache_key; further filtering, sorting, counting and paging of that result is free, and the cache lives for 7 days across sessions. Before any paid execute, check search_requests (free) for a recent identical call — same endpoint, matching params — and reuse its cache_key via query_cache/get_page instead of refetching (verified live: a two-day-old cache_key from another session served in full). Freshness rule: reuse when the data's age is fine for the task (enrichment firmographics — usually yes; "what's new today" — no).
4. Cheap-first cascade. When several endpoints can answer, call the cached/DB one first (*/db/*, *sql* endpoints, ~1 credit) and the live one only for the remainder.
5. Estimate volume before bulk runs — plan-aware. First know the user's plan (the CRM profile stores it after setup; if unknown, ask once: MCP Unlimited or credit-based?).
   • Credit-based plan: before anything above ~100 calls, state the estimate (N targets × credits-per-call) and get a nod. Prefer cheap DB endpoints, batch hard.
   • MCP Unlimited: credit warnings off, but keep batch sizes sane anyway — the real limits are latency and upstream rate limits, so cap sweeps the same way and say "this will take ~N minutes" instead of a price.
6. Live LinkedIn search fails as an empty list, not an error. search_users and search_companies return {"results":[]} on queries that just don't hit ("stripe", "databar" both came back empty live, while "microsoft" worked) — it is not a broken key. On empty, switch to the search_sql_* DB endpoints; do NOT retry with broader keywords. (This is why reverse-lookup via live search_users is best-effort, not "usually one match".)
7. gdelt is slow by design, not broken — 10–50s per call is normal (upstream per-IP throttling), and worst cases exceed the MCP client's silent-call timeout, which looks like a hang. Endpoints: gdelt/articles/articles_search and articles_context (timespan like 3d/1w or start_datetime YYYYMMDDHHMMSS; count ≤250). Keep it OUT of per-account sweep loops (use techmeme / google news — seconds); fine for a one-off deep media dive with a "takes a minute" warning.