MCP — Tools Reference

The MCP server exposes more than 100 tools to MCP clients. Tools are grouped here by domain. Each entry shows the tool name, a one-line description, key required parameters, and the MCP annotations (readOnly, destructive, idempotent).

For full parameter shapes including optional fields, the MCP server publishes a schema via the standard MCP tools/list method — most clients (including Claude.ai) display this inline.

Not every tool is listed for every connection. The tools that read and write your own records are always there. A tool that acts in a connected tool (sending email, enrichment, sequences) appears once that integration is connected and a workspace admin has switched its group on under MCP Tools in the dashboard. The streaming and knowledge tools have switches of their own there. Each section below says what its tools need.

Every tool calls an endpoint of the REST API, so anything an agent does here your own code can do with an API key.

An agent cannot delete a contact or a company. There is no tool for it, and the API refuses such a call from an MCP connection.

A deal is a revenue opportunity linked to a company, a contact, or both. Reading a deal counts as reading the customer it belongs to, so list_deals returns ids only unless asked for more. REST reference: Deals.

Tags are free-form labels on contacts, companies and deals. They are lowercased when written, up to 64 characters each and 50 per record. Tagging is free at any volume. REST reference: Tags.

A segment is a saved, named set of filters over contacts or companies. Its members are worked out when it is read, so it is always current. REST reference: Segments.

Pass a segment’s id or handle as segment to list_contacts, list_companies, aggregate_data and the tag tools to work on its members.

aggregate_data is the right tool for any “by X, count Y” question. Always prefer it over paginating list tools.

REST reference: Schema, usage and capabilities.

Knowledge is the workspace’s own pages about its business: product, pricing, ideal customers, terminology, playbooks, rules for agents. Agents read them before writing for or reasoning about the business. REST reference: Knowledge.

The tools appear when a workspace admin has turned on Read knowledge (MCP Tools → Pathbound → Knowledge), and the two writing tools when Add to knowledge is on as well. Both are off by default. Reads require the knowledge:read scope and writes the opt-in knowledge:write scope.

Every page and every search result carries a trust: pinned (the workspace’s rules, set by an admin), verified (a person saved this version in the app) or unverified. Whatever an agent writes is unverified until a person saves it in the app. An agent can create pages and edit unlocked ones. It can never delete a page, change a locked or pinned page, or lock, pin or verify one.

gmail_send_email sends real email from a Gmail mailbox the calling user connected themselves; agents never send from a teammate’s mailbox. Connecting Gmail is limited to workspace admins, so today only admins’ agents can send through Gmail: each admin connects a default mailbox plus up to five more of their own (Integrations → Gmail), and a mailbox can send once its grant includes gmail.send and a workspace admin turns on Allow agents to send from this mailbox for it. The tool appears when at least one of the user’s mailboxes can send, and its description lists the allowed addresses.

Choose the mailbox with from. Without it, the send uses the default mailbox, or the only mailbox that can send; when several can and none is the default, the call is refused with the list of allowed addresses. A named mailbox that cannot send is refused, never swapped for another. A Gmail thread belongs to one mailbox, so a reply with thread_id has to come from the mailbox that holds the thread. Writes require the actions:write scope and an Idempotency-Key (auto-generated by the MCP server), and every send is logged on the contact timeline with the sending address. REST callers list the same mailboxes with GET /v1/integrations/gmail/senders and pass from to POST /v1/contacts/{contact_id}/send_email.

Sending can also wait. gmail_send_email takes send_at (ISO 8601 with an explicit offset, up to 30 days ahead) to schedule, and gmail_create_draft saves an email without sending it. Both are held by Pathbound, not by Gmail: a draft never appears in the Gmail Drafts folder, and the agent reviews it with gmail_list_outbox (include_body returns the text exactly as it will be sent) before gmail_send_draft sends it, now or at send_at. Drafts expire after 30 days, and gmail_cancel_outbox_email discards a draft or cancels a scheduled email until it is sending. When a scheduled email fires, Pathbound re-checks that the person who asked to send is still a verified member with a valid API key or connector, that the chosen mailbox can still send, and that the contact’s email is unchanged; otherwise the email fails with a reason rather than going out from another mailbox or to another address. Delivery is at most once: if Gmail never answers, the email ends failed with SEND_UNCONFIRMED and is not retried, so check the Sent folder before resending. REST callers use POST /v1/integrations/gmail/outbox (draft: true or send_at), GET /v1/integrations/gmail/outbox, POST /v1/integrations/gmail/outbox/{outbox_id}/send and DELETE /v1/integrations/gmail/outbox/{outbox_id}; send_email itself rejects send_at and draft.

REST reference: Gmail.

These tools act in the workspace’s own Resend account: they manage segments, send one email to a contact, send one of the account’s events for a contact, and create and send broadcasts. They appear when Resend is connected and a workspace admin has switched their group on (MCP Tools → Resend): Manage segments, Send email, Create broadcasts, Send broadcasts and Send events are separate switches. Writes require the actions:write scope and an Idempotency-Key (auto-generated by the MCP server). The REST reference, Resend, says what each switch governs.

