Skip to main content
Glama
yimindev

DatI

by yimindev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

execute_parameterized_sql

Run preconfigured parameterized SQL operations on DatI services to perform business database tasks safely, including data changes, with parameter binding and row-level permission guards.

Instructions

Execute a pre-configured parameterized SQL tool published on the DatI MCP gateway.

Behavior: - May mutate data depending on the configured SQL template (INSERT/UPDATE/DELETE). - Safe execution: Protected by DatI row-level permission guards and SQL parameter binding. Usage Guidelines: - Use this tool when you need to run specific business database operations. - Prerequisite: Use search_metadata first if you are unsure of the service or parameters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNoJSON-encoded string containing parameter key-value pairs matching the tool template variables.{}
tool_nameYesThe specific pre-configured parameterized SQL tool name to run (e.g. 'add_transaction').
service_codeYesThe unique code of the published MCP service in DatI (e.g. 'family-finance').

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / params / description
      Added value: +"JSON-encoded string containing parameter key-value pairs matching the tool template variables."
    • addedInput schema / properties / service_code / description
      Added value: +"The unique code of the published MCP service in DatI (e.g. 'family-finance')."
    • addedInput schema / properties / tool_name / description
      Added value: +"The specific pre-configured parameterized SQL tool name to run (e.g. 'add_transaction')."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the critical trait that the operation may mutate data (INSERT/UPDATE/DELETE depending on the template). It also names the safety controls (row-level permission guards, SQL parameter binding), which is useful context an agent cannot get from the schema. It stops short of describing failure behavior or result shape, but the output schema covers returns.

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 purpose sentence is front-loaded, followed by tight Behavior and Usage Guidelines sections with no filler. Every bullet carries information (mutation risk, safety guards, prerequisite) rather than restating the name or schema.

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 an output schema, the description supplies the missing pieces an agent needs: mutation risk, safety guarantees, and the discovery prerequisite. Only minor gaps remain (e.g., error/partial-failure semantics), which are not essential for correct invocation.

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 all three parameters already have documented semantics in the schema. The description only adds the notion that params must match the template variables, which is marginal beyond what the schema already states — the baseline of 3 applies.

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 (Execute) and resource (a pre-configured parameterized SQL tool published on the DatI MCP gateway), and clarifies that the tool is a dispatcher for published SQL templates rather than a generic query runner. That framing lets an agent distinguish it from the discovery-oriented sibling search_metadata.

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?

It gives a clear context for use (running specific business database operations) and an explicit prerequisite: call search_metadata first when the service or parameters are unknown. There is no explicit when-not guidance, but the routing to search_metadata covers the main alternative for a two-tool set.

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

Deploy Server

Other Tools