Field Notes/bryngtmagentsmcpsignalsdata-vendorsthe-record
Your Vendors Ship MCP Servers Now
In the last six weeks the signal data layer became callable. PredictLeads exposes every dataset as a tool at mcp.predictleads.com, Coresignal shipped an MCP server with OAuth on August 4 and moved its company dataset to daily delivery on September 10, Demandbase lists native MCP support for enrichment and intent, and Clay puts its data providers and workflows behind an MCP server. Last Monday we wrote that Bryn is the agent your agents call. Now the vendors are too. Good news, and it changes less than it looks like it changes: an agent that can ask for a signal still has to decide, act inside a rule, and write down what it did. Callable is a data property. Run is an operating property.
Civic Team, Staff⬩12 min read
tl;dr
In the last six weeks the signal data layer became callable. PredictLeads exposes every dataset as a tool at mcp.predictleads.com. Coresignal shipped an MCP server with OAuth on August 4 and moved its company dataset to daily delivery on September 10. Demandbase lists native MCP support for enrichment and intent. Clay puts its data providers and workflows behind an MCP server. Last Monday we wrote that Bryn is the agent your agents call. Now the vendors are too. Good news, and it changes less than it looks like it changes: an agent that can ask for a signal still has to decide, act inside a rule, and write down what it did. Callable is a data property. Run is an operating property.
Here is the shipping list, from the vendors' own pages.
PredictLeads runs an MCP server at mcp.predictleads.com that exposes every one of its datasets (technology detections, job openings, financing events, news, company relationships) as a tool an agent can call (PredictLeads, Sep 18, 2026). Coresignal shipped a new MCP server with OAuth 2.1 sign-in on August 4, four tools for search, discovery, fetching, and enrichment, and no API key pasted into a client config (Coresignal, Aug 4, 2026). On September 10 it moved its Multi-Source Company Dataset to daily delivery, with MCP listed as one of the ways to consume it (Coresignal, Sep 10, 2026). Demandbase lists native MCP support so an assistant can pull its enrichment and intent data through natural-language prompts (Demandbase). Clay's MCP server puts its data providers, research agents, and your team's prebuilt workflows inside ChatGPT, Claude, and Codex, with admin-set credit limits and function allow-listing (Clay; Clay docs).
Four vendors across signals, company data, intent, and enrichment, each saying the same sentence in its own words: you no longer have to wait for our file. Ask us.
This is progress, and we mean that without a wink. Last Monday we wrote that Bryn is the agent your agents call. This week the data vendors are too, and a stack where everything answers is a better stack than one where everything exports.
From a file on a schedule to a question at scoring time
What MCP does to a data vendor is simple to state. Before, you bought a dataset and it arrived as a CSV, a warehouse table, or a nightly enrichment job that wrote fields into your CRM. The fields were true on the day they landed and quietly aged afterwards. PredictLeads' own guide to agent lead qualification says it plainly: pull live signals for the domain at the moment of scoring, instead of reading CRM fields that were enriched weeks ago (PredictLeads, Sep 2026). Coresignal's daily-delivery post makes the same case from the file side: an agent working from a stored dataset ends up citing facts that have already changed.
So the vendor stops being a file and becomes a question you can ask at the exact minute the answer matters. Funding, headcount, tech installs, intent topics, arriving as a tool result instead of a column. We wrote in August, when 6sense did this with intent, that intelligence became an ingredient. A month later the whole pantry is labelled and within reach.
The same answer
Here is the part that changes less than it looks. When a vendor's data is callable over MCP, it is callable by everyone who pays for it. Your agent can ask whether acct_5108 raised a Series B in the last 30 days. So can your closest competitor's agent, on the same afternoon, from the same vendor, and it gets the same answer with the same timestamp. Fresh is real. Fresh is not the same as yours.
Four servers. One answer. Who is calling?
Pick a server on the shelf, then pick who is asking. The answer does not move. The join does.
Server
Who is calling
company data · called byyousame answer
> funding_events(acct_5108)→ Series B · 18d ago · first_seen 2026-09-03
The vendor returns this line to you. On your side it lands next to a funding event on an account that hit your pricing page twice this week. That join exists nowhere else, and it is what turns the answer into a score. (illustrative, not a benchmark)
Qualitative and illustrative, not a benchmark. Generic servers, no vendor named. Tool-shaped strings are illustrations of an MCP result, not any vendor's real tool names. Account anonymized.
Figure 1. Four generic vendor servers and a toggle for who is calling. The answer does not change with the caller; what differs is what the answer is joined to on your side (illustrative, not a benchmark).
The vendor answer earns its keep at the join: the moment it lands next to something only you have. A Series B is weather. A Series B on an account that hit your pricing page twice this week and has an open trial in your product is a forecast for one address. Brad closes the field guide this week on exactly this class, so we will leave the taxonomy to him. The short version is that callable data is now the shared layer, and the join is the private one.
Three things a callable data layer does not do, and was never meant to do.
It does not decide within a rule. A tool result is a fact. Whether that fact crosses a threshold you set, on an account that fits a profile you defined, inside a window you chose, is a decision, and the vendor's server is not where it lives.
It does not act inside your stack. The answer comes back to the agent that asked. Turning it into a Slack line to the owner, a CRM task, or an intro note in your sequencer is a write into your systems, and the boundary on that write (which channels, how many a day, what is off by default) is yours to set. We laid out the five controls in Bounded Autonomy Is the Spec, and none of them belong to the data vendor.
It does not record the join. The vendor logs that you asked, and what it cost. Nobody logs what you did with the answer unless the thing that acted writes it down.
Ask. Decide. Act. Record.
Four steps between a question and a result. At each one, what a callable data layer does, and what a governed execution layer does.
step 1 of 4Ask
Callable data layer
Answers the question at the minute you ask. funding_events(acct_5108) → Series B, 18 days ago, timestamped.
The same line for every caller.
Governed execution layer
Asks at scoring time, not on a schedule. The answer lands as one input on the Timing axis.
Next to it sits a signal only you have: pricing → repeat (7d) on your site.
illustrative, not a benchmark
Illustrative, not a benchmark. Axis values and the Play name are illustrative; threshold 70 is Bryn's default. Tool-shaped strings are generic illustrations of an MCP result.
Figure 2. Ask, decide, act, record: what a callable data layer does at each step, and what a governed execution layer does (illustrative, not a benchmark).
That gap stayed open through every consolidation we have written about this year, from Tools Converge. Action Doesn't. to the third surface. Callable is a data property. Run is an operating property.
Here is Bryn's shape against this month's shelf. Bryn watches your product, your site, and your CRM: the signals that are yours alone. Vendor answers come in as inputs. A funding event lands on the score's Timing axis, a headcount change on Fit, a do-not-contact match on the suppression list. The score clears the threshold or it does not. If it does, Bryn runs the Play you approved, in Run mode or held in Approve mode for one click, through the channels the Play names and no others. Then it writes the line.
Figure 3. The same vendor answer arriving at two consoles: one stops at the answer, one joins it to a signal of yours, runs a Play, and writes a record (illustrative, not a benchmark).
Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack.
Vendors making themselves callable makes that layer more useful, not less. More questions to ask at scoring time means better-timed scores. It does not add a second place where the decision lives.
Do this Monday
Take one enrichment call your team runs by hand today. Look up funding, look up headcount, look up tech installs, whichever one someone on the team does in a browser tab every morning. Write down the three things that happen after the answer comes back: who decides what to do with it, what they are allowed to do, and where it gets recorded.
If any of the three is "depends who's on," the callable layer did not fix anything yet. It made the question faster to ask. The answer still needs an owner.
When it has one, the record reads like this:
acct_5108 · funding → Series B (18d) + pricing → repeat (7d) · held intro-note-v2 for approval
One vendor answer, one signal of yours, one join, one Play, held for your click. The vendor gave the same answer to everyone who asked. Only one of them wrote that line.
Our team brings decades of experience across the domains that matter: 10 years in AI and agentic systems, 65 in financial services, 35 in identity and access management, 30 in marketing and AdTech, 15 in legal and professional services, and 12 in manufacturing and industrial.
We're for operators who can't afford unintended actions or silent failures, and who want the agent in production quickly and effectively.
