Claude, Cursor or any MCP agent, on the SQL database you already run

How to Connect AI Agents to Your Databases and APIs

Magic Cloud wraps your SQLite, MySQL, PostgreSQL or SQL Server database in role-gated endpoints, publishes them as MCP tools, and lets you generate new tools by describing them in plain English. Your data stays where it is. No migration, no hand-written glue, no tool definitions to maintain.

terminal
# Run it next to your database. Log in at http://localhost:5555 with root/root.
$ curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up
SQLite built in — MySQL, PostgreSQL and SQL Server connected with a connection string
No migration — your schema wraps, your data stays where it is
Every generated endpoint gated by your own roles — RBAC, not a prayer
Step one, on video

From your database to 54 role-gated tools in under a minute

This is the whole first step, unedited: pick a database, tick the tables, choose which roles may read, create, update and delete, and click. Fifty-four endpoints and 2,472 lines of Hyperlambda come out, secured for root and admin, and the first one answers with real rows a moment later.

Every one of those endpoints is already in your agent's tool list, because a Magic cloudlet publishes each endpoint over MCP with no tool definition to write. The recording uses the chinook sample database; the same click works on your SQL Server, MySQL or PostgreSQL. Step two, the tool that did not exist yet, is the worked example below.

Worked example

One sentence in, one live agent tool out

This ran on the cloudlet serving this page. The generator reports its own execution time: 3.03 seconds from the sentence to a live, typed, documented tool over a SQLite table. Nothing below is mocked. The last panel is a public endpoint you can call right now, and the full measured ledger is in From Prompt to MCP Tool in 5 Seconds.

1. The sentence

Describe the tool the way you would document it

The prompt becomes the tool description your agent reads, so it is written like a docstring: what it returns, who wants it, and the argument with its type.

Returns the daily trend of anonymous carbon footprint submissions, one entry per day, so a caller can see how many people submitted and how heavy their average footprint was. Takes days, an integer, defaulting to 7.
2. What the generator saved

A readable file, verified against the runtime, live the moment it lands

Verbatim apart from the abbreviated comment. No build, no restart, no registration. The argument type became the tool's JSON Schema type; nobody wrote a schema.

footprint-trend.get.hl
// Returns the daily trend of anonymous carbon footprint submissions, one entry per day [...]
.arguments
   days:int
validators.default:x:@.arguments
   days:int:7
