Letting AI assistants work with your business data through MCP

To let an AI assistant work with your business data, you connect it to an MCP server: a service that exposes named tools (list rows, update a record, count open orders) which the assistant can call. The safe version signs each person in with OAuth, acts with that person's own permissions, keeps read tools apart from write tools, caps what comes back and rate-limits the calls. The risky version is a database connection string pasted into a config file, which gives the model everything that database user can do.

This guide covers what MCP is, why raw credentials are the wrong shortcut, a checklist for judging any MCP server, and how the Emberblocks server handles each point.

What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to the systems where data lives. Anthropic open-sourced it on 25 November 2024. On 9 December 2025 Anthropic donated it to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. As of October 2026 the current version of the specification is dated 2026-07-28.

A server can offer three things: tools (functions the model can call), resources (data for context) and prompts (templated workflows). Local servers run as a subprocess on your machine and talk over stdio. Remote servers sit behind a URL and use Streamable HTTP, where each message is an HTTP POST to a single endpoint. Remote is the kind that matters for shared business data, because one server can serve a whole team without anyone installing anything.

Client support is wide as of October 2026. Claude supports custom connectors to remote MCP servers on every Claude plan from Free to Enterprise (Free users get one custom connector). ChatGPT's developer mode gives full MCP client support for read and write tools on Pro, Plus, Business, Enterprise and Education accounts on the web. VS Code and Cursor both connect to MCP servers that require OAuth sign-in.

Why giving an assistant raw database credentials is risky

The fastest setup is a generic database MCP server with your connection string in its config. It works in five minutes, and it is the setup most likely to hurt you later.

{
  "mcpServers": {
    "prod-db": {
      "command": "npx",
      "args": ["some-database-mcp-server", "postgresql://app_user:S3cret@db.example.com:5432/prod"]
    }
  }
}

• Everything the database user can do, the model can do. If that user can run DELETE or DROP TABLE, so can a tool call. A read-only database role helps, but it is just as easy to paste in the app's own credentials.
• One identity for everyone. Every query arrives as the same database user. Rules that depend on who is asking (a sales rep sees only their accounts) do not apply, and your logs cannot tell people apart.
• The password lives in a file. Each copy can end up in backups or a dotfiles repo, and rotating the password breaks every copy at once.
• Prompt injection travels through data. OWASP lists prompt injection as the top risk for LLM applications in 2025, including indirect injection from content the model reads. A support ticket or a customer note can carry instructions. Simon Willison calls the mix of private data, untrusted content and a way to send data out the lethal trifecta.
• Nothing slows it down. A model stuck in a retry loop can run thousands of queries against production.

The specification is blunt about it: tools represent arbitrary code execution and must be treated with appropriate caution, and hosts must get explicit user consent before invoking any tool.

What does a permissioned MCP layer add?

A permissioned layer sits between the assistant and the database. It turns "any SQL statement" into a short list of named operations that run as a signed-in person, under the same rules that person has everywhere else.

The MCP specification supports this design but does not force it: authorization is optional for MCP implementations, which is why you have to check each server. Where a server does use it, the authorization section builds on OAuth 2.1, requires servers to publish protected resource metadata (RFC 9728) so a client can find where to sign in, and requires clients to use PKCE. The security guidance forbids token passthrough: a server must not accept tokens that were not issued for it. Servers must also validate tool inputs, implement access controls, rate limit tool calls and sanitize outputs.

How do I evaluate an MCP server before connecting it?

Run any server, vendor-built or open source, through these questions before it touches real data.

1. How does it authenticate? OAuth with your own login is the bar. A pasted API key or connection string means anyone holding the file holds the access.
2. Whose permissions does it use? It should act as you, with your roles. A server running on a service account or an admin key can show the assistant data you could not open yourself.
3. Are reads and writes separate tools? You want to allow reading without allowing writing, and to see which tools change things.
4. What do destructive tools require? Deletes and schema drops should need an explicit confirmation argument, ideally with an impact report first.
5. Are results capped? Page limits and column selection keep a single call from pulling a whole table into the model's context.
6. Is there a rate limit, and does it fail closed? If the limiter breaks, calls should be refused rather than waved through.
7. Are secrets ever returned? API keys and passwords stored on the server should be write-only from the assistant's side.
8. Can you see and revoke connections? You should be able to list connected clients, see when each was last used, and disconnect one.
9. Are changes attributed? A row edited by an assistant should say so in the history.

