get_full_lawRetrieve the full text of a specified Japanese building law. Returns the complete legal document for reference and citation verification.
法令の全文を取得する。条番号を指定せず法令全体のテキストを返す。
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | 取得開始位置（0から始まる文字位置）。続きの取得時は案内された offset を指定。 | |
| law_name | Yes | 法令名（正式名称、略称のいずれか。例: 建築基準法施行令、建基令） | |
| max_chars | No | 1回に取得する最大文字数（1,000〜48,000）。省略時は30,000文字。 |
Changes observed during successful MCP inspections.
v1.11.2Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / max_charsAdded value: +{
+ "default": 30000,
+ "description": "1回に取得する最大文字数（1,000〜48,000）。省略時は30,000文字。",
+ "maximum": 48000,
+ "minimum": 1000,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "取得開始位置（0から始まる文字位置）。続きの取得時は案内された offset を指定。",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}v1.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that the entire law text is returned rather than a subset, which is useful return-scope context, but it says nothing about pagination/truncation behavior (covered only in the schema) or any rate/permission constraints.
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 short sentences with zero waste; the core action is front-loaded and the scope clarification follows immediately. Every sentence 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?
For a read-only, idempotent retrieval tool with full schema coverage and no output schema, the description is largely sufficient: it states what is returned and at what granularity. It stops short of describing the offset-based continuation flow, but that is adequately handled by the schema.
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 law_name, offset, and max_chars are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the 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 clarifies scope ('条番号を指定せず法令全体のテキストを返す'), which implicitly separates it from article-level siblings. However, it never names or contrasts with the closely related 'get_law' sibling, so an agent cannot fully disambiguate between the two from the description alone.
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 phrase '条番号を指定せず' implies this tool is for whole-law retrieval as opposed to article-specific tools, but no alternative (e.g., get_law, search_articles) is named and no explicit when-to-use condition is given. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.