data.connect:billionair
   data.select:"select date(created) as day, count(*) as submissions, avg(total_kg) as average_total_kg from footprints where created >= date('now', '-' || @days || ' day') and total_kg > 0 group by day order by day desc"
      days:x:@.arguments/*/days
   return-nodes:x:@data.select/*
3. Call it yourself

The same endpoint an agent calls, over plain HTTP

This one is public and read-only. Inside Claude it appears as a tool named after the endpoint, described by the sentence above, with days as an integer parameter.

terminal
$ curl "https://hyperlambda.dev/magic/modules/mcp-demo/footprint-trend?days=365"
[{"day":"2026-09-02","submissions":2,"average_total_kg":8150.0},
 {"day":"2026-09-01","submissions":1,"average_total_kg":13400.0}, ...]
The problem

Most AI agents can talk about data. Fewer can safely work with it.

Many organisations already have the data they need sitting inside existing databases. CRM systems, ERP platforms, custom line-of-business applications, and legacy SQL servers already contain the records, relationships, and operational context an AI agent needs.

The hard part is not the data itself. The hard part is connecting an agent to that data in a way that is useful, fast to implement, and safe enough to trust. Most stacks still require a hand-built MCP server, a tool definition per operation, custom code, and too much glue between the model and the database.

Every table in the database rendered as a schema card with columns, types and foreign keys
How it works

Your database becomes tools. Your sentence becomes the next tool.

Hyperlambda is the language the tools are written in. Magic Cloud is the server that generates them, secures them, and serves them to your agent over MCP. Three doors lead into the same tool list: tick a table, describe a query, describe a tool. You describe, it generates, you review, the agent calls.

Tick a table

Point the CRUD generator at a database and every table you select becomes read, create, update, delete and count endpoints, role-gated per verb. Milliseconds, and no model involved.

Describe a query

Open the SQL endpoint generator, describe the query in English, and the machine writes the SQL against your schema. Read it, declare the arguments, pick a role, save. Your reporting joins and Monday aggregates become tools your DBA has reviewed.

Describe a tool

Anything the first two doors do not cover, the Hyperlambda Generator writes from a sentence, inside a whitelisted runtime where a hallucinated instruction fails before it executes. The sentence survives as the tool description your agent reads.

Not text-to-SQL

Tools the agent calls, not SQL the agent improvises

Text-to-SQL hands the model a database connection and asks it to write a fresh query for every question. It works in a demo and fails in production for the same reason: the query is different every time, so it cannot be reviewed, permissioned or trusted, and a prompt injection becomes a database injection. Magic Cloud takes the other road. The SQL is written once, when the tool is generated, and reviewed once, by you. From then on the agent calls a named, role-gated tool with typed arguments, and never sees a connection string. You still get natural language to database in seconds; you just get it as a tool the agent can be trusted with instead of a query it has to get right every time.

You do not even have to write that SQL. The SQL endpoint generator has a prompt bar under its editor: describe the query in English, and the machine writes the SQL against your actual schema. You read it, run it, declare the arguments it takes and their types, pick a role, and save. Text-to-SQL happened once, at design time, with your DBA reading the result in a language they already know. From then on it is a tool.

The SQL endpoint tab of the Endpoint Generator: a country argument declared, the sentence 'Top ten customers in @country by number of invoices, with name, city, invoice count and total spend' in the prompt bar, and the SQL the machine wrote from it in the editor above, ready to be generated as a role-gated endpoint
The sentence in the bar at the bottom produced the SQL above it, against the real schema, with the declared argument already in the WHERE clause. Read it, click Generate endpoint, and it is a tool.
Connecting an external MySQL, PostgreSQL or SQL Server database to a Magic cloudlet
Use what you already have

Add AI on top of legacy systems instead of replacing them

Magic Cloud wraps existing SQLite, MySQL, PostgreSQL, and Microsoft SQL Server databases with generated endpoints and database aware workflows. That means your agent can work with the systems your business already runs, whether they are modern or decades old.

Instead of migrating data first, rewriting everything, or introducing a parallel platform, you create a scoped database user, expose carefully chosen tables from your current schema, and let your agent use them immediately. Start read-only; add writes when you are ready.

Use cases

What database enabled agents can do

Query

Read operational data

Let agents retrieve customers, invoices, orders, leads, products, support cases, and other records from live systems.

Update

Write back to systems

Allow agents to update statuses, create records, enrich data, or trigger business actions through controlled endpoints.

Reporting

Generate SQL backed views

Describe the report in English, let the SQL endpoint generator write the query against your schema, review it, and ship it as a role-gated tool.

Workflows

Automate multi step tasks

Combine reads, updates, validation, and messaging into backend flows an AI agent can invoke when needed.

Legacy

Extend older systems

Expose useful database capabilities from older software without having to redesign the original application first.

Security

Keep control over access

Apply roles, endpoint boundaries, and generated backend constraints instead of giving agents direct unrestricted database access. Users sign in with Magic credentials or through OpenID Connect with Google, Microsoft Entra, GitHub, LinkedIn, Okta, Auth0, Keycloak or Slack, and the agent inherits exactly the roles of the person who authorised it.

Not just databases

Your APIs join the same tool list

Paste an OpenAPI specification and every operation you tick becomes an agent tool with the same role gating, its upstream credential held in your configuration and attached server-side at invocation. Your CRM, ERP and payment provider join the same MCP server as your database, so one agent can read an order from SQL Server and look up the customer in HubSpot in the same conversation. The walkthrough is Connect your CRM to Claude with 2 clicks; the security argument is Convert your OpenAPI specification to a secured MCP tool in seconds.

The difference

Most stacks generate code. Magic Cloud generates usable backend leverage.

Typical approach

  • Hand write integrations and SQL wrappers
  • Build a custom MCP server with one tool definition per operation
  • Rely on generated source code that still needs validation
  • Hand the agent a shared service token and hope
  • Spend time rebuilding what already exists

Magic Cloud

  • Use natural language to describe backend intent
  • Every endpoint is an MCP tool automatically, described from its own comments
  • Wrap existing databases instead of replacing them
  • Execute inside a whitelisted runtime, under the caller's own roles
  • Give agents practical database capabilities in minutes
From database to agent

From legacy database to usable agent in minutes

The workflow is simple. Connect the database, describe the capability in natural language, generate the backend tools, and let the agent start using live business data through clear boundaries.

1. Connect

Create a scoped database user and point Magic Cloud at your existing SQL database.

2. Describe

Pick the tables that matter, or explain in natural language what the agent should read, update, or automate.

3. Generate

Tick tables for CRUD, describe a query for the SQL endpoint generator, or describe a whole tool, each behind a role you choose.

4. Attach

Paste the cloudlet's MCP URL into Claude, Claude Code or Cursor and authorise. The tools are already there.

5. Operate

Let the agent work with real data through controlled backend access.

Frequently asked questions
Which databases can an AI agent connect to?

SQLite is built in. MySQL, PostgreSQL and Microsoft SQL Server connect with an ordinary connection string, through the standard .NET data providers your existing applications already use. The database itself is not modified: Magic is one more client of it.

Which AI agents can connect to the database?

Anything that speaks MCP over HTTP. Claude as a custom connector, Claude Code, Cursor, Codex, Qoder and your own agents. The cloudlet runs its own OAuth 2.1 flow, so connecting is paste a URL and authorise.

Can the agent write data, or only read it?

Both, and you decide per table and per verb. Every generated endpoint is gated by a role you assign, and the recommended starting point is a read-only database user plus read-only endpoints. Add update, create and delete tools when you are ready for writes.

Is it safe to give an AI agent access to a production database?

The agent never receives a connection string or a SQL surface. It receives named tools, each of which runs a role check at invocation time, inside a runtime where every instruction must bind to a whitelisted capability. Underneath sits the scoped database user you created, enforced by the database engine itself. The worst a confused agent produces is a failed call.

Can I self-host, and does my database need to be reachable from the internet?

Yes, and no. Magic Cloud is MIT-licensed and runs from one docker compose command, inside the same network as your database, so the database port is never exposed. Only the MCP surface needs to be reachable, and only if you connect a cloud-hosted agent such as Claude custom connectors. Claude Code and Cursor run on your machine and reach a cloudlet on localhost or inside your firewall directly. A managed cloudlet is available if you would rather not host.

Do I have to write Hyperlambda?

No. The CRUD generator emits it for every table you select, the SQL endpoint generator wraps SQL you already know how to write, and the Hyperlambda Generator writes new tools from a sentence. The generated code is readable and editable when you want to customise, but none of it has to be authored by hand.

How do you connect an AI agent to a database?

Create a scoped database user, connect the database to Magic with its connection string, tick the tables and choose which roles may read, create, update and delete, and the generated endpoints are published as MCP tools. The agent then connects with the cloudlet's URL and authorises over OAuth 2.1, and the tools appear in its tool list with the roles of the person who authorised it.

Ready to build

Give your AI agent access to the systems you already run

You do not need to replace your existing database to make it useful for AI. Wrap the tables that matter, generate the tools you are missing from a sentence, and connect Claude, Cursor or any MCP agent to live SQL data under your own roles.

terminal
# Or run it next to your database — log in at http://localhost:5555 with root/root.
$ curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up