複数住所の位置をファイルへエクスポート保存(地図・アプリをその場で作る用途には使わない)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description correctly carries the full burden. It discloses that the tool writes to the local filesystem, does not include the file contents in the MCP response, returns only a path and summary, overwrites existing files, and can create parent directories. It also explains the technical reason (1MB response limit) and the practical consequence that Claude cannot draw maps from the written file.

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 long but well-structured with a bold warning up front, followed by clear use-case boundaries, technical rationale, and a final caution. The repetition of the 'not for map-building' rule is somewhat redundant, but it is a critical safety constraint that warrants emphasis. Overall, each section contributes useful context for correct tool selection and invocation.

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?

The description is complete for a complex tool with no output schema and no annotations. It explains the return value (path and summary), the invisibility of file contents to Claude, the difference from get_address_locations, the 1MB workaround, filesystem write behavior, and links to sibling tools like list_prefectures. Combined with the very detailed input schema, there is no significant missing context for invocation.

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 baseline is 3. The input schema already provides detailed semantics for all parameters, including addresses, outputPath, simplify, dropSmallIslands, and degenerateIslands. The main description adds some usage context, such as recommending list_prefectures for 47 prefectures and clarifying that the 1MB limit does not require splitting, but these are reinforcement of schema information rather than new parameter-level semantics.

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 clearly states a specific verb+resource: exporting multiple addresses to a single GeoJSON FeatureCollection file, returning only path and summary. It explicitly distinguishes itself from get_address_locations, which returns data in the MCP response, while this tool writes to a local file and avoids the 1MB response limit. The title also reinforces the export/save purpose.

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 description gives explicit when-to-use and when-not-to-use guidance: it must not be used for building maps or visualizations in place, and get_address_locations must be used instead for such requests. It states that this tool is only appropriate when the user explicitly asks for file export/save and Claude does not need to read the contents. It also explains when it is better than splitting into 5 groups, e.g., for 47 prefectures.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.