Skip to main content

​
Tools

Every tool description ends with its own price, generated from config, so the model can see the meter running and pace itself instead of looping blind.
Module prices come from the same table as the REST API, so the same data costs the same whichever door you come through. See Credits and Modules. Failed calls are never billed.

​
search_signals

The cross-company question: who did something worth reacting to, and when. The response also reports how many companies produced signals in the window at all, so a ranked list of 25 is not mistaken for the whole market.
require_all_keys is the one worth knowing about. “Raised a round” is a weak buying signal on its own; “raised a round and is hiring sales roles” is a much smaller, much warmer list.
funding_stage narrows twice. We hold a stage for about 60% of the companies we observe, and the rest are excluded rather than guessed at — so the filter cuts by stage and by what we happen to know. A short result is as likely to be a gap in our records as a fact about the market, and the response says so in notes.

​
find_company

Every tool here takes a domain, and you will usually have a name. Guessing the domain is the expensive mistake: a wrong guess comes back as “not indexed” for a company we actually hold, and sends the agent on to spend a scan on a host nobody checked. find_company takes a name (a domain works too and is resolved directly), an optional country and limit, and returns a handful of candidates with the few fields that tell them apart — country, founding year, headcount, and when we last saw a signal. It never picks for you. Once you have chosen, get_company returns the full profile. If search is unavailable it returns an explicit error rather than an empty list, because “we could not look” and “not in the index” are different answers and only one of them is true.

​
search_companies

Firmographic search over the companies we watch: country, min_employees, max_employees, funding_stage, observed_within_days, founded_after, founded_before, limit. observed_within_days is floored at 30 and capped at 365. There is deliberately no way to search the whole index: this tool covers what we observe, and every answer carries a coverage block saying how many companies that is. Each result reports signal_activity.level — light, moderate, high — rather than a raw count. Nobody acts differently on six signals versus eight, and a bare number invites a comparison against vendors who count every conference badge. latest_signal_date stays exact; timing is the thing worth being precise about.

​
get_company / get_company_signals

get_company takes a domain and an optional include list of enrichment modules. get_company_signals takes a domain plus days, categories, signal_keys and limit, and returns the dated timeline — the raw material for a “why now” argument.

​
refresh_company / get_refresh_status

refresh_company takes a domain and optional modules, queues a scan and hands back a batch_id. get_refresh_status polls that id for free until the scan lands — the call blocks and waits for you, so a scan costs two or three patient calls rather than twenty impatient ones. A scan only refreshes what you ask for, and anything left out keeps the date it already had. The default is signals + funding, the two that go out of date fastest; every result names both what it refreshed and what it did not.
Read is_finished, not status. A batch reaches completed when its jobs report back, but the signal analysis they started keeps writing rows for a few seconds afterwards. 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. When it finishes, signals_added says how many new signals the scan actually produced — zero is a real answer.

​
watch_company / check_watches

MCP is request-response: a server can only ever answer, never initiate. So every company-data MCP server is read-only pull, and an agent finds out something changed only if a human happens to ask again. It does not need the protocol. Registration is an ordinary tool call; the wake-up travels out of band. watch_company records a standing interest in a company, optionally narrowed by signal_keys or min_weight. When a matching signal lands it is delivered two ways:
  • An inbox, drained by check_watches — free, and it returns only what is new since your last call. This is the path for an agent living inside a chat client, which has no address to be called back on.
  • A webhook, if the key has one configured — signal.matched, signed exactly like an enrichment webhook so you do not need a second verifier. This is the path that genuinely wakes a hosted agent.
The webhook never replaces the inbox row, so a failed delivery is not a lost event.
This is the right instrument for the rare, high-value signals. A funding round is a few hundred events across the whole index in a quarter — the odds one lands inside the window you happen to search are poor. You do not search for a funding round; you wait for one.
Guardrails, because an agent loop can dispatch scans far faster than a person would: a daily cap per key, per-plan concurrency, a 24-hour cooldown on the same domain, and a global in-flight lock so two keys cannot scan the same domain at once.

​
Prompts

The server also exposes MCP prompts — ready-made workflows that clients surface as a menu or slash command. Rendering one is free; the tools it triggers are billed normally.
The real value is not the phrasing. Each template has the correct tool sequence and the freshness caveats baked in — check coverage before calling a company quiet, do not report a rumour as an event — so a first-time user gets expert behaviour without knowing the rules.

​
Errors

Two channels, and the difference matters:
  • JSON-RPC errors mean the call was malformed — unknown method, bad envelope. The client sees them; usually the model does not.
  • Tool errors mean the call was fine but the answer is a failure — out of credits, unknown domain, quota hit. These come back as results so the model can read them and adapt.
Rejections that happen before the protocol is reached — auth, credits, rate limits — are rewrapped as JSON-RPC errors with an actionable sentence, rather than being handed to the agent as an opaque transport failure. A 429 also carries Retry-After.