Skip to main content
Glama

sql_query

Run SQL SELECT queries on document metadata, text chunks, and tags to filter, join, and aggregate data for analysis and retrieval.

Instructions

Run a SQL SELECT query over relational tables.

Full SQL supported: SELECT, JOIN, CTE, GROUP BY, window functions, subqueries, UNION, etc.

Available tables:

  • documents: Document-level metadata (doc_id, source, source_type, chunk_count, file_size, file_hash, language, created_at)

  • chunks: Individual text chunks (chunk_id, doc_id, chunk_index, source_type, chunk_type, entity_name, file_path, start_line, end_line, char_count)

  • tags: Defined tags (tag_id, name, color, description)

  • document_tags: Many-to-many mapping (doc_id, tag_id)

  • metadata: Flexible key-value store (key, value, doc_id)

Examples: SELECT source_type, COUNT(*) as cnt FROM documents GROUP BY source_type SELECT * FROM chunks WHERE source_type = 'code' LIMIT 10 SELECT d.source, COUNT(c.chunk_id) as chunks FROM documents d JOIN chunks c ON d.doc_id = c.doc_id GROUP BY d.source ORDER BY chunks DESC SELECT d.source FROM documents d JOIN document_tags dt ON d.doc_id = dt.doc_id JOIN tags t ON dt.tag_id = t.tag_id WHERE t.name = 'important'

Args: query: SQL SELECT query string. limit: Max rows to return (default 100, max 5000).

Returns: Dict with "columns", "rows", and "row_count".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses that only SELECT queries are supported, specifies return format (columns, rows, row_count), and documents default and maximum limit. This provides adequate behavioral context for safe usage.

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?

The description is relatively long but well-organized: summary, SQL support, table list, examples, arguments, returns. Every section adds value. Could be slightly tighter, but the structure aids readability.

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 the complexity and lack of output schema, the description fully covers purpose, allowed SQL, schema details, examples, default behavior, and return structure. An agent can confidently understand and invoke the tool without ambiguity.

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?

Input schema has 0% parameter descriptions, so the description must compensate. It details both parameters: query is an SQL SELECT string, limit has a default and max. Examples illustrate valid query syntax. This fully compensates for the schema gap.

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 clearly states the tool runs SQL SELECT queries, lists supported SQL features, and enumerates available tables with columns. Examples further clarify usage. This distinguishes it from siblings like sql_execute.

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 explicitly limits queries to SELECT and provides examples, implicitly indicating read-only use. It does not explicitly state when not to use it or mention alternatives, but the sibling sql_execute suggests a distinction. Still clear enough for effective selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/moliver28/corpus-kb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server