The same thinking applies to permissions in the app itself; row and field level permissions covers how to design them.

How the Emberblocks MCP server works

Emberblocks is a visual app builder on a built-in database, your own Postgres or an Airtable base (see data sources). It runs a remote MCP server so Claude, ChatGPT or Claude Code can build and edit apps and read or write their rows. Below is what the server does, checked against its code and mapped to the checklist.

Connecting

The connector URL is https://www.emberblocks.com/api/mcp/mcp. Use the www host exactly: the bare domain answers with a 308 redirect, and that breaks MCP clients. In Claude, add the URL as a custom connector. In ChatGPT, create a connector in developer mode with OAuth authentication. In Claude Code:

claude mcp add --transport http emberblocks https://www.emberblocks.com/api/mcp/mcp
# then run /mcp and choose Authenticate

Workspace settings show the URL, these steps, and a Connected agents list with when each client was approved, when it was last used, and a Disconnect button.

Sign-in and identity

The endpoint speaks Streamable HTTP and keeps no session. A request without a valid token gets a 401 whose WWW-Authenticate header points to the protected resource metadata, so the client can find the authorization server and start OAuth. You sign in to Emberblocks and see a consent page that says the client will be able to read and edit apps, tables, rows, workflows and connections in every workspace you belong to, with exactly your permissions. After that, every tool runs with your own token, so the same database rules that protect the builder decide which workspaces and apps it can reach.

Permissions on rows

Every tool that opens an app, its rows or its draft checks that you are a workspace owner, admin or app builder; a member who is only an app user is refused. Row tools take a mode. Draft mode, the default, is for building and gives builder access. In published mode the call goes through your own role in the live app: per-table create, read, update and delete rights and row filters, as described in roles and permissions. Writes are validated like edits in the app (required fields, validation rules) and trigger the app's row workflows the same way.

Guard rails in the code

• list_rows returns at most 100 rows a call (50 by default), and select trims each row to the columns you name.
• create_rows inserts at most 50 rows a call and validates every row before writing any.
• delete_row needs confirm: true, and there is no bulk delete tool.
• Dropping a field or table needs confirmDataLoss: true. Without it the tool returns an impact report (row counts, apps affected) to show you first.
• publish_app needs confirm: true and zero blocking issues.
• Connection secrets are write-only: tools say which secret keys are set, never their values. Connecting a new Postgres database or Airtable base happens in the builder, not in chat, so database credentials never pass through the assistant.
• Rate limits default to 120 requests and 30 changes a minute for each person and client. If the limiter itself is down, the server refuses the call with a 503.
• Read tools are annotated read-only and delete tools destructive, so clients can ask before the risky ones.

There are 56 tools: reads (apps, tables, views, workflows, a publish check, a docs search), draft edits, schema changes, rows, templates, data sources and connections, publishing, plus the search and fetch pair ChatGPT's connectors expect. Draft edits never overwrite the whole app. Each tool applies one narrow change, validates the result, and reports how many blocking issues the app has afterwards.

With activity tracking on, a row changed through MCP is recorded with MCP as the source and the client's id. That covers built-in tables; Airtable mirrors and external Postgres tables are not tracked.

Where the Emberblocks MCP server is not the right fit

• No read-only or per-workspace tokens yet. A connection carries your full builder permissions in every workspace you belong to. An assistant limited to reading one table is not something you can set up today.
• It is a builder tool. App users cannot connect their own assistant through it. For them, Ask Ember for app users answers questions inside the published app through their own role: row filters apply, hidden fields never reach it, and changes are proposals the user has to apply.
• It is not a SQL console. The assistant gets the tools above, not arbitrary queries or joins across your database. If ad hoc SQL is the goal, a database server with a dedicated read-only role is the better tool, with the risks covered earlier.

Builders never pay in Emberblocks; paid plans are priced by the people who use your published apps, and the pricing page has the details.