지명·좌표를 기후·문화·관할 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 먼저 부르고, 돌아온 scope 와 jurisdiction 을 뒤따르는 질의에 넘긴다. 행정구역이 확인되지 않은 좌표 결과는 추정이라고 밝힌다.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for coordinate fallback. | |
| lng | No | Longitude for coordinate fallback. | |
| region | No | Place name such as "부산 수영구" or "Dubai". |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals important behavior: coordinate-based results with unconfirmed administrative districts should be labeled as estimates, and the tool returns scope and jurisdiction. This is meaningful behavioral context beyond the schema.
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 three concise sentences: core transformation, usage priority, and an important uncertainty caveat. It is front-loaded with the main behavior and contains no filler.
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 covers what the tool does, when to invoke it, how to use its result, and the key fallback caveat. With an output schema present and only three parameters, nothing essential for correct invocation is missing.
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 schema already documents lat, lng, and region. The description adds context by explaining that lat/lng are coordinate fallbacks and that region accepts place names, but it does not need to add much more given the schema's completeness.
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 states a specific action: converting place names and coordinates into climate, culture, and jurisdiction conditions. It clearly differentiates itself from sibling tools by framing this as a context-resolution step that should precede other tools when location is mentioned.
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 guidance: call it before other tools when site, region, administrative district, or coordinates are mentioned. It also instructs how to use the returned scope and jurisdiction in subsequent queries, which is actionable direction an agent can follow directly.
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.
Several tools operate on the same underlying graph and can be confused: scenario and traverse both answer construction-order questions with overlapping examples, while answer_why, path_between, and evidence_for all deal with causal/conceptual connections. The descriptions are detailed and try to fence off compare, enumerate, and scenario, but the process/path cluster still has unclear boundaries.
Tool names are readable and consistently lowercase snake_case, but the grammatical pattern varies widely: verb-only (compare, traverse), noun-only (scenario, feedback), verb_noun (review_plan), and compound noun/preposition forms (evidence_for, site_context, answer_why). It is mixed but not chaotic, so an agent can still infer each tool's role from its name.
Twelve tools is a reasonable size for a broad curated AEC knowledge server and fits the ideal 3-15 range. The count is slightly inflated by overlapping process/path tools (scenario/traverse) and niche additions (emotional_palette, feedback), but it is not excessive.
The surface covers a wide range of reasoning types: causal explanation, comparison, classification, code retrieval, plan review, path traversal, sequence construction, site context, and evidence verification. The main gap is the lack of a direct generic 'what is X / define a concept' tool, which may require chaining multiple tools to get a simple definition.