Skip to main content
Glama

dannet

by io.github.kuhumcst

Server Details

DanNet - Danish WordNet with rich lexical relationships and SPARQL access.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
kuhumcst/DanNet
GitHub Stars
24

Available Tools

6 tools
autocomplete_danish_wordAInspect

Danish words starting with prefix (at least 3 characters), at most max_results, as {"autocompletions": [...]} where lemmas are plain strings and inflected forms of a matching lemma are [lemma, form] pairs.

ParametersJSON Schema
NameRequiredDescriptionDefault
prefixYes
max_resultsNo

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It successfully discloses the return format ({"autocompletions": [...]}) and the distinction between plain-string lemmas and [lemma, form] pairs, which is valuable. But it omits edge-case behavior such as what happens with prefixes shorter than 3 characters, empty results, or case sensitivity.

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 compact and every sentence earns its place, covering function, constraints, and return shape in a single dense block. It is not overly verbose, though the compressed inline JSON format could be slightly more readable with clearer separation of ideas.

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 two-parameter tool with no output schema and no annotations, the description covers the core essentials: what it does, parameter meanings, result format, and lemma/form data structure. It is missing usage guidance and boundary-condition behavior (e.g., invalid prefix length), which leaves some gaps for an agent deciding how to call it correctly in unusual cases.

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, and it does. It clarifies that 'prefix' is the starting substring (with a minimum length of 3 characters) and that 'max_results' caps the output size. It adds meaningful semantic weight to both parameters, though it does not specify whether counts include inflected forms.

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 a specific verb and resource: returning Danish words starting with a given prefix, with a clear condition ('at least 3 characters') and an explicit result-shape definition. Its focus on prefix-based autocompletion and lemma/form pairs clearly distinguishes it from siblings that fetch definitions, entity info, word overviews, and synsets.

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 use case (autocompletion for Danish words starting with a prefix) is clearly implied, and the sibling names suggest it is the right choice for prefix-based lookups rather than exact definitions or entity queries. However, the description provides no explicit guidance on when to prefer this tool over 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.

fetch_ddo_definitionAInspect

The full definitions of synset_id from DDO (ordnet.dk), where DanNet's own skos:definition may be truncated. Follows the dns:source of each sense. Returns the DanNet definition, the DDO definitions found and any errors; DDO and DanNet have drifted apart, so some source URLs no longer resolve.

ParametersJSON Schema
NameRequiredDescriptionDefault
synset_idYes

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states that the tool returns the DanNet definition, found DDO definitions, and any errors. It also discloses that DDO and DanNet have drifted apart and some source URLs no longer resolve, providing valuable context about potential failures.

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 composed of three sentences, each with a clear purpose: stating what it does, how it works, and what it returns. It also includes a warning about potential link rot. Every sentence adds value, and the structure is 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?

For a single-parameter tool with no output schema, the description covers the essential elements: purpose, return structure, and potential errors. The only notable omission is a more explicit explanation of the synset_id parameter format. Given the tool's simplicity, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, leaving the description to explain what synset_id means. However, the description merely mentions synset_id without defining its format, origin, or providing examples. The term 'synset_id' is used as if the reader already understands it, which may not be safe for an AI agent unfamiliar with the domain.

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 that the tool fetches full DDO definitions for a given synset_id, and distinguishes it from truncated DanNet definitions. It also mentions the mechanism of following dns:source. This provides a specific and unambiguous purpose that differentiates it from general lookup tools.

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 when to use this tool: when DanNet's own definition may be truncated and the full DDO definition is needed. However, it does not explicitly mention alternatives or when not to use it. The guidance is implicit rather than explicit.

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

get_entity_infoAInspect

Full JSON-LD of a DanNet resource: a synset ("synset-3047"), word ("word-11021628") or sense ("sense-21033604"), given bare or prefixed ("dn:synset-3047"), or an external resource by prefix ("ili:i76470", "ontolex:LexicalConcept"). Properties use prefixed names (wn:hypernym, ontolex:isEvokedBy, ...); language-tagged values are {"@value": ..., "@language": ...}.

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosing behavior. It explains the return format (JSON-LD), use of prefixed property names, and structure of language-tagged values, which is more than a typical fetch tool. It does not mention error handling or what happens for unknown identifiers, but the detailed response format is helpful enough to merit a 4.

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 dense but well-structured, starting with the core outcome (Full JSON-LD) and then enumerating supported identifier formats and response style. Every sentence adds necessary information; examples are illustrative without fluff. It is appropriately concise for a one-parameter lookup 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?

