Microsoft SQL Server

Connect your SQL Server or Azure SQL database to let Tony (Database Engineer) discover your schema, read and aggregate records, and make single-row changes you approve one at a time. The connection reaches your tables directly. It cannot run arbitrary SQL, call stored procedures, or change your schema. Reads happen without a prompt. Every create, update, and delete asks you first, one call at a time.

Supported platforms

Platform	Supported	Notes
SQL Server	Yes	2016 or later, on-premises or self-managed
Azure SQL Database	Yes	Managed, no version to choose
Azure SQL Managed Instance	Yes	Managed, no version to choose
SQL Server on Azure Virtual Machines	Yes	2016 or later
Azure Arc-enabled SQL Server	Yes	2016 or later
SQL Server 2014 and earlier	No	Below the minimum version

SQL database in Microsoft Fabric is not covered here. It does not accept SQL Server logins, so the username-and-password credential this connection uses cannot reach it.

Prerequisites

A SQL Server or Azure SQL database reachable from CloudThinker on its SQL port, 1433 by default.
Permission to create a login or a database user and grant it read access.
The tables you want the agent to reach in a normal user schema. Objects in sys and INFORMATION_SCHEMA are never exposed, whatever the user is granted.

Setup

Create a dedicated user

Give CloudThinker its own least-privilege account. Which statement you use depends on the platform.SQL Server and Azure SQL Managed Instance — create a login in master, then a user for it in your database:

-- In master
CREATE LOGIN cloudthinker WITH PASSWORD = '<strong-password>';

-- In your database
CREATE USER cloudthinker FOR LOGIN cloudthinker;

Azure SQL Database — create the user directly in your database, with no login in master. Microsoft recommends this form because it keeps the database portable:

CREATE USER cloudthinker WITH PASSWORD = '<strong-password>';

Grant read access to only what the agent should see

Grant on the specific schema that holds the tables you want reachable:

GRANT SELECT ON SCHEMA :: dbo TO cloudthinker;

Or, tighter, one table at a time:

GRANT SELECT ON OBJECT::dbo.orders TO cloudthinker;

Adding the user to the db_datareader role also works, but Microsoft notes it “grants read access to every table in the database, which is more than is strictly necessary”. A schema or object grant is the better boundary.

Allow network access

Azure SQL Database and Managed Instance: add CloudThinker to the server firewall rules.
SQL Server: allow inbound 1433 from CloudThinker, and confirm the server accepts SQL Server authentication rather than Windows authentication only.

Add the connection in CloudThinker

Go to Connections → Microsoft SQL Server and fill in the single Connection string field:

Server=<host>,1433;Initial Catalog=<database>;User ID=cloudthinker;Password=<password>;Encrypt=True;

Click Connect. CloudThinker opens the connection, reads the tables the user can see, and the Connected message reports what it loaded. A failure comes back with the reason SQL Server gave — see Troubleshooting.

Connection details

One field carries everything: an ADO.NET connection string for the user you created above.

Field	Description	Default
Connection string	ADO.NET connection string for the dedicated least-privilege user	—

The keywords that matter:

Keyword	What to put
`Server`	Host and port, for example `sql.example.com,1433`.
`Initial Catalog`	The database name. Required when you created the user directly in the database rather than from a login in `master`.
`User ID` and `Password`	The user created in step 1.
`Encrypt`	`True`. It is the default in current SQL client versions, and worth stating anyway.
`TrustServerCertificate`	Leave it out, or `False`. Set it to `True` only for a self-signed or internal-CA certificate.

With Encrypt=True and TrustServerCertificate=False, Microsoft’s client encrypts traffic only if the server presents a verifiable certificate. If it does not, the connection attempt fails rather than falling back to plaintext. That failure is the single most common one on a first connect against a self-hosted server.

Required permissions

Minimum (read only)

GRANT SELECT ON SCHEMA :: dbo TO cloudthinker;

This is enough for schema discovery, reading records, and aggregation. Leave it here unless you want the agent to change data.

Write access (only if you want it)

GRANT INSERT, UPDATE, DELETE ON SCHEMA :: dbo TO cloudthinker;

Grant these on the specific schema you want changeable, never database-wide. The grant is the durable boundary. The per-call approval prompt decides whether CloudThinker asks; the grant decides whether SQL Server allows it. A user holding only SELECT cannot write, no matter what anyone approves.

Agent capabilities

Once connected, Tony can:

Capability	Description
Schema discovery	List the reachable tables with their columns
Record inspection	Read rows with column selection, filtering, sorting, and paging
Aggregation	Count, sum, average, minimum, and maximum, with grouping and having
Row changes	Insert a row, or update and delete a row by its primary key — each one after you approve it

