공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 시퀀스·시나리오 요청에 호출하라(단순 사실은 k_snippets). 결정론. ordering_coverage가 낮거나 gaps가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 공정/시퀀스 질의 (예: 철근콘크리트 골조 시공 순서). | |
| max_nodes | No | 수집할 공정 노드 상한. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it states that the tool is deterministic, and that low ordering_coverage or gaps signal missing order knowledge, with an explicit instruction not to fabricate and to surface gaps as-is. No annotation contradiction exists.
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 and front-loaded: it opens with the core function, then gives usage examples, the sibling distinction, and a critical honesty rule. Every sentence earns its place with no redundant 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?
An output schema exists, so return values are structurally documented, and both parameters are fully covered by the input schema. The description adds the necessary selection criteria, deterministic behavior, and gap-handling policy, so no missing context prevents correct 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 query parameter is already described in the schema, and the description's examples reinforce the expected query style but do not add materially new semantics for max_nodes or query 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 names a specific verb and resource (공정 시나리오를 구성한다) and explains the mechanism: collect related process nodes and topologically sort them via enables/requires edges into an ordered step flow. The examples make the scope concrete and the tool is clearly distinct from siblings like k_snippets.
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 invocation criteria: call it for sequence/scenario requests such as '기초부터 3층까지 시공 순서' and '가설공사 절차', while routing simple fact queries to k_snippets. It also explains how to handle gaps honestly, which is a concrete usage rule.
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.