A Japanese shiritori (word-chain game) dictionary of 88,000+ nouns. Check whether a move is valid (including words ending in ん), suggest next words, and look up a word's reading — so an AI can play shiritori correctly.
Scored across 3 tools
check_move validates a chain move using a previous word, check_word is a standalone word lookup, and suggest_next offers follow-up candidates. The purposes are distinct, though check_move also reports dictionary/next-kana info that overlaps with check_word, which could cause minor hesitation.
All tool names use snake_case and start with a verb (check_, suggest_). The pattern is mostly consistent, with suggest_next being a slight deviation from the check_* pairing but still predictable.
Three tools is reasonable for a focused shiritori dictionary helper: validate, look up, and suggest. It is at the lean end and could arguably use one more tool for a complete feel, but each tool earns its place.
The core lifecycle is covered: validate a move, inspect a word, and generate suggestions. A few minor gaps remain (e.g., deterministic listing of all valid next words or game-state management for used words), but agents can work around them.
Check whether the next word correctly follows the previous word in shiritori: it must start with the previous word's last kana, it loses if it ends in ん or was already used. Also tells whether each word is in the dictionary and what the next word must start with.
| Name | Required | Description | Default |
|---|---|---|---|
| next | Yes | The word just said. | |
| used | No | Words already used in this game. | |
| previous | Yes | The previous word (kana is safest; kanji is looked up in the dictionary). | |
| loose_dakuten | No | House rule: allow ば→は/ぱ style dakuten variants. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral substance beyond that: it discloses the exact failure conditions (ends in ん, already used) and the additional outputs (dictionary membership, required starting kana). It does not mention the loose_dakuten house-rule variant or any error/ambiguity behavior.
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 dense sentence that front-loads the core check and then appends the secondary outputs. Nothing is padded and there is no filler. It is slightly run-on, with the rule list and the output list competing in a single sentence, but the size is appropriate.
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, so the description must carry return semantics, and it does name two of the returned facts (dictionary membership, next required kana) plus the win/lose conditions. It stops short of describing the response shape or how a valid vs invalid move is represented, which an agent calling this programmatically would want.
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%, so all four parameters are already documented in the schema, making 3 the baseline. The description reinforces the meaning of the `used` parameter ('was already used') but adds no format, syntax, or edge-case detail beyond what the schema states, and never mentions loose_dakuten.
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 verb and resource: it checks whether a proposed word legally follows the previous word in shiritori, and enumerates the rule set (last-kana match, ん loss, reuse loss). That is clear and actionable. It does not explicitly distinguish itself from the sibling check_word, which a reader must infer checks a single word rather than a move pair.
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 only implied by the phrasing 'the next word' and 'this game' – it is clearly a mid-game move validator. There is no explicit when-to-use statement, no mention of when to prefer check_word or suggest_next, and no prerequisites or ordering guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a word: is it in the dictionary, its reading, its first and last kana under shiritori rules (ー and small kana handled), whether it ends in ん, and which kana the next word must start with.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds substantial domain behavior: explicit handling of ー and small kana under shiritori rules, and detection of words ending in ん, which tells the agent how the lookup differs from a plain dictionary check.
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 enumerating the outputs with no filler; the parenthetical about ー and small kana is a tight, necessary qualifier. It is dense rather than padded, though the list format runs long for one sentence.
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 takes on the burden of explaining returns and does so thoroughly (membership, reading, first/last kana, ん flag, next starting kana). What remains missing is input format guidance and any routing relative to the sibling tools.
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?
One parameter with 0% schema description coverage, and the description says nothing about the accepted input form (kanji, kana, romaji, case, length). For a tool whose entire logic hinges on kana, leaving the input format unstated is a meaningful omission that the schema does not compensate for.
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 (a word) and enumerates exactly what is computed: dictionary membership, reading, shiritori kana, ん detection, and the required next starting kana. It is clearly distinguishable from suggest_next and check_move by its output set, 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?
No when-to-use, when-not-to-use, or alternative routing is given. An agent cannot tell from the description whether this should be called before or instead of check_move or suggest_next, which is a real gap given the shared shiritori domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick random words that can follow the previous word (or start with a given kana), excluding words already used and, by default, words ending in ん. pool "everyday" (default) uses hand-picked everyday words, "common" adds common dictionary words, "all" uses the whole dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| pool | No | everyday | |
| after | No | The previous word. | |
| count | No | ||
| genre | No | Theme for 食べ物しりとり etc. (everyday words only). | |
| allow_n | No | Include words ending in ん (they lose). | |
| exclude | No | Words already used in this game. | |
| start_char | No | Or: one kana to start with, e.g. "り". | |
| loose_dakuten | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld=false). The description adds real behavioral context beyond them: random selection (consistent with idempotentHint=false), automatic exclusion of used words, and default exclusion of words ending in ん. It does not describe the return format.
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, purpose front-loaded, no filler. The pool sentence is dense but informative and correctly ordered after the core behavior.
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 an 8-parameter tool with no output schema, the description covers purpose and the main behavioral rules but leaves loose_dakuten entirely unexplained and gives no sense of what the returned suggestions look like. Adequate but with clear gaps.
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?
At 63% schema coverage the description does useful work by explaining each pool value (everyday vs common vs all), which the schema only lists as bare enums. It also clarifies the ん-ending exclusion tied to allow_n, though loose_dakuten and count remain undocumented anywhere.
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 gives a specific verb and resource: 'Pick random words that can follow the previous word (or start with a given kana)'. It's clear this is a suggestion/generation tool rather than a validator, which implicitly separates it from check_move and check_word, but it never names or contrasts with those siblings.
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 through the 'after'/'start_char' alternatives and the exclusion of already-used words, but there is no explicit when-to-use, when-not-to-use, or reference to the sibling check tools. The agent must infer that this generates options while the siblings validate them.
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.
check_movecheck_wordsuggest_nextAuthoritative JLPT-graded Japanese dataset (kanji, vocab, grammar, history) via MCP and REST.
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Normalize and romanize Japanese addresses, look up postal codes, count Japanese business days.
Resolve Japanese food names to nutrition facts. All 2,538 foods from Japan's official tables.
Add one secure layer between your agents and this server.
