Solr MCP

sql-select

Execute SQL SELECT queries on Solr collections for filtering, grouping, sorting, and aggregation via Solr's SQL interface. Use for explicit SQL access rather than Lucene full-text queries.

Instructions

Execute SQL SELECT queries against Solr (advanced).

Prefer the search tool for Lucene/full-text queries. Use this when you need Solr's SQL interface explicitly.

Collection/Field Rules:

Collections are used as table names (case-insensitive)
Field names are case-sensitive and must exist in Solr schema
SELECT * only allowed with LIMIT clause
Unlimited queries restricted to docValues-enabled fields
Reserved words must be backtick-escaped

WHERE Clause Differences:

Field must be on one side of predicate
No comparing two constants or two fields
No subqueries
Solr syntax in values:
- '[0 TO 100]' for ranges
- '(term1 term2)' for non-phrase OR search
String literals use single-quotes

Supported Features:

Operators: =, <>, >, >=, <, <=, IN, LIKE (wildcards), BETWEEN, IS [NOT] NULL
Functions: COUNT(*), COUNT(DISTINCT), MIN, MAX, SUM, AVG
GROUP BY: Uses faceting (fast) for low cardinality, map_reduce (slow) for high cardinality
ORDER BY: Requires docValues-enabled fields
LIMIT/OFFSET: Use 'OFFSET x FETCH NEXT y ROWS ONLY' syntax
- Performance of OFFSET degrades beyond 10k docs per shard

Parameters:

query: SQL query to execute

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 30, 2026

TDQS

A4.6/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 largely succeeds: it discloses case-sensitivity rules, the SELECT * + LIMIT constraint, docValues restrictions on unlimited queries, ORDER BY docValues requirements, GROUP BY faceting vs map_reduce cost, and OFFSET performance degradation past 10k docs per shard. It stops short of stating read-only semantics, error behavior, or default result limits.

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 routing guidance before the dialect details, and the headed sections make it scannable. It is long, but nearly every bullet encodes a real constraint; the trailing 'Parameters: query' block is the one redundant element.

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?

An output schema exists, so return-value explanation is unnecessary; the description covers the remaining burden — routing, dialect rules, and performance caveats. Nothing an agent needs in order to write a valid query is missing.

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% for the single `query` parameter, so the description must compensate — and it does, effectively documenting the SQL dialect (operators, functions, WHERE restrictions, range syntax, backtick escaping, LIMIT/OFFSET form). The generic 'query: SQL query to execute' line adds nothing, but the surrounding dialect documentation is what makes the parameter usable.

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+resource ('Execute SQL SELECT queries against Solr') and immediately qualifies the scope as the advanced/explicit SQL path. It names the sibling tool `search` as the default alternative, so an agent can distinguish it from siblings without opening any schema.

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?

Explicitly states when to prefer the alternative ('Prefer the `search` tool for Lucene/full-text queries') and when to use this one ('when you need Solr's SQL interface explicitly'). This is a clean when/when-not/alternative routing statement.

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

Deploy Server