Works with
Works in any MCP client.
Pathbound is one remote MCP server, so the recipe runs wherever your agent does. Pick the product your team already uses and follow its setup.
Don’t see yours? Any MCP client connects the same way.
For a founder or first sales hire at a self-serve B2B product, the job is: every signup looked at properly (who they are, what they did, whether the account matters) before the first reply goes out.
There was a time when the founder read every signup over coffee and sent the good ones a personal note. Growth killed that. Each signup still deserves ten minutes of looking up who this is, what company they’re from, and what they tried in the product—and nobody has ten minutes times forty. So the queue gets worked by whoever has a recognizable domain, and the account that actually mattered gets noticed a week late.
The whole job is four calls to Pathbound’s MCP server (MCP is the open protocol agents use to call tools). Your agent runs them on a schedule; there’s no glue code to write or keep alive.
list_contacts One call returns the contacts created since yesterday, filtered to the lifecycle stage you care about. Signups arrive here from every connected source, so the list is complete without anyone exporting a CSV.
batch_get_details Up to 25 profiles per call, already stitched together: name, job title, the company behind the domain, firmographics from enrichment, whether the email address is deliverable. That’s the fit half of the research done before a browser tab opens.
get_contact_timeline Each signup’s tracked history in order: pages read, features tried, forms submitted, return visits. The signup who read your pricing page twice and came back the next day reads differently from the one who bounced at the confirmation screen—the timeline is where that difference shows.
create_contact_note The verdict lands as a note on the contact: who they are, what they did, whether they’re worth a personal reply, and a suggested opener. Every agent and teammate reading the profile starts from that brief; syncing notes into two-way CRMs like HubSpot is rolling out.
The same four calls run every morning, or per signup from a webhook.
First, connect Pathbound to your agent—about five minutes, in whichever client your team runs. Then paste this prompt. This is how you research trial signups on a schedule: run it as a recurring morning task in ChatGPT or Claude, or fire it per signup from an n8n webhook.
Research every trial signup from the last 24 hours. For each one, pull their profile and company details, read what they did on our site and in the product, and work out who they are and whether the account is a fit. Write a short research brief as a note on each contact (who they are, what they did, verdict, suggested opener), then give me the list ranked by how promising they look, with one line each on why.
The first hour of the rep’s day comes back, and every signup gets looked at, including the ones without a famous domain. The promising ones get personalized outreach while the trial is still warm: a personal, informed reply, not a templated blast. A small team gets the morning research motion a larger company staffs for—this recipe is how one of our customers runs inbound today.
Pathbound is one remote MCP server, so the recipe runs wherever your agent does. Pick the product your team already uses and follow its setup.
Don’t see yours? Any MCP client connects the same way.
Yes—this recipe is how you research trial signups automatically. Point any MCP agent (ChatGPT, Claude, n8n, or your own loop) at Pathbound and every new signup gets researched on its own: the person, the company behind the domain, and what they did on your site, written back as a ranked brief on the contact. You bring the runtime; Pathbound is the customer data MCP it reads from and writes to.
No. Pathbound is the customer context layer underneath whatever agent you run: one customer data MCP it reads from and writes to. The agent stays yours (ChatGPT, Claude, n8n, or your own loop), so you can swap models or frameworks without re-plumbing your data.
Yes—that’s the layer Pathbound provides. Your SDR agent, in whatever runtime it lives, reads HubSpot, Gmail, enrichment, and site activity from Events as one synced, identity-resolved profile per lead, and writes its research back as notes. The agent stays yours; the sync underneath is what this recipe sets up.
Whatever you connect: site and product activity from Events, firmographic enrichment from Apollo, CRM state from HubSpot or Pipedrive, email history from Gmail. Identity resolution stitches those records onto one profile per person, so the agent reads one record instead of five exports.
Then the brief says so. Contacts that arrive from a CRM sync or an import may have no tracked events yet, and “signed up cold, no site history” is a useful read on its own. Connecting more sources (the events snippet, product events, email) fills in the blanks over time.
A note on the contact, written with create_contact_note: the brief plus the evidence behind it. The note lives on the unified profile every connected agent and teammate reads; syncing notes into two-way CRMs like HubSpot is rolling out. Nothing else changes unless you also ask the agent to update fields.
Yes. The calls are stateless MCP requests, so any scheduler works: a recurring task in ChatGPT or Claude each morning, an n8n flow on the signup webhook, or a cron in your own runner. Start with a daily run a human reviews; tighten the loop once you trust the reads.
Sign up, connect one CRM or drop the events snippet, and point your MCP client at
mcp.pathbound.ai/mcp.