The tool has one parameter, no output schema, and no annotations. The description nonetheless covers the input space thoroughly and explains the output format, property naming, and language-tagged encoding. This is sufficient for an agent to construct a valid call and interpret the result. Even without explicit error semantics, the description is complete for the tool's simple purpose.

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 0% and the only parameter 'identifier' has no schema description. The tool description fully compensates by providing concrete examples of valid values ('synset-3047', 'word-11021628', 'dn:synset-3047', 'ili:i76470') and accepted forms (bare, prefixed, external). This leaves no ambiguity about what to put in the identifier field.

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 that the tool returns 'Full JSON-LD of a DanNet resource', listing the exact entity types (synset, word, sense) and external resources by prefix. This makes it distinct from sibling tools like get_word_overview or get_word_synsets, which focus on summaries or synsets; an agent can immediately tell it is the raw generic lookup.

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 instructions on what identifiers to pass, including bare, prefixed, and external forms. It implies the tool is for fetching complete resource data, but it does not explicitly contrast it with alternatives or say when not to use it. This is clear context without exclusions, fitting a 4.

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

get_word_overviewAInspect

Every sense of the Danish word in one call: a list with synset_id, label, definition, lexfile, ontological_types, synonyms (words sharing the synset) and hypernym ({synset_id, label} or null) per synset. Only synsets where the word itself has a sense count, not multi-word expressions containing it.

ParametersJSON Schema
NameRequiredDescriptionDefault
wordYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It does reveal a non-obvious behavior: it excludes multi-word expressions and only includes synsets where the word itself has a sense count. However, it does not mention whether the operation is read-only, potential empty results, or any error conditions. This is adequate but not thorough.

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 dense but every sentence contributes valuable detail. It front-loads the core purpose and return structure, then adds the important filtering rule. No filler or repetition.

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 single-parameter read-like tool with an output schema present, the description gives enough detail about the return payload and scoping for an agent to make a correct call. It lacks usage-context guidance and explicit read-only clarity, but these are partially covered by the detailed return structure and the lack of side-effect verbs.

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 schema has 0% coverage, but the description clarifies that the single parameter `word` is a Danish word, and implies it should be a lemma for which sense information is requested. This adds meaning beyond the bare schema field name 'Word', although it could be more explicit about expected format (e.g., inflected vs. base form).

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 a specific verb ('get'), a precise resource (word overview), and enumerates the exact contents per synset (synset_id, label, definition, lexfile, ontological_types, synonyms, hypernym). It also clarifies a key scoping rule (only synsets where the word itself has a sense count), which makes the tool's purpose distinct from simply listing synsets.

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?

There is no mention of when to use this tool versus its siblings such as get_word_synsets or fetch_ddo_definition. The description explains what the tool returns but does not guide the agent on selecting it over alternatives or provide exclusions.

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

get_word_synsetsAInspect

The synsets (senses) of the Danish word, as JSON-LD entries with @id (e.g. "dn:synset-3047" for get_entity_info), skos:definition, dns:ontologicalType and wn:lexfile. A word with a single synset gives that synset's full JSON-LD as the only entry.

ParametersJSON Schema
NameRequiredDescriptionDefault
wordYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

The description discloses the structure of the response (JSON-LD entries, listed fields) and adds an edge-case note for words with a single synset, which helps parsing. However, with no annotations at all, it does not address what happens for unknown words, whether the lookup is restricted to dictionary headwords, or any access/error behaviors. As a non-mutating getter, side-effect disclosure is less critical, but the behavioral coverage is only partial.

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 relatively compact and front-loaded: the main resource and format appear in the first sentence, and the second sentence handles a specific edge case. All content is informative and no filler is present. The parenthetical referencing get_entity_info adds clarity about the @id format without being redundant.

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 presence of an output schema and only one required input, the description provides most of what an agent needs to call the tool correctly: it names the input as a Danish word, explains that the output is a set of JSON-LD synset entries, and notes the single-synset behavior. It does not cover not-found results or error cases, but these are minor for a simple lookup and may be reflected in the output schema. Overall it is reasonably 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?

With 0% schema description coverage for the only parameter, the description adds crucial meaning by specifying that `word` is Danish and provides synsets for that word. It connects the parameter to the output format. It does not specify input form (lemma vs. inflected), but for a single string parameter in this domain the semantic constraint is substantial.

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 states what the tool returns – the synsets (senses) of a given Danish word – and outlines the serialization format (JSON-LD with @id, skos:definition, etc.). Although there is no explicit verb, the `get_` prefix and the resource-focused noun phrase make the purpose unambiguous. It is distinct from siblings like fetch_ddo_definition or get_word_overview because it specifically covers synsets, not definitions or overviews.

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?

