Skip to main content
Glama
jansc4
by jansc4

Execute database statement

db_execute
Destructive

Execute non-SELECT SQL statements (CREATE, INSERT, UPDATE, DELETE, ALTER, DROP) on a SQLite database, creating the database file if missing. Requires confirm='EXECUTE' and logs each statement to log_path.

Instructions

Runs a single SQL statement that isn't SELECT — CREATE TABLE, INSERT, UPDATE, DELETE, ALTER, DROP. Requires confirm='EXECUTE'. Creates the database file (and its parent folder) if it doesn't exist yet — this is how you create a new database: CREATE TABLE against a path that doesn't exist yet. One statement per call. params: a list for '?' positional placeholders, or a dict for ':name' named placeholders — write a whole row with one call by pairing a for_each step (item_arg='params') over a list of row-dicts with an INSERT using ':name' placeholders matching the dict's keys. confirm/log_path go in args, shared across every item in for_each — one 'EXECUTE' in the step still gates the whole series. Logs every statement to log_path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
paramsNo
confirmYes
db_pathYes
log_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Even though annotations already mark destructiveHint=true, the description adds substantial behavioral detail: the confirm='EXECUTE' gate, creation of the database file and parent folder, one-statement-per-call limit, for_each interaction, and logging behavior. This goes well beyond the structured annotations and gives the agent a clear model of side effects.

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 long but each sentence earns its place. It front-loads the core purpose and confirm requirement, then covers creation semantics, parameter formats, and advanced for_each behavior without repetition or filler.

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?

Given five parameters, zero schema descriptions, and destructive behavior, this description is remarkably complete. It covers preconditions, side effects, placeholder syntax, workflow integration, and logging, leaving no critical gap for an agent attempting correct invocation.

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 carries full responsibility for parameters. It explains sql, confirm, db_path, log_path, and params in meaningful terms, including positional vs named placeholders and the exact confirm value. The for_each usage example further clarifies how params and confirm/log_path behave in a workflow.

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 opens with a specific verb and resource: 'Runs a single SQL statement that isn't SELECT' and explicitly enumerates the supported statement types. This clearly distinguishes it from the sibling db_query tool, which handles reads, without needing to inspect schemas.

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?

The description gives clear usage context: use this for non-SELECT SQL statements, and explains how to create a new database by running CREATE TABLE against a non-existent path. It excludes SELECT but does not explicitly name db_query as the alternative, so it stops short of the strongest possible guidance.

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