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": ...}.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / namespaceRemoved value: -{
- "default": "dn",
- "title": "Namespace",
- "type": "string"
-}Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "additionalProperties": true,
- "title": "Result",
- "type": "object"
- }
- },
- "required": [
- "result"
- ],
- "title": "get_entity_infoOutput",
- "type": "object"
-}New value: +nullDoes 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.
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.
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.
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.
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.
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.
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.