Skip to main content
Glama

smart_query

Read-only

Analyzes natural-language questions to extract schema, match examples, assess complexity, and request clarification before SQL execution.

Instructions

BIRD SQL-based intelligent query tool. Analyzes natural-language questions to (1) extract relevant schema, (2) match similar few-shot examples, (3) assess complexity, (4) request clarification for ambiguous questions. Call this tool before run_query. For a new data source, first inspect the schema with list_tables, then register keyword-to-table mappings via manage_keyword_map to significantly improve accuracy. Note: when ANTHROPIC_API_KEY is set, table names, column names, and the question text (never query results or row data) may be sent to the Anthropic API as a fallback for table selection.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "data_source_id": "<data_source_id>",
      "question": "<question>"
    },
    "name": "smart_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoUser's answer to a previous clarification question (for multi-turn)
questionYesNatural-language question (e.g., 'How many payments were completed last month?')
data_source_idYesData source ID (from list_data_sources)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint, but the description discloses meaningful extra behavior: it may return a clarification request for ambiguous questions, and it explains the external API fallback and exactly what data crosses the boundary (names and question text, never results). It stops short of describing the shape of what is returned, which for a multi-output tool (schema context, examples, complexity, clarification) leaves a gap.

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-loads the identity and numbered analysis steps, then appends usage ordering and the privacy note. The middle clause is dense with nested parentheses, but every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description never states what a successful call returns (selected schema? generated SQL? a clarification question?). For a complex, multi-stage tool with no output schema, that omission is a real gap even though workflow and safety context are well covered.

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 coverage is 100%, so baseline is 3. The description adds value by framing 'context' as part of a multi-turn clarification loop and clarifying that 'question' is the natural-language input that triggers analysis, which is more than the schema's one-line descriptions convey.

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?

States a specific verb and resource ('SQL-based intelligent query tool') and enumerates the four analyses it performs on a natural-language question. It is clearly distinguishable from run_query, which it explicitly precedes.

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

Usage Guidelines5/5

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

Gives an explicit ordering rule ('Call this tool before run_query') and a prerequisite workflow for new data sources (list_tables, then manage_keyword_map), naming the sibling tools to use. Alternatives and conditions are spelled out, not implied.

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