Skip to main content
Glama
italia

Schema.gov.it MCP Server

Official
by italia

Inspect Concept in Local / Uploaded Ontology

inspect_local_concept
Read-onlyIdempotent

Get a complete profile of an ontology class or concept from a local or uploaded file, showing definition, hierarchy, properties, and data relations, with raw or effective mode.

Instructions

Get a full profile of a class or concept from a local or uploaded ontology.

CRITICAL — file access workflow:

  1. Try file_path first (works only if the file is readable by the MCP server process).

  2. If file_path fails for any reason → call get_upload_instructions with the local path, execute the returned curl command via Bash tool, parse the id from the JSON response, then call this tool again with upload_id.

  3. NEVER read the file content and pass it through the conversation. NEVER attempt to parse or analyse the TTL text manually. The upload workflow sends raw bytes directly from disk to server without the AI ever seeing the content — it is always faster, cheaper, and more reliable.

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) → valuta content + format con inspect_local_ontology, poi passa a upload se servono query ripetute

Args:

  • uri: URI of the class/concept to inspect

  • file_path / upload_id: exactly one (see workflow above)

  • mode: "raw" | "effective" (default: "effective")

Tip: Use search_concepts first if you are checking whether a similar concept already exists in schema.gov.it. Use this tool only after you know you want to inspect the local/uploaded ontology.

mode: "raw" — only triples explicitly present in the local file:

  • definition, hierarchy, usage, own_properties (rdfs:domain asserted directly on this class)

  • No ancestor traversal, no incoming/outgoing

mode: "effective" (default) — full OWL/RDFS-implied view:

  • All raw sections, plus:

  • inherited_properties: properties from superclasses via rdfs:subClassOf+/skos:broader+, each annotated with the ancestor that declares them

  • incoming / outgoing: data-level relations via instances

Distinguishing own vs inherited:

  • own_properties = rdfs:domain explicitly written as this class in the local file

  • inherited_properties = rdfs:domain written on an ancestor class (traversed via property paths)

  • Properties applicable only via owl:restriction or anonymous class expressions are NOT shown — use query_local_ontology for those

Limitation with owl:imports: inherited_properties traverses only superclasses present in the local file. Classes from imported external ontologies (e.g. l0:, COV:, CPV:) are absent from the local store unless the file includes them. For complete property semantics of a property that subPropertyOf an external one, use inspect_local_property instead — it falls back to schema.gov.it for missing super-properties.

When to use this vs X:

  • vs inspect_concept: use this for a local or uploaded ontology; use inspect_concept for the remote schema.gov.it catalog

  • vs query_local_ontology: use this when you want the standard profile of one concept; use query_local_ontology only for custom SPARQL questions not covered here

Unicode SPARQL note: oxigraph rejects prefixed names with non-ASCII local parts (e.g. myont:modalità_cup). Always use full URIs in angle brackets (<https://...#modalità_cup>) for properties or classes with Unicode in the local name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriYesURI of the class or concept to inspect
modeNo"raw": only asserted triples (own_properties, no ancestor traversal). "effective" (default): adds inherited_properties via rdfs:subClassOf+/skos:broader+ and data-level incoming/outgoing.effective
file_pathNoAbsolute path readable by the MCP server process. If this fails, do NOT read the file — use get_upload_instructions + Bash curl + upload_id instead.
upload_idNoUUID from POST /upload. Preferred when the file is on the client machine or file_path failed.
Behavior5/5

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

Annotations readOnlyHint=true, idempotentHint=true, destructiveHint=false indicate a safe read operation. The description adds extensive behavioral context: modes (raw vs effective), limitations with owl:imports, Unicode SPARQL note, and the file access workflow. No contradictions with annotations.

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 lengthy but well-structured with sections, bold headers, and lists. It is front-loaded with the core purpose and workflow. While every sentence is informative, slight trimming could improve conciseness without losing clarity.

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?

The tool is complex with 4 parameters and no output schema. The description comprehensively covers input modes, return behavior (raw vs effective sections), limitations, and cross-references to sibling tools. The agent is fully equipped to invoke the tool correctly.

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 significant meaning beyond schema: it explains when to use file_path vs upload_id with detailed workflow, elaborates on mode values with examples and behaviors, and clarifies the uri parameter's role. This far exceeds baseline expectations.

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's purpose: 'Get a full profile of a class or concept from a local or uploaded ontology.' It distinguishes from siblings like inspect_concept (remote) and query_local_ontology (custom SPARQL). The workflow and use cases are explicitly explained.

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?

The description provides explicit when-to-use and when-not-to-use guidelines, including a step-by-step file access workflow, a comparison with related tools, and a tip to use search_concepts first. It covers prerequisites and alternatives comprehensively.

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