Skip to main content
Glama
italia

Schema.gov.it MCP Server

Official
by italia
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Query Local Ontology

query_local_ontology
Read-onlyIdempotent

Run SPARQL SELECT queries directly on ontology files stored locally or uploaded to the server, enabling precise data extraction from RDF vocabularies and models.

Instructions

Execute a SPARQL SELECT query against an ontology available on the server filesystem or through HTTP upload.

Quale modalita di input usare:

  • stdio / stessa macchina → file_path

  • server remoto, file grande → get_upload_instructions + upload_id

  • server remoto, file piccolo (<1 MB) → usa inspect_local_ontology con content + format per l'analisi; per query ripetute preferisci upload + upload_id

Args (provide exactly one of file_path or upload_id):

  • file_path: Absolute path on the MCP server filesystem. Use only if the server can really read that path.

  • upload_id: UUID returned by POST /upload. Use this in HTTP/remote mode when the file is local to the client, not the server.

  • query: SPARQL SELECT query

  • inject_prefixes: Inject standard prefixes (rdf, rdfs, owl, skos, dct…) — default true

Important for remote MCP servers:

  • If a direct file path is not accessible from the server, do not keep retrying with alternative local paths.

  • Call get_upload_instructions with the file path, execute the returned curl command via Bash tool (do NOT read the file first), then use the upload_id here.

  • Never relay the file content through the conversation — this wastes tokens. curl sends bytes directly from disk to server.

Returns:

  • Compressed SPARQL results (tabular for >5 rows, compact for ≤5 rows)

When to use this vs X:

  • vs query_sparql: use this for a local/uploaded ontology; use query_sparql for the default remote catalog

  • vs query_uploaded_store: prefer this tool when you already have an upload_id; query_uploaded_store is only a thinner upload-specific path

Do not use this if:

  • you need a standard profile of a concept or property → use inspect_local_concept or inspect_local_property

  • you just need a summary of the ontology → use inspect_local_ontology

Supported formats: .ttl (Turtle), .owl / .rdf (RDF/XML), .nt (N-Triples), .jsonld (JSON-LD), .graphol (Graphol XML) Efficiency: File is cached after first load; repeated queries on the same unchanged file skip re-parsing. Note: Standard prefixes (rdf, rdfs, owl, skos…) are injected automatically unless inject_prefixes=false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSPARQL SELECT query to execute
file_pathNoAbsolute path to the local ontology file (local/Docker)
upload_idNoUpload UUID returned by POST /upload (HTTP mode)
inject_prefixesNoInject standard prefixes (default: true)

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description adds file caching, automatic prefix injection, compressed result format, supported file formats, and efficiency notes. No contradictions.

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?

Well-structured with headings, bullet points, and clear sections. While lengthy, every part serves a purpose. Slightly verbose but not wasteful.

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 (multiple input modes, remote server considerations, many siblings), the description covers all necessary aspects: return format, caching, prefixes, supported formats, and links to related tools. No gaps.

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 coverage is 100%, so baseline is 3. The description adds context: mutual exclusivity of file_path and upload_id, logic for choosing input mode, and default for inject_prefixes. Adds value beyond schema.

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 executes SPARQL SELECT queries against a local or uploaded ontology, using a specific verb and resource. It distinguishes from sibling tools like query_sparql and query_uploaded_store by specifying when to use each.

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?

Provides explicit when-to-use and when-not-to-use guidance, including three input modes (file_path, upload_id, inspect_local_ontology) with conditions, and lists alternatives for concept/property inspection and ontology summary.

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/italia/dati-semantic-mcp'

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