Execute DDL statements like ALTER TABLE and CREATE INDEX to modify your Turso database schema directly from the MCP server. Use this tool to apply structural changes without leaving your workflow.
Executa comandos DDL (Data Definition Language) como ALTER TABLE, CREATE INDEX, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Comando DDL SQL a ser executado |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that DDL commands are executed and does not mention side effects like irreversibility, non-transactional behavior, privilege requirements, or error semantics. For a mutation-capable tool, this is a significant gap.
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 a single, front-loaded sentence with concrete examples and no filler. Every word contributes to identifying the tool's purpose. It is appropriately sized for a tool with one parameter.
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?
With no annotations and no output schema, this description is thin. It omits return behavior, error handling, and the relationship to overlapping siblings like create_index or add_column. An agent is left without enough context to confidently choose between this generic DDL executor and the more specific DDL tools.
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%: the sql parameter is documented as 'Comando DDL SQL a ser executado'. The tool description adds no additional meaning beyond what the schema already provides, such as syntax, formatting, or constraints. The baseline of 3 is appropriate when the schema carries the parameter documentation burden.
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 a specific action (execute) on a specific resource (DDL commands) with concrete examples like ALTER TABLE and CREATE INDEX. It is not a tautology and conveys the core purpose. However, it does not differentiate from sibling DDL-specific tools such as add_column or create_index, so it falls short of a 5.
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 provides no guidance on when to use execute_ddl versus the more specific DDL siblings like create_index, add_constraint, or add_column. There is no mention of preferred usage, exclusions, or alternatives. An agent must infer the appropriate use case purely from the name and the generic DDL description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.