Japanese kanji worksheets (elementary grades, Kanken 10-5). Returns a review link. No login.
Scored across 4 tools
Each tool has a clearly distinct purpose: checking available kanji/coverage, creating a worksheet, finding replacement candidates, and replacing a question. The boundaries are well-defined, with no overlapping functionality that would cause misselection.
All tool names use consistent snake_case formatting with a verb-first pattern (check_, create_, find_, replace_). The naming is predictable and easy to scan, with no deviations in style.
Four tools is well-scoped for a focused kanji worksheet generator. Each tool earns its place by covering a distinct step in the create-modify workflow, and there is no bloat.
The surface covers checking coverage, creating worksheets, and replacing questions, but lacks a way to list or retrieve previously created worksheets beyond the returned link. This is a minor gap since links serve as retrieval, but could be a dead end if links are lost.
作れる漢字プリントの範囲（教育漢字・漢検の級）、形式、指定した字の問題の数を返します。
| Name | Required | Description | Default |
|---|---|---|---|
| chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns information (ranges, formats, counts), but does not disclose any additional behavioral traits such as rate limits or authentication requirements.
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 a single, front-loaded sentence with no wasted words. It packs the returned information efficiently, though the parenthetical about educational kanji and kanken levels adds slight density.
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 should explain return values. It lists the main categories returned (range, format, question count), which is adequate for a simple query tool, but it lacks detail on the structure or format of those returns, leaving some gaps for the agent.
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 0%, so the description must compensate. It references '指定した字' (specified characters), which gives meaning to the single 'chars' parameter as the characters to inspect, but it does not explain that the parameter is an array, that it is optional, or that it has a max of 24 items.
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 ('返します' / returns) and resources (range of kanji worksheets, formats, question counts). It clearly identifies the tool's function as a query/check operation, but does not differentiate it from siblings like create_kanji_worksheet.
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 guidance or named alternative. However, the tool name and description imply it is used to check available ranges before creating worksheets, which is a reasonable implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
既存の問題を組み合わせて A4・24マスのプリント案を作り、問題一覧（番号・種類・問題文・答え・字）と確認用の短いリンク（30日有効）を返します。形式を省くと書きと読みのテストになります。プリントの保存と PDF の作成はしません。
| Name | Required | Description | Default |
|---|---|---|---|
| chars | Yes | プリントに載せる字（重複なし）。テストは8〜24字、練習は1〜6字。テストで25字以上・8字未満のときは、字の絞り方や分け方の案（proposals）を返す。 | |
| grade | No | 教育漢字のプリントの学年（1〜6）。省くと字の配当学年の最大。漢検のプリントでは使わない。 | |
| title | No | 紙面のタイトル（1〜60文字）。省くと自動で付く。テストのタイトルに出題する字が入っていると、答えが見えるため受け付けない。 | |
| words | No | 優先して出題する語（例：想像・経験）。指定した字の問題に同じ語があれば先に選ぶ。 | |
| format | No | practice（練習）・test_mixed（書きと読み）・test_write（書きだけ）・test_read（読みだけ）。省くと test_mixed。 | |
| practiceMax | No | 練習（format=practice）の1枚に載せる字数の上限。3字までなら3、6字までなら6（字の練習回数ではない）。練習のときは必須。 | |
| learningScope | No | 学習範囲。省くと小学校の教育漢字。漢検は {system:'kanken', level:10〜5}。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the description is not contradicted. It adds real context beyond them: the returned artifact set, a verification link with an explicit 30-day expiry, and the explicit disclaimer that the worksheet is neither saved nor rendered to PDF.
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?
Three compact sentences, front-loaded with what is produced, then the default behavior, then the negative scope. No filler, though the middle sentence could be folded into the schema's format documentation.
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 7-parameter tool with no output schema, the description supplies the return payload, the link lifetime, and the non-persistence guarantee, which the schema cannot convey. Only the routing against sibling tools is absent, so it is near-complete rather than fully complete.
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 the parameters are already well documented. The description only restates one default (format omitted → test_mixed), adding marginal value over the schema; baseline 3 applies.
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 (既存の問題を組み合わせて…プリント案を作り) and enumerates the return (問題一覧 + 確認用リンク). It implicitly separates itself from the sibling mutation tools by framing itself as the generator, but does not name an alternative 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?
It gives one when-behavior (形式を省くと書きと読みのテストになります) and one when-not (プリントの保存と PDF の作成はしません), which is genuinely useful. However it never explains when to pick this over check_available_kanji, find_replacement_questions, or replace_question, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定した字の既存の問題を最大20件、問題文と答え付きで返します。プリント案の1問を差し替える候補になります。
| Name | Required | Description | Default |
|---|---|---|---|
| char | Yes | 候補を調べる字（1字）。 | |
| type | No | 熟語（書き）・読み・送りがなで絞る。 | |
| grade | No | 教育漢字のとき、プリントの学年。省けば字の配当学年。 | |
| learningScope | No | 学習範囲。省くと教育漢字。漢検の級を指定すると、その級の範囲の問題だけを返す。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, closed-world, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a hard cap of 20 results and the fact that each result includes question text and answer.
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 tight sentences with no filler. The core capability (returns up to 20 character questions with text and answers) is front-loaded before the use-case 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?
No output schema exists, but the description discloses the essential return shape (question text + answer, max 20) and the annotations carry the safety profile. Combined with 100% schema coverage, an agent has what it needs to call this correctly, though richer detail on result ordering or filtering interaction would help.
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 (char, type, grade, learningScope) are already documented in the schema. The description only mentions the target character and does not add filtering semantics beyond what the schema provides; baseline 3 applies.
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+resource: it returns existing questions for a given character, capped at 20, with question text and answers. It also frames the result as candidates for replacing one worksheet question, which differentiates it from replace_question (the action) and create_kanji_worksheet.
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 clause 'プリント案の1問を差し替える候補になります' gives clear usage context (finding candidates before a swap), but it never names a sibling alternative or states when-not to use it. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
プリント案の1問を同じ字の別の問題に差し替えた新しいプリント案を作り、新しい問題一覧と確認用リンクを返します。元のリンクは元の内容のまま残ります。
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | 差し替えるマスの位置（問題一覧の index。0始まりで、番号とは別）。手本・空白のマスは差し替えられない。 | |
| proposalId | Yes | 差し替えるプリント案の ID（proposalId）。 | |
| replacement | Yes | 差し替え先の問題の ref（差し替え候補の検索結果に含まれるもの）。対象マスと同じ字に限る。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive, non-idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuinely new behavior: it creates a NEW proposal rather than editing in place ('新しいプリント案を作り'), and the original link retains its original contents. That immutability guarantee is not derivable from the annotations.
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 padding, and the primary effect (new draft created) is front-loaded before the secondary guarantee (original link unchanged). Every clause 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?
No output schema exists, so the description carries the return-value burden and does so: it names the new question list and the confirmation link. Combined with the immutability note and full schema coverage, an agent has everything needed to call it 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%, and the schema itself documents index (0-based, template/blank cells not replaceable), proposalId format, and the replacement ref structure. The description adds no parameter detail beyond that, so the baseline of 3 is appropriate.
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: replacing one question in a worksheet draft with another using the same character, and producing a new draft. It also clarifies the output (new question list + confirmation link) and that the original link is untouched, which is a strong differentiator against find_replacement_questions. It stops short of naming sibling tools 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?
The workflow is implied: the replacement candidate comes from the search results ('差し替え候補の検索結果に含まれるもの'), which points the agent toward find_replacement_questions. However, the description never states when to use this over alternatives or any prerequisites, leaving routing to inference.
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_available_kanjicreate_kanji_worksheetfind_replacement_questionsget_capabilitiesprepare_printreplace_questionrevise_printsearch_questionsget_capabilitiesprepare_printrevise_printsearch_questionsAuthoritative JLPT-graded Japanese dataset (kanji, vocab, grammar, history) via MCP and REST.
Semantic search across Japan's government white papers, in English or Japanese. Free beta.
Free: turn your AI chats into spaced-repetition vocabulary. 13 tools, reads and writes.
Make Anki, Quizlet, Mochi and Brainscape decks and review your vocabulary from the chat.
Add one secure layer between your agents and this server.
