QGIS MCP Server

Execute Connection SQL

execute_connection_sql

Destructive

Run SQL directly against the database behind a saved QGIS connection, including DDL/DML changes, with an optional row limit to control returned results.

Instructions

Run SQL directly on the database behind a saved connection (server-side, not a virtual layer - use execute_sql for that). Can modify the database: DDL/DML run as issued. limit caps returned rows (-1 for all).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>",
      "connection": "<connection>",
      "sql": "<sql>"
    },
    "name": "execute_connection_sql"
  }
}

Input Schema

Name	Required	Description	Default
`sql`	Yes
`limit`	No
`provider`	Yes
`connection`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide destructiveHint=true, and the description reinforces this by stating 'Can modify the database: DDL/DML run as issued.' It adds useful behavioral context beyond the annotation: server-side execution, distinction from virtual layers, and the limit parameter capping returned rows (-1 for all). It does not contradict the destructive hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences that front-load the primary purpose and immediately differentiate from a sibling tool. Every clause carries important information: server-side execution, virtual layer exclusion, mutability, and limit behavior. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has an output schema and a destructive annotation, the description covers the key operational concerns: what it runs, where it runs, the mutability risk, and row limit control. It could be more complete by explaining provider and transaction semantics, but the existing information is sufficient for effective tool selection and basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It meaningfully explains sql (SQL executed directly), connection (a saved connection), and limit (caps returned rows, -1 for all). However, the provider parameter is left unexplained, which is a notable gap since it is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific function: 'Run SQL directly on the database behind a saved connection'. It also distinguishes itself from the sibling tool execute_sql by explicitly noting 'not a virtual layer - use execute_sql for that', which resolves potential ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance by naming the alternative tool for virtual layers ('use execute_sql for that'). It also warns that the tool can modify the database with DDL/DML, which helps agents decide whether to use this tool based on whether data mutation is intended or acceptable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server