list_schemas and list_tables let an agent map the database before it writes anything, which is the part that otherwise takes several failed queries. execute_sql then runs whatever statement you want — writes and DDL included — so the grants on the login in your connection string are the boundary, not the tool.
A .NET server that puts three tools over one SQL Server connection: the schemas the instance holds, the tables inside them, and a SQL statement of your own.
- Every schema or database the connection can see on the instance
- The tables, with schema, name, type and row count for each
- Any SQL you write, run as-is — SELECT, INSERT, UPDATE, DELETE and DDL all go through the same call
- Results laid out as tables rather than raw rows
- A connectivity check on startup, so a bad connection string fails before the first question
One environment variable, MSSQL_CONNECTION_STRING, holding a complete connection string — Windows authentication, SQL Server authentication and Azure SQL forms all work. Runs as a .NET application or from the Docker image the repository builds.
One command plus a key — docker run -i --rm -e MSSQL_CONNECTION_STRING mssql-mcp:latest, then supply credentials