design_map

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only that the tool 'shows' a map and produces a list of gaps, implying a read-only view, but it does not state side effects, whether it mutates anything, how complete the analysis is, or what happens when the map is empty. The intent is clear but the behavior is under-specified.

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 verbose and wrapped in layered metaphor ('트리는 하나로 끝나지 않는다', '그 목록이 곧 완성하려면 뭘 더 만들어야 하는가'). The core message — shows tree-to-tree connections and lists gaps — is buried in prose rather than front-loaded, and the poetic framing adds little operational value for an agent.

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?

An output schema exists, so the return value need not be spelled out, and with zero parameters there is no invocation risk. The description conceptually conveys the output (a map plus a list of gaps), which is adequate. However, the metaphor makes the exact semantics fuzzy — '끊긴 곳' is never precisely defined — so an agent's understanding of the tool's deliverable remains somewhat speculative.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to document, and schema coverage is trivially 100%. It correctly avoids inventing parameter details, which is appropriate for a parameterless tool.

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 indicates the tool shows a connection map of design trees and lists what connections are missing (끊긴 곳), which conveys a core purpose. However, it is heavily metaphorical ('트리', '약축 트리', '연결 기준') and never states a concrete verb+resource, leaving whether it computes, visualizes, or audits ambiguous. It also does not differentiate itself from nearby siblings like design_flows or design_flow.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The structural-calc context (weak-axis members, block-shear review) explains domain triggers for the connections being mapped, but never tells the agent under what condition it should select this tool instead of a sibling.

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