Skip to content
Deckbell

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

Settings → Agent connections
The Agent connections page, opened from the Workspace group of the Settings sidebar: three connections and the Add connection button.

Settings → Agent connections

Workspace owners and admins add and change connections:

  1. Open Settings → Agent connections and choose Add connection.
  2. Give it a Name that says what it reaches, for example "Production database (read-only)".
  3. 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.
  4. 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).
  5. Optionally pick the Agents that may use it now. You can also do this later, after you've looked at the tools.
  6. Choose Add connection.
Agent connections → Add connection
The Add a connection dialog with a name, the MCP server address and an optional token.

Agent connections → 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

Agent connections → a connection → Tools
The tools of a database connection, each set to Allowed, Ask first or Off, with read-only tools marked.

Agent connections → a connection → Tools

Open a connection to see its tools. Each tool has one of three settings:

SettingWhat happens
AllowedAgents use it without asking.
Ask firstThe run pauses until a person approves that call (see Approve a tool call).
OffAgents 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

Agent connections → a connection → Agents
The Agents part of a connection, choosing which agents get its tools.

Agent connections → a connection → Agents

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:

Agents → ⋯ → Edit → Connections
The Connections part of the Edit agent dialog, with a switch for each of the workspace's connections.

Agents → ⋯ → Edit → Connections

  1. On a project's Agents tab, open the agent's ⋯ menu and choose Edit.
  2. Under Connections, turn on the ones this agent may use.
  3. 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.

Run page → Approvals
A request for approval on a run page: the agent wants to run a SQL query, with the query shown in full, the time left, and Approve and Decline buttons.

Run page → Approvals

  • 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:

The request on the issue
The agent's request for approval posted on the issue, with Approve, Decline and See the input.

The request on the issue

  • 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_ref limits the agent to one project, and read_only=true runs 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.

Still stuck? Email us and we’ll help.