공간을 순서대로 지날 때의 분위기 전이를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방" 처럼 이동 순서와 체험 목표가 있을 때 쓴다. spaces 는 실제 이동 순서로 넣는다. 작품 평가("왜 걸작인가")에는 쓰지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| spaces | Yes | Ordered spaces such as ["좁은 진입로", "낮은 천장 복도", "높은 거실"]. | |
| target | No | Optional affective target such as "환대와 개방감". |
| 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 burden, and it does disclose the core behavior: it reads atmosphere transitions and expects spaces in actual movement order. It also sets a boundary by excluding artwork evaluation. It does not describe every edge case, but the read-oriented verb and output schema make the behavior reasonably transparent.
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 compact, front-loaded with the main purpose, and uses three short sentences that each add meaningful guidance. There is no filler or repetition beyond the useful emphasis on ordering.
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?
Given the small parameter set, 100% schema coverage, and the presence of an output schema, the description fully equips an agent to select and invoke the tool correctly. It covers what the tool does, when to use it, when not to use it, and how to provide the key input.
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 both parameters. The description adds a useful reinforcement that 'spaces' should be in actual movement order, but this largely echoes the schema's 'Ordered spaces' wording, and it adds nothing about the optional 'target' parameter.
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 opens with a specific verb and resource: it 'reads the atmosphere transition' when passing through spaces in order. It further distinguishes itself from evaluation-oriented tools by explicitly saying it is not used for artwork evaluation ('작품 평가...에는 쓰지 않는다').
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: use when there is a movement sequence and experiential goal, such as 'emotional flow from entry to living room' or 'compression to liberation.' It also provides a clear when-not-to-use exclusion: do not use for answering 'why is it a masterpiece.'
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.