get_kanji_manuscript_rules小学校1〜6年の読み・書き取り・読み書きについて、問題原稿のデータ構造、字の配当、文字数・問数の上限、検査条件と短い作例を返します。形式の省略時は全問書き取りで、送りがなも解答に含めます。読み・混合は利用者が希望した場合だけ指定します。問題の生成はしません。
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes | プリントの学年（1〜6）。 | |
| format | No | 省略時は書き取り。利用者が読み・混合を希望したときだけtest_read・test_mixedを指定。元写真の「読む」表示や赤青の区別は出題形式の指定ではありません。 | test_write |
Changes observed during successful MCP inspections.
Input schema / properties / format / descriptionPrevious value: -"読み・書き取り・読み書きの形式。"New value: +"省略時は書き取り。利用者が読み・混合を希望したときだけtest_read・test_mixedを指定。元写真の「読む」表示や赤青の区別は出題形式の指定ではありません。"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: that examples are included, that okurigana counts toward answers, and that the tool performs no generation. It does not describe output shape or size, but with annotations covering safety this is a solid contribution.
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?
Content is front-loaded with what is returned, followed by default/format rules, with zero filler sentences. The final clause 「問題の生成はしません」 is well placed as a disambiguator, though the middle sentences are dense and slightly run-on.
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 does the work of listing the return contents (structure, allocation, limits, conditions, examples), which is enough for an agent to know what to expect. Only the granularity/format of those returned rules is unspecified, a minor gap for a read-only lookup tool.
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%, so both parameters are documented in the schema, which already states the default of test_write and that photo reading/color cues are not format directives. The description largely restates those same points, adding emphasis but little new semantics. Baseline 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?
The description names a specific resource (problem manuscript rules for grades 1–6) and enumerates what is returned: data structure, character allocation, character/question limits, inspection conditions, and short examples. It also distinguishes itself from the generation siblings by explicitly stating 「問題の生成はしません」.
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 concrete selection rules for the optional format: default is write, and read/mixed are specified only when the user requests them. It further warns that a 'read' label or red/blue distinction in the source photo is not a format specification. However, it never explicitly names the sibling create_* tools or states the workflow position (e.g., call this before creating a worksheet).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.