Scoopkit now has an MCP server at api.scoopkit.dev/mcp, so an AI agent (Claude, Cursor, or anything else that speaks MCP) can query AI industry news directly, without a human writing the REST calls by hand. It's live on every tier, free included, using the same X-Api-Key auth and tier gating as the REST API.
Verified 2026-08-30 against production with a real MCP client, not just the library's own claims.
Facts
| Tool | What it does | Requires a key? |
|---|---|---|
list_events | List and filter events by category, subcategory, time window | Yes |
get_event | Fetch one event by id | Yes |
search | Semantic search | Yes, Pro tier |
taxonomy | Full category/subcategory reference | No |
request_magic_link | Kick off free-tier signup by email | No |
Why MCP, not just REST
An AI agent's tool-calling standardizes on MCP, not raw REST. Without it, an agent that wants AI industry news either needs a human to wire up REST calls first, or can't use Scoopkit at all. The MCP server closes that gap by wrapping the same 4 read endpoints already documented at api.scoopkit.dev/docs, plus the signup step.
What's deliberately not exposed
The MCP server excludes 3 things on purpose, not by oversight: billing, webhooks, and 2 of the 4 auth endpoints.
Billing and webhooks are account and payment management, not something an agent should be doing on someone's behalf. Webhooks specifically also don't fit how a chat agent connects: they push data to a URL the subscriber controls, and a chat-based agent mid-conversation has no stable endpoint to receive a push to.
The bigger call is verify and verify/confirm, the 2 steps that actually mint a plaintext key. Getting a key requires a real human to click the emailed link themselves, the same security boundary described at scoopkit.dev/start: it's what stops email security scanners from silently consuming the link before a person ever sees it. An agent can kick off the email (request_magic_link), but finishing the flow needs a human, on purpose.
2 real bugs found shipping this, not just configuration
Wiring this up surfaced 2 real problems before it worked at all.
First, a dependency conflict: the MCP library this runs on requires an older major version of the underlying mcp package, but installing it alone resolved the newest release instead, a breaking version with a changed function signature. The app crashed on startup until the version got pinned down explicitly.
Second, and more important: the library only forwards specific HTTP headers from an incoming agent request into each tool call, and by default that allowlist doesn't include X-Api-Key at all, only Authorization. Left as default, every tool call would have silently dropped the API key before it ever reached Scoopkit's own auth check. That's not a crash you'd notice immediately: it would have looked like every agent request was simply unauthenticated, with no obvious cause. Fixed by explicitly adding the header to the forwarding allowlist.
Both were confirmed and fixed before this shipped, verified with a real MCP client against production: a valid key returns real data, a free-tier key calling search gets a real 403 instead of a crash, and a missing or invalid key gets a real 401.
Try it
Connect an MCP-compatible client to api.scoopkit.dev/mcp and call taxonomy first; it needs no key at all. For everything else, get a free API key and use it as X-Api-Key, the same way you would with the REST API.
FAQ
Does the MCP server require a paid plan?
No. list_events, get_event, taxonomy, and request_magic_link all work on the free tier. Only search needs Pro.
How is this different from just using the REST API?
Same data, same auth, same limits. The difference is the transport: an MCP-compatible agent can call these as native tools instead of a human writing REST calls for it.
Can an agent get a full API key without a human involved?
No, and that's intentional. An agent can request a magic-link email, but opening it and clicking through requires a real person.