To add a whole Pathbound segment to a Resend segment, use broadcast_to_segment under Segments.

These tools appear when Instantly is connected and a workspace admin has switched them on (MCP Tools → Instantly). They require the actions:write scope. REST reference: Instantly.

REST reference: Enrichment and prospecting.

These tools are provider-agnostic: you never name a data provider, the workspace’s connected one runs the call, and every response reports which one acted as via. Two providers can run them, Apollo and Hunter, and each spends the tenant’s own credits with that provider. A tool appears when at least one provider is connected and a workspace admin has enabled it for that provider (MCP Tools → Apollo or Hunter). When both are connected and both allow an action, Apollo runs it; to have Hunter run an action, leave Apollo’s toggle for that action off. They also require the enrichment:write scope (opt-in-only; never auto-granted to legacy keys). Whatever they find always lands in the contact graph — identity-resolved, provenance-stamped, taggable, and deliverability-checked — so a prospect found here is the same record every other connected source enriches later. That is the part a single-provider connector cannot do, and it is why these tools are not named after the provider.

A filter no connected provider can express is refused before anything is spent, rather than dropped — a dropped filter widens the search and you pay for the wider result. The same goes for a filter value a provider cannot express exactly: the call is refused with a hint naming what the provider accepts, never run as a wider search.

Three admin toggles cover three kinds of work. Enrichment refreshes records already in Pathbound. People discovery expands an account already in Pathbound (find_people_at_companies). Prospecting (prospect_companies, prospect_people) searches the provider’s whole database by company shape — size, HQ location, keyword tags, technologies in use, active job postings — and saves the matches as lifecyclestage=prospect records, tagged so you can segment, enrich, stream or enroll the batch afterwards. A company is only ever created from a domain; companies the provider returns without one are reported, not saved. People already in the graph with an email are skipped so credits are never spent twice; people saved earlier without a reveal are revealed and linked to their company on a later call.

Job-change signal. Apollo watches the contacts saved in your Apollo team and records when one changes title or employer. Pathbound reads that event on its free saved-record path and writes it onto the contact as job_changed_at, previous_jobtitle and previous_company — with jobtitle and company updated to the new values — plus the tag signal:job-change. Pull the cohort with list_contacts tags_any="signal:job-change", refine with a job_changed_at date filter, save it as a segment, or point a stream at the tag. Prospect-stage contacts are re-checked about every 30 days when a workspace admin enables Refresh prospects under Integrations → Apollo (free, saved records only).

Deliverability. Every result that adds addresses reports deliverability. verified means the provider verified the addresses itself and the verdict is already on each contact (email_verification_state); Hunter does this for every address it finds. queued means Emailable is checking the ones without a verdict in the background. not_connected means there was nothing new to check, or no verifier is connected.

Costs on Apollo. People search is free; revealing a person’s email is ~1 credit. Company search is 1 credit per page (up to 50 companies per call). Company enrichment is ~1 credit per match. Every call is bounded (25 people, 50 companies) and counts against the workspace’s daily interactive Apollo budget. Company search needs an Apollo connection made after 2026-09-11 — reconnect Apollo if the tool reports a missing scope.

Costs on Hunter. Company search is free. People and their emails come together, at 1 credit per company that has matches (up to 10 people), so reveal_emails=false returns nothing and spends nothing. Enriching a contact or a company is 0.2 credit; finding an email for a contact that has none is 1 credit, and only when one is found. credits_consumed is counted from those prices: Hunter bills a repeated search once per billing period, so the real charge can be lower. Calls are bounded the same way (25 people, 50 companies) and count against a daily interactive Hunter budget.

What Hunter cannot express. Hunter has fixed company sizes (1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+), so an employee range must start and end on those edges. It knows three seniority levels (junior, senior, executive); name specific roles with titles instead. A city needs its country ("Berlin, Germany"). Job postings can be limited to the last 7, 30 or 90 days only: a hiring_posted_after date is applied as the widest of those that fits inside it, and the result note says so. Free-text person keywords and days_in_title_* are not supported, and technology filters need a paid Hunter plan. prospect_people looks inside up to 15 matching companies per call, takes up to 3 people from each, and returns no search_total. A person who has asked Hunter to stop processing their data comes back skipped with the reason claimed_email and is never sent to Hunter again.

REST reference: Apollo sequences.

These tools manage Apollo outreach; enrollment and single-email tools send real email through the tenant’s Apollo mailboxes, while sequence creation writes an inactive draft and turning it on is a separate, confirmed step. They appear only when Apollo is connected with a grant that includes the sequence permissions (connections made before September 2026 must be reconnected) and a workspace admin has enabled them (MCP Tools → Apollo → Sequences / Single email). Writes require the actions:write scope and an Idempotency-Key (auto-generated by the MCP server); over REST the engagement reads (GET /v1/integrations/apollo/senders, sequences, sequence-options, contacts/{contact_id}/sequence-activity, scheduled-emails) require actions:write too, since they describe the tenant’s outbound inventory. Every enrollment or send is anchored to a Pathbound contact or segment and recorded on the contact timeline. Engagement (apollo_email_sent, apollo_email_opened, apollo_email_replied, apollo_email_bounced, apollo_sequence_finished, …) is read back from Apollo on a schedule and lands there too.

