"A 가 B 를 유발한다"는 한 연결의 근거를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. from·to 는 개념명, relation 은 causes/enables/requires 등. evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target concept name. | |
| from | Yes | Source concept name. | |
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| relation | Yes | Relation, e.g. enables, causes, evokes. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It conveys that the tool is a read-only verification action, explains that evidence_note and stance are delivered separately, and states that disclaimers are reproduced verbatim. It does not discuss failure modes or authorization, but for a non-mutating evidence lookup this is 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 three short, front-loaded sentences. The first sentence states the core purpose, the second gives usage context and parameter semantics, and the third describes output behavior. Every sentence earns its place with 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 the tool's purpose, when to use it, what the parameters mean, and key output behaviors. An output schema exists, so detailed return structure does not need to be repeated. It could be more explicit about exclusions or alternatives, but overall it is sufficient for an agent to select and invoke the tool 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 description coverage is 100%, so the baseline is 3. The description reinforces that from/to are concept names and gives example relation values, but the schema already explains each parameter clearly, including the as_of date usage. No significant additional parameter meaning is added beyond what the schema provides.
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: verify the evidence for one causal link ('A가 B를 유발한다는 한 연결의 근거를 확인한다'), and anchors it to a concrete use case: validating causality used in a previous answer. It distinguishes the tool from sibling tools by focusing on a single connection's evidence rather than paths or comparisons.
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 clearly says when to use the tool: when verifying causality in a prior answer ('앞선 답에 쓰인 인과를 검증할 때 쓴다'). It does not explicitly mention when not to use it or name alternative tools, so it falls just short of a 5.
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.