QGIS MCP

Overview Schema Source Related Servers Discussions Admin

Create PostgreSQL Connection

create_postgresql_connection

Validate and save a PostgreSQL Browser-panel connection using QGIS Authentication Manager credentials or pg_service.conf, selecting a connection mode for endpoint or service access.

Instructions

Validate and save a new PostgreSQL Browser-panel connection. Passwords are never accepted: credentials come from a QGIS Authentication Manager configuration, from the libpq service file (pg_service.conf), or both. connection_mode selects which parameters are required; when the user's intent is unclear, ask which mode applies before calling. endpoint_using_auth_manager: host, port, database, auth_config_id (port must be the actual database port supplied by the caller or user, this tool never assumes 5432). service_using_auth_manager: service (the name defined in pg_service.conf) and auth_config_id; database optionally overrides the service file's dbname. service_only: service; database optionally overrides dbname; do not pass auth_config_id. Parameters a mode does not use are rejected. Fails if name already exists or the database cannot be reached. ssl_mode is one of prefer (default), disable, allow, require, verify-ca, or verify-full.

Input Schema

TableJSON Schema

Name	Required	Default
`host`	No
`name`	Yes
`port`	No
`service`	No
`database`	No
`ssl_mode`	No	prefer
`auth_config_id`	No
`connection_mode`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.14.0Sep 13, 2026

addedInput schema / properties / auth_config_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / auth_config_id / default
```
Added value: +null
```
removedInput schema / properties / auth_config_id / type
```
Removed value: -"string"
```

addedInput schema / properties / connection_mode

Added value: +{
+  "enum": [
+    "endpoint_using_auth_manager",
+    "service_using_auth_manager",
+    "service_only"
+  ],
+  "type": "string"
+}

addedInput schema / properties / database / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / database / default
```
Added value: +null
```
removedInput schema / properties / database / type
```
Removed value: -"string"
```

addedInput schema / properties / host / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / host / default
```
Added value: +null
```
removedInput schema / properties / host / type
```
Removed value: -"string"
```

addedInput schema / properties / port / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / port / default
```
Added value: +null
```
removedInput schema / properties / port / type
```
Removed value: -"integer"
```

addedInput schema / properties / service

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "host",
-  "port",
-  "database",
-  "auth_config_id"
-]New value: +[
+  "name",
+  "connection_mode"
+]

Addedv0.11.0Aug 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so: passwords are never accepted, credentials originate from QGIS Auth Manager or pg_service.conf, unused parameters are rejected, and it fails when the name exists or the database is unreachable. The port note (never assumes 5432) and ssl_mode default are additional non-obvious behaviors.

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

Conciseness4/5

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

Purpose and the password/credential rule are front-loaded, then the mode-specific parameter rules follow in a predictable order. It is dense with per-mode detail but each sentence carries required information; a bulleted mode breakdown would read more cleanly than the semicolon-heavy prose.

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

Completeness5/5

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

For a complex three-mode tool with 8 parameters, zero schema annotations, and no schema descriptions, the definition covers mode selection, credential sourcing, parameter exclusivity, failure conditions, and ssl behavior. Return shape is handled by the output schema, so nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it does: host/port/database/auth_config_id for endpoint mode, service plus optional database override for service modes, the three connection_mode enum values, and ssl_mode's full value set with its default. Only 'name' is left implicit (as a unique identifier, clarified by the duplicate-name failure).

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?

States a specific verb ('Validate and save') and resource ('a new PostgreSQL Browser-panel connection'), and the QGIS-panel framing distinguishes it from siblings such as add_layer_from_connection or import_layer_to_connection. An agent knows exactly what the tool produces without opening the schema.

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

Usage Guidelines4/5

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

Gives strong when-to-use conditions: it enumerates the three connection_mode branches, states which parameters each requires, and instructs the agent to ask the user which mode applies when intent is unclear. It does not name sibling tools (e.g., list_connections) as alternatives, so it falls just short of a 5.

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

Deploy Server