GUIDES

MCP servers

Point EERRAA 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 EERRAA 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. EERRAA 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.

text
URL:   https://mcp.example.com/sse
Auth:  bearer
Token: (stored encrypted, sent as Authorization: Bearer …)

Discover and enable

When you connect, EERRAA 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.

Re-running Discover later preserves your choices. Newly added tools come in disabled, the ones you already enabled stay enabled, and the ones you turned off stay off. Safe to re-Discover any time the upstream server changes.

Auth types

Pick how EERRAA authenticates to the server when it connects and when it calls tools.

FieldTypeDescription
noneauthPublic server, no credentials. EERRAA connects directly.
bearerauthA bearer token sent as Authorization: Bearer <token>. Stored encrypted.
headerauthA custom header (name and value) attached to every request.
oauthauthFull 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, EERRAA 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 EERRAA has to trust who is connecting.

Per-user connections are driven straight from the widget. You can kick one off from your own UI:

js
// Prompt the current user to connect their own account for one server
ERA.connectMcp("server_id")
Under the hood the widget calls 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. EERRAA 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, template it the same way custom tools do. EERRAA substitutes at call time, so the secret goes to the upstream server and never to the model.

text
# From the per-user vault (Fernet-encrypted at rest):
Authorization: Bearer {{user.creds.exa_key}}

# Forward the live JWT you signed the identity with:
X-Auth-Token: {{user.auth_token}}
The vault caps at 50 credentials per user and 8 KB per value. Provision them server-to-server with PUT /v1/credentials (signed identity), or let a user add their own from the widget when signed identity is on.