MySQL

Connect AI agents to MySQL and MySQL-compatible servers such as MariaDB, PlanetScale, and Aurora. Agents run parameterized SQL, do CRUD without SQL, inspect schemas, and bulk-load rows.

9 actions available

A flow step needs to update application records after an external event

Agent runs Select Rows to load the current state of the affected records

Agent confirms the incoming change is consistent with what the table holds

Agent identifies which rows are safe to write and which are ambiguous

Agent runs Update Rows with an explicit Where object for the safe matches

The owning team gets a summary of what changed via Slack

Any write to a production table above a row threshold pauses for approval

What This Integration Enables

Agents read and write MySQL data as steps in a flow, run arbitrary SQL for the cases the row helpers do not cover, and inspect structure with Get Table Schema and List Tables so they adapt to your schema. MySQL has no `RETURNING` clause, so writes return `insertId`, `affectedRows`, and `changedRows` rather than the full row; when an agent needs the database-generated values, it follows the write with Select Rows. The connect-per-call model keeps every step isolated, with no cached connections between runs.

Without FlowRunner

App-only access The only way to change a record is through the application UI, one at a time

Unbounded writes An UPDATE with a forgotten WHERE rewrites every row in the table

No write status After a batch write there is no clean record of what changed

With FlowRunner

Governed batch writes Rows are read and written as named flow steps with a full run log

Writes require a Where Update Rows and Delete Rows refuse to run without an explicit filter

Change is visible Every write returns matched and changed counts the agent can act on

Use Case Scenarios

Event-driven record updates

An external event fires an upstream flow. The agent calls Select Rows to load the affected records, decides which are safe to change, and calls Update Rows with an explicit Where object, reading back `affectedRows` and `changedRows` to confirm exactly how many rows moved. The team stops making one-off edits through the app UI and lets the flow apply consistent changes.

Idempotent import from an API

Records arrive from another connector as an array. The agent calls Insert Rows to bulk-load them, or Upsert Row keyed on the table's primary or unique key when the run needs to be safe to repeat. Re-running the flow updates existing rows rather than creating duplicates.

Status sync with a human gate

The agent processes records in batches, marking each with a status after it writes. When a write would touch a production table above the configured threshold, the agent does not proceed on its own. It routes the write for approval and resumes only after a person confirms.

Human-in-Loop Highlight

A bulk UPDATE or DELETE against a production MySQL table is the kind of action that is trivial to run and painful to reverse. FlowRunner's answer is human-in-the-loop, an execution pattern where the agent pauses on its own, assembles the context and the choices, routes to a human on their preferred channel, and resumes the moment they respond. When an Update Rows or Delete Rows would affect more rows than the configured threshold, or would write to a table flagged as production, the agent pauses before executing and asks through Slack: "This Delete Rows on `orders` matches 2,140 rows. Here is the Where object and a sample. Approve, edit the filter, or cancel?" The write runs only after a person confirms, with the approver and timestamp captured in the run log. A connector can run any SQL; an orchestration layer knows which SQL should stop and ask.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

9 actions

SQL

Execute Query Runs any single SQL statement (SELECT, INSERT, UPDATE, DELETE, DDL, CTEs) with `?` placeholders bound via the Parameters array, and returns rows and field metadata for reads or `affectedRows`, `insertId`, and `changedRows` for writes. Use it for the intentional cases the row helpers do not cover.

Rows

Select Rows Reads rows without writing SQL, with column selection, equality filters, ordering, and limit and offset pagination.
Insert Row Inserts one row from a JSON object and returns `insertId`, `affectedRows`, and an echo of the data.
Insert Rows Bulk-inserts an array of row objects in a single statement and returns the inserted count and the first auto-increment id.
Update Rows Updates rows matching a non-empty Where object and returns `affectedRows` (matched) and `changedRows` (actually modified). A Where object is required to prevent a full-table write.
Delete Rows Deletes rows matching a non-empty Where object and returns `affectedRows`. A Where object is required to prevent a full-table delete.
Upsert Row Runs `INSERT ... ON DUPLICATE KEY UPDATE` keyed by the table's primary or unique indexes. Use it to keep a table in sync with an external source across repeated runs.

Schema

Get Table Schema Returns column names, full types, nullability, defaults, key membership, and extra attributes from `information_schema.columns`.
List Tables Lists all tables and views in the current database, for schema discovery without hardcoded configuration.

Start building with MySQL

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us