Custom tools
When the capability you need isn't built in, add it: point your agents at your own HTTP endpoint or MCP server.
Who can do what
| Task | User | Agent owner | Admin |
|---|---|---|---|
| Register a custom tool | — | — | ✅ |
| Edit or delete a custom tool | — | — | ✅ |
| View the egress allow-list | — | — | ✅ |
| Add a registered custom tool to an agent | — as Editor | ✅ | ✅ |
Registration is admin-only because a custom tool is a new route out of your organization. Once registered, it behaves like any other tool and an agent's owner or Editor can attach it.
Registering one
Organization → Integrations → Custom tools. You give the tool a name, a description, and its endpoint.
The description matters as much as it does for a skill: it's what the agent reads to decide whether this tool is the right one. Say what it does and when to use it.
For an MCP server, Delegate reads the server's tool catalogue and presents each advertised tool to the agent. Re-read the catalogue from the agent's tool settings after you add or change tools on your server — the list isn't refetched automatically.
The egress allow-list
Custom tools can only reach hosts on the organization's egress allow-list. Admins can view it in the same area; it's maintained by the platform team.
This is a containment boundary, not a formality. It means a compromised or misbehaving tool definition can't be used to reach an arbitrary host, and it's why adding a tool pointing somewhere new needs the host allowed first. If a custom tool fails with a connection error, check the allow-list before debugging your server.
Writing a good tool
The MCP guide covers this properly. The short version:
- One tool, one job, with a name that says which job.
- Scope by credential, not by argument. Derive whose data to touch from the authenticated token, never from a parameter the model fills in — you cannot verify a value the model produced. See the security model.
- Gate mutations separately. A tool that changes something needs its own confirmation path.
- Return errors the agent can act on. "Invalid request" tells it nothing; "start_date must be before end_date" gets it fixed on the next call.
Tool descriptions are untrusted
Delegate treats the descriptions your MCP server advertises as data, not as instructions — a server can't use its tool description to redirect the agent. Worth knowing if you're relying on a third-party MCP server, and worth mirroring in your own trust decisions.
Building an integration
If you're embedding Delegate agents into your own product rather than adding a tool to your own agents, start at Building an integration.