Skip to main content
Glama

dannet

by io.github.kuhumcst

sparql_query

Run a SPARQL SELECT query against DanNet and return standard SPARQL JSON results ({"head": ..., "results": {"bindings": [...]}}). The common prefixes (dn, dns, dnc, dnf, wn, ontolex, lexinfo, skos, rdfs, rdf, owl, marl, dc, ili, en, enl, cor) are declared automatically. timeout is in ms (max 15000), max_results at most 100, distinct adds DISTINCT, and inference selects the model: None tries the base model and retries with inference on an empty result; True forces inference, which inverse relations like wn:hyponym and wn:holo_* need; False forces the base model.

Performance rules: anchor every query on a known URI or a word lookup (dn:synset-3047 wn:hypernym ?x, never ?x wn:hypernym ?y alone); never FILTER(CONTAINS(...)) over all labels, look the word up first; make every triple pattern share a variable with another; add LIMIT; prefer VALUES over FILTER for several known URIs; the store also holds the English WordNet (en:), so anchor on dn: or "..."@da to stay in Danish.

Templates: Synsets of a word: SELECT DISTINCT ?synset ?label WHERE { ?entry ontolex:canonicalForm/ontolex:writtenRep "hund"@da . ?entry ontolex:sense/ontolex:isLexicalizedSenseOf ?synset . ?synset rdfs:label ?label } Taxonomic ancestors: SELECT DISTINCT ?ancestor ?label WHERE { dn:synset-3047 wn:hypernym+ ?ancestor . ?ancestor rdfs:label ?label } Hyponyms (needs inference=True, or query the inverse wn:hypernym): SELECT DISTINCT ?hyponym ?label WHERE { ?hyponym wn:hypernym dn:synset-3047 . ?hyponym rdfs:label ?label } Ontological types (an RDF bag): SELECT ?type WHERE { dn:synset-3047 dns:ontologicalType/?pos ?type . FILTER(STRSTARTS(STR(?pos), STR(rdf:_))) } Taxonomic similarity (dnf:path, dnf:lch, dnf:wup score two synsets of the same language and part of speech, 1.0 for identical): SELECT ?synset ?score WHERE { ?synset a ontolex:LexicalConcept . FILTER(STRSTARTS(STR(?synset), STR(dn:))) BIND(dnf:wup(dn:synset-3047, ?synset) AS ?score) } ORDER BY DESC(?score) LIMIT 20

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
timeoutNo
distinctNo
inferenceNo
max_resultsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "sparql_queryOutput",
-  "type": "object"
-}New value: +null
  2. Changed3 schema fields changed
    • addedInput schema / properties / distinct
      Added value: +{
+  "default": true,
+  "title": "Distinct",
+  "type": "boolean"
+}
    • addedInput schema / properties / inference
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Inference"
+}
    • changedInput schema / properties / timeout / default
      Previous value: -5000New value: +8000
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the return format, automatic prefix declaration, timeout and max_results limits, the exact inference modes including the None retry behavior, and the reliance on inference for inverse relations. It also reveals the store's contents including English WordNet and gives practical performance caveats.

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?

Although long, the description is densely packed and well-structured with clear sections: execution semantics, parameter constraints, performance rules, and ready-to-use templates. Every sentence adds operational value, and the templates are directly actionable for an agent constructing queries.

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 has no output schema and no annotations, but the description covers the return format, all parameter semantics, inference behavior, prefix setup, performance constraints, and even provides templates for common query archetypes. Nothing required to call the tool correctly is missing.

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 0%, and the description fully compensates. It explains query, timeout in ms with a 15000 max, max_results cap at 100, distinct behavior, and the three inference modes (None, True, False) with concrete retry semantics. This is far beyond what the bare input schema offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair — 'Run a SPARQL SELECT query against DanNet' — and specifies the exact return format as standard SPARQL JSON. This clearly distinguishes it from sibling tools like get_word_synsets or autocomplete_danish_word, which serve simpler lookup purposes.

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 gives clear context that this is the raw SPARQL endpoint for DanNet and provides detailed performance rules, such as anchoring queries on known URIs and adding LIMIT. It does not explicitly mention when to prefer sibling tools, so it stops short of explicit alternatives, but the context is strong enough for an agent to infer when this tool is appropriate.

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

All dannet toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation3/5

Most tools are clearly distinct, but get_word_overview and get_word_synsets both retrieve senses for a given word, overlapping in purpose. Their descriptions clarify different output structures (custom summary vs. JSON-LD), but an agent could still be uncertain which to use for a given task.

Naming Consistency4/5

Five of six tools follow a verb_noun pattern (autocomplete_danish_word, get_entity_info, get_word_overview, get_word_synsets, fetch_ddo_definition), and the shared 'get_word_' prefix for the overlapping tools is helpful. The exception is sparql_query, which is a noun phrase rather than a verb-led name, creating a minor inconsistency.

Tool Count5/5

With six tools, the server is well-scoped for a wordnet/RDF resource. Each tool addresses a distinct need: prefix search, entity lookup by ID, word sense summaries, JSON-LD retrieval, external definitions, and arbitrary SPARQL queries. No tool feels redundant at a count level, even though two serve similar word sense retrieval.

Completeness5/5

The tool set covers the core use cases for a Danish wordnet: autocomplete, word sense lookup, detailed entity retrieval, external dictionary definitions, and flexible SPARQL querying. The SPARQL tool allows arbitrary queries, making the surface effectively exhaustive for read-only access. No obvious dead ends or missing lifecycle operations are apparent.

Resources