Bounce Watch MCP is a hosted Model Context Protocol server for finding out what changed at companies and when, using dated, weighted signals tracked across 40+ event types.
Search signals: Query the latest company events by date window, signal type, category, country, headcount, funding stage, founded year, and minimum weight.
Find and profile companies: Look up a company by name to get its domain, then retrieve firmographic details like location, headcount, funding history, tech stack, team, and competitors.
Get company timelines: Pull dated signal histories for a specific company — funding, hiring, partnerships, product launches, leadership changes, risk events, and more.
Watch companies: Set up standing watches with filters (signal keys, minimum weight, webhook delivery) so new matching events are queued and collected via a personal inbox.
Refresh company data: Queue fresh scans of a company (signals, funding, team, technology, business, competitors) and poll for completion.
Use saved prompts: Run pre-built prompts like pre-round radar, why-now outreach angles, funded-and-hiring detection, account watch briefs, and risk scans.
Explore the taxonomy: List every signal type and category, free of charge, to design accurate searches.
Understand coverage: Results include coverage metadata so you know whether an empty or thin result reflects a real quiet company or a scanning gap.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bounce Watch MCP What signals has OpenAI had this month?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Find out what changed at a company, and when.
Bounce Watch tracks buying and momentum signals for companies — who raised money, who hired a senior person, who opened an office, won a customer, or announced a partnership. Over forty kinds of event, and every one carries the date it happened. This repository holds the connection details and client configs for the hosted Model Context Protocol server.
The server itself is hosted. There is nothing to install or run.
https://api.bouncewatch.com/api/v1/mcpTransport: HTTP streamable
Auth: OAuth, or an API key in X-API-Key / Authorization: Bearer
Browsable without either: the handshake, the tool list and the prompt list answer an unauthenticated caller, so you can see what this offers before you have an account. Running a tool needs one.
There is a Dockerfile here for running the launcher inside a container. It
packages the launcher and nothing else — the server itself is hosted, so running
the image gives you a connection to Bounce Watch, not a copy of it.
Free tier: 2,500 credits on every new account. No card, no expiry.
Registry name: com.bouncewatch/signals
claude mcp add bouncewatch --transport http https://api.bouncewatch.com/api/v1/mcpPress Connect and approve in the browser. No key to paste.
Ready-made config files are in clients/. Cursor takes the URL
directly:
{
"mcpServers": {
"bouncewatch": {
"url": "https://api.bouncewatch.com/api/v1/mcp"
}
}
}Add it in the app: Settings → Connectors → Add custom connector, with the URL above. Claude Desktop's config file will not take a remote URL — that file is for servers running on your own machine.
If you would rather keep it in the config file anyway, point it at the launcher below.
For clients that cannot open an HTTP connection, this repository publishes a launcher — a transparent pipe to the same endpoint, with no dependencies:
{
"mcpServers": {
"bouncewatch": {
"command": "npx",
"args": ["-y", "@bouncewatch/mcp"],
"env": { "BOUNCEWATCH_API_KEY": "your-key" }
}
}
}Both connect to remote MCP servers without any custom node or app. Paste the URL,
add your API key as a header, and the tool list loads itself. See
clients/n8n.md and clients/make.md.
Related MCP server: FundzWatch MCP Server
Ask in plain language. The server answers with real company names, dates and sources.
"Which Dutch companies under 50 people raised in the last month?"
"What has been happening at stripe.com?"
"Which companies in Belgium announced a partnership in the last two weeks?"
"Tell me the next time something happens at these twelve accounts."
Ten tools, eight of them read-only.
Tool | What it does |
| The latest signals across the whole index — which companies did something recently, what it was, and when |
| Find companies by country, headcount and funding stage |
| Look up a company by name and get its domain |
| Firmographic profile of one company |
| The dated signal timeline for one company |
| Queue a fresh scan of one company |
| Check a queued scan. Free to call |
| Put a standing watch on a company |
| What happened at the companies this key already watches |
| Every signal type, grouped by category. Free to call |
refresh_company and watch_company are the two that write.
Five saved prompts ship with the server.
Prompt | What it is for |
| Companies showing growth momentum that have not raised recently — the ones likely raising soon |
| An outreach angle for one company: what changed, why it matters, what to open with |
| Closed a round and hiring in the same window — new budget plus a mandate to spend it |
| What happened at a named list of companies since a given date |
| Layoffs, shutdowns and leadership exits across a list of companies |
Every signal carries its own date. Not the date we found it — the date the thing happened. That is what lets you separate this week's news from last year's.
Every signal carries a weight from 1 to 10. A funding round outranks a conference booth. Roughly a third of what happens at any company is background — event attendance, news mentions, follower drift — and all of it is weighted 1 or 2 so you can drop it in one filter. Set a floor of 3 or 4 and you are searching on substance.
An empty result is not the same as a quiet company. Every answer states how recently the company was looked at. When coverage is thin, the answer says so rather than implying nothing happened.
One question typically costs around 50 credits — a signal search plus a timeline
for a handful of companies — so the free tier's 2,500 credits cover about 50 of
them. get_signal_taxonomy and get_refresh_status cost nothing at all.
Keys and balances: https://bouncewatch.com/api-panel/mcp
Official MCP Registry, as com.bouncewatch/signals
(entry)
Documentation: https://docs.bouncewatch.com/mcp/overview
Pricing: https://bouncewatch.com/pricing
Product: https://bouncewatch.com
MIT. See LICENSE. The hosted service itself is a commercial product; this repository covers the connection details and examples.
Returns what has happened at the companies THIS KEY ALREADY WATCHES, since the last time you asked.
This is a personal inbox, not a view of the index. Use it when the question is about continuity — "anything new since last time", "what did I miss", "what fired on my watchlist". If the question is what is happening at companies generally — latest signals, who raised, who is hiring, anything about the market or a company not already watched — that is search_signals, and this tool cannot answer it.
Do not open a session with this call. Answer what was actually asked first; reach for this when the user's question is about their own watches.
Each event is handed over once: collecting it marks it seen, so the next call returns only what is new. Pass include_acknowledged to re-read ones you already collected.
An empty result means nothing matched YOUR watches. It is not a statement about the market, and if you hold no watches it says nothing at all — the response reports how many you have so the two cases can be told apart.
The response also lists your active watches, so this is the only call needed to see both what fired and what is armed.
Cost: free — call it as often as you need.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events to return. Default 25, max 100. Anything beyond the limit stays queued for the next call. | |
| domain | No | Only events for this watched domain. | |
| include_acknowledged | No | Also return events already collected, and do not acknowledge anything on this call. Use when you lost context and need to re-read. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses stateful behavior: 'Each event is handed over once: collecting it marks it seen, so the next call returns only what is new.' It also explains the meaning of empty results and that the response includes active watches. This enriches the annotation signals without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with clear sections and front-loaded purpose. It's longer than typical but every sentence adds value, whether explaining the personal-inbox metaphor or the cost implication. The only minor quibble is that some information (like 'Cost: free') could be inferred from annotations, but it doesn't feel padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's stateful nature and potential for user confusion, the description covers all critical bases: what counts as 'new', how acknowledgment works, what empty results mean, and how to recover from lost context. It also notes that the response includes active watches, which is a key piece of information for callers. No gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already covers all parameters, the description adds crucial semantics beyond a simple restatement. For example, it explains the limit parameter's behavior ('Anything beyond the limit stays queued for the next call') and clarifies include_acknowledged's purpose for re-reading. This goes beyond the schema's basic definitions, though the schema itself is quite good.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a crystal-clear purpose: 'Returns what has happened at the companies THIS KEY ALREADY WATCHES, since the last time you asked.' It explicitly distinguishes itself from sibling search_signals by saying 'that is search_signals, and this tool cannot answer it.' This is a specific verb+resource+scope with clear differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use it when the question is about continuity — "anything new since last time", "what did I miss", "what fired on my watchlist".' It names the alternative tool (search_signals) and explicitly states what this tool cannot do. It also warns against opening a session with this call, giving practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a company in the BounceWatch index by name, and returns its domain — which is what every other company tool needs.
Use this whenever you have a company's NAME rather than its domain. Do not guess the domain: a wrong guess comes back as "not indexed" for a company we actually hold, and sends you on to spend a scan on a domain nobody checked.
Returns up to a handful of candidates with just enough to tell them apart — country, founding year, headcount, and when we last saw a signal. It never picks for you: names are ambiguous and you have the context that decides. If several look plausible, say so rather than choosing silently. Once you have picked, get_company returns the full profile.
An empty result means no company by that name is in our index. It is not a statement about whether the company exists. If you know its domain, refresh_company indexes it.
Cost: 3 credits per call. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Company name to look for, e.g. "Silk and Cashmere". A domain is also accepted and resolved directly. | |
| limit | No | Max candidates to return. Default 5, max 10. | |
| country | No | ISO 3166-1 alpha-2 code of the company HQ, e.g. "NL". Narrows an ambiguous name; a code that matches nothing is rejected rather than silently ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly and openWorld, so the description adds valuable extra behavior: it never disambiguates on its own, multiple plausible candidates mean the agent should say so, an empty result does not imply the company doesn't exist, and failed calls are not charged. This goes beyond the structured hints and gives practical operational expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but is front-loaded with the key purpose and usage rule, and every added sentence covers a useful nuance such as ambiguity handling, cost, or empty-result semantics. It could be tightened slightly, but it is not padded or self-referential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains what the return provides: a small set of candidates with distinguishing fields like country, founding year, headcount, and signal recency. It also explains the empty result meaning and the recommended follow-up path, so an agent has enough context to act correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the parameter descriptions in the schema already explain name, limit, and country semantics. The tool description does not add much parameter-level detail beyond that, but the schema fully carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Finds a company in the BounceWatch index by name, and returns its domain.' It clearly distinguishes this tool from siblings like get_company and search_companies by stating that this is the name-to-domain lookup and that get_company returns the full profile after a pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this whenever you have a company's NAME rather than its domain' and warns not to guess domains. It also names alternatives: 'Once you have picked, get_company returns the full profile' and 'If you know its domain, refresh_company indexes it.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Firmographic profile of one company from the BounceWatch index: identity, location, headcount, funding history, tech stack, team and competitors.
Returns what we currently hold — it never triggers a scan on its own. coverage says
what monitoring this company is under; if it is not being followed continuously and
the answer depends on facts being current, call refresh_company explicitly.
For what has been HAPPENING at a company rather than what it IS, use get_company_signals.
Cost: 10 credits per call at minimum, rising with the extra data you request. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain, e.g. "stripe.com". URLs are accepted and normalised. | |
| include | No | Optional enrichment modules: business, technology, funding, team, competitors. Each adds credits — request only what you will use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: it never triggers a scan on its own, discloses the coverage field for monitoring status, and explains refresh fallback semantics. Cost behavior (minimum 10 credits, failures not charged) is also disclosed, which is far beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every paragraph serves a distinct purpose: core function, data freshness behavior, alternative tool guidance, and cost caveats. The description is front-loaded with the primary purpose and maintains clarity without fluff, making it appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains what is returned (firmographic profile contents and a coverage field). It covers key operational aspects: no scan triggering, refresh recommendation, alternatives for different data needs, and credit costs. No critical gaps remain for the agent to select and invoke this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that include modules increase cost and advising to request only what will be used, which the schema does not convey. The domain parameter is well-documented in the schema, so the description doesn't need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a firmographic profile of one company, listing specific content areas like identity, headcount, funding history, and tech stack. It distinguishes itself from siblings by contrasting with get_company_signals and refresh_company, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: it contrasts current-state facts vs. recent activity (get_company_signals), and instructs when to call refresh_company if data freshness matters. It also warns about cost implications for selecting include modules, helping users choose wisely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the dated signal timeline for one company: funding, hiring, partnerships, expansion, product launches, leadership changes and risk events.
Use this when you already know which company you care about and need to know what has been happening and when. To find companies by signal instead, use search_signals.
categories and signal_keys widen each other rather than narrowing to the overlap: a category adds all of its keys to whatever signal_keys already lists.
Read coverage before drawing conclusions. If coverage.signal_absence_is_meaningful
is false, an empty or thin result reflects our scanning gap, not the company — say
so rather than reporting the company as quiet.
Cost: 8 credits per call. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days. Default 90, max 365. | |
| limit | No | Max signals to return, newest first. Default 50, max 100. | |
| domain | Yes | Company domain, e.g. "stripe.com". URLs are accepted and normalised. | |
| categories | No | Restrict to signal categories (funding, hiring, business, product, growth, event, milestone, risk). Call get_signal_taxonomy for the list. | |
| signal_keys | No | Restrict to exact signal keys, e.g. ["recently_funded","key_hire_announced"]. Unrecognised keys are rejected rather than silently ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: explains that categories and signal_keys widen rather than narrow the result, advises reading coverage to avoid misinterpreting empty results, and discloses the credit cost and failure billing. Annotations already note read-only and non-destructive nature, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is focused and well-organized, mixing core purpose, usage guidance, and key caveats without unnecessary verbosity. The repeated emphasis on widening and coverage is justified due to its importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential context: what it returns, when to use, how parameters interact, cost, and how to interpret results (via coverage). No output schema exists, but the description sufficiently sets expectations about the response shape and meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already provides clear descriptions for each parameter, the description adds crucial semantics about how categories and signal_keys combine (widening vs. narrowing). This goes beyond the individual parameter definitions, though the parameters themselves are well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a dated signal timeline for a single company, enumerating signal types. Distinguishes from search_signals which finds companies by signal, making the tool's niche explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use ('when you already know which company you care about') and directs to search_signals for the inverse scenario. Also explains the interaction of categories and signal_keys, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a scan queued by refresh_company, and WAITS for it.
This call blocks until the scan is done or wait_seconds runs out, so you do not
have to idle between polls — just call it again if it comes back unfinished. A
typical scan needs two or three calls at the default wait.
Read is_finished, not status. A scan reaches completed when its jobs report
back, but the signal analysis they started is still writing rows for a few seconds
after that — read too early and you get the pre-scan picture with a completed
stamp on it. status becomes settling for that window and is_finished stays
false until the writes stop.
Do not answer from the old data while a scan you asked for is unfinished: you requested it because the existing figures were too stale to rely on, and they have not changed yet. Either wait for it, or say plainly that a refresh is in flight.
When it finishes, signals_added says how many new signals the scan actually
produced — zero is a real answer and means we looked and found nothing new, not
that the scan failed. Then read the data with get_company or get_company_signals;
this tool returns progress, not company data.
Cost: free — call it as often as you need.
| Name | Required | Description | Default |
|---|---|---|---|
| batch_id | Yes | The batch_id returned by refresh_company. | |
| wait_seconds | No | How long this call may block waiting for the scan, 0-25. Default 20. It returns the moment the scan finishes, and waiting the full 25 costs exactly what waiting 1 costs — so there is nothing to gain by polling with a low value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnlyHint, openWorldHint) by explaining that the call blocks until scan completion or timeout, the distinction between is_finished and status (settling window), cost implications of wait_seconds, and behavior when signals_added is zero. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with the main purpose, then provides critical behavioral details and caveats in a logical order. Every sentence adds unique value, covering usage, edge cases, and next steps without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blocking tool with distinctive semantics (is_finished vs status, settling window, zero-signal handling), the description is exceptionally complete. It explains what to read, what to expect, and where to go next, fully compensating for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for both batch_id and wait_seconds, including polling advice. The description reinforces the wait_seconds behavior (no cost to wait full duration) but adds no new parameter meaning beyond what the schema covers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a scan queued by refresh_company and waits for it, distinguishing it from sibling tools that retrieve company data or search signals. It uses a specific verb (checks) and resource (scan) with context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes when to use the tool (after refresh_company), how to handle unfinished scans (call again), and provides alternatives for retrieving actual data (get_company or get_company_signals). It also advises against relying on stale data while a scan is in progress, giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every signal type BounceWatch detects, grouped by category, with what each one means and whether it is an announcement or an unconfirmed inference.
It also returns coverage, which says which categories produce steadily and which
are rare by nature. Read it before designing a search: the rarest signals are the
highest-value ones — funding, acquisitions, shutdowns — and searching a window for
them usually returns almost nothing, because that is how often they happen. Those
are caught with watch_company, not with a query.
Call this before filtering by signal type in search_signals or get_company_signals: filters are matched exactly, and an unrecognised key returns nothing rather than an error. The answer is stable, so once per session is enough.
Cost: free — call it as often as you need.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false), the description adds valuable behavioral context: the response is stable ('once per session is enough') and free ('Cost: free'). It also explains what the `coverage` field means for the user's search design, which is not apparent from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into four short paragraphs, each with a distinct purpose: (1) what it lists, (2) how to use it for search design, (3) when to call it before related functions, and (4) cost. Every sentence adds value without unnecessary verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no parameters, the description completely covers what the agent needs to know: what the taxonomy contains, how to interpret the coverage field, and when to call this tool. It even addresses the likely use case of filtering by signal type, making it complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, the schema provides no semantics and the description doesn't need to justify parameter handling. However, it does provide useful guidance on filtering behavior in related functions (exact matching, returning nothing for unrecognized keys), which helps the agent reason about using this tool in a workflow. Since 0 params = baseline 4, this is appropriately scored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'lists every signal type BounceWatch detects, grouped by category, with what each one means and whether it is an announcement or an unconfirmed inference.' This uses a specific verb and resource, distinguishes it from sibling tools by noting when to call it (before designing a search), and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when-to-use guidance ('Read it before designing a search'), when-not-to-use with an alternative ('Those are caught with watch_company, not with a query'), and warns about exact matching of filters in search_signals or get_company_signals. This clearly differentiates it from alternatives like search_signals and get_company_signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queues a fresh scan of one company and returns a batch id to poll with get_refresh_status. Works for companies already in the index and for domains we have never seen, which is how you add one.
A scan only refreshes what you ask for, and each module reads a different source. Anything you leave out keeps the date it already had, so pick by the fact you need:
signals recent events and announcements (default) funding rounds, investors, valuations (default) team headcount, leadership, open roles technology tech stack business positioning, model, target market competitors similar companies
The default is signals + funding, because those are the two that go out of date
fastest and the two most answers turn on. Pass modules explicitly to go cheaper —
["signals"] alone is the least you can usefully scan.
This spends credits and real scanning budget, so call it deliberately: when
coverage on a previous answer showed stale data AND the decision depends on
current facts. Do not call it speculatively across a list of candidates.
Returns in a second or two; the scan itself typically takes 60-180 seconds. Poll get_refresh_status (free) until it reports finished, then re-read the data with get_company or get_company_signals.
Cost: 36 credits per call at minimum, rising with the extra data you request. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain, e.g. "stripe.com". URLs are accepted and normalised. | |
| modules | No | What to refresh: business, technology, funding, team, signals, competitors. Each adds credits. Defaults to signals only, which is the cheapest useful scan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations present, the description adds substantial behavioral context: it spends credits and scanning budget, failed calls are not charged, the initial call returns in a second or two while the scan takes 60-180 seconds, and modules left out retain their previous date. It also explains open-world behavior for unseen domains, consistent with openWorldHint=true. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It is well-structured with a clear intro, a bulleted module list, explicit default behavior, usage timing, async expectations, and cost. The front-loaded first sentence gives the core purpose immediately, and the later sections add necessary operational detail without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately explains the return value as a batch id, tells the caller to poll with get_refresh_status, and gives expected latency. It also covers cost, failure handling, module selection, and the distinction between this tool and the read/poll siblings. This is complete for a complex, credit-spending async tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters, so baseline is 3. The description adds real value by explaining what each module refreshes, clarifying the default modules (signals + funding), showing how to run a cheaper scan with ['signals'], and attaching cost implications. However, there is a conflicting default statement: the schema's modules description says 'Defaults to signals only' while the tool description says 'The default is signals + funding,' which prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Queues a fresh scan of one company and returns a batch id to poll with get_refresh_status.' It clearly distinguishes itself from sibling tools by explaining it queues a scan, covers both existing and unseen companies, and is how you add a new company. This is far beyond a tautology and gives a precise resource + verb + outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: call deliberately when 'coverage on a previous answer showed stale data AND the decision depends on current facts,' and explicitly says 'Do not call it speculatively across a list of candidates.' It also names the correct follow-up flow: poll get_refresh_status, then re-read with get_company or get_company_signals. This is model-ideal usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds companies by firmographics — country, headcount, funding stage — within the set BounceWatch actively observes, most recently refreshed first.
By default it returns only companies we have observed in the last 90 days, so the firmographics you get are backed by recent observation rather than a record we last touched years ago. Each result reports its signal activity, so you can tell a closely-watched company from a thinly-covered one.
If you want companies selected by what HAPPENED to them rather than by what they ARE — recently funded, hiring, expanding — use search_signals instead. That is the stronger discovery path and usually the one you want.
Cost: 5 credits per call. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max companies to return. Default 20, max 50. | |
| country | No | ISO 3166-1 alpha-2 country code of the company HQ, e.g. "NL", "DE", "US". | |
| founded_after | No | Only companies founded in or after this year, e.g. 2023. Companies whose founding year we do not hold are excluded when this is set, and the result says so. | |
| funding_stage | No | Funding stage, e.g. "Seed", "Series A", "Pre Seed". Spacing, case and hyphens are normalised; a value that matches nothing is rejected with the valid list rather than returning a near-empty result. This is the costliest filter here: a company whose stage we do not hold is excluded rather than guessed at, so it narrows the field twice — once by stage, once by what we know. | |
| max_employees | No | Maximum headcount. Same exclusion of unknown headcounts as min_employees. | |
| min_employees | No | Minimum headcount. Companies whose headcount we do not hold are excluded when this is set — same rule as founded_after, and for the same reason: not knowing a number is not evidence it falls outside the range. | |
| founded_before | No | Only companies founded in or before this year. Same exclusion of unknown founding years as founded_after. | |
| observed_within_days | No | Only companies we observed within this many days, 30-365. Default 90. Widening it grows the result set but lowers confidence in the firmographics, because the record is older. There is no way to switch this off — pass 0 and the widest available window (365) runs instead, and the answer says so. This tool covers the companies we watch, not the whole market. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial behavioral context: default 90-day observation window, refresh ordering, per-result signal activity, per-call cost, and no charge for failed calls. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short paragraphs, each serving a distinct purpose: what the tool does, default behavior, sibling alternative, and cost. The purpose is front-loaded and every sentence earns its place for an 8-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core selection semantics, the observed-set boundary, recency filtering, and cost, which is strong for a read-only search tool. Minor gap: with no output schema, it only partially describes the return shape via 'signal activity' and doesn't state concrete result fields like id/name/country.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 8 parameters with 100% description coverage, so the description can rely on it. The description only adds high-level firmographic framing and the 90-day default, which doesn't materially extend per-parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb+resource ('Finds companies by firmographics') and scopes it to the set BounceWatch actively observes, with recency ordering. It clearly distinguishes this tool from search_signals, so the agent knows exactly what this sibling does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names search_signals as the alternative for event-driven queries and states it is 'the stronger discovery path and usually the one you want.' This gives clear when-to-use guidance and frames search_companies as the firmographics/state-based path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest signals across the whole index: which companies did something recently, what it was, and when.
This is the tool for ANY question about what is happening. "Show me the latest signals", "what's new", "which companies raised a round and are now hiring sales in the Netherlands", "who announced expansion in the last two weeks", "which of my target segment just made a key hire". Returns matching companies with the signals that matched and their dates.
Reach for this first. check_watches only reports on companies already being watched by this key and cannot answer a question about the market or about a company that is not on that list.
Filter by signal type, category, recency, country, headcount and funding stage. Call get_signal_taxonomy first if you are unsure which signal keys exist — unrecognised keys are rejected rather than quietly returning nothing.
The two signal filters WIDEN each other rather than narrowing to the overlap: a category adds all of its keys to whatever signal_keys already lists. min_weight then cuts what is left, so a low-weight signal type named alongside a floor above its own weight returns nothing rather than one of the two being quietly ignored.
coverage is working material for you, not for the answer: it bounds what this
search could have found. Let it shape what you claim, and offer a narrower search
rather than reporting figures about our index.
Cost: 12 credits per call. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days. Default 30. Max 365. Shorter windows mean sharper timing. | |
| sort | No | most_recent (default) ranks by newest matching signal; most_active by how many matched. | |
| limit | No | Max companies to return. Default 25, max 100. | |
| country | No | ISO 3166-1 alpha-2 country code of the company HQ, e.g. "NL", "DE", "US". | |
| categories | No | Signal categories to match: funding, hiring, business, product, growth, event, milestone, risk. | |
| min_weight | No | Only count signals worth at least this much, 1-10. Background chatter (event attendance, news mentions, follower drift) sits at 1-2 and dominates an unfiltered result; 3 or 4 searches on substance and is the useful setting. Above 7 you are asking for rare events — funding, acquisitions, shutdowns are seldom what a window contains, because that is how often they happen, not how well we see them. Searching for those usually returns little; watch_company is how you catch them. Default 0 (everything). | |
| signal_keys | No | Signal types to match, e.g. ["recently_funded","key_hire_announced"]. See get_signal_taxonomy. | |
| founded_after | No | Only companies founded in or after this year, e.g. 2023. Companies whose founding year we do not hold are excluded when this is set, and the result says so. | |
| funding_stage | No | Funding stage, e.g. "Seed", "Series A", "Pre Seed". Spacing, case and hyphens are normalised; a value that matches nothing is rejected with the valid list rather than returning a near-empty result. This is the costliest filter here: a company whose stage we do not hold is excluded rather than guessed at, so it narrows the field twice — once by stage, once by what we know. | |
| max_employees | No | Maximum headcount. Same exclusion of unknown headcounts as min_employees. | |
| min_employees | No | Minimum headcount. Companies whose headcount we do not hold are excluded when this is set — not knowing a number is not evidence it falls outside the range. | |
| founded_before | No | Only companies founded in or before this year. Same exclusion of unknown founding years as founded_after. | |
| require_all_keys | No | When true, only return companies showing EVERY requested signal key in the window (signal stacking) rather than any of them. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds significant behavioral details beyond this: filter widening semantics (the two signal filters broaden rather than narrow), min_weight's effect on result filtering, the meaning and handling of coverage, the cost per call, and the fact that failed calls are not charged. It also explains exclusions when unknown values are present. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It progresses from a summary to usage guidance, then to filter specifics, and ends with cost. Every sentence contributes value: it explains when to use the tool, how filters work, potential pitfalls, and cost implications. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 optional parameters and no output schema, the description is exceptionally complete. It explains what the tool returns (matching companies with signals and dates), how to use filters effectively, edge cases (unknown data exclusions, filter widening), and cost. It also provides guidance on when to use alternatives, covering both selection and invocation. This is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds extra context by explaining how filters interact (e.g., categories add to signal_keys, min_weight cuts), which clarifies parameter behavior beyond individual parameter descriptions. It also mentions the costliest filter (funding_stage) and the exclusion behavior for unknown headcounts/founding years, enriching the schema's info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the latest signals across the index, including what changed, for which companies, and when. It distinguishes itself from siblings like check_watches, which only covers watched companies, and explicitly positions itself as the primary search tool. The verb 'search' and resource 'signals' are clear, and the scope ('whole index') is defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Reach for this first' and contrasts with check_watches for watched companies. It also advises calling get_signal_taxonomy first if unsure about signal keys, and warns that invalid keys are rejected. Additionally, it explains how min_weight settings affect results and when to use watch_company for rare events, giving clear alternative paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registers a standing watch on one company, so you find out what happened there without asking again. This is the only tool that persists between sessions.
A watched company is kept under continuous monitoring — we keep looking at it for as long as the watch is active, rather than waiting for someone to ask about it.
Matching signals are queued for you and collected with check_watches (free). If this API key has a webhook URL configured, set deliver_webhook to also have them pushed to it as they land — that is what lets a hosted agent be woken rather than having to poll.
Narrow it. A watch with no filters delivers everything, including the background chatter that makes a feed unreadable: pass signal_keys for the events you care about, or min_weight to set a floor on how much a signal has to matter. Given both, a signal has to clear both — a named key that sits below the floor never fires.
Call again with the same domain to change the filters, or with stop:true to end the watch. Watching a domain we have not indexed is allowed, but nothing will fire until it is — refresh_company indexes it.
Cost: 5 credits per call. Failed calls are not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| stop | No | Ends the watch on this domain. Already-queued events stay collectable. | |
| label | No | Your own note for this watch, e.g. "Q3 pipeline". Returned with every event so you can route it without a second lookup. | |
| domain | Yes | Company domain, e.g. "stripe.com". URLs are accepted and normalised. | |
| min_weight | No | Floor on how much a signal has to matter, 1-10. Roughly: 8+ funding and leadership changes, 5+ hiring and expansion, below 4 background noise. Signals we do not weight never clear a floor. | |
| signal_keys | No | Only these signal types wake you. Omit for all of them. Values come from get_signal_taxonomy; an unrecognised key is rejected with the valid list rather than creating a watch that silently matches nothing. | |
| deliver_webhook | No | Also push matches to this key's configured webhook URL. Default false. Events are queued for check_watches either way. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains continuous monitoring, queuing of signals, webhook delivery option, filtering behavior with both filters, and cost implications ('Cost: 5 credits per call. Failed calls are not charged.'). It also notes that watching an unindexed domain is allowed but nothing fires until indexed, which is valuable context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose, then explaining behavior, then filtering guidance, then modification actions, and finally cost. Each section is a separate short paragraph with clear logical flow. No redundant sentences; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (6 parameters, side effects like persistence and cost), the description is complete. It covers the core functionality, filtering semantics, lifecycle (change/stop), edge cases (unindexed domains), and output behavior (queued for check_watches). No output schema exists, but the description explains what happens with results (queued, webhook). All parameters are explained in schema but enriched in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. It explains the interplay between signal_keys and min_weight: 'Given both, a signal has to clear both — a named key that sits below the floor never fires.' It also clarifies domain normalization, and the purpose of the label for routing. The schema already provides per-parameter descriptions, but the description enriches the semantics with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Registers a standing watch on one company, so you find out what happened there without asking again.' It specifies the verb (watch) and resource (company), and distinguishes it from siblings by noting 'This is the only tool that persists between sessions' and mentioning check_watches for collecting signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and alternatives: it explains that it persists between sessions, is the only persistent tool, and mentions check_watches for collecting queued signals. It also explains how to modify or end a watch: 'Call again with the same domain to change the filters, or with stop:true to end the watch.' It even mentions refresh_company for indexing new domains, showing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_watchesfind_companyget_companyget_company_signalsget_refresh_statusget_signal_taxonomyrefresh_companysearch_companiessearch_signalswatch_companyScored across 10 tools
Each tool targets a distinct action: search_signals finds events, search_companies finds by firmographics, find_company resolves names to domains, get_company returns profiles, get_company_signals returns timelines, refresh_company triggers scans, get_refresh_status polls scans, watch_company manages watches, check_watches reads watched events, and get_signal_taxonomy explains signal types. No two tools have overlapping purposes; descriptions explicitly differentiate when confusion could arise (e.g., search_signals vs check_watches).
All tool names follow a consistent verb_noun snake_case pattern: search_* (signals, companies), find_company, get_* (company, company_signals, refresh_status, signal_taxonomy), refresh_company, watch_company, check_watches. The verbs are descriptive and the pattern is uniform throughout, making the API predictable.
With 10 tools, the server is well-scoped for a company signal intelligence service. Each tool serves a clear purpose: discovery (search_signals, search_companies, find_company), retrieval (get_company, get_company_signals), refresh (refresh_company, get_refresh_status), and persistent monitoring (watch_company, check_watches), plus taxonomy. No redundancy or unnecessary tools.
The tool surface covers the full lifecycle: discovery of companies and signals, detailed company profiles, signal histories, on-demand refreshing with polling, persistent watches, and a taxonomy guide. There are no obvious missing operations—stopping a watch is handled via watch_company with stop:true, and check_watches lists active watches. The domain is thoroughly addressed.
Millions of dated buying and momentum signals: who raised, who's hiring, what changed and when
Structured company & industry news for AI agents: typed, dated, source-linked events.
Real-time B2B buying signals on your target accounts: funding, hiring, leadership, tech stack.
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