No guidance is given about when to prefer this tool over the sibling tools. There is no mention of alternative tools for definitions, entity info, or overviews, nor any conditions/exclusions under which get_word_synsets should not be used. The only usage signal is the inherent semantics – when a user needs synsets for a Danish word – but this is implied rather than explicitly stated.

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

sparql_queryAInspect

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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
timeoutNo
distinctNo
inferenceNo
max_resultsNo

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedget_word_synsets1 field changed
      • removedInput schema / properties / language
        Removed value: -{
-  "default": "da",
-  "title": "Language",
-  "type": "string"
-}
  2. 15 tool updates
    • Removedanalyze_namespace_usage
    • Changedautocomplete_danish_word1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "autocomplete_danish_wordOutput",
-  "type": "object"
-}New value: +null
    • Removedextract_semantic_data
    • Changedfetch_ddo_definition1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "fetch_ddo_definitionOutput",
-  "type": "object"
-}New value: +null
    • Removedget_cache_stats
    • Removedget_current_dannet_server
    • Changedget_entity_info2 fields changed
      • removedInput schema / properties / namespace
        Removed value: -{
-  "default": "dn",
-  "title": "Namespace",
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_entity_infoOutput",
-  "type": "object"
-}New value: +null
    • Removedget_sense_info
    • Removedget_synset_info
    • Removedget_word_info
    • Removedget_word_synonyms
    • Changedget_word_synsets7 fields changed
      • removedInput schema / properties / query
        Removed value: -{
-  "title": "Query",
-  "type": "string"
-}
      • addedInput schema / properties / word
        Added value: +{
+  "title": "Word",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "query"
-]New value: +[
+  "word"
+]
      • removedOutput schema / $defs
        Removed value: -{
-  "SearchResult": {
-    "description": "Search result from DanNet",
-    "properties": {
-      "definition": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "description": "Definition",
-        "title": "Definition"
-      },
-      "label": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "description": "Synset label",
-        "title": "Label"
-      },
-      "synset_id": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "description": "Associated synset ID",
-        "title": "Synset Id"
-      },
-      "word": {
-        "description": "The word form",
-        "title": "Word",
-        "type": "string"
-      }
-    },
-    "required": [
-      "word",
-      "synset_id",
-      "label",
-      "definition"
-    ],
-    "title": "SearchResult",
-    "type": "object"
-  }
-}
      • removedOutput schema / properties / result / anyOf
        Removed value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/SearchResult"
-    },
-    "type": "array"
-  },
-  {
-    "additionalProperties": true,
-    "type": "object"
-  }
-]
      • addedOutput schema / properties / result / items
        Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
      • addedOutput schema / properties / result / type
        Added value: +"array"
    • Changedsparql_query1 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
    • Removedswitch_dannet_server
    • Removedvalidate_synset_structure
  3. 3 tool updates
    • Addedget_cache_stats
    • Addedget_word_overview
    • Changedsparql_query3 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
  4. 14 tool updates
    • First observedanalyze_namespace_usage
    • First observedautocomplete_danish_word
    • First observedextract_semantic_data
    • First observedfetch_ddo_definition
    • First observedget_current_dannet_server
    • First observedget_entity_info
    • First observedget_sense_info
    • First observedget_synset_info
    • First observedget_word_info
    • First observedget_word_synonyms
    • First observedget_word_synsets
    • First observedsparql_query
    • First observedswitch_dannet_server
    • First observedvalidate_synset_structure

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • ConceptNet MCP Server

    infinitnet
    A
    license
    A
    quality
    D
    maintenance
    Provides seamless access to the ConceptNet semantic knowledge graph, enabling concept lookup, search, relationship discovery, and semantic similarity calculations across multiple languages.
    4
    2
    GPL 3.0

  • phenoforge

    colbyw5
    A
    license
    A
    quality
    B
    maintenance
    Enables semantic retrieval and assembly of ICD-10-CM value sets from natural language descriptions for clinical cohort definitions.
    4
    Apache 2.0

  • Bareun (바른) — Korean NLP &

    gih2yun
    A
    license
    Not graded
    quality
    C
    maintenance
    Bareun (바른) is a Korean natural-language engine. This MCP server lets any MCP-compatible client hand Korean text to a dedicated Korean engine instead of guessing: analyze_syntax (morphological analysis with 47 POS tags and beta homograph sense disambiguation), analyze_syntax_raw (raw model output), tokenize, correct_grammar (spelling and spacing correction), and list_pos_tags. Hosted at https://ap
    MIT
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