Read-only Old English (Anglo-Saxon) dictionary over MCP: headword lookup with senses, etymology and inflections; full declension and conjugation tables; inflected-form identification; Modern English to Old English reverse lookup; and Beowulf citations with line numbers.
Scored across 5 tools
Each tool has a clearly different input and output: headword lookup, modern-English reverse lookup, inflected-form analysis, full inflection tables, and Bēowulf line retrieval. The only slight overlap is that lookup_headword mentions declension/verb class while inflect returns the full table, but the descriptions make the boundary clear.
The names mix conventions: identify_form and lookup_headword are verb_noun, inflect is a bare verb, beowulf_occurrences is noun-based, and english_to_old_english is a descriptive phrase. They remain readable, but there is no predictable pattern across the set.
Five tools is well-scoped for an Old English dictionary and corpus helper. Each tool serves a distinct lexical or morphological need without obvious redundancy.
The surface covers the core workflows: headword lookup, reverse lookup from modern English, inflection generation, form identification, and Bēowulf citations. Minor gaps remain, such as browsing or listing headwords and broader dictionary/text search beyond a single modern-English query.
Given an Old English headword, return every line of Bēowulf that carries it: the line numbers, the line text, the spellings used, and a link to the poem line on eldertongue.com.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Old English headword to locate in Bēowulf (e.g. cyning, hilde). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does useful work by enumerating the return fields (line numbers, line text, spellings, permalink) and implying variant spellings are matched, but it says nothing about no-match behavior, ordering, or access constraints for a tool with zero annotation coverage.
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?
One sentence, front-loaded with the input then the output contract via a colon list. Every clause adds information; no filler.
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 simple read-only, one-parameter lookup with no output schema, the description supplies the missing return shape and the external link source. Only the no-results case and matching rules remain undocumented, which is a minor but real 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?
Schema coverage is 100% and the single parameter already documents 'Old English headword to locate in Bēowulf' with an example. The description's phrase 'Old English headword' merely restates that, adding no format or scoping detail beyond the 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 names a specific verb and resource: return every line of Bēowulf carrying a given Old English headword. That is unambiguous and clearly distinct in subject matter from the morphological siblings (inflect, identify_form), though it never names an alternative to route against.
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?
Saying 'Given an Old English headword' implies a prerequisite (the input must be a headword, not an inflected form) but stops short of telling the agent to use identify_form or lookup_headword first. No when-not conditions or explicit alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a modern English word (e.g. king, ship, write), list Old English headwords whose definitions mention it, with a score, part of speech, gloss, and the eldertongue.com page URL for each.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Modern English word to translate back into Old English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that the output is a list of candidate headwords, not a single translation, and enumerates the returned fields (score, part of speech, gloss, URL). It does not mention result limits, scoring semantics, or empty-result behavior, which keeps it short of a 5.
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?
A single front-loaded sentence that covers input, matching rule, and return fields with no filler. Nothing could be removed without losing information.
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?
There is no output schema, and the description compensates by naming the returned fields and the page URL, which is exactly what an agent needs to interpret results. Minor gaps remain around ranking semantics and result size limits for what is likely a fuzzy search.
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?
Only one parameter and the schema already documents it at 100% coverage, so the baseline is 3-4. The description adds value with concrete examples (king, ship, write) that clarify the expected input domain better than the schema's lone 'cyning' example, which is arguably an Old English rather than modern English form.
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?
States a specific verb and resource: list Old English headwords whose definitions mention a given modern English word, and it clarifies the matching mechanism (definition mention, not direct translation). It distinguishes itself in spirit from lookup_headword by describing the reverse lookup direction, but never names that sibling explicitly.
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?
Usage is implied by 'Given a modern English word...' and the input examples, so an agent can infer the call pattern. However, there is no explicit guidance on when to prefer this over lookup_headword or identify_form, and no note that results are ranked candidates needing disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given any inflected form (e.g. cyninges, band, gōdra), return the headwords it could belong to and the grammatical reading (case, number, gender, person, tense, mood…) of each.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Inflected Old English form to analyse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does disclose the return content (headwords plus grammatical reading across case, number, gender, person, tense, mood) and hints at ambiguity via "could belong to", but it says nothing about behavior when no analysis is found, how candidates are ordered, or handling of macrons versus plain vowels.
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?
A single sentence with the input condition front-loaded and examples embedded inline; nothing is redundant or padded.
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?
With no output schema, the description wisely summarizes the return payload, which is the most important missing piece. Gaps remain around no-match behavior and output shape, but for a one-parameter read-only analysis tool it is largely sufficient.
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 100% for the single parameter, so the baseline is 3. The description adds some value through extra examples ("band", "gōdra") implying macronized input is accepted and that forms may coincide with modern English words, but it offers no syntax or normalization details beyond the 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 states a specific operation on a specific resource: take an inflected Old English form and return candidate headwords plus a grammatical reading. It is immediately distinguishable in practice from lookup_headword and inflect, but it never names those siblings, so the differentiation is left to inference.
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?
"Given any inflected form" sets an implicit input precondition and the examples clarify the expected shape of the input. There is no explicit statement of when to prefer this over lookup_headword or inflect, nor any exclusion for non-Old-English or already-lemmatized input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full declension (nouns/adjectives) or conjugation (verbs) table for an Old English headword. Every word form carries an anchor URL into the eldertongue.com entry page.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Old English headword whose paradigm to show (e.g. cyning, gōd, bindan). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose something genuinely useful beyond the name: the result is a complete table and every form carries an anchor URL into the eldertongue.com entry page. It omits error behavior for a headword with no paradigm (e.g. an already-inflected form passed by mistake) and says nothing about whether macrons/diacritics must match.
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?
Two sentences, no filler: the capability is front-loaded and the output detail follows. Every clause carries information about either what is returned or what the return values contain.
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?
This is a simple single-parameter lookup with no output schema, and the description adequately covers both the input expectation (headword) and the shape of the result (full paradigm table with per-form anchors). Only the failure mode for an unrecognized headword is left unaddressed.
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 100% and the single parameter is documented with examples (cyning, gōd, bindan), so the baseline is 3. The description reinforces that the argument is a "headword" rather than an arbitrary inflected form, which is a small but real addition over the schema text.
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?
"Return the full declension (nouns/adjectives) or conjugation (verbs) table for an Old English headword" gives a concrete verb (return a table), a specific resource (inflectional paradigm), and names the word classes covered. It distinguishes itself in kind from lookup_headword or identify_form, though it never names those siblings explicitly.
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?
There is no explicit when-to-use or when-not-to-use guidance, and none of the four siblings are referenced. The agent must infer from the word "full ... table" that this is for paradigms rather than definitions (lookup_headword) or reverse analysis of an inflected form (identify_form).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an Old English headword (macrons optional) in the eldertongue dictionary. Returns senses, IPA, syllables, part of speech, gender, noun declension / verb class, etymology, and the eldertongue.com page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Old English headword, macrons optional (e.g. cyning, cyninges, scieppan). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does well on output disclosure by enumerating senses, IPA, syllables, POS, gender, declension/verb class, etymology, and the source page URL, but says nothing about what happens when a word is not found, whether the lookup is exact-match only, or whether results are cached or rate-limited.
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?
Two sentences, front-loaded with the core action and immediately followed by the return payload. There is no filler and the parenthetical constraint sits right where the parameter first appears.
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?
With no output schema and no annotations, the description is the sole carrier of return-value information, and it enumerates the response fields thoroughly for a one-parameter read tool. The only real gap is failure/empty-result behavior, which is minor for a simple lookup.
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 100% and the single parameter is already documented with examples and the macrons-optional note, which the description merely restates. Baseline 3 applies since the schema does the heavy lifting and the description adds no new meaning about the word parameter.
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?
States a specific verb ('look up') and resource ('Old English headword') plus the source dictionary, so the agent knows this is a dictionary entry lookup rather than a morphological operation. It does not name the sibling tools it differs from (identify_form, inflect, english_to_old_english), so the distinction is implied by 'headword' rather than made explicit.
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?
No explicit when-to-use or when-not-to-use guidance, and no mention of alternatives. The parenthetical 'macrons optional' gives a small practical cue, but the agent must infer that this tool is for whole-lexeme lookup while inflect/identify_form handle form-level analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
beowulf_occurrencesenglish_to_old_englishidentify_forminflectlookup_headwordBible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Grounds LLMs in real Old Norse: lemmas, mediopassive paradigms, English→Old Norse lookup.
Dictionary MCP — wraps Free Dictionary API (free, no auth)
Wiktionary MCP — multilingual dictionary via Wikimedia REST + MediaWiki Action API
Add one secure layer between your agents and this server.