Is Dannet MCP server safe?
Yes, with the usual care.
Safe to use. Minor gaps such as a missing repository or slower maintenance.
What to know before installing
- highWrite-action tools reachable without authentication
How Dannet compares
Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.
- Safety score
- 80/100
- higher than 60% of 48,255 servers
- Tools that change things
- 17%
- typical: 0%. Fewer write tools means less an agent can break
- Uptime
- 100%
- of our recent checks; the typical remote server answers 100%
What its tools let an agent do: 5 read · 1 change
Public scan report
scanner v0.1.10 · 2026-10-01 · same rubric, same numbers if you re-run it
1 high1 low
- –Code scanremote-only server, no package to scann/a
- Live reliabilityremote reachable in 1636ms20/20
- Tool poisoning6 tool descriptions checked13/15
- Auth qualityopen endpoint exposes 1 write-action tools with no auth3/15
- Maintenancelast push 0 days ago15/15
- Maintainer identityregistry namespace matches repository owner; GitHub account older than a year9/10
Findings (2)
- highWrite-action tools reachable without authentication
auth.open-write - lowUnusually long tool description (over 2,000 characters)
poison.long-descriptiontool 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…
Overall 80/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON