The pages here cover the products we have tested, but Pathbound is one remote MCP server, so any MCP-capable agent can read the same customer profiles. Point a custom or in-house agent, or a runtime we have not documented yet, at the endpoint and it gets the resolved contact, company, timeline, and conversation history.
If your agent can call a remote MCP server, it can read Pathbound. There is no Pathbound-specific SDK to install.
Most agent SDKs and desktop clients can register a remote MCP server. That is all Pathbound needs to expose its tools.
Interactive clients complete Pathbound OAuth. Headless and custom runners send a scoped API key as a bearer token.
A custom agent reads the identity-resolved contact and company, event timeline, and conversation history that every other runtime sees.
Two paths: a bearer API key for a headless or in-house runner, or interactive OAuth for a client that can open a browser.
In Pathbound, open REST API keys and create a key with contacts:read, companies:read, and events:read. Add write scopes later, only when a workflow needs them.
Register Pathbound as a remote Streamable HTTP MCP server and send the key in the Authorization header. Most MCP client libraries take a URL and a set of headers.
{
"mcpServers": {
"pathbound": {
"type": "http",
"url": "https://mcp.pathbound.ai/mcp",
"headers": { "Authorization": "Bearer ${PATHBOUND_API_KEY}" }
}
}
}If the client supports MCP OAuth, add the same URL https://mcp.pathbound.ai/mcp and let it authorize in the browser. No API key is stored in that case.
Confirm the client discovered the Pathbound tools, then ask it to read a contact you can verify (for example get_contact then get_contact_timeline) before wiring it into a workflow.
New to MCP? The MCP docs cover the endpoint, tools, and authentication. Popular agent SDKs (the OpenAI Agents SDK, the Vercel AI SDK, Google ADK, and others) all accept a remote MCP server.
A custom agent can run unattended. Decide what it can read before you let it write.
Create the smallest key scope that serves the job, and rotate or revoke it from the dashboard. A key without actions:write receives no write or action tools.
Store the key in the runtime environment, never in source control. Start read-only, add one write path at a time, and keep an approval step around anything that changes a record.
Any client or SDK that can call a remote MCP server over Streamable HTTP, including custom in-house agents and runtimes we have not written a page for yet. If your client supports MCP, it supports Pathbound.
Use interactive OAuth when the client can open a browser and each person should connect their own Pathbound identity. Use a scoped sk_ API key as a bearer token for a headless or shared runner.
No. Pathbound is a standard MCP server, so your existing MCP client library is enough. Send a URL and an Authorization header; Pathbound returns the tools.
If you would like a step-by-step page for a product we have not covered, tell us. The documented runtimes are on the use-with hub; the rest connect the same way as above.
Only when the key includes the required write scopes and the connected source allows the tool. Keep the first setup read-only. Governed write-back is rolling out; versioning and rollback are not live yet.
Sign up, connect one CRM or drop the events snippet, and point your MCP client at mcp.pathbound.ai/mcp.