Agents
Connecting tools and databases
Give agents tools from your own systems (a database, Supabase, Stripe, your own services) and choose which tools need a person's OK first.
Connections give your agents tools from your own systems. With a connection to your database, an agent fixing a bug can look at the real rows; with Stripe, it can look up a customer's payments. You choose which agents get each connection, and for every tool whether agents use it on their own, ask first, or never.
A connection is a link to an MCP server: a service that offers tools to AI agents over the Model Context Protocol. Many products run one for you (Supabase, Stripe), and there are open-source MCP servers for databases and most other tools that you can run yourself.
Add a connection
Workspace owners and admins add and change connections:
- Open Settings → Agent connections and choose Add connection.
- Give it a Name that says what it reaches, for example "Production database (read-only)".
- Paste the MCP server address. The service's docs call it the remote MCP
or Streamable HTTP URL. It must be a public
https://address; private and local network addresses aren't accepted. - If the server needs one, paste a Token (an access token or API key). Use one with the least access that does the job (see Keep it safe).
- Optionally pick the Agents that may use it now. You can also do this later, after you've looked at the tools.
- Choose Add connection.
Deckbell contacts the server and lists its tools. If it can't, the dialog says why: the address didn't answer, the server refused the token, or the address isn't an MCP server. A workspace can have up to 20 connections.
The token is sent to the server as Authorization: Bearer <token> and is never
shown again. It's stored encrypted, and it's never placed in the agent's
workspace, so an agent can't read it or send it anywhere else.
Allowed, Ask first, Off
Open a connection to see its tools. Each tool has one of three settings:
| Setting | What happens |
|---|---|
| Allowed | Agents use it without asking. |
| Ask first | The run pauses until a person approves that call (see Approve a tool call). |
| Off | Agents can't see or use it. |
When you add a connection, tools the server marks as Read-only start as Allowed and every other tool starts as Ask first. Change any of them, or use Set all to set every tool at once. Find a tool filters a long list.
Servers add and remove tools over time. Choose Check again (or Check tools again in the connection's ⋯ menu) to list them again; new tools get the same defaults. Changing the address or token lists the tools again too.
The Read-only mark comes from the server. Deckbell can't check what a tool really does, so read a tool's description before you allow it.
Choose which agents use it
Only the agents you pick get a connection's tools. Pick them under Agents on the connection, or turn the connection on in the agent's own settings:
- On a project's Agents tab, open the agent's ⋯ menu and choose Edit.
- Under Connections, turn on the ones this agent may use.
- Save.
Anyone who can edit an agent can turn its connections on and off, but only owners and admins can add connections or change their tools. Changes apply from the agent's next run.
Approve a tool call
When an agent wants to use a tool set to Ask first, its run pauses and asks. The request shows exactly what the agent wants to send, such as the full SQL query, and waits up to 15 minutes.
- Approve runs this one call, and the agent carries on. The next call to the same tool asks again.
- Decline skips it, and the agent carries on without it. On the run page you can add a note to tell the agent why, or what to do instead ("Use the staging database for this.").
- If no one answers in time, the call is declined, and the agent says so in its summary.
You don't have to watch the run page. The request also reaches people where they are:
- Where the run started. The agent posts the request with Approve and Decline in the chat where it was asked, or on the issue. See the input opens the run page at the request.
- Inbox and push. The person who started the run (for automatic runs, the issue's assignee or creator, or else the board's admins) gets an Inbox notification and a push notification, and an email if it's still waiting after 5 minutes.
Anyone who can run agents on the board can answer. Once someone does, the post shows who allowed or declined it. The run page keeps every request, with what it asked for and the answer. See Approvals for who's told and how to turn the push notifications off.
Examples
A Postgres or MySQL database
Run an MCP server for your database on your own infrastructure, reachable over
https://, and connect it to the database as a read-only user (see
Create a read-only database user). Then add
its address here, with the token your server expects. With a read-only user you
can let agents run queries (Allowed), because the database itself refuses
any change. Point it at a replica or a staging copy when you can.
Supabase
Supabase runs an MCP server for you.
- Address:
https://mcp.supabase.com/mcp?project_ref=<your project ref>&read_only=true.project_reflimits the agent to one project, andread_only=trueruns every query as a read-only database user. - Token: a personal access token from your Supabase account settings.
Stripe
- Address:
https://mcp.stripe.com - Token: a restricted key from the Stripe Dashboard that allows only what the agent needs (for example, read access to customers and payments). Check Stripe's MCP docs for which keys its server accepts.
Leave money-moving tools such as refunds on Ask first, and set tools you never want used, such as cancelling subscriptions, to Off.
Sentry and Notion
The servers that Sentry and Notion run for you sign in through a browser (OAuth), or expect a different header than connections send, so they don't work as connections yet. You can connect an MCP server for them that you run yourself and that accepts a token. To bring Sentry errors into Deckbell without an agent, see Sentry; for Notion pages, see Notion & Confluence.
Your own tools
Anything with an MCP server can be a connection: an internal admin API, a feature-flag service, a runbook search. Mark tools that only read as read-only on your server, so they start as Allowed.
Create a read-only database user
Give an agent a database user that can read and nothing else. Then even an Allowed query can't change or delete data. Use a strong password, and keep it in your MCP server's settings, not in Deckbell.
Postgres
Run this as an admin, replacing the database name, schema and password:
CREATE ROLE deckbell_agent LOGIN PASSWORD 'a-long-random-password';
ALTER ROLE deckbell_agent SET default_transaction_read_only = on;
ALTER ROLE deckbell_agent SET statement_timeout = '30s';
GRANT CONNECT ON DATABASE app_production TO deckbell_agent;
GRANT USAGE ON SCHEMA public TO deckbell_agent;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO deckbell_agent;
-- Tables created later by the role that owns them:
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO deckbell_agent;
default_transaction_read_only makes every transaction read-only, and
statement_timeout stops a slow query after 30 seconds. To hide sensitive
tables or columns, grant SELECT only on the tables (or columns) the agent
needs instead of ALL TABLES. On Postgres 14 and later you can use
GRANT pg_read_all_data TO deckbell_agent; to read every table in every schema.
MySQL
CREATE USER 'deckbell_agent'@'%' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT, SHOW VIEW ON app_production.* TO 'deckbell_agent'@'%';
Replace '%' with the address your MCP server connects from, so the user can't
sign in from anywhere else. To limit it further, grant SELECT on single tables
(app_production.orders) instead of the whole database.
Keep it safe
- Least access. Use read-only database users, restricted API keys and tokens scoped to one project.
- Ask first for anything that changes data, spends money or contacts customers. Turn tools you never need Off, so agents don't even see them.
- Only the agents that need it. A connection's tools reach only the agents you turn it on for.
- Remove what you don't use. Remove in a connection's ⋯ menu deletes the saved address and token; agents that used it lose its tools from their next run.
- Agents read what tools return. Text from a tool (a database row, a customer's note) can contain instructions. Ask first keeps a person in the loop for anything that writes.