Skip to main content
Glama
infino-ai

code-context

by infino-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

SQL over the code index

sql

Query the codebase with SQL to compute counts, rankings, and aggregations via search functions, answering analytical questions like which files have the most code about a topic.

Instructions

Whole-repo analytical questions that file tools cannot express at any budget: counts, rankings, GROUP BY across the codebase in one query, on table chunks(path, start_line, end_line, lang, content[, embedding]). Search functions are callable as table-valued relations, so one query can rank AND aggregate: bm25_search('chunks','content','terms', k) needs no embedding; hybrid_search('chunks','content','terms','embedding', {{q}}, k) and vector_search('chunks','embedding', {{q}}, k) take a {{name}} placeholder with an embed map: {"q":"query text"}. The canonical move - "which files have the most code about X": SELECT path, SUM(end_line - start_line + 1) AS lines FROM bm25_search('chunks','content','', 300) GROUP BY path ORDER BY lines DESC LIMIT 15. Build queries on bm25_search/hybrid_search so results are ranked by relevance to the topic, not on a raw scan of the whole table. Read-only, single statement. The result includes a 'usage' field - a one-line receipt (tokens returned, rows, session total). After you answer, end your reply by showing that 'usage' line to the user verbatim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoAbsolute path to the repository root to query. Defaults to the server's configured root; set it to target a specific repo when a session spans more than one.
embedNoMap of placeholder name → query text, embedded server-side. E.g. {"q":"vector indexing"} fills {{q}}.
queryYesA single read-only SELECT or WITH statement. May use search table functions and {{name}} vector placeholders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/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. It explicitly discloses that the tool is read-only, supports a single statement, and returns a 'usage' field with a receipt. It does not cover error behavior or permissions, but the core behavioral traits an agent needs are present.

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 dense and somewhat long, but every component earns its place: purpose, search function usage, placeholder semantics, canonical example, read-only note, and result receipt. It is front-loaded with purpose and then provides practical details.

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 of the tool, the absence of an output schema, and the lack of annotations, the description is remarkably complete. It covers the table structure, callable search functions, vector placeholder syntax, read-only behavior, and the usage receipt, leaving an agent with enough information to construct and invoke valid queries.

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?

Schema coverage is 100%, but the description adds substantial meaning beyond the JSON schema: it explains the {{name}} placeholder mechanism, gives an embed map example, provides a canonical whole-repo query, and explains when embeddings are needed versus bm25-only search. This is far beyond baseline schema documentation.

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 identifies the tool as SQL querying over the code index for whole-repo analytical questions including counts, rankings, and GROUP BY. It gives a canonical example and explicitly contrasts with 'file tools', making its distinct role easy to grasp.

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 states when to use SQL: for whole-repo analytical questions that file tools cannot express, and advises building queries on bm25_search/hybrid_search instead of raw scans. It does not explicitly compare against the sibling 'search' tool, but the guidance is clear enough for most routing decisions.

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