What the connection cannot do, by design:

No arbitrary SQL. The agent works through the table operations above, not a query console.
No stored procedures.
No schema changes. It cannot create, alter, or drop a table, an index, or a column.
No joins across tables in a single read. Each read covers one table.

Verify the connection

@tony #report list the SQL Server tables you can reach and their columns

Example prompts

@tony #report how many orders were placed per status in the last 30 days
@tony #report show the ten most recent rows in dbo.orders
@tony #recommend which columns in dbo.orders look like they need an index

Write access

There is no connection-wide write switch. Every insert, update, and delete is approved individually, in the conversation, before it runs.

Operation	What it needs
Insert a row	Your approval, plus `INSERT` on the table
Update a row	Your approval, the row’s primary key, and `UPDATE` on the table
Delete a row	Your approval, the row’s primary key, and `DELETE` on the table

Two things to weigh:

Updates and deletes are keyed, not filtered. The agent addresses one row by its primary key, so a mistyped filter cannot sweep a table. A table without a primary key cannot be updated or deleted through this connection at all.
Approval is per call, not per session. Approving one delete does not approve the next.

If you never want the agent to change data, do not grant INSERT, UPDATE, or DELETE. That is stronger than declining each prompt.

Troubleshooting

SQL Server answered and rejected the credentials.

Confirm the user exists in the right place: a login lives in master, a user created with WITH PASSWORD lives in your database.
Confirm the server accepts SQL Server authentication. A server set to Windows authentication only refuses every username-and-password login.
Retype the password rather than pasting it. A pasted value carrying a stray space or line break fails here.

The connection fails on a certificate error

The server did not present a certificate the client could verify, and the client refused to continue unencrypted.

Install a certificate the client trusts. This is the right fix.
For a self-signed or internal-CA certificate on a private network, add TrustServerCertificate=True to the connection string. Traffic is still encrypted, but the server’s identity is no longer checked.

The server is unreachable, or the connection times out

Nothing answered at that host and port.

Check that Server carries the host and port in SQL Server’s own form, host,1433, with a comma rather than a colon.
Azure SQL: add CloudThinker to the server firewall rules.
SQL Server: confirm the firewall allows inbound 1433 and that the server is listening on TCP/IP, which is off by default on some installations.

The agent cannot find a table it should see

The user needs SELECT on that table or its schema. A table the user cannot read does not appear at all.
Tables in sys and INFORMATION_SCHEMA are excluded and cannot be exposed.
Name the table with its schema, for example dbo.orders. The agent sees the schema and the table name together, so an unqualified name can be ambiguous when two schemas hold the same table name.

An update or delete is refused, and the table has no primary key

Updates and deletes address exactly one row by its primary key. Without one, the operation has no way to identify a row and is refused. Reading and aggregating the table still work. Add a primary key if you want the agent to change it.

A column never appears in results

Some SQL Server data types are not carried over this connection: geography, geometry, hierarchyid, json, rowversion, sql_variant, vector, and xml. Tables holding them still work; those particular columns are not returned. Add a plain-text column holding the value you want visible if the agent needs to read it.

The agent will not run the SQL I gave it

Expected. This connection has no SQL console and no stored-procedure access. Ask for the result you want — a filtered read, a grouped count — rather than for a statement to execute.

Security

Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

Dedicated user — never reuse an application or admin account. A separate user keeps the audit trail readable and the blast radius small.
Grant the schema, not the database — scope SELECT to the schema holding the tables the agent should reach. Everything else stays invisible.
Read-only by omission — withhold INSERT, UPDATE, and DELETE and the connection is permanently read-only, regardless of what is approved in a conversation.
Keep encryption on — leave Encrypt=True and reach for TrustServerCertificate=True only when you own the certificate and the network.

Tony Agent

Database-focused optimization agent

Organization

Agents

Automation & Autonomy

Connections

Platform Settings

Security

Billing

Supported platforms

Prerequisites

Setup

Connection details

Required permissions

Minimum (read only)

Write access (only if you want it)

Agent capabilities

Verify the connection

Example prompts

Write access

Troubleshooting

Security

Tony Agent

PostgreSQL Connection

​Supported platforms

​Prerequisites

​Setup

​Connection details

​Required permissions

​Minimum (read only)

​Write access (only if you want it)

​Agent capabilities

​Verify the connection

​Example prompts

​Write access

​Troubleshooting

​Security

​Related

Tony Agent

PostgreSQL Connection

Supported platforms

Prerequisites

Setup

Connection details

Required permissions

Minimum (read only)

Write access (only if you want it)

Agent capabilities

Verify the connection

Example prompts

Write access

Troubleshooting

Security

Related