Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@linkit-sql show me the first 10 rows from the users table in staging"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for read-only SQL Server queries across LinkIt environments:
internal / staging / uat / preprod / prod / au.
Same UX as teamwork-mcp: connections are stored in the OS keychain
(or an AES-256-GCM encrypted file), so MCP client config files never contain secrets.
The first tool call without a configured env opens a local setup page where you
enter host + database + user + password per env (each connection is tested before saving).
MCP server over stdio
Read-only by construction: only single SELECT / WITH...SELECT statements pass
validation — INSERT/UPDATE/DELETE/MERGE, DDL, and EXEC are blocked
(inspect procedures with explore/procedure_info instead of executing them).
Still, prefer a db_datareader login for defense in depth.
Multi-env: every tool takes an explicit env param — there is no default,
so prod is only touched when you say env="prod".
Smart result guard: maxRows (default 50, max 500), server-side SET ROWCOUNT
cap when your query has no TOP/OFFSET, long-text cell trimming, ~120 KB response
byte-cap, truncated flag + hints, opt-in countTotal.
Catalog discovery for huge DBs: all explore actions are paginated
(page/pageSize, max 100) with LIKE search — never dumps the whole catalog.
Setup page + CLI (auth / status / test / logout), CI overrides via env vars.
Related MCP server: MSSQL MCP Server
claude plugin marketplace add sondv5/linkit-dev-sql-mcp
claude plugin install linkit-sql@linkit-dev-sql-mcpThe first time anyone calls a SQL tool for an unconfigured env, the guided setup page opens automatically for them to enter their own per-env connections (stored locally in their OS keychain) — nothing to configure by hand.
npx -y linkit-dev-sql-mcp@latestThe first time you call any tool for an env with no connection, the server will:
Open your browser to a local setup page (http://127.0.0.1:<port>/setup/<nonce>)
You enter host + port + database + user + password for that env → the server tests the connection, then saves it
Retry the tool you just called — everything works, no restart needed
For local development:
npm install
npm run build
node dist/bin.jsA CLI is also available for terminal users:
npx -y linkit-dev-sql-mcp@latest auth # pick envs, enter connections, test and save
npx -y linkit-dev-sql-mcp@latest status # show configured envs
npx -y linkit-dev-sql-mcp@latest test # test connectivity (or: test prod)
npx -y linkit-dev-sql-mcp@latest logout # remove all stored connections{
"mcpServers": {
"linkit-sql": {
"command": "npx",
"args": ["-y", "linkit-dev-sql-mcp@latest"]
}
}
}Ready-made templates are included in this repository:
.cursor/mcp.json
.mcp.json
.codex/config.toml
opencode.json(See teamwork-mcp README for per-client instructions — same pattern, server name linkit-sql.)
Tool | Type | Actions (via |
| read |
|
| read |
|
| local |
|
Typical flow for a big unknown DB:
explore/list_databases (or system/status to see what's configured)
explore/search_objects with a keyword, or explore/list_tables with search
explore/table_info for the shortlist
query/select with a filtered SELECT ... WHERE ... and small maxRows
Per-env overrides (they win over stored connections):
LINKIT_SQL_<ENV>_HOST / _PORT / _DB / _USER / _PASSWORD / _ENCRYPT / _TRUST_CERTENV is one of INTERNAL, STAGING, UAT, PREPROD, PROD, AU.
Note: env vars are plaintext — prefer the keychain for interactive use.
The server is read-only at the SQL-text layer, but SQL Server cannot enforce
that by itself — always connect with a read-only login (db_datareader,
no db_owner/db_ddladmin), especially for prod.
EXEC/sp_executesql/SELECT...INTO are blocked, so stored procedures can be
inspected but not executed through this server.
env is required on every tool — there is no implicit default env, so an agent
cannot "accidentally" query prod while meaning staging.
Never pass credentials via args in mcp.json (visible in process lists).
The server only logs to stderr; stdout is reserved for JSON-RPC.
npm install
npm run build # tsc -> dist/
npm run dev # watch mode
node dist/bin.js --helpMIT
Discover database objects with paginated, capped results (safe for catalogs with thousands of tables/procs): list_databases, list_tables, table_info (columns/keys/FKs/rowcount), list_views, list_procedures, procedure_info (params + definition), list_functions, function_info, search_objects.
| Name | Required | Description | Default |
|---|---|---|---|
| env | Yes | Target env: internal | staging | uat | preprod | prod | au (always explicit, no default) | |
| page | No | Page number (default 1) | |
| table | No | Table/view name (table_info) | |
| types | No | Object types to include (search_objects, default all) | |
| action | Yes | Discovery action | |
| schema | No | Schema filter, e.g. dbo (default: all schemas) | |
| search | No | Case-insensitive name filter (LIKE %...%) | |
| routine | No | Procedure/function name (procedure_info/function_info) | |
| database | No | Override the env default database | |
| pageSize | No | Rows per page (default 20, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate it. The description adds valuable context: paginated, capped results safe for large catalogs, and details per action (e.g., table_info returns columns/keys/FKs/rowcount). This goes beyond the annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the main purpose front-loaded, followed by a compact list of all actions. No redundant words; the structure efficiently communicates scope and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all actions and key behavioral traits (pagination, capping), but it does not explicitly address usage guidelines or explain pagination parameters (page, pageSize), though those are in the schema. For a discovery tool with this complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description does not add parameter-specific semantics beyond the schema; it only provides high-level action context. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers database objects and enumerates all nine actions (list_databases, list_tables, etc.). It is specific and easily distinguishes itself from query and system, which are for executing queries and system info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for discovery but does not explicitly state when to use it over siblings (query, system) or when not to use it. No alternatives or exclusions are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a READ-ONLY SELECT/WITH query against a LinkIt SQL Server env. INSERT/UPDATE/DELETE/DDL/EXEC are blocked. Results are auto-capped (maxRows default 50, max 500) with truncation hints; set countTotal for COUNT(*).
| Name | Required | Description | Default |
|---|---|---|---|
| env | Yes | Target env: internal | staging | uat | preprod | prod | au (always explicit, no default) | |
| sql | Yes | Single SELECT or WITH...SELECT statement | |
| action | No | select | select |
| maxRows | No | Max rows returned (default 50, max 500) | |
| database | No | Override the env default database | |
| trimChars | No | Trim long text cells at N chars (default 500) | |
| countTotal | No | Also run COUNT(*) over the query (default false; can be slow on huge scans) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, and the description reinforces this. It adds meaningful behavioral details beyond annotations: results are auto-capped with maxRows default 50 and max 500, truncation hints are provided, and countTotal triggers an additional COUNT(*) that may be slow. This gives the agent practical expectations for execution without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: two sentences. The first sentence states purpose and restrictions, the second covers row caps and countTotal. Every clause earns its place, and the most critical information (read-only, query type) is front-loaded. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description provides sufficient execution context: allowed query forms, blocked operations, row limits, truncation hints, and an optional slow-mode flag. It does not describe error behavior or the exact output format, but the readOnlyHint and implicit SELECT semantics cover the main risks. Answers what an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all 7 parameters, including defaults and bounds for maxRows and countTotal. The description adds marginal value by mentioning 'truncation hints' and the behavior of countTotal on huge scans, but this does not substantially exceed what the schema already states. Baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a READ-ONLY SELECT/WITH query against a LinkIt SQL Server env' – a specific verb, resource, and query type. It names the blocked statement types, which further clarifies the tool's exact scope. This clearly distinguishes it from the sibling tools 'system' and 'explore' without needing to reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the read-only intent explicit and states that INSERT/UPDATE/DELETE/DDL/EXEC are blocked, which tells the agent when not to use the tool. However, it does not name sibling alternatives or state explicit conditions for choosing this tool over 'explore' or 'system'. The usage context is implied rather than directly contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local connections: which envs are configured (status), test connectivity per env (test), remove all stored connections (logout).
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Limit test to one env (test) | |
| action | Yes | status | test | logout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says logout will 'remove all stored connections', which is a destructive mutation of stored state. The annotations mark the tool with readOnlyHint: true, implying no state changes. This is a direct contradiction, so behavioral transparency must be 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence packs the domain ('Local connections'), all three actions, and their effects without wasted words. The core resource is front-loaded, making the tool's scope immediately obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all actions and parameters adequately, but there is no output schema, and the description does not explain what status or test return. More importantly, it leaves the destructive logout contradicting the readOnlyHint annotation, which is a significant completeness gap for an agent relying on the definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions, but the tool description adds functional meaning beyond the bare enum values, mapping each action to its real-world effect (status → configured envs, test → connectivity, logout → removal). This enriches the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies distinct actions (status, test, logout) on the resource 'local connections', giving each a clear purpose. This clearly distinguishes the tool from siblings query and explore, which are about data access rather than connection management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what each action does, implying when the tool would be used (e.g., check configured envs, test connectivity, clear stored connections). However, it does not explicitly mention alternatives or state when not to use this tool, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0explorequerysystemScored across 3 tools
The three tools have clearly distinct purposes: query executes SQL, explore discovers schema/metadata, and system manages connections. There is no overlap in their core functions, so an agent can easily select the right tool.
Tool names are all single-word, lowercase, which is consistent in style. However, 'query' and 'explore' are verbs while 'system' is a noun, creating a minor deviation from a uniform verb-based pattern.
With only three tools, the server is well-scoped for its purpose. Each tool covers a broad but necessary area—querying, exploration, and system management—without unnecessary bloat or missing essentials.
For a read-only SQL server, the tool surface is complete: query handles data retrieval, explore provides full schema discovery (databases, tables, views, procedures, functions), and system manages connectivity. No obvious gaps exist within the stated domain.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
