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.
| Name | Required | Description | Default |
|---|---|---|---|
| synset_id | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "additionalProperties": true,
- "title": "Result",
- "type": "object"
- }
- },
- "required": [
- "result"
- ],
- "title": "fetch_ddo_definitionOutput",
- "type": "object"
-}New value: +nullDoes 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.
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.
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.
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.
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.
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.
Add one secure layer between your agents and this server.
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.
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.
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.
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.