Skip to main content
Glama

sql_run

Executes one read-only SELECT or WITH query against PII-free views, with row limits and cell suppression, so aggregate results can be inspected without exposing raw records.

Instructions

claude スキーマの PII 無しビューに対して SELECT を1本実行する(読み取り専用・行数上限・少数セル抑止)。

Args:
    sql: SELECT または WITH で始まる1文。SELECT * は不可。
    max_rows: 返す最大行数(上限は設定値)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
max_rowsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/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 key behaviors: read-only, a row-count cap, and small-cell suppression (a privacy safeguard an agent should know about). It omits error/timeout behavior and the exact meaning of the max_rows ceiling, so it is not fully transparent.

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?

Front-loaded one-line summary followed by structured Args entries; every sentence carries constraint information with no filler. The mixed-language summary slightly hurts scannability for a non-Japanese reader but does not waste space.

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?

An output schema exists, so return values need not be described. The description covers what is executed, the safety profile, and both parameters' constraints; only error handling and the concrete row ceiling are absent.

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

Parameters4/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 compensate, and it does: it constrains sql (SELECT/WITH prefix, no SELECT *) and explains max_rows as a maximum with a configured upper bound. It still doesn't state the default value or the actual ceiling, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (execute one SELECT) and a specific resource (the PII-free view of the claude schema), with scope qualifiers (single statement). It does not explicitly distinguish itself from py_run, the other execution sibling, 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.

Usage Guidelines3/5

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

The description gives constraints (must start with SELECT or WITH, SELECT * disallowed, read-only) but never says when to choose this over py_run or schema_describe, nor what to do if the query is rejected. Usage is implied by the constraints rather than stated.

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