MCP
MCP client
Let OrcaPulse consume external MCP servers so assistants and workflows can use third-party tools, live business context, and approved actions without one-off custom integrations.
Overview
In the MCP client model, OrcaPulse connects out to an external MCP server and loads the tools that server exposes. This is the right setup when your assistants need to work with systems that are not native OrcaPulse features, such as scheduling platforms, CRMs, workflow engines, internal knowledge tools, or custom business actions.
Think of this page as the operator guide for connecting those tools safely. It covers what users need to prepare, how to think about configuration, which MCP providers are commonly used, and how to write instructions so OrcaPulse assistants use dynamic tools well.
Use the MCP client pattern when OrcaPulse should call someone else's tools. Use the MCP server guide when you want Claude, Cursor, or another MCP client to call into OrcaPulse itself.
Prerequisites
- Have an active OrcaPulse workspace and portal access at app.orcapulse.ai.
- Have an assistant, workflow, or automation path in OrcaPulse that would benefit from external tool access.
- Know which external systems matter most for your team today: CRM, calendar, messaging, support, or internal data.
- Review the external tool's permission scope so future tool access stays tightly controlled.
Current state
OrcaPulse does not currently expose a public self-serve MCP client setup flow in this portal. That means users cannot yet log in, paste an MCP server URL, and immediately attach third-party MCP tools from a dedicated workspace settings screen.
What OrcaPulse does support today is the operational foundation around that future flow: assistants, workflows, integrations, lead handling, API access, and security controls. So the practical job today is to prepare those real product surfaces and treat MCP as a support-assisted or planned extension, not a live self-serve feature.
What users can do today
- Build assistants and workflows inside the live OrcaPulse portal.
- Connect supported integrations through the current integrations area.
- Use the OrcaPulse API for workflows, leads, calls, integrations, templates, and related operations.
- Design external-tool use cases now so they map cleanly to future MCP-style access later.
In other words: the current real path is `portal + integrations + API`. MCP client support should be treated as an extension of those foundations, not as the main operational entrypoint today.
How it would work
When OrcaPulse consumes external MCP tools, the model would connect to a configured MCP server, discover the approved tools, call those tools during workflow or assistant execution, and then use the returned result inside the rest of the OrcaPulse flow.
The examples below are reference patterns only. They are useful for planning and implementation discussions, but they do not mean a self-serve OrcaPulse MCP client configuration screen is already available in the current portal.
Default configuration (Streamable HTTP)
{ "type": "mcp", "function": { "name": "workspaceTools" }, "server": { "url": "YOUR_MCP_SERVER_URL", "headers": { "Authorization": "Bearer YOUR_PROVIDER_TOKEN" } }, "metadata": { "protocol": "shttp" }}Custom configuration (SSE)
{ "type": "mcp", "function": { "name": "workspaceTools" }, "server": { "url": "YOUR_MCP_SERVER_URL", "headers": { "Authorization": "Bearer YOUR_PROVIDER_TOKEN", "X-Workspace": "sales-automation" } }, "metadata": { "protocol": "sse" }}Treat these as planning templates. The safest live implementation path today is still the existing OrcaPulse integrations and API stack.
Example usage
Good results come from pairing MCP tools with strong system instructions. The model should know when it is allowed to call tools, when it should ask for confirmation, and what to say after a tool succeeds or fails.
System instruction example
You are an OrcaPulse operations assistant. Use MCP tools when the user asks to:- look up records in connected systems- trigger approved follow-up actions- update CRM or workflow state- retrieve external context required to complete a task Before executing write actions:- confirm the target record- explain what you are about to do- summarize the result after the tool call finishes If the MCP server is unavailable, tell the user and suggest the OrcaPulse portal or API as fallback.Example user requests
- Scheduling: "Book a follow-up meeting for next week and add it to the connected calendar."
- CRM lookup: "Find this account in the CRM and show the last activity before I call them."
- Workflow action: "Run the approved onboarding sequence for this lead after you confirm the email address."
- Support operations: "Check our internal support knowledge source and draft the best response for this ticket."
Best practices
Keep the current product reality in mind while planning MCP-related work.
Build for today first. If your use case is already solvable through OrcaPulse integrations, workflows, and API routes, use those real supported paths before designing around future MCP access.
- Use supported surfaces first: assistants, workflows, integrations, and the API are the real product paths today.
- Avoid pretending MCP is self-serve: only document user actions that actually exist in the current portal.
- Keep prompts explicit: even future MCP-style tool access should remain narrow and approval-aware.
- Plan fallback paths: if advanced tool access is not available, users should continue through the portal or direct API.