Schema.gov.it MCP Server

Official

by italia

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Many tools have distinct purposes, but there are several overlapping pairs (e.g., query_sparql vs query_local_ontology vs query_external_endpoint; inspect_concept vs inspect_local_concept). The descriptions help differentiate, but with 47 tools an agent may still struggle to select the correct one.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern with underscores (e.g., list_ontologies, explore_classes). A few names are longer phrases (find_recommended_scheme_for_property), but overall the pattern is predictable.
Tool Count3/5
At 47 tools, the count is high for a single server. While the domain is broad (semantic catalog, external endpoints, OKG, territorial codes), many tools are specialized. The count is borderline between 'slightly over' and 'too many' for typical use.
Completeness4/5
The tool set covers a wide range: SPARQL execution, ontology/vocabulary/dataset exploration, quality checks, coverage analysis, external endpoint integration, and OKG catalog interaction. Missing reasoning or classification tools, but the surface is largely complete for the stated catalog purpose.
Average 4.5/5 across 47 of 47 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, and non-destructive. The description adds that it returns a list of overlaps with relation types (owl:sameAs, skos:exactMatch, Same Label), which is useful but does not disclose full behavioral traits like result limits beyond the default 50, or whether results are exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but slightly redundant: the Returns section repeats the relation types already mentioned in the first sentence. It is front-loaded with the purpose, but the Args section is necessary. Overall, it could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers purpose, parameter, and return structure. However, it lacks context about the scope of the check (e.g., entire knowledge graph vs. specific dataset) and does not explain what 'Same Label collisions' means precisely.
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%, so the description must compensate. It clearly documents the single parameter 'limit' with its default value (50), adding meaning beyond the schema's type and default. However, it could be improved by noting any accepted range or behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies potential overlaps (same labels) or explicit mappings, using specific verbs and resources. It distinguishes its function from sibling tools like 'check_quality' or 'check_coverage' by focusing on overlaps, but does not explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only describes what the tool does without context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. Description adds a behavioral constraint (min query count) and explains the analysis source (usage logs), complementing annotations without contradicting them.
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?
Description is concise with only two sentences plus a note. Purpose is stated upfront, and no unnecessary text is present. However, it could be slightly more structured (e.g., listing args and returns explicitly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the tool's purpose, input condition, and output type (list of recommendations). It omits details like recommendation format or examples, but remains complete enough for a simple tool.
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?
No parameters exist, so description is not required to add parameter details. Baseline score of 4 applies as schema coverage is 100% and description adds no redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes usage logs to suggest new specialized tools, using a specific verb and resource. It distinguishes itself from sibling tools like 'suggest_improvements' by focusing on new tools from usage data, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides a precondition (requires at least 2 queries for same type) but lacks guidance on when to use this tool versus alternatives like suggest_improvements or analyze_usage. No explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds value by explaining normalization of trailing slashes and return ordering, which are behavioral traits beyond 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?
Well-structured with Args, Returns, and Note sections. Efficiently covers multiple aspects without verbosity. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, behavior, and return format. No output schema exists, but description adequately documents return list content and ordering.
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?
All three parameters are explained with defaults and effects, compensating for 0% schema description coverage. Provides meaningful usage context (e.g., normalize_trailing_slash, include_variants).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available Ontologies' and mentions specific resource type and ordering. It is specific but does not explicitly differentiate from sibling list tools like list_vocabularies or list_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains default parameter behaviors and provides guidance on using include_variants for catalog cleaning. However, it does not give when-not-to-use context or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context about the depth parameter and return types (direct connections vs. multi-hop paths), beyond what annotations provide. However, it does not mention authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an introductory sentence, clear 'Args' and 'Returns' sections, and no redundant information. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the purpose, parameters, and return types. However, it could be more explicit about the exact return format (e.g., JSON structure) since there is no output schema.
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% with descriptions for all parameters. The description adds value by explaining max_hops options (1|2|3, default 1) and noting that '1 preserves previous behaviour,' which clarifies the schema's const values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find how two concepts are connected' with specific arguments and return types. It is distinctive among siblings but does not explicitly differentiate itself from similar tools like search_concepts or check_overlaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining inputs and outputs, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No guidance on preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by detailing the conditional return behavior based on the identifierType parameter, which aids understanding beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured with clear headings (Args, Returns, Use when). Every sentence serves a purpose, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description adequately covers behavior, parameter effects, and usage context. Minor omissions like pagination details do not significantly detract from completeness.
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%, but the description enriches both parameters: limit with default value (also in schema) and identifierType with concrete examples ('Codice Catastale', 'Sigla Automobilistica'). This adds practical semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists CLV Identifier resources by type with counts and sample values, specifying the action and resource. It does not explicitly differentiate from sibling tools like explore_classes or describe_resource, but 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?
The 'Use when' section provides clear context for when to use the tool (exploring clv:Identifier resources). However, it offers no exclusions or alternative tool references, so it falls short of a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the return fields (total_calls, tool_breakdown, etc.). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three bullet points for Args and Returns) with no superfluous text. Every element serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately lists the return fields. It could benefit from specifying types (e.g., 'total_calls' is an integer) but is sufficient for a simple introspection tool.
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?
There are no parameters, and schema coverage is 100%. The description correctly reflects this with 'Args: None'. With zero parameters, the baseline of 4 is appropriate.
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 uses a specific verb 'analyze' and a precise resource 'server's own usage logs'. It clearly distinguishes from sibling tools by focusing on introspection rather than external queries or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives. However, the zero parameters and self-referential nature imply it's for internal diagnostics, but no comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description adds security details (HTTPS only, 15s timeout), which are behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: four sentences plus bullet-pointed Args and Returns. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, security, and return format (ordered list with counts). Lacks error handling description, but adequate for a quick overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for each parameter; description repeats this info without adding new semantics beyond what schema provides.
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 explores an external SPARQL endpoint to discover main classes and instance counts, and the 'Use when' context distinguishes it from siblings like query_sparql.
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?
Explicit 'Use when' section provides context for when to use (quick overview before detailed queries), but does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and description confirms 'Find' (read operation). Additionally, description lists specific alignment types searched (owl:sameAs, skos:exactMatch, etc.), adding context beyond 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 well-structured with Args and Returns sections, plus a usage line. Sentences are concise and front-loaded with the core purpose.
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 simple read-only query tool with one parameter and no output schema, the description fully covers purpose, parameters, return fields, and use case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'uri' with description 'URI of the concept in schema.gov.it'). Description repeats this without adding new meaning, so baseline 3 applies.
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 states 'Find all alignment links from a concept in schema.gov.it toward external resources.' This is a specific verb (Find) and resource (alignment links), clearly distinguishing it from siblings like find_okg_alignments (OKG-specific) and others.
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?
The 'Use when' section explicitly states: 'Understanding how a local concept maps to external systems (Eurostat, DBpedia, EU Publications Office, etc.)' This provides clear context, though it doesn't mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description's role is reduced. The description adds that data is CC0 and specifies return fields, which is useful but not critical. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-organized with clear sections, and every sentence adds value. No redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with only 2 simple parameters and no output schema, the description adequately covers usage, examples, and return structure. It could mention pagination or error behavior, but the current level is sufficient for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description repeats the parameter names and adds example values for 'query', but does not provide additional syntactic or behavioral details beyond the schema. Baseline score of 3 is appropriate.
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 explicitly states it searches the OKG catalog for semantic web software tools, listing concrete examples like ontology editors and SPARQL engines. This clearly defines the resource and action, distinguishing it from sibling tools like 'search_okg_resources' or 'list_okg_categories'.
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?
The 'Use when' section provides specific scenarios (e.g., validating ontologies, working with RDF data). However, it lacks explicit guidance on when not to use this tool or mention of alternatives (e.g., 'search_okg_resources' for broader searches), which would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds behavioral transparency by stating it runs 3 parallel queries and joins client-side, and gives specific counts of provinces and metropolitan cities. 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?
The description is well-structured with Args and Returns sections, and the Note adds useful context. It is not overly verbose but could be slightly more concise.
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 no output schema, the description adequately explains return fields (ISTAT code, name, sigla, metro code). It also describes the parallel query execution and counts, making the tool's behavior fully understandable.
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% with both parameters described. The description adds extra semantic value: keyword is case-insensitive, and lang default behavior is clarified. This goes beyond the schema's enum and default.
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 it lists Italian provinces with their codes, using specific verbs and resource (list provinces). It distinguishes itself from sibling tools like list_municipalities, list_ontologies, or list_identifiers by focusing on provinces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and optional arguments but does not provide guidance on when to use this tool vs alternatives. No explicit when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds transparency by specifying the return format (list of ConceptSchemes with labels and concept counts, ordered by count descending), which is beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a structured Args/Returns section. No wasted words, front-loaded with the core purpose, and well-organized for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, safety annotations), the description covers the essential behavior. It returns a list with ordering and fields, which is adequate for agent decision-making.
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 0%, but the description documents the 'limit' parameter with a default value of 20, providing meaning beyond the schema's type and default. For a single self-explanatory parameter, this is sufficient compensation.
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 lists available Controlled Vocabularies (ConceptSchemes) with instance counts. The verb 'list' and specific resource 'ConceptSchemes' differentiate it from sibling tools like browse_vocabulary or search_in_vocabulary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing vocabularies but does not explicitly state when to use this tool versus alternatives like explore_catalog or list_ontologies. No exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds transparency about pagination parameters (limit, offset) and return structure, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-organized with separate sections for Args, Returns, and Use when. Every sentence adds value without redundancy.
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 tool's simplicity, the description fully covers parameters, return format, and usage context. No output schema is needed because Returns are described in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description mainly echoes the schema with defaults and constraints. It adds an example URI for class_uri, but does not significantly enhance understanding beyond the 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 'List instances of a given class in the catalog' with a specific verb and resource. It distinguishes from sibling tools like explore_classes or inspect_concept by focusing on listing actual instances.
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?
Includes a 'Use when' section that provides clear context: when you have a class and want to know if it has real instances. Although it doesn't explicitly exclude other tools, the guidance is precise and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: the BIND+REPLACE URI extraction for Belfiore codes to avoid timeout, deduplication logic, and return structure. 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?
The description is well-structured with Args, Returns, and Notes. It is front-loaded and clear, though the technical note about Virtuoso timeout adds slight verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description covers the return structure, pagination, and deduplication. It provides sufficient context for an agent to use the tool 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%, baseline 3. The description adds meaning: keyword is a filter, lang sets name language, withBelfiore is slower and optional. It explains the tradeoff for withBelfiore beyond the 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 browses Italian municipalities (comuni) with their codes. It uses specific verbs and resource, distinguishing it from sibling tools like list_provinces or list_identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing municipalities and provides parameter guidance, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only/idempotent, and description adds the URI prefix heuristic and return structure, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with bulleted args and returns; every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, usage, return, and a heuristic for a single-parameter tool, though it could mention when to use more specific siblings.
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 covers 100% of parameters, but description adds the heuristic note and clarifies the return grouping, adding 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?
Clearly states the tool lists classes and properties from a specific ontology, distinguishing it from siblings like explore_classes or list_properties.
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?
Indicates the ontologyUri comes from list_ontologies, implying a prerequisite, but does not explicitly state when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is clear. The description adds value by detailing the return structure (list with endpoint URL, title, description, conformsTo standard) and source catalog, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a few short sentences to cover purpose, arguments, returns, and usage. The structured format with 'Args:' and 'Returns:' sections, plus a 'Use when' tip, is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides adequate context: it specifies the source (schema.gov.it catalog), return fields, and usage scenario. It might lack details on pagination or limits, but for a catalog exploration tool, it is sufficiently complete.
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?
The tool has zero parameters, so the description has no need to explain parameters. Schema coverage is 100% (vacuously). The description correctly states 'Args: None', which is sufficient.
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 discovers SPARQL endpoints from the schema.gov.it catalog via dcat:DataService. It uses a specific verb ('Discover') and resource ('SPARQL endpoints'), distinguishing it from sibling tools like list_datasets or list_ontologies.
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?
The 'Use when' section explicitly advises to use the tool when exploring external SPARQL endpoints connected to the Italian PA semantic catalog. While it doesn't mention alternatives or when not to use it, the guidance is clear and context-appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds that it returns a flat list with direction and depth, which is helpful output detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args, Returns, and Use when sections. Every sentence serves a purpose, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and output format. For a simple navigation tool with 3 parameters and no output schema, this is nearly complete. Could mention result size limits, but depth max handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description repeats uri, direction, depth but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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 'Navigate a SKOS hierarchy upward and/or downward from a concept,' specifying the verb (navigate), resource (SKOS hierarchy), and scope (upward/downward). This distinguishes it from sibling tools like query_sparql.
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 says 'Use when: You want a dedicated SKOS navigation tool instead of writing custom query_sparql property paths,' providing a clear alternative and use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying that results include rationale, suggested use cases, and example query ideas, and that the list is curated (high-signal). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, bullet-pointed Args and Returns, and a clear 'Use when' section. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return as curated recommendations with rationale, use cases, and example queries. It also sets context for when to use the tool. Could mention behavior without category filter, but still complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 repeats the parameter names and default but adds little beyond the schema descriptions. Category filter is described as 'endpoint family' with enumerated values, but this is already in the 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 returns a curated list of useful public SPARQL endpoints to pair with schema.gov.it, which is a specific verb+resource. It distinguishes from sibling tools by explicitly mentioning use before query_external_endpoint or explore_external_endpoint.
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?
Description includes 'Use when: You want a high-signal shortlist of external endpoints before using query_external_endpoint or explore_external_endpoint', providing explicit context and alternatives. This tells the agent when to use this tool and what to do next.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds value by noting parallel execution and specific return categories, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args, Returns, Note sections. Every sentence adds value, no waste.
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 one parameter, no output schema, and complexity of ontology analysis, the description adequately covers return values and parallel execution behavior.
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?
Despite 0% schema coverage, the description fully explains the limit parameter with default value and meaning: 'Maximum issues per category (default: 20)'.
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?
Description clearly states the tool analyzes ontology for structural issues, listing specific categories (cycles, unused classes, etc.). It distinguishes from siblings like check_overlaps and check_quality by focusing on improvement suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied ('analyze the ontology for structural issues') but no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds value by explaining the return type ('All properties and values') and depth behavior, but does not disclose authorization or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise and well-structured: brief intro, clear args/returns sections, bulleted usage guidance. No unnecessary sentences; every sentence adds value.
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 2 parameters, rich annotations, and no output schema, the description covers purpose, parameters, return info, and usage guidance. It adequately addresses the tool's scope and context among 40+ siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. Description repeats the parameter info from the schema in 'Args' without adding new meaning beyond default value for depth.
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?
Description states 'Get all triples for a resource (Concise Bounded Description)', providing a specific verb and resource type. It clearly distinguishes from siblings like inspect_concept and query_sparql in the 'When to use' section.
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 includes a 'When to use this vs X' section with two alternatives, stating conditions for each. Also adds a 'Use when' line, providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description adds behavioral context: 'Both queries run in parallel for performance.' No contradiction. However, it doesn't mention any potential side effects or prerequisites, but the safety profile is clear from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, a brief contextual note, and a clear Args/Returns/Note section. Every sentence adds value, and the most important information is front-loaded.
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?
With only one parameter, clear annotations, and no output schema, the description is complete. It explains what the tool does, what arguments it takes, what it returns (metadata and distributions), and includes a performance note. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'datasetUri' has a schema description 'The URI of the Dataset'. The description adds 'URI of the dataset to explore,' which is essentially a restatement. Since schema coverage is 100%, baseline is 3. The description does not provide examples, format constraints, or additional context beyond the 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 'Get details of a specific Dataset including metadata and distributions.' It uses a specific verb ('Get details') and identifies the resource ('Dataset'). It also distinguishes this tool from siblings by noting it is for targeted DCAT-AP_IT inspection and usually secondary to other exploration tools.
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 'Use this for targeted DCAT-AP_IT inspection' and provides clear guidance on when not to use it: 'On schema.gov.it, many datasets describe semantic assets, so this tool is usually secondary to ontology, vocabulary, class/property, and SPARQL exploration.' This gives a clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover safety. The description adds valuable behavioral details: the three-step process, how matches are classified (confirmed vs candidates), and how cross-referencing works. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered steps, separate sections for args and returns, and a 'Use when' clause. Every sentence is concise and informative, with no fluff.
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 simple input (one param), clear annotations, and no output schema, the description fully explains the process, return fields, and confidence levels. The agent has all necessary information to use the tool 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?
The single parameter 'uri' is fully described in both the schema and the description as 'URI of a schema.gov.it resource'. Schema coverage is 100%, so the description's additional mention of 'concept, class, or vocabulary' adds useful specificity.
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: given a schema.gov.it URI, find related resources in the Open Knowledge Graphs catalog. It uses a specific verb 'find' and resource 'OKG alignments', distinguishing it from sibling tools like search_okg_resources or find_external_alignments.
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?
The description includes a 'Use when' section that explicitly advises discovering international equivalents or checking representation in global standards. While it does not list counterexamples, the context strongly implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds significant context about return fields (range, instance_count, schemes, suggestion) and mentions 'actionable advice', which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (Args, Returns, Use when). Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return fields well. It could be slightly more explicit about when not to use, but overall sufficient for an agent to invoke 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?
The single parameter is fully documented in the schema, but the description adds a concrete example URI and explains its purpose ('URI of the property to analyze'), providing meaning beyond the schema type.
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 uses a specific verb ('find') and resource ('range class and associated SKOS ConceptSchemes'). It clearly distinguishes from many sibling tools focused on searching, browsing, or inspecting resources.
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?
The description explicitly states when to use the tool (to find controlled vocabulary values or official ConceptSchemes). It lacks explicit alternatives or when-not-to-use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds no additional behavioral context about side effects, auth needs, or rate limits, only describes return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: what it does, what it returns, when to use. No fluff, well-structured with bolded headings for returns and use case.
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?
Despite simplicity, description fully covers purpose, return value, and usage context. Sibling tools like search_okg_resources are referenced, making it complete for its role.
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?
No parameters, so description needs no parameter info. Baseline 4 as per instructions for 0-param tools.
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?
Description clearly states it fetches thematic categories from OKG catalog, specifying the resource and action. Differentiates from siblings by focusing on listing categories for filtering.
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?
Explicit 'Use when' statement provides clear guidance: when you need categories before filtering OKG searches. Also notes the output can be used as filters in specific tools, avoiding misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds behavioral details: returns a list of properties with domain, range, and label, and limits results to 50 by default. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args, Returns, and Examples sections. It front-loads the purpose and uses minimal but complete sentences. No redundant or extraneous information.
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 tool with 3 optional params and no output schema, the description covers all aspects: argument details, return value structure, and concrete examples. It is complete for an agent to understand and use the tool 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 has 3 params with only 33% description coverage (ontologyUri has description). The description adds meaning for all params: ontologyUri as optional filter, propertyType as enum with default 'both', limit as max results default 50. It compensates for low schema coverage.
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 lists ObjectProperty and DatatypeProperty from an ontology or globally. It uses specific verbs and resource types, and distinguishes from sibling tools like get_property_details (which likely retrieves a single property) and explore_ontology (broader context).
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?
The description provides explicit arguments, defaults, and examples (empty args, with ontologyUri). It implicitly guides when to use (listing properties) but does not state when not to use or alternatives. Still, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds that the date parameter is noted in output but full filtering not yet implemented, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Use when). It uses bullet-like formatting and every sentence adds value without redundancy.
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 tool's simplicity (3 params, no output schema), the description covers purpose, parameters, return fields, usage guidance, and a limitation. It is fully self-contained.
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% with descriptions for all params. The description adds examples, allowed values (matching enum), and explains the date parameter's partial implementation, adding value beyond the 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 resolves Italian territorial codes to canonical CLV URIs. It uses a specific verb-resource combination and distinguishes from siblings which handle search, listing, or querying rather than code resolution.
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?
The 'Use when' section explicitly tells agents to use this when they have a raw code and need a semantic URI. It does not list alternatives, but the context of sibling tools makes the purpose sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. Description adds that data is CC0, categories are fetched dynamically, and explains the return format, offering solid behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with sections, bullet points, and no filler. Every sentence adds value, including usage context and return explanation.
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?
Despite no output schema, description explains return fields. All 4 parameters are covered, and context (CC0 license, dynamic categories) is provided. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description repeats the parameter list but adds example values and default (limit: 20). No contradiction, but adds little 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 it searches the OKG catalog for ontologies, vocabularies, and taxonomies, which distinguishes it among many sibling search tools like search_concepts and search_in_vocabulary.
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 use: 'Discovering international ontologies... before aligning with schema.gov.it resources,' and suggests complementary tools (find_okg_alignments, compare_coverage_with_okg), meeting the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral details beyond annotations, such as the return format (instance count, properties used, top 50 types) and the effect of providing/omitting targetUri. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, How to interpret). Each sentence adds value, and the format is front-loaded with the core purpose. No redundancy.
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 tool has only one optional parameter and no output schema, the description fully covers return values, usage scenarios, and interpretation. It is complete for an AI agent to select and 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?
Input schema has 100% description coverage, but the description significantly adds meaning by explaining the two modes of operation with and without the parameter, including concrete examples. This goes well beyond the schema description.
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?
Clearly states the tool analyzes usage coverage of a class/property or provides global stats, with two distinct modes. The verb+resource is specific and distinguishes from sibling tools like 'analyze_usage' through explicit mode descriptions.
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?
Provides explicit guidance on when to use each mode via examples and the 'How to interpret' section. However, it does not explicitly mention when not to use this tool or name alternatives among siblings, so it loses a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, idempotent, non-destructive behavior. The description adds significant detail: specific resource types checked, label lookup across all graphs, and false positive filtering of import stubs, providing behavioral depth beyond annotations without contradiction.
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 sections for args, returns, when-to-use, notes, and false positive filtering. Front-loaded with purpose. While slightly lengthy, every section adds value with minimal redundancy.
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 quality check tool with no output schema, the description comprehensively covers what is checked, how parameters affect results, false positive handling, and return format. It is complete enough for an AI agent to use 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 coverage is 50% (ontologyUri described, limit not). The description adds: default for limit (50), detailed usage of ontologyUri to avoid false positives, and its relationship to explore_ontology. This meaningfully supplements the 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 it verifies quality issues like missing labels or descriptions, specifying the resource types checked (owl:Class, owl:ObjectProperty, etc.). This distinctly separates it from siblings like 'check_overlaps' or 'check_coverage'.
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?
The description includes a 'When to use ontologyUri' section with explicit guidance on when to pass the ontology URI to exclude imported resources, reducing false positives. It also explains false positive filtering. While it doesn't list alternatives explicitly, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent; description adds context about not reading file content, one-hour expiration, and HTTP mode requirement, with no contradiction.
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 and lists, but lengthy; every sentence is meaningful given workflow complexity.
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?
Covers all aspects: return value, workflow steps, prerequisites, format support, and expiration, despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema coverage; description adds usage context but no new semantic meaning beyond schema definition.
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?
Description clearly states it returns a curl command to upload a local RDF file, distinguishing it from sibling tools that use upload_id or file_path directly.
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 step-by-step instructions, when to use vs alternatives (e.g., server-read file, small file), and prerequisites like HTTP mode and Docker setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds behavioral details: case-insensitive regex keyword matching, default limit, language options, and return format (labels and optional notation codes). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, clear list of args, return info, usage guidance, and deprecation notice. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, return values, and usage context. Differentiates from sibling browse_vocabulary. Lacks error handling or edge cases, but for a deprecated search tool it is sufficient.
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 75%; description adds meaning beyond schema: schemeUri comes from list_vocabularies, keyword is case-insensitive regex, limit is maximum results, lang values are explicitly listed. Adds useful context not in 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 searches for concepts within a specific Controlled Vocabulary, with a specific verb and resource. It distinguishes itself from browse_vocabulary by noting it is for quick keyword search in a known scheme.
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 provides when-to-use vs alternatives: 'use this only for a quick keyword search inside a scheme you already know', and recommends browse_vocabulary as a better default. Also marks the tool as deprecated, guiding agents away from it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, and idempotent behavior. The description adds that it supports pagination, returns a list of concepts with code and label, and gives output structure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headers (Args, Returns, When to use, Use for). Every sentence adds value, no redundancy. Front-loaded with the core purpose.
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?
Comprehensive for a tool with 5 parameters and sibling comparison. Explains input, output, usage guidance, and use cases. No output schema, but description provides clear output structure.
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 60% (3 of 5 parameters have descriptions). The description adds value for the undocumented 'limit' and 'offset' by listing defaults and purpose, and clearly explains optional parameters and language options.
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?
Clearly states 'Browse concepts in a vocabulary with pagination support', specifying the verb 'browse' and resource 'concepts in a vocabulary'. Explicitly distinguishes from sibling 'search_in_vocabulary'.
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 this vs X' section, comparing with 'search_in_vocabulary' and stating that this is the preferred default for exploring a known ConceptScheme due to pagination support, while the alternative is for lightweight keyword lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful context about parallel query execution and the dual-list return, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for Args, Returns, When to use, and a Note. Each sentence serves a purpose, no fluff, and information is front-loaded.
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 no output schema, the description fully explains the return value (two lists: graphs and ontologies) and adds context about parallel execution. It covers all necessary information for an agent to understand the tool's behavior and output.
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?
The tool has no parameters, and the schema coverage is 100% (empty). The description explicitly states 'Args: None', which is clear but slightly redundant. With no parameters, the baseline is 4, and the description adequately conveys the lack of inputs.
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 lists named graphs and ontologies in the endpoint. It uses the specific verb 'list' and identifies the resources, distinguishing it from siblings like list_ontologies and list_vocabularies by emphasizing a quick structural overview.
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?
Explicit guidance is provided: use this for a quick structural overview, and use list_ontologies or list_vocabularies for richer views. The Note also mentions parallel execution, providing context for performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior beyond annotations: results are ordered by count descending, filter is regex case-insensitive, and limit defaults to 50. Annotations already indicate safe, read-only operation, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples) and a front-loaded purpose sentence. Every sentence adds value, and there is no redundancy.
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 two parameters and no output schema, the description fully explains input semantics, return format, and provides examples. No gaps in understanding for an AI agent.
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 50% (filter has description in schema, limit has none). The description adds meaning: filter is regex case-insensitive, limit is maximum with default 50. Examples clarify usage. Slight deduction as filter could be more explicitly tied to URI.
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 lists available classes in the ontology with instance counts, using a specific verb and resource. It distinguishes from siblings like explore_ontology or search_concepts by emphasizing instance counts and ordering.
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?
The description provides clear context for when to use (listing classes with counts) but does not explicitly mention when not to use or offer alternatives among siblings. However, the specificity is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds significant behavioral details: it downloads and previews data, returns 10-15 rows, auto-detects CSV/JSON formats, and has a 10-second timeout. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose sentence, followed by usage context, then clearly labeled sections for Args, Returns, Supported formats, and Timeout. No redundant information; every sentence adds value.
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 tool's simplicity (one parameter, no output schema, rich annotations), the description covers purpose, usage context, parameter details, return format, supported formats, and timeout. The note about semantic assets adds domain-specific completeness. No gaps are apparent.
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% (one param with description). The description adds value by specifying the accepted formats (CSV or JSON) and that format is auto-detected, which goes beyond the schema's generic description. This benefits the agent beyond the baseline of 3 for high coverage.
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 first sentence clearly states the action (Download and preview) and the resource (distribution file). The phrase 'most useful after you already identified a concrete distribution URL' distinguishes it from sibling tools like explore_dataset or inspect_concept, which deal with broader resources. The domain-specific note about semantic assets further clarifies its niche.
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?
The description explicitly states when to use: 'most useful after you already identified a concrete distribution URL.' It provides context about schema.gov.it and distributions belonging to semantic assets. However, it does not explicitly exclude alternative tools or mention when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: security constraint (HTTPS only), timeout (15 seconds), and return format (compressed results). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear section headers (Args, Returns, Security, Examples, When to use). Each sentence adds value, no repetition. Appropriate length given complexity (11 lines).
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 description covers all critical aspects: purpose, parameters, security, return format, usage guidance with alternatives, and examples. Despite no output schema, the return description is sufficient. For a tool with 3 parameters and security considerations, this is complete.
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% with descriptions for all three parameters. The description adds value with examples (DBpedia, EU Publications Office), clarifies the injectPrefixes default, and reiterates security constraint on endpointUrl. This goes beyond baseline 3.
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 it executes SPARQL queries against any public HTTPS SPARQL endpoint, with specific verb 'Execute a SPARQL query' and resource 'public HTTPS SPARQL endpoint'. It distinguishes from siblings like query_sparql (internal endpoint) and explore_external_endpoint (structural overview).
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 explicitly provides a 'When to use this vs X' section with clear alternatives (query_sparql, explore_external_endpoint, recommend_external_endpoints, list_linked_endpoints) and a 'Do not use this if' section with specific conditions and correct tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Builds on annotations (readOnly, idempotent, non-destructive) by adding key behavioral facts: stores evicted after 1 hour, standard prefixes auto-injected, and alternative direct endpoint access. No contradiction 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?
Well-structured with clear sections (summary, workflow, when-to-use, alternatives, notes). Front-loaded with purpose. Slightly verbose due to workflow details that could be external, but every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very complete for a complex tool: explains prerequisite workflow, supported content types, eviction policy, and prefix injection. Lacks specification of the output format (e.g., SPARQL results JSON), but this is somewhat implied by the nature of a SPARQL query tool.
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 already has 100% description coverage for both parameters (id and query). The description adds context about where the id comes from (workflow step 3) and that query is a SPARQL SELECT, but does not add syntax or format details beyond the 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 it executes SPARQL SELECT queries against a temporary ontology store created via HTTP upload, specifying both the resource (temporary store) and action (querying). It distinguishes from siblings like query_local_ontology and query_sparql by emphasizing the upload workflow.
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 step-by-step workflow, conditions for when to use (HTTP mode only, remote server scenario), and clear alternatives (prefer query_local_ontology with upload_id). Also includes deprecation note guiding toward newer flows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, establishing a safe, idempotent, read-only operation. The description goes further by detailing the three-step workflow, explaining that categories are fetched dynamically, and noting that resources without Wikidata IDs cannot be cross-referenced. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings: 'How it works', 'Args', 'Returns', 'Available categories', and 'Use when'. It is concise yet complete, with no unnecessary sentences.
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 tool's moderate complexity, no output schema, and two parameters, the description fully covers the return structure (summary, covered, gaps, without_wikidata), explains the dynamic nature of categories, and provides usage context. It is adequately complete for an AI agent to invoke and interpret the result.
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?
Input schema covers both parameters with descriptions (100% coverage). The description adds value by explaining the 'limit' default (50), noting that 'category' comes from a dynamic list, and providing a 'Returns' section that clarifies the output structure. This exceeds what the schema alone provides.
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 'Gap analysis: compare schema.gov.it semantic resources against the international OKG catalog for a given domain.' This is a specific verb-resource combination that distinguishes the tool from siblings like 'check_coverage' or 'check_overlaps' by naming the external catalog.
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?
The 'Use when' section provides explicit guidance: 'Assessing which international standards are missing in schema.gov.it for a specific domain, or prioritizing new ontology and vocabulary contributions.' While clear, it does not mention when not to use this tool or suggest specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds context that the datasets are often semantic assets like ontologies and controlled vocabularies, which is a behavioral trait beyond annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, usage guidance, then clearly labeled Args and Returns sections. Every sentence serves a purpose, and the most important information (what the tool does) comes first.
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 tool is a simple list with 2 parameters, no output schema, and rich annotations, the description covers everything needed: it explains what the tool returns (items with labels and pagination metadata), how to use parameters, and even gives usage context. Nothing is missing for an agent to invoke it 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?
The input schema has 2 parameters (limit, offset) with no descriptions in the schema (0% coverage). The description compensates fully by providing explicit descriptions: 'Maximum datasets per page (default: 20)' and 'Number of datasets to skip (default: 0).' This adds significant meaning beyond the 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 'List available Datasets (dcatapit:Dataset) in the catalog.' It uses a specific verb ('List') and resource ('Datasets'), and distinguishes itself from siblings by noting that other tools (ontology/vocabulary/SPARQL) are usually better starting points, aligning with the context of the sibling tools list.
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 explicitly says 'Use this when you explicitly need DCAT-AP_IT dataset records.' It also provides guidance on when not to use it: 'so ontology/vocabulary/SPARQL tools are usually a better starting point.' This helps the agent decide between this tool and its numerous siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: prefix auto-injection, compressed JSON response format, unsupported hybrid mode. No contradiction 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?
Well-structured with sections (Args, Returns, Examples, guidance), but somewhat lengthy. Every sentence adds value, but could be more concise.
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 6 parameters, no output schema, and annotations, the description covers the tool comprehensively with examples, return format, and usage scenarios.
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%, but description adds context for parameters (grouping, default source, hybrid restriction) and includes examples. Could be slightly more detailed for source parameter.
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 it executes a RAW SPARQL query against schema.gov.it, and distinguishes from sibling tools by listing alternatives and disclaimers.
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 provides when-to-use and when-not-to-use guidance with specific alternative tools, making selection unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, non-destructive. Description adds behavioral details: input methods (file_path vs upload_id), limitations of file_path for remote servers, and return structure (matched, local_only, summary).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (args, important notes, returns, usage hint). It is concise yet thorough, front-loading the main purpose.
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 (4 params, no output schema, comparative logic), the description covers all necessary aspects: input, behavior, return values, and usage context. No gaps remain.
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%, but description adds value by explaining the requirement to provide exactly one of file_path or upload_id, defining the type enum, and detailing the limit parameter. This goes beyond the 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 it compares classes and/or properties from a local ontology against schema.gov.it, using specific verbs and resources. It distinguishes itself from siblings by focusing on alignment with schema.gov.it.
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 says when to use (starting to build an ontology) and provides alternatives (use get_upload_instructions + Bash if file is not on server). Also warns against incorrect usage of file_path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: mode differences, inheritance details, redundancy analysis, hybrid mode behavior, and what is not included (owl:equivalentProperty expansions).
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 clear sections (Args, Tip, mode details, interpretation, hybrid mode, when to use). It front-loads core information and each section earns its place, though could be slightly more concise.
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 tool's complexity (7 parameters, no output schema), the description is remarkably complete. It explains output interpretation, redundancy analysis, hybrid mode behavior, and limitations, leaving little ambiguity for an AI agent.
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?
The input schema has 100% description coverage. The description enriches each parameter with detailed explanations of enum values (e.g., mode 'raw' vs 'effective', source 'schema' vs 'local' vs 'hybrid') and the local context parameters, adding significant meaning beyond the 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 it retrieves comprehensive details of a specific property from schema.gov.it, with explicit raw vs effective views. It also distinguishes itself from sibling tools like inspect_local_property and query_sparql in the 'When to use this vs X' section.
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?
Includes a tip to use search_concepts first if the URI is unknown, and explicitly contrasts with inspect_local_property and query_sparql, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds caching by mtime, repeated calls skip re-parsing, and explains return structure, aligning with annotations without contradiction.
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 well-structured with sections and front-loaded purpose, but slightly lengthy due to multiple input workflows. Every sentence adds value, so still efficient.
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 tool complexity (multiple input modes, remote considerations, caching), the description covers all aspects: input selection, format, returns, efficiency. No output schema, but description sufficiently explains return structure.
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 descriptions cover all 4 parameters (100%), but the description adds crucial context: max size for content, workflow for upload_id, default format, and usage scenarios, going 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 explicitly states the tool loads and summarizes an RDF/OWL ontology from three sources (filesystem, inline content, upload). It uses specific verbs and resource, and the purpose is clearly differentiated from siblings like query_local_ontology or explore_ontology.
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 detailed guidance on when to use each input, with explicit workflow for remote servers (prefer upload_id, use get_upload_instructions). It warns against assumptions about file paths and inefficient token usage, making selection guidance exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and openWorldHint, already indicating safety. The description adds extensive behavioral details: how super-properties are resolved (local/remote/not-found), owl:imports handling, redundancy analysis, Unicode SPARQL note, and return structure. 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?
The description is long but well-structured with clear sections (critical workflow, input mode guidance, returns, etc.). It front-loads essential purpose and uses formatting (e.g., lists, bold) for clarity. Could be slightly more concise, but every section adds necessary detail.
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 tool's complexity and absence of an output schema, the description thoroughly covers return values, edge cases (file access failures, Unicode, remote resolution), and provides a complete semantic profile. It leaves no gaps for an AI agent to misinterpret.
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 description coverage is 100%, but the description adds significant context: explains when to use each parameter, the workflow for file_path failure, and the difference between file_path and upload_id. Also provides a tip for Unicode handling with the uri parameter.
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 'Get the full semantic profile of a property' and mentions resolving inherited domain/range, distinguishing it from siblings like get_property_details (for remote properties) and query_local_ontology (for custom SPARQL).
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 guidance, including a critical file access workflow with step-by-step instructions, alternatives for input modes, and comparisons to other tools like get_property_details and query_local_ontology. Also advises using search_concepts first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures include fuzzy search behavior, return format ('Matching subjects with type and label'), ranking with prefer_core, and default limit. Annotations (readOnlyHint, etc.) are consistent and description adds significant context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (description, args, returns, when to use). Every sentence provides value; no redundancy. Efficient length for a 6-parameter 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?
Given the tool's complexity and no output schema, the description covers return format, parameter usage, and when to use. It is complete for an agent to select and invoke 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 coverage is high (83%), and the description adds meaningful context: keyword example, limit default, resource_type options, ontology_filter example, prefer_core explanation, lang options. However, some parameter details are already in schema, so slightly above baseline.
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 'Fuzzy search for concepts/classes/properties by keyword', specifying the verb and resource. It distinguishes from sibling tools like search_in_vocabulary by explaining 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?
Explicitly states when to use this tool ('when you do not know the exact URI yet') and contrasts with alternatives (search_in_vocabulary, browse_vocabulary). Also advises using resource_type and ontology_filter to reduce noise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by detailing the exact behavior of each mode, including limitations of effective mode (owl:equivalentClass, owl:unionOf, owl:imports not expanded), hybrid mode details, and interpretation of own vs inherited properties. There is no contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, bullet points for args and mode details, and a concise 'When to use this vs X' section. Despite its length, every sentence provides necessary information, and the structure allows for easy scanning. It is front-loaded with the core purpose and immediately useful details.
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 of the tool (8 parameters, 3 enums, no output schema), the description covers all relevant aspects: parameter behavior, return structure (including differentiation of sections for each mode), limitations, and comparative guidance. The inclusion of interpretation details and performance notes ('All queries run in parallel') adds completeness.
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?
With 100% schema coverage, the description adds significant meaning beyond the schema by explaining the semantics of each parameter. For example, it elaborates on the 'mode' parameter ('raw' vs 'effective') with detailed sub-sections, explains how 'source' modes interact, and provides tips for interpreting 'own_properties' and 'inherited_properties'. The lang parameter is also clarified.
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 comprehensive profile of a concept from schema.gov.it, with explicit raw vs effective views.' It distinguishes between modes and explicitly contrasts with sibling tools like inspect_local_concept, describe_resource, and query_sparql in the 'When to use this vs X' section, ensuring the agent knows exactly what this tool does and how it differs.
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 guidance. It includes a dedicated 'When to use this vs X' section that compares with three sibling tools, stating clear conditions for each. Additionally, it gives a tip to use search_concepts first if the URI is unknown, providing practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dati-semantic-mcp MCP server](https://glama.ai/mcp/servers/italia/dati-semantic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/italia/dati-semantic-mcp)

Score Badge

Copy to your README.md:

[![dati-semantic-mcp MCP server](https://glama.ai/mcp/servers/italia/dati-semantic-mcp/badges/score.svg)](https://glama.ai/mcp/servers/italia/dati-semantic-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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