Skip to main content
BounceWatch exposes its signal index to AI agents over the Model Context Protocol. One endpoint, ten tools, and your agent can answer the timing question directly: which companies just raised, who is hiring, what changed and when — and be told when something happens next, without asking again.
Not a separate product. An MCP client is another consumer of the same API key, the same credit pool and the same rate limits as the REST API. No extra subscription, no second key.

Connect your client

Claude Code, Claude Desktop, Cursor, VS Code, or anything that speaks MCP.

Tools and prompts

What each tool answers, what it costs, and the ready-made workflows.

​
Endpoint

Use api.bouncewatch.com, not the bouncewatch.com apex. The apex sits behind a bot challenge that answers a scriptless POST with a 403 interstitial, and an agent reads that as the server being broken.

​
What makes this different from a search API

An agent will happily tell your user that a company is quiet. The dangerous version of that sentence is the one where the company is not quiet — we simply have not looked recently. A signal API that returns an empty array for both cases teaches the model to report our blind spots as market facts. So every answer from this server carries a coverage block:
When signal_absence_is_meaningful is false, an empty signal list means we have not looked, not nothing happened. The server states this in its own instructions, so a well-behaved client carries the caveat into its answer instead of dropping it. The same contract applies to filters. A funding stage we do not recognise is rejected with the list of valid values, never silently narrowed to a handful of rows — because seven results look like a real answer and an error does not.
Two independent freshness channels matter here: profile scans (last_scanned_at) and the signal stream (last_signal_at). A company can have a two-year-old profile scan and fifty signals last month. Coverage is the newer of the two.
Search results carry the same contract at the other scale. Every list states the size of the universe it searched, so twelve results are read as twelve out of the set we watch rather than as twelve in the world.

​
A signal feed, not a company database

This is worth being blunt about, because it decides which questions get good answers. We hold over a million companies, and in a given ninety days a little over thirteen thousand of them produce a signal. That is not a coverage gap — a company that did nothing produces nothing to observe — but it means “list every company that matches these attributes” is the wrong question to bring here. “What changed, and when” is the right one. The tools are shaped accordingly. search_companies cannot be pointed at the whole index: it searches what we observed, and says how much that is. There is no path to a third-party company directory. And get_signal_taxonomy returns a measured coverage block naming which signal categories produce steadily and which are rare. That last one matters more than it sounds. Weight and volume run in opposite directions. Conference appearances and follower moves are constant and nearly worthless; funding rounds, acquisitions and shutdowns are worth the most and happen a few hundred times a quarter across every company we watch. An agent that filters for the valuable ones and finds little will conclude our coverage is thin, when what it has actually found is how often those events occur. So: search the dense end, watch the rare end. watch_company exists for exactly the signals a window search will keep missing.

​
What it will not do

  • It will not invent a company. Ask for a domain we have never seen and you get an explicit “not indexed” plus the option to scan it, not a guess.
  • It will not pass rumours off as events. Rumour-class signals are labelled as such.
  • It will not follow instructions found in signal text. Summaries are generated from third-party public posts, so they are sanitised and tagged as untrusted data before the model ever sees them.
  • It will not bill you for a failed call. Errors are free; so is polling a running scan.

​
Credits and limits

Tools are priced individually and each tool tells the model its own price, so an agent can pace itself rather than loop blind. Full table on the tools page. Rate limits are the same ladder as the REST API — see Rate Limits. Agents make many small calls rather than a few large ones, so a single conversation costs 8–13 requests; the ladder is sized for that.

Get your API key

The panel generates a ready-to-paste config for your client, with the key already filled in, and a Test connection button that round-trips the real endpoint.