Model Context Protocol (MCP) server for QLever SPARQL engine — query knowledge graphs from Claude Code and other MCP clients
Strong tool definitions with comprehensive schemas and clear descriptions. All 11 tools have explicit registrations with input schemas and descriptions. Most parameters are well-typed with constraints (min/max, enums, patterns). Descriptions average ~150 chars, meeting the 10-1024 char baseline. Key strengths: spatial_query uses discriminated unions (oneOf) for mode variants; timeout parameters include regex patterns; limit parameters consistently bounded. Weaknesses: output schemas not documented (tools return text/JSON but structure not specified); error handling lacks recovery guidance; no tool annotations (readOnlyHint, idempotentHint); descriptions could be more prescriptive about when to use each tool vs alternatives.
Analyze a SPARQL query plan WITHOUT executing it. Shows estimated result sizes and costly operations.
Look up all triples where a given IRI appears as subject or object. Returns both outgoing properties (where the entity is the subject) and incoming references (where it is the object). Accepts full IRIs (e.g. '<http://www.wikidata.org/entity/Q42>') or prefixed names if the dataset supports them.
Retrieve metadata about the QLever index: dataset name, number of triples, predicates, subjects, and objects. Useful for understanding the scope of the knowledge graph before querying.
List the predicates (properties) available in the dataset, ordered by frequency. Useful for exploring an unfamiliar knowledge graph and understanding its schema before writing queries.
List named graphs in the dataset. Call this before graph-scoped queries or updates.
Search for entities by name or label using SPARQL text matching. Works with datasets that have rdfs:label or schema:name predicates. Returns matching entities with their labels.
Output schemas not documented. Tools return text or JSON but LLMs cannot infer field structure for downstream chaining. E.g., sparql_query_json returns 'raw QLever JSON response' but no schema of result fields (results[], timing, totalResultCount).
Error handling lacks recovery guidance. Tools catch errors and return errorText(err) but do not categorize as retryable/user-fixable/fatal or suggest next steps. E.g., 'No completions found' vs 'Partial query syntax invalid, check SPARQL syntax'.
No tool annotations. All tools are read-only but lack readOnlyHint annotation. This prevents clients from optimizing caching, retry logic, or UI presentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Search QLever's text index for entities co-occurring with keywords. Different from search_entities which matches labels. Requires text index.
Use this BEFORE sparql_query when unsure which predicates or entities exist. Uses QLever's context-sensitive autocompletion, not generic SPARQL.
Execute a SPARQL query against the configured QLever endpoint. Supports SELECT, ASK, CONSTRUCT, and DESCRIBE query forms. Returns results as a formatted table with timing information.
Execute a SPARQL query and return the raw QLever JSON response. Useful when you need structured data for further processing (result arrays, timing breakdown, total result count).
Find entities within a geographic area using QLever's native spatial join. Supports radius and bounding box modes.
Descriptions lack prescriptive guidance on tool selection. E.g., sparql_query vs sparql_query_json both execute SPARQL but descriptions do not explain when to use each. LLMs must infer from names alone.
spatial_query description does not explain coordinate system (WGS84 assumed) or what 'native spatial join' means operationally. Ambiguity invites misuse.