norse
Server Details
Grounds LLMs in real Old Norse: lemmas, mediopassive paradigms, English→Old Norse lookup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 5/5 across 2 of 2 tools scored.
norse_search and norse_get_inflections have clearly distinct purposes: search for initial lookup (including optional English queries), get_inflections for fetching detailed inflection tables when search didn't provide them inline. No overlap.
Both tools follow a consistent verb_noun pattern with the 'norse_' prefix, using lowercase and underscores. 'search' is a single word verb, 'get_inflections' is verb+noun, but the pattern is uniform and predictable.
Two tools is minimal but justifiable for a focused domain: search covers primary lookup, get_inflections handles edge cases. However, the surface feels thin, and a single tool could arguably cover the use case.
The tools cover word search and inflection retrieval adequately. A minor gap is that get_inflections is somewhat redundant since search already returns tables, but it serves as a fallback. Missing features like etymology or word lists are not core to the stated purpose.
Available Tools
2 toolsnorse_get_inflectionsGet an Old Norse inflection tableARead-onlyIdempotentInspect
Fetch the full declension (nominals) or conjugation (verbs — active AND mediopassive) tables for a lemma identified by a search result's inflection handle (entry_id + word_class). Use this only when a search ran without inline forms or left a match un-expanded — a default search already returns each match's table inline. Returns Markdown plus the table as structuredContent with the shape {"result": } per the declared outputSchema — switch on result.category ('nominal' | 'verbal' | 'not_found') before reading the body. Content from en.wiktionary.org (CC BY-SA 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | The Wiktionary page title (the lemma) from a search result's inflection handle, e.g. 'maðr', 'kasta'. | |
| word_class | Yes | The part-of-speech section from a search result's inflection handle, e.g. 'verb', 'noun', 'adjective'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns Markdown plus structuredContent with shape per outputSchema, instructs to switch on result.category, and notes content license. No contradictions.
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?
Description is concise at three sentences, front-loaded with purpose, then usage condition, then output details. Every sentence earns its place.
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?
Given schema coverage 100%, output schema present, and clear context from sibling tools, the description fully covers what agent needs: when to use, what parameters, what output shape, and how to handle results.
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 covers both parameters with descriptions and constraints. Description adds concrete examples ('e.g. 'maðr', 'kasta'' and 'e.g. 'verb', 'noun', 'adjective'') which adds value beyond schema.
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 it fetches declension or conjugation tables for a lemma identified by entry_id and word_class, and distinguishes from sibling norse_search by specifying when to use this tool.
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?
Explicitly states 'Use this only when a search ran without inline forms or left a match un-expanded' and notes that default search returns tables inline, providing clear guidance on when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
norse_searchLook an Old Norse word upARead-onlyIdempotentInspect
Look an Old Norse word up on Wiktionary and return its senses plus full declension/conjugation tables — attested content (including the verbs' mediopassive voice), not invented. Any form of the word works; an inflected query is resolved to its lemma automatically via previously cached paradigms and the result notes the resolution. With search_language='eng' the query is an English word instead: the result lists its per-sense Old Norse equivalents (the translations block) plus their expanded entries. Returns Markdown plus the same result as structuredContent matching the declared outputSchema.
Results are cached server-side; first-time queries reach the live upstream politely and calls are rate limited — on a rate-limit error, wait a few seconds and retry. Content is from en.wiktionary.org (CC BY-SA 4.0 — attribute and share alike if republished).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The word to look up, in the language search_language names. Old Norse (default): a SINGLE Old Norse word, any form — an inflected form ('mǫnnum') is resolved to its lemma ('maðr') automatically via cached paradigms, and the result says so; diacritics are optional once a paradigm is cached ('madr' and 'mathr' both find maðr, 'monnum' finds mǫnnum). English (search_language='eng'): the English word whose Old Norse equivalents you want — multiword entries like 'apple tree' work. | |
| max_forms | No | Optional override for how many inflection tables to expand this call (0–12). On an uncached query each table is one politely paced upstream fetch, so high values on cold queries are slow. Omit for the server default. | |
| include_forms | No | When true (default), each match's full declension/conjugation table is returned INLINE — usable cases/tenses (and the verbs' mediopassive voice) in ONE call, no follow-up norse_get_inflections. Set false for a cheap screen of which entries exist. Bounded by a per-search cap — use max_forms to adjust per call. For eng queries this governs the expanded Old Norse entries; the per-sense translations list itself is always returned. | |
| search_language | No | Language the query word is in: 'non' (default) looks the Old Norse word up directly; 'eng' finds the Old Norse equivalents of an English word (per-sense, from Wiktionary's translation tables) and returns their full entries. Glosses are in English either way. | non |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | False when nothing matched. For an eng query, True means Old Norse translations were found — entries may still be empty when none of them could be expanded (see translations). |
| query | Yes | |
| source | No | |
| entries | No | |
| handles | No | |
| language | Yes | |
| translations | No | Populated only for eng queries (always [] for non): the Old Norse terms each English sense translates to, in sense order. Entries/handles below are the expanded dictionary entries of those terms. |
| resolved_from | No | The original inflected query when resolved; else empty. non queries only — always empty for eng results. |
| search_method | No | How the match was found: 'direct' = the query itself matched; 'lemma_index' = an inflected form resolved via a previously cached paradigm; 'translations' = an English query resolved via Wiktionary translation tables. |
| resolved_lemma | No | The lemma actually searched when resolved; else empty. non queries only — always empty for eng results. |
| forms_truncated | No | How many handles did NOT get an inline table because the per-search cap was reached. |
| translations_truncated | No | How many distinct translated lemmas were NOT expanded into entries because the per-search expansion cap was reached (they still appear under translations). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses caching behavior, rate limiting, upstream politeness, and attribution requirements, going beyond the annotations which already indicate read-only, idempotent, and non-destructive behavior. It also explains how inflected forms are resolved and notes the content license.
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 well-structured, starting with the core purpose, then detailing parameter behavior, caching, and attribution. Every sentence adds unique value, and the information is efficiently presented without redundancy.
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?
Given the tool's complexity with 4 parameters and an output schema, the description covers all aspects: purpose, usage modes, parameter details, caching, rate limiting, output format, and legal attribution. It fully equips the agent to use the tool correctly.
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 description coverage is 100%, but the description adds significant value by providing usage examples (e.g., resolving 'mǫnnum' to 'maðr'), performance implications for max_forms, relationship to the sibling tool for include_forms, and clear explanation of the search_language enum values.
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 it looks up Old Norse words on Wiktionary, returning senses and full declension/conjugation tables. It distinguishes between direct Old Norse lookup and English reverse lookup, and explicitly mentions that it subsumes the functionality of the sibling tool norse_get_inflections by returning full tables inline.
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 explicit guidance on when to use this tool versus the sibling norse_get_inflections, stating that full tables are returned in one call so no follow-up is needed. It also explains the use of the include_forms parameter for a cheaper screen, and the search_language parameter for English reverse lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!