Not everything you want an agent to do lives in Pipedream’s catalog. Custom MCP lets you register your own Model Context Protocol server as a data source — your server’s tools become first-class agent tools alongside the OAuth’d integrations. This is the right move when you have an internal API, a private database, or a domain-specific tool surface that already speaks (or can speak) MCP.Documentation Index
Fetch the complete documentation index at: https://docs.copass.com/llms.txt
Use this file to discover all available pages before exploring further.
What you can do
- Register your MCP server’s URL and credentials as a
user_mcpdata source. - Health-check the connection.
- Revoke the source (your server stays running; Copass forgets the binding).
- Have agents call your tools the same way they call any OAuth’d integration tool.
Via the Concierge (recommended)
“Add my MCP server at https://mcp.acme.internal — it’s authenticated with a bearer token.” “Test the health of my custom MCP source.” “Revoke my custom MCP source.”The Concierge walks through the registration interactively: server URL, auth scheme (bearer / header / none), label, sandbox.
Via the CLI
What the agent sees
Once the source is live, every tool your MCP server exposes shows up in the dynamic tool catalog under the source’s label. An agent in the same sandbox can call them by name — no per-agent wiring, no allowlist edit needed. To inspect what tools an agent will actually see:“What tools does my support agent have right now?”
Auth patterns
Copass supports the common MCP auth schemes:| Scheme | When to use |
|---|---|
| None | Local dev, internal-only servers behind a VPC. |
| Bearer token | A static token your server validates on every request. Most common production setup. |
| Custom header | Anything more complex — your server expects a specific header name and value. |
Building a server (if you need to)
This page assumes you already have an MCP server running. If you’re writing one from scratch:- Spec: Model Context Protocol — Copass speaks the standard MCP wire protocol. Any conformant server works.
- Transports: Copass supports HTTP servers (the most common). stdio servers can be wrapped behind a thin HTTP shim.
- What Copass calls: at runtime Copass calls your server’s
tools/list(once at resolve time, cached briefly) andtools/call(on every tool invocation by the agent). Your server sees standard MCP requests. - What Copass doesn’t call: prompts, resources, and notifications. The current integration is tool-only — your server can advertise prompts and resources, but Copass agents won’t reach for them.
Common patterns
Internal API surface
Wrap your internal REST API in an MCP server. Agents in your sandbox can call it without you maintaining a custom adapter on the Copass side.
Private knowledge base
Expose your private docs / runbooks / wikis through MCP. Now agents can query them as a tool, not just as ingested chunks.
Multi-environment routing
Register
dev, staging, and prod MCP servers as separate sources. Agents in the right sandbox automatically use the right environment.Plug a partner's MCP in
Your partner publishes an MCP server. Add it as a
user_mcp source — no engineering on your side beyond the registration.Next steps
- Data Sources — the lifecycle pattern your custom MCP follows.
- Integrations — OAuth’d alternative when the Pipedream catalog covers your need.
- MCP Server — Copass’s own MCP surface (different concept — this exposes Copass to MCP clients like Claude Code).

