Skip to main content
Glama

Look up a word

lookup_word

The immit dictionary entry for one English or Japanese word: its senses with definitions, translations and example sentence pairs, every inflected form as a row with its reading, the pronunciations with IPA for English or the kana reading and pitch accent for Japanese and a playable MP3 URL for each, the frequency rank, synonyms and antonyms, and alternative spellings. Call it rather than answering from memory whenever the question is about pitch accent, a reading, an inflection table, how a word sounds, an example sentence, how common a word is, or an exact definition: those are the facts a model guesses wrong. text is the dictionary form (食べる, not 食べた; eat, not eating); a case variant or an alternative spelling resolves to its entry, an inflected form does not, so take the dictionary form or use search_words, which matches inflected forms. The result is the entry JSON that the immit://entry-shape resource describes field by field.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lang": "<lang>",
      "text": "<text>"
    },
    "name": "lookup_word"
  }
}

Input Schema

NameRequiredDescriptionDefault
langYesThe language of the word: eng for English, jpn for Japanese
textYesThe word in its dictionary form, or an alternative spelling of it; matched exactly, then case-folded

Output Schema

NameRequiredDescriptionDefault
idYes
langYes
sensesYes
headwordYesThe canonical headword. A case variant or a spelling in the request resolves to it
relationsNoAlways served. Not required, because a device parses entries stored before the field existed
spellingsNoAlways served. Not required, because a device parses entries stored before the field existed
updated_atYesWhen the entry last changed; the entry's ETag is derived from it
inflectionsYesEvery form as a row, so a client never deinflects
frequency_rankYes1 is the most frequent entry of its language; null when unranked
pronunciationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and mostly does: it discloses the failure mode (case variants and alternative spellings resolve, inflected forms do not), states the matching behavior, and points to immit://entry-shape for field-by-field result structure. It omits anything about error behavior when a word is absent (report_missing_word exists, unmentioned) and rate or auth constraints, though those are likely irrelevant for a read-only dictionary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and free of filler, but the first sentence is a very long noun phrase stacking nine return fields, which reads as an inventory rather than a purpose statement. The second paragraph is well-structured and earns its length; the field enumeration is useful but could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description still summarizes the fields, which lets an agent decide relevance without opening it, and it routes to the entry-shape resource for detail. For a two-parameter read-only lookup, nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns extra by specifying the dictionary-form constraint with concrete examples (食べる not 食べた; eat not eating) and the negative case that inflected input will not resolve. That goes beyond the schema's 'dictionary form, or an alternative spelling' phrasing by explaining what happens when you violate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (the immit dictionary entry for one English or Japanese word) and enumerates exactly what it contains: senses, translations, example pairs, inflected forms with readings, IPA/kana + pitch accent, MP3 URL, frequency rank, synonyms/antonyms, alternative spellings. The scope is unmistakably single-word lookup, cleanly separated from the sibling search_words.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use trigger list (pitch accent, reading, inflection table, pronunciation, example sentence, frequency, exact definition) plus the rationale that these are facts a model guesses wrong. It also names the alternative for the one case this tool fails on: inflected forms go to search_words.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources