Draxlr

Save SQL query

draxlr_save_query

Save a SQL query to a Draxlr database so it appears under the database's saved queries. Provide either sql (it is executed then saved) or a queryId returned by draxlr_run_query.

Input Schema

TableJSON Schema

Name	Required	Description
`sql`	No	The SQL to save. Provide either this or queryId. If you add variables, write them as {{variableName}} using letters only (e.g. {{startDate}}); numbers, underscores and other special characters are not allowed. Pass their values in `variables`, or wrap each condition that uses a variable in [[ ]] (e.g. WHERE 1=1 [[AND created_at >= {{startDate}}]]) so it is skipped when no value is given.
`name`	Yes	Name for the saved query
`queryId`	No	A queryId from draxlr_run_query. Provide either this or sql.
`variables`	No	Values for the {{variables}} used in the SQL, keyed by variable name, e.g. { "startDate": "2026-01-01" }. Use an array for IN lists.
`databaseId`	Yes	The database id the query belongs to
`description`	No	Optional description for the saved query

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 25, 2026

changedInput schema / properties / sql / description

Previous value: -"The SQL to save. Provide either this or queryId."New value: +"The SQL to save. Provide either this or queryId. If you add variables, write them as {{variableName}} using letters only (e.g. {{startDate}}); numbers, underscores and other special characters are not allowed. Pass their values in `variables`, or wrap each condition that uses a variable in [[ ]] (e.g. WHERE 1=1 [[AND created_at >= {{startDate}}]]) so it is skipped when no value is given."

addedInput schema / properties / variables

Added value: +{
+  "additionalProperties": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "number"
+      },
+      {
+        "type": "boolean"
+      },
+      {
+        "items": {
+          "type": [
+            "string",
+            "number"
+          ]
+        },
+        "type": "array"
+      }
+    ]
+  },
+  "description": "Values for the {{variables}} used in the SQL, keyed by variable name, e.g. { \"startDate\": \"2026-01-01\" }. Use an array for IN lists.",
+  "type": "object"
+}

First observedSep 11, 2026

TDQS

B3.4/5.0

Behavior1/5

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

The description states that the provided SQL 'is executed then saved', meaning the tool can run arbitrary SQL that may modify or destroy data. Annotations declare destructiveHint: false, which conflicts with this disclosure and would mislead an agent about the tool's safety profile. This is an annotation contradiction.

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 two sentences, front-loads the main action and scope, and contains no filler. Every sentence earns its place by stating what is saved and the two input modes.

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?

For a tool with full schema coverage and annotations, the description is nearly complete: it covers the save operation, destination, and input alternatives. It omits return behavior and permission expectations, but those gaps are minor for a save operation and no output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters, including variable syntax and allowed types. The description only restates the sql/queryId either-or choice already present in the schema and adds no meaning beyond it.

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 states a specific verb and resource: saving a SQL query to a Draxlr database so it appears under saved queries. It also distinguishes itself from draxlr_run_query by explaining that sql is executed then saved or that queryId comes from that sibling, allowing an agent to route correctly.

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

Usage Guidelines3/5

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

The description gives usage detail for the two input alternatives (sql or queryId from draxlr_run_query), but it does not explicitly state when to use this tool versus draxlr_update_saved_query, draxlr_run_saved_query, or draxlr_add_query_to_dashboard. Usage is implied by the purpose rather than fully guided.

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

All Draxlr tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?