Skip to main content
Glama
MatthiasVanDE

jena-mcp-server

sparql_query

Run read-only SPARQL queries (SELECT, CONSTRUCT, ASK, DESCRIBE) on Apache Jena Fuseki datasets to fetch or inspect RDF triples.

Instructions

Run a read-only SPARQL query (SELECT, CONSTRUCT, ASK or DESCRIBE).

Forms: SELECT returns rows, CONSTRUCT and DESCRIBE return triples, ASK returns a boolean. WHERE is optional -- "SELECT ?s { ?s ?p ?o }" is valid SPARQL.

Property paths are the reason to reach for SPARQL over a REST API: a/b sequence ?s foaf:knows/foaf:name ?name a|b alternative ?s (rdfs:label|skos:prefLabel) ?label a* zero or more ?s skos:broader* ?ancestor a+ one or more ?s rdfs:subClassOf+ ?super a? zero or one ^a inverse ?child ^ex:hasParent ?parent !a negated ?s !rdf:type ?o

Named graphs: GRAPH { ?s ?p ?o }, or GRAPH ?g { ... } to range over all of them. Note that a query without a GRAPH clause reads the default graph, which on many datasets is empty unless the store is configured with a union default graph.

Results are capped. A SELECT without its own LIMIT gets one appended (see default_limit), because an unbounded exploration query over even a small dataset can return hundreds of thousands of characters. Pass limit: 0 to lift the cap deliberately, and out_file to send a large result to disk instead of through the conversation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRow cap for a SELECT that sets none itself. 0 lifts it. Defaults to the server setting.
queryYesThe SPARQL query.
datasetNoDataset name. Defaults to the configured one.
out_fileNoWrite the result here (inside the file sandbox) and return only the path and size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: read-only semantics, the fact that a LIMIT is auto-appended to SELECTs, that limit:0 lifts the cap, and that out_file routes large results to disk instead of the conversation. It also discloses the empty-default-graph behavior on many datasets — exactly the operational context an agent needs.

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-loaded with the core purpose, then organized into scannable sections (forms, property-path table, named graphs, result caps). It is on the longer side, but the property-path examples and cap warnings each earn their place for a complex query tool.

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?

For a query tool with no output schema, the description still explains the return shape of each form (rows, triples, boolean) and the cap/file behaviors. Combined with 100% schema coverage, an agent has everything needed to invoke it correctly.

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 100%, so baseline is 3, but the description adds real meaning: it explains why limit exists (unbounded queries can return hundreds of thousands of characters), that limit:0 lifts the cap deliberately, and that out_file sends results to disk. dataset is only lightly touched.

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 opens with a specific verb+resource: 'Run a read-only SPARQL query (SELECT, CONSTRUCT, ASK or DESCRIBE).' It enumerates the query forms and their return shapes, clearly distinguishing this read-only tool from the sibling sparql_update. The purpose is unambiguous.

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 gives explicit when-to-use guidance ('Property paths are the reason to reach for SPARQL over a REST API') and warns about default-graph pitfalls that inform usage. It does not explicitly contrast with read-oriented siblings like describe_resource or read_graph, so it falls short of full alternative coverage.

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