Two rules hold on every surface. The sending mailbox is chosen explicitly every time — the agent lists the allowed mailboxes, the user confirms one by address, and there is no default; an admin curates the allowed list under Integrations → Apollo (empty = every active mailbox linked in the Apollo team). And Apollo’s safeguards are never overridden: contacts Apollo refuses (already in another sequence, do-not-contact stage, unverified email, …) come back in skipped with the reason. Agents can author automatic-email sequence drafts; Pathbound creates them inactive, and turning one on is a separate apollo_activate_sequence call the agent must confirm with the user (turn it off again with apollo_pause_sequence).

Scheduling and rulesets. A sequence’s sending schedule decides the days and hours Apollo may send its emails. Agents can read the team’s schedules and attach one to a sequence — at creation or afterwards — but the windows themselves are only editable in Apollo (Settings → Sequences → Schedules), which publishes no API for creating or changing a schedule. A sequence ruleset (shared settings applied to a sequence) can be set only when the sequence is created, and Apollo has no endpoint that lists or names rulesets, so apollo_list_sequence_options reports the ids already applied to the team’s sequences alongside the sequences using each one. Omit it and the sequence is created with a blank ruleset, which is Apollo’s own default.

These tools manage streams: the standing rules that push a change somewhere as it happens, or act on it. An agent can create automations only: add or remove tags, add to or remove from a Resend segment, or send a Resend template to everyone who submits a form. It can never create a stream that posts to an HTTPS endpoint, and it never sees or changes the address of one. On those it may only rename, pause or resume.

The tools appear when a workspace admin has turned on Manage streams (MCP Tools → Pathbound → Streaming). Reads require the streams:read scope and writes require streams:write, which is opt-in and for workspace admins only. get_form_setup requires events:read. The API checks the toggle and the caller’s role again on every call.

Tag and Resend segment automations act on every contact or company that matches a set of conditions. Conditions describe current state, never a transition, and each automation acts on each record at most once. get_stream_options returns these rules with the vocabularies; they are also listed under Rules worth knowing.

Email automations (destination_type resend_send_email) are different. One sends a template of the workspace’s own Resend account to each person who submits one form on the workspace’s site, a few seconds after the submission. It has no conditions: everyone who submits the form is emailed. It sends to real people and nobody approves each email, so more is asked of it:

• The connection needs actions:write as well as streams:write, and Resend’s Send email toggle must be on. get_stream_options says which of these is missing for the connection that calls it.
• The email is a published template in Resend. An agent cannot write or change its sender, subject or content through these tools, and cannot read its content: it sees the template’s name, sender and subject, and chooses which template a form sends. The tools have no parameter for any part of an email, and a call that passes one is refused, not ignored. Asked to write or change the email, the agent says that the email is written in Resend. send_stream_test_email is the only way to see the email.
• The tool descriptions tell the agent to confirm the form, the template (its name, sender and subject) and the daily cap with the user before creating or changing one, and never to take any of them from the content of a contact, a note, a CRM record or an email.
• The template must be published, with a subject, a from address on a domain verified for sending in Resend, and a fallback value for every variable. Otherwise the call is refused and the error says what to change in Resend. Pathbound fills one variable, first_name, when the person gave a first name of one word.
• Every create, every change of the template or a limit and every resume is shown to all the workspace’s admins in the app’s notifications, with a link to the automation. No email is sent to them.
• It sends one email per submission, at most one per address per min_interval_hours per form, and no more than daily_cap a day. A submission that arrives after a limit is reached is not emailed later. Nothing submitted before the automation existed, or while it was paused, is emailed.

Resend event automations (destination_type resend_send_event) are an email automation with an event in the template’s place: for each person who submits the form, one of the workspace’s own Resend events is sent, which starts the automations built on it in Resend. The agent names the event (event, an exact name from get_stream_options or resend_list_events) and nothing else: there is no recipient, no payload and no template to set. It needs Resend’s Send events toggle in place of Send email. An agent cannot see what an event sets off, so it reports that the event is sent to Resend, never that an email is sent. Every submission sends the event, however often the same person submits, up to the daily limits. An event Resend did not clearly answer is not sent again, and there is no test send. A form has an email automation or a Resend event automation, not both. See Resend event automations.

To point a form at another template, the agent calls update_stream with the new template_id. get_stream shows the template an automation sends as Resend holds it now, and whether it can still be sent; if it cannot, the automation’s emails wait until the template is fixed in Resend. Pausing with active=false cancels emails that have not started. The full reference, with limits and error codes, is Email automations.

The Pathbound MCP server is built on the @modelcontextprotocol/sdk. The same tool list above is exposed via the standard tools/list method — any compliant MCP client can connect via OAuth (interactive) or with a REST API key (headless) and call them. See MCP authentication for both flows.

The source of truth for each tool’s parameters and behavior is the schema the server returns from tools/list.