GUIDES
MCP servers
Point Agentifys at a remote MCP server and its whole toolset shows up, ready to enable. No glue code, no per-tool wiring.
The Model Context Protocol is the fastest way to give your agent a lot of capability at once. Connect a remote MCP server over Streamable-HTTP and Agentifys imports every tool it exposes. You then turn on the ones you want.
Connect a server
Add an MCP server in your project with its Streamable-HTTP URL and an auth type. Agentifys connects, lists what the server offers, and pulls the tools in. You do not describe each tool by hand: the server already declares its names, descriptions, and schemas.
URL: https://mcp.example.com/mcp Auth: bearer Token: (stored encrypted, sent as Authorization: Bearer …)
2025-06-18. Local stdio servers and the legacy two-channel SSE transport are not supported. The URL passes the same SSRF guard as a webhook tool on every call: https only, and no host that resolves to a private, loopback, link-local, reserved or multicast address. Redirects are not followed.Discover and enable
When you connect, Agentifys runs Discover: it fetches the server's tool list and imports each one disabled. That is on purpose. You review the list and enable exactly the tools you want your agent to have, nothing more.
A discovered tool whose name reads like a write — it is, starts with, or contains one of create, update, delete, send, post, cancel and a dozen similar verbs — is imported with requires_confirmation already on, so the first call waits for the user to approve it. That is a heuristic on the name, not a claim about what the tool does. Check it per tool and override where it guessed wrong in either direction.
Auth types
Pick how Agentifys authenticates to the server when it connects and when it calls tools.
| Field | Type | Description |
|---|---|---|
none | auth | Public server, no credentials. Agentifys connects directly. |
bearer | auth | A bearer token sent as Authorization: Bearer <token>. Stored encrypted. |
header | auth | A custom header attached to every request. If you leave the header name blank it defaults to X-API-Key. |
oauth | auth | Full OAuth 2.1 with PKCE. Either shared (you connect once) or per-user (each end user connects from the widget). |
OAuth 2.1: shared vs per-user
For servers that need OAuth, Agentifys runs the full authorization_code flow with PKCE. There are two ways to hold the connection, and the choice depends on whose account the tools should act on.
- Shared. You (the admin) connect once, and every user of the project shares that single authorization. Right when the tools act on your organization's account, not the individual's.
- Per-user. Each end user connects their own account from inside the widget, so the agent acts as that user upstream. This requires signed identity, since Agentifys has to trust who is connecting.
Per-user connections are driven straight from the widget. You can kick one off from your own UI:
// Prompt the current user to connect their own account for one server
ERA.connectMcp("server_id")POST /v1/oauth/mcp/start (which returns an authorize_url), and you can list connectable servers with GET /v1/oauth/mcp/servers or revoke with DELETE /v1/oauth/mcp/connection/{server_id}.The one-click catalog
You do not have to hunt down URLs for the common providers. Agentifys ships a one-click catalog: pick a provider and it connects with the right settings already filled in.
In the catalog today: Tavily, Exa, Firecrawl, Context7, DeepWiki, and Hugging Face. Add one, Discover, enable the tools you want, and your agent can search the web or read docs in minutes.
Forward per-user credentials
When a server uses bearer or header auth but the value differs per user, put a {{user.*}} placeholder in the stored token instead of a literal secret. Agentifys substitutes it at call time, so the secret goes to the upstream server and never to the model.
# Token field, bearer auth — from the per-user vault (Fernet-encrypted at rest):
{{user.creds.exa_key}}
# Token field — forward the JWT you signed the identity with:
{{user.auth_token}}{{…}} and it resolves to an empty string — the credential name does not match anything in that user's vault, or the user is not signed in — Agentifys does not open the connection. The tool returns TOOL_DISABLED with a detail naming the exact credential the template asked for, and no failure alert is raised, because this is a configuration state rather than an outage.{{user.auth_token}} is empty in a scheduled run. The scheduler snapshots only the user id plus name, email, role and company, so a server whose token is {{user.auth_token}} is unusable unattended: its tools return TOOL_DISABLED on every scheduled run. Vault credentials are the exception — {{user.creds.<name>}} resolves normally there.PUT /v1/credentials with a signed identity. There is no route for an end user to add their own credential from the widget — the widget never touches /v1/credentials. In the console you can list the masked hints and revoke entries, but not enter values.