search_lawSearch Japanese building laws by keyword across registered aliases and e-Gov API. It matches law titles only; use article-specific search for full-text provisions.
キーワードで建築関連法令を横断検索する。登録済みエイリアスとe-Gov APIの両方を検索する。注意: 検索対象は法令名（タイトル）のみ。条文本文のキーワード検索には search_articles を使用してください。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 検索キーワード（例: 耐火構造、避難階段、建築確認） |
Changes observed during successful MCP inspections.
v1.11.2Input schema / additionalPropertiesRemoved value: -falsev1.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful context beyond them: the search spans both locally registered aliases and an external e-Gov API, which implies a network dependency and possible variability in results. It stops short of describing latency, rate limits, or result count 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?
Three short sentences, front-loaded with the core action followed by source coverage and then the caveat/alternative. Every sentence carries distinct information with no repetition of the tool name or schema.
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 single-parameter read tool with annotations covering safety and openWorld, the description covers purpose, scope, and the sibling routing decision. The only omission is what the result looks like (law titles/IDs to feed into get_law), which matters mildly for chaining but is not required to invoke 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 coverage is 100%, so the parameter itself is documented. The description nonetheless adds a semantic constraint the schema does not encode: the keyword is matched against law titles, not article text, which materially shapes what strings are worth passing. That is real value over the schema.
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 immediately names the scope (law titles only) plus the source coverage (registered aliases and the e-Gov API). It clearly distinguishes itself from search_articles, which operates on article bodies.
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?
Explicitly states the exclusion ('検索対象は法令名（タイトル）のみ') and routes the agent to the correct sibling for the other case ('条文本文のキーワード検索には search_articles を使用してください'). The when/when-not decision is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.