den is an MCP server that curates Korean AEC codes, laws, and domain knowledge into one graph, answering why, ordering, comparison, and code-lookup questions with cited evidence instead of guessing.
answer_why: explains causal reasons behind regulations or phenomena (e.g., why concrete curing is needed), with evidence, stance, and scope caveats.
k_snippets: retrieves exact clauses and figures from KDS, KCS, KS, Building Act, and related Korean regulations, with source citations; supports as-of dates and scope filtering.
scenario: builds ordered construction process flows from graph relationships, reporting gaps rather than inventing missing steps.
traverse: follows precedence/sequence relationships (requires/enables) to show what comes before or after a concept.
compare: contrasts two methods or concepts, showing shared steps, unique steps, and key differences.
enumerate: lists complete curated taxonomies, types, and components for a topic.
path_between: finds how two concepts are connected and whether a meaningful path exists.
evidence_for: verifies the grounds for a single causal or enabling relationship.
site_context: turns place names or coordinates into climate, culture, and jurisdiction context for later queries.
review_plan: checks floor plans against building regulations for lighting, ventilation, egress, and area violations.
emotional_palette: reads atmosphere transitions as one moves through a sequence of spaces.
feedback: records user satisfaction or issue types so the server can improve future answers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@den 옥내소화전 방수구 높이 기준 알려줘"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
It answers with Korean construction standards (KDS·KCS·KS) and building law with the clause number attached. When it cannot find grounds, it does not guess — it says it is not certain.
mcp.den.archi/mcp 원격 MCP 서버
den.archi 얼리 액세스 신청 · Claude Desktop 확장 내려받기When you ask an AI "the height of an indoor fire hydrant discharge outlet," you get a plausible number. Sometimes it is right, sometimes it is wrong — and there is no way to know which.
In practice, that is worse than no answer, because you have to open the standard again to check.
den attaches a source to the answer. If there is no source to attach, it does not answer.
Related MCP server: narajangteo-prespec
Below are actual responses, reproduced verbatim without editing.
① Question with a standard
Height of the indoor fire hydrant discharge outlet installation
relevance: high · confidence 0.998
근거: 옥내소화전설비의 화재안전기술기준(NFTC 102) · KCS 31 80 10
옥내소화전은 노즐 선단 방수압력 0.17 MPa 이상 0.7 MPa 이하,
방수량 130 L/min 이상을 확보해야 한다. 방수압력이 0.7 MPa를 초과하면
호스접결구 인입측에 감압장치를 설치하고, 방수구는 바닥에서 높이 1.5 m 이하,
건축물 각 부분으로부터 수평거리 25 m 이하로 배치한다.② Figure stipulated by law
Minimum parking stall size for perpendicular parking in an underground parking garage
relevance: high · confidence 0.968
근거: 주차장법 시행규칙 제3조
평행주차 외(직각 등)는 경형 2.0m×3.6m, 일반형 2.5m×5.0m,
확장형 2.6m×5.2m, 장애인전용 3.3m×5.0m, 이륜차 1.0m×2.3m다.③ Qualitative judgment — when den says it is not confident
Recommend a lighting color temperature that suits a café interior
relevance: low · confidence 0.237den has data on color temperature classifications, but "what suits" is not something a code determines. In cases like this, den shows its low confidence level as is. The judgment is yours.
Comparing the same model on the same questions, with den toggled on and off.
Correct answer rate | |
without den | 166/192 |
with den | 183/192 |
Difference | +8.9%p |
By grade: Master Craftsman +20.0%p · Manager +15.0%p · Engineer +6.8%p · Industrial Engineer ±0. Easy questions the AI handles as well. The gap widens as the content gets deeper and more specialized.
Because these are publicly released past exam questions, both conditions include memorized content. The absolute score is higher than the real level of skill, so look at the difference only.
In another model (sol) as well, it was +7.3%p in the same direction.
Because trust is the product, this goes first.
Architectural planning · interior architecture — It is weak in qualitative judgment territory. That is example ③ above.
Contract document interpretation — Exemption from delay-damages, design changes, and defect liability cannot be covered right now (3 internal golden questions failed, public tracking in progress, and we're tracking severity).
Drawings · formula images — It only handles text-based standards.
Immediate reflection of latest revisions — update monitoring is running, but reflection may be lagged.
Outside the scope, it lowers its confidence instead of fabricating an answer. Note: The prompt codes at issue.
Claude Desktop
Download and run the den.mcpb from den.archi.
After early access approval, input the API key issued from the dashboard.
The key is stored in the OS keychain, and a bundled local proxy attaches it to the request header.
Other MCP clients
{
"mcpServers": {
"den": {
"url": "https://mcp.den.archi/mcp",
"headers": { "Authorization": "Bearer <your-key>" }
}
}
}Tool | What it does |
| finds the numeric values and original clauses in construction standards and laws |
| explains, through a causal path, why a rule is so |
| finds the ground clauses for a particular claim |
| places two standards or construction methods side by side |
| shows how two concepts are connected |
| assembles, given a situation, the standards applicable |
| scans lists and adjacent concepts |
| converts a location name and coordinates into climate and jurisdictional conditions |
| reviews a plan against the standards |
Give as_of, and it answers on the basis of the standard that is at that time. It is intended for reviewing past contracted documents and disputes.
The queries sent are only kept in memory. The den server does not persist what you ask in the disk. Only an irreversible fingerprint with shape remains.
{"query_fp": "a8edb8c424a5c84b",
"query_shape": {"len_bucket": "s", "has_number": true, "lang": "ko"},
"tool": "k_snippets", "relevance": "high"}The full query and arguments are never logged; this rule is checked as an invariant that is the local server invariant. Even if you ask about your design drawings or undisclosed project content, no sentence remains on the server.
On beta · free. If you request an early access at den.archi, you will be given after review and approval by the review.
If you encounter a wrong answer, send it to us. den records the incorrect answer as a case, and re-authors that clause, which is the most important metric we care about.
den is a remote MCP server for the Korean AEC (architecture · engineering · construction) standards. It answers with the clause number attached — KDS, KCS, KS, and the building law — and stays silent when it has no grounds.
Endpoint: https://mcp.den.archi/mcp (Bearer token)
Desktop extension: den.archi → den.mcpb
Measured lift: +8.9%p on 192 national qualification exam items, same model, den toggled on/off. Largest gains on advanced tiers (+20.0%p on the most advanced). The public past exams — both sides include memorized content, so read the delta, not the absolute.
Query text is never stored to disk. Only a non-reversible fingerprint and shape metadata.
Weak on qualitative design judgment and contract-document interpretation. Stated up front.
Beta, free. Request access at the den.archi.
건축·공간의 왜·원리·득실을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. 수치·조문이 필요하면 k_snippets 를 함께 부른다. relevance=low 또는 no_path_reason 이면 den 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| depth | No | L1, L2, or L3. Hops are hard-capped at 4. | L2 |
| scope | No | Optional comma scope filter such as climate=arid,epoch=ancient. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). | |
| question | Yes | Natural-language why question. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful context about output semantics: relevance=low or no_path_reason means the den does not contain that path and should not be cited. It does not elaborate on other behavioral aspects, but the output schema partially fills that gap.
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?
Three compact sentences deliver the core purpose, example usage, a complementary-tool pointer, and an important result-interpretation caveat. Every sentence earns its place, and the main action is front-loaded.
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 moderate complexity (5 parameters, output schema present), the description covers the essential intent, example usage, and a key limitation. Slightly more explicit differentiation from other siblings would make it fully complete, but nothing critical is missing for invoking 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 adds value beyond the schema by giving realistic example questions that clarify the expected form of the 'question' parameter, going beyond the schema's one-line 'Natural-language why question'.
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 clearly states the tool's function: explaining architectural 'why', principles, and pros/cons as causal paths. Concrete examples ('왜 콘크리트에 양생이 필요한가') anchor the purpose, and the mention of k_snippets for numeric/legal content helps distinguish it from at least one sibling.
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?
It explicitly says to use this tool for reason-seeking questions and advises calling k_snippets when numeric/legal content is needed. It also warns not to use low-relevance/no-path results as evidence. However, it does not explicitly contrast with other closely related siblings like evidence_for or path_between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
두 공법·개념의 차이를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 비교/차이 요청에 호출하라(단일 순서는 scenario). 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage가 낮으면 그쪽 지식이 얇다는 정직한 신호 — 지어내지 말고 gaps 그대로 전하라.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | 첫째 공법/개념 (예: RC 골조 시공). 'A vs B'를 a에 한 번에 줘도 됨. | |
| b | No | 둘째 공법/개념 (예: 철골 시공). a에 vs가 있으면 생략 가능. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so strongly: it states the operation is deterministic, that no LLM is involved, what the result will contain, and that low a_coverage/b_coverage signals thin knowledge and must be reported honestly rather than fabricated.
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?
Every sentence earns its place: purpose, invocation condition, return structure, determinism, and honesty policy. The most decision-relevant information is front-loaded before the examples, and there is 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 tool has a rich output schema, so return values need not be fully re-specified; the description still summarizes them. It also covers when to use it, when not to, input flexibility, determinism, and how to handle low coverage—leaving no practical gap for an agent selecting or invoking this tool.
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% and the schema already documents a ('A vs B' can be passed at once) and b (optional when a contains vs). The description adds contextual examples but does not materially deepen parameter semantics beyond the schema, so baseline 3 applies.
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 verb ('대조한다' – contrasts) and a specific resource ('두 공법·개념의 차이'), and distinguishes itself from scenario by explicitly assigning single sequence to scenario. Concrete examples make the matching intent unambiguous.
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?
It gives explicit call conditions ('비교/차이 요청에 호출하라') and an explicit exclusion ('단일 순서는 scenario'), naming the sibling tool that should be used instead. The examples make positive matching easy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공간을 순서대로 지날 때의 분위기 전이를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방" 처럼 이동 순서와 체험 목표가 있을 때 쓴다. spaces 는 실제 이동 순서로 넣는다. 작품 평가("왜 걸작인가")에는 쓰지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| spaces | Yes | Ordered spaces such as ["좁은 진입로", "낮은 천장 복도", "높은 거실"]. | |
| target | No | Optional affective target such as "환대와 개방감". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavioral traits: it reads transitions, requires spaces in actual traversal order, and is not applicable to work evaluation. It does not describe output behavior, but an output schema is present and covers that gap.
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?
Three short sentences deliver the function, usage context, parameter constraint, and a negative case. The core behavior is front-loaded, and every sentence earns its place without 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?
For a two-parameter tool with full schema coverage and an output schema, the description covers purpose, ordering, experiential target, and an explicit non-use case. No critical information needed to invoke this tool correctly 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 coverage is 100%, so the baseline is 3, but the description adds meaning by insisting spaces be in actual movement order rather than any ordering, and by framing the target as the 'experience goal' in the examples. This modestly enhances the schema's existing parameter descriptions.
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 leads with a specific verb and resource: it 'reads the atmosphere transition' across spaces in sequence. It also bounds the tool's scope with concrete use cases and explicitly excludes work evaluation, which differentiates it from siblings like answer_why.
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?
It gives clear when-to-use conditions: when there is a movement order and an experiential goal, with examples like 'compression to release'. It also states a when-not condition for artwork evaluation, though it only implicitly points to the sibling answer_why rather than naming an alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
어떤 것의 종류·구성요소·분류를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 'X의 종류/체계' 요청에 호출하라(순서는 scenario, 비교는 compare). 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None이면 미큐레이션 주제 — k_snippets로 폴백. gaps는 멤버 정의가 아직 그래프에 없다는 정직한 신호(지어내지 말고 그대로 전하라).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 'X의 종류/체계/구성요소' 질의 (예: 건축물 하중의 종류). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: it states determinism, that the response is a complete member list from an authoritative curated taxonomy, that definitions are pulled from the graph, that gaps honestly signal missing graph data, and that the agent must not fabricate content. It even discloses the fallback behavior for non-curated topics.
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 yet information-dense: purpose, examples, sibling routing, fallback, and honesty guarantees all appear in a few sentences. Core intent is front-loaded before caveats, and no sentence is redundant with the schema or output schema.
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?
For a one-parameter tool with an output schema and no annotations, the description covers everything needed: what it returns, how it behaves, when to call it, how to distinguish it from siblings, fallback behavior, and how to interpret gaps. There are no material gaps that would prevent 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 coverage is 100% for the single query parameter, so the baseline is 3. The description adds value beyond the schema by defining the accepted query pattern ('X의 종류/체계/구성요소') and clarifying the match=None case that affects behavior, which helps the agent form valid inputs.
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 precise verb-and-resource combo: completely enumerate the kinds/components/classifications of an entity, with concrete examples like '건축물 하중의 종류'. It also differentiates itself from siblings by explicitly routing ordering to scenario and comparison to compare, so the agent can select it correctly.
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 criteria ('X의 종류/체계' requests), names alternatives for other request types (scenario, compare), and specifies the fallback to k_snippets when match=None. This is clear routing guidance rather than leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
"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 |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful output behavior—separating evidence_note from stance and passing disclaimers through—but it does not explicitly state read-only semantics, prerequisites, or error behavior. This is adequate but not fully 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 dense, purposeful sentences: purpose, usage trigger, parameter semantics, and output handling. Every sentence earns its place and there is 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?
Given the tool has four parameters and an output schema, the description covers the core invocation context, parameter semantics, and key output distinctions. It lacks explicit sibling routing and operational caveats, but nothing essential for calling the tool correctly 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 coverage is 100%, so the baseline is 3, and the description adds real value on top: it clarifies that from and to are concept names, gives example relation values like causes/enables/requires, and explains as_of for past-as-of queries. This goes beyond the bare schema descriptions.
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 concrete action and object: confirming the evidence for one causal link ('A 가 B 를 유발한다'는 한 연결의 근거를 확인한다). It also states the tool is for validating causality in a previous answer, which separates it from sibling tools like path_between or enumerate.
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?
'앞선 답에 쓰인 인과를 검증할 때 쓴다' provides a clear trigger condition for when to use the tool. It does not explicitly name alternative tools or state when not to use it, but the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운 issue_type으로 매핑한다. 관찰 가능한 반응이 전혀 없으면 만족 여부를 추측하지 않는다. ★satisfied=true(채택·긍정)이면 comment 에 den 이 없었으면 무엇을 하려 했는지 한 마디를 함께 적는다 — "다른 값을 쓰려 했다" · "몰라서 정하지 못하고 있었다" · "다른 출처로 갔어야 했다" 중 사용자가 실제로 말한 것. 이 한 마디만이 'den 을 썼다'와 'den 때문에 달라졌다'를 가른다. ★★사용자가 말하지 않았으면 비워 둔다. 추측해 지어내지 않는다 — 없는 것을 적는 편이 안 적는 것보다 나쁘다. ★★★그렇다고 comment 를 통째로 생략하지는 않는다. satisfied=true 면 무엇을 채택했는지 한 줄은 항상 적는다(어느 값·조문·판단을 그대로 썼는가). 비워 두는 것은 반사실 한 마디뿐이다 — 요지까지 비면 그 만족은 기록에 남아도 쓸 수 없다. 사용자 대화 원문은 전송하지 않는다. 만족/불만족과 사유는 다음 날 그래프 보완에 반영된다.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Summary of the user's reaction; never send conversation text. When satisfied=true this is expected, not optional: state in one line what the user actually did with the answer (which value / clause / decision they adopted). Also add what the user would have done without den (used a different value / was stuck undecided / would have gone to another source) — but ONLY if the user actually said it; never infer or invent that part. Omitting that one clause is correct when unsaid; omitting the whole comment is not. | |
| query_id | No | The 16-character query_id returned in the previous response meta. | |
| satisfied | Yes | Whether the previous Den response was satisfactory. | |
| issue_type | No | Required when dissatisfied: 오답, 무관, 기권과다, 얕음, or 기타. | |
| question_text | No | The exact prior Den tool query, used only when query_id is unavailable. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that raw conversation text is never sent, that summaries are limited to 200 characters, that satisfaction must not be inferred, and that a counterfactual phrase must never be invented. It even explains the downstream consequence of the data and the distinction between 'using den' and 'changed because of den'.
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 long but front-loaded with the core purpose and organized with star-bulleted rules for the delicate comment requirements. Some repetition occurs around not guessing or inventing the counterfactual phrase, but this emphasis is purposeful for a tool where hallucinating feedback would be harmful.
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 tool's complexity, the absence of annotations, and the need to capture nuanced user feedback ethically, the description is complete: it covers purpose, invocation timing, parameter selection rules, content restrictions, and downstream use. Since an output schema exists, not describing the return value is acceptable.
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?
Although the schema already covers all parameters, the description adds critical relational meaning: query_id is preferred over question_text as a fallback, issue_type is only recorded when dissatisfied, satisfied=true requires an adoption line in comment, and the counterfactual part is only included when the user actually stated it. These conditional rules cannot be inferred from the schema alone.
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 defines the tool precisely as a 'relay tool' that records the user's reaction (correction, complaint, adoption, ignoring) after the calling agent uses the prior Den response, and it explicitly contrasts itself with a user-facing form. This verb+resource+scope framing makes its role distinct from the sibling Den answer tools even though it never names them.
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 states when to record ('대화 종료 전', after the preceding Den response) and gives explicit when-not guidance: do not guess satisfaction if no observable reaction exists. It also defines mapping rules from user behavior to satisfied/issue_type, though it does not explicitly name an alternative tool for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국 건설기준(KDS·KCS·KS)과 건축 법령의 수치·조문 원문을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 웹 검색보다 먼저 이 도구를 쓴다.
이럴 때 부른다: · 수치 기준 — "철근 피복두께", "콘크리트 압축강도 시험 재령", "방화구획 면적", "계단 챌판 높이" · 조문·법령 — 건축법·시행령·시행규칙, 국가건설기준 조항 · 시공 방법 — "이어치기 면 처리", "되메우기 다짐", "방수층 시공 순서" · 설계 요건 — 하중·내진·단열·피난·주차 기준
돌아오는 것: 조문 원문과 출처(예: KDS 14 20 22 §4.3.1). 출처를 그대로 인용한다.
★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 갖고 있지 않다는 뜻이다. 스니펫을 근거로 쓰지 말고 "den 이 이 부분은 보유하지 않는다"고 말한 뒤 다른 출처로 답한다. (자료가 없는데 있는 척하는 것이 틀린 답보다 나쁘다.)
as_of 로 과거 시점 기준을 조회한다. 예: as_of=2020-06-01
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| limit | No | Maximum snippets to return. | |
| scope | No | 선택. 이 질문이 속한 **공종·기준**을 알면 넣어라 — 그 범위로 좁혀 답한다. 같은 용어라도 공종마다 규정값이 다르다(되메우기 다짐 두께는 도로·하수도·조경이 각각 다르다). 넣지 않으면 den 은 갈리는 공종을 `scope_split` 로 알려 주고, 값을 인용하기 전에 공종을 확인하라고 요구한다. 넣었는데 그 범위 밖 자료가 섞여 나가면 `scope_partial` 로, 하나도 없으면 `scope_absent` 로 알려 준다 — den 은 범위 밖 자료를 버리지 않고 **고지**한다. 형식: 공종 이름('도로'·'하수도'·'건축') 또는 기준코드('KCS 44'·'KDS 14 20 50'). ★모르면 넣지 마라 — 틀린 범위는 틀린 답을 만든다. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). | |
| question | Yes | Question or retrieval slot for K snippets. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It explains the return format (original clause text plus source identifiers like KDS 14 20 22 §4.3.1), the meaning of relevance=low and lacks_answer=true, and instructs the agent to say den does not hold the material rather than fabricating. It also discloses as_of behavior for historical queries.
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 front-loaded with the core purpose, then organized into scannable use-case categories, return semantics, missing-data handling, and historical querying. Though longer than average, each section earns its place and the structure makes it easy for an agent to extract the key guidance.
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 schema covers all five parameters, and the description covers purpose, when to use it, return format, source citation expectations, missing-data behavior, and historical query semantics. With no annotations and an output schema present, nothing critical is missing for selecting and invoking this 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 schema already documents question, as_of, limit, scope, and profile in detail. The description adds only a small amount of behavioral context around as_of and scope, but does not materially improve parameter understanding beyond the schema.
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 finds original numeric text and clause wording from Korean construction standards (KDS, KCS, KS) and building laws, and gives four concrete example categories. It is clear what the tool does, but it does not explicitly distinguish this tool from sibling tools such as compare, enumerate, or traverse, so it does not fully meet the 5-level criterion.
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 use contexts with concrete examples ('철근 피복두께', '이어치기 면 처리') and instructs to use this tool before web search when grounding answers. It does not provide exclusions or mention when sibling tools would be more appropriate, so it is clear context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
두 개념이 어떻게 이어지는지 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 출발·도착이 분명할 때 쓴다. 경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Start concept name or phrase. | |
| b | Yes | End concept name or phrase. | |
| scope | No | Optional comma scope filter such as climate=arid,epoch=ancient. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses a critical trait: '경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다' (do not fabricate a path; report that no connection is confirmed). The verb '확인한다' also signals a read/verification operation. It does not discuss permissions or side effects, but those are less relevant for a graph-query tool.
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?
Three short sentences, each earning its place: purpose, usage condition with examples, and the no-fabrication rule. The content is front-loaded 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?
For a graph-query tool with a rich schema and an output schema, the description supplies the key selection condition and the critical negative-result behavior. It is slightly incomplete in not addressing when sibling tools such as answer_why or evidence_for would be more appropriate, but the agent can still call path_between 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 schema already documents a, b, scope, and profile. The description's examples illustrate valid values for a and b but add no new parameter syntax or semantics beyond the schema.
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 uses a specific verb and resource: '두 개념이 어떻게 이어지는지 확인한다' (verify how two concepts connect) and gives two concrete examples. The phrase '출발·도착이 분명할 때 쓴다' distinguishes this from broader siblings like traverse or enumerate by requiring clear endpoints.
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?
It explicitly states when to use the tool: when the start and destination are clear, with examples. It does not, however, name alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
평면도·배치도를 건축 법규 관점에서 검토한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. 이미지가 아니라 도면에서 읽어낸 구조를 넣는다: 방(용도·외부창 유무)·인접·개구부·동선. 위반(violation) 항목은 답변에서 빼지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | Yes | Parsed rooms with id, use, ext_windows, optional area/floor/access/shape. | |
| openings | No | Openings, including exterior windows and doors, as parsed objects or pairs. | |
| adjacency | No | Room adjacency pairs such as [[a,b]] or objects with from/to. | |
| site_scope | No | Optional site scope such as climate/culture/epoch/tech_level. | |
| circulation | No | Circulation edges or ordered paths, e.g. [[from,to]] or [a,b,c]. | |
| jurisdiction | No | Optional jurisdiction key such as KR-서울 for NormClause lookup. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the input must be parsed structural data, not an image, and guarantees that violations are not omitted from the answer. However, it does not explain how missing data is handled, whether jurisdiction influences the review, or what kind of output format to expect beyond the output 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?
Three dense sentences deliver the core action, trigger condition, input semantics, and an output guarantee. There is no fluff or repetition of schema details, and the most important information is front-loaded.
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 output schema and complete parameter descriptions, the definition adequately covers what the tool does, when to use it, what to pass in, and how it behaves. The main gaps are the lack of exclusions/alternatives and jurisdiction-related caveats, but these are minor given the structured schema coverage.
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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that rooms, adjacencies, openings, and circulation should be the structure extracted from drawings—and clarifies room attributes like use and exterior-window presence—going slightly beyond the schema's generic descriptions.
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 verb and resource: it reviews floor plans/layouts from a building-code perspective and flags daylight, ventilation, evacuation, and area violations. This clearly distinguishes it from the sibling tools, which focus on paths, comparisons, evidence, or enumeration.
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?
It explicitly says to use this tool when the user shares drawings or requests spatial-composition review. It does not state exclusions or name alternatives, but the trigger condition is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 시퀀스·시나리오 요청에 호출하라(단순 사실은 k_snippets). 결정론. ordering_coverage가 낮거나 gaps가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 공정/시퀀스 질의 (예: 철근콘크리트 골조 시공 순서). | |
| max_nodes | No | 수집할 공정 노드 상한. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses determinism and, crucially, the honest-fallback behavior: low ordering_coverage or gaps mean the graph lacks order knowledge, so the agent must not fabricate and should pass gaps to the user. This is valuable 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?
Two dense, well-organized sentences: core behavior first, usage routing second, behavioral caveat last. Every clause earns its place; there is no filler or repetition of schema content.
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?
With a full output schema and complete parameter documentation in the schema, the description covers purpose, invocation criteria, algorithm, and gap-handling behavior. An agent has everything needed 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 coverage is 100%, so both parameters are already fully documented. The description reinforces the query type with examples but adds no new semantics beyond the schema for max_nodes or query format; baseline 3 is appropriate.
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?
States a specific action ('constructs a process scenario'), resource ('related process nodes'), and method ('topologically sorts with enables/requires edges') to return an ordered step flow. It also distinguishes itself from k_snippets by clarifying that simple facts belong there, making sibling differentiation clear.
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?
Explicitly says when to call: for sequence/scenario requests such as 'construction order from foundation to 3rd floor' and 'temporary works procedure'. It also names the alternative for simple facts (k_snippets), providing a clear routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지명·좌표를 기후·문화·관할 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 먼저 부르고, 돌아온 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 |
|---|---|---|
No output parameters | ||
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 key behavior: the tool returns scope and jurisdiction, is intended to run early in a chain, and requires the agent to disclose when coordinate results lack confirmed administrative district information. It does not cover error behavior or what happens with invalid or conflicting inputs, but the core behavioral traits are transparently stated.
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 sentences with no filler. The core transformation purpose is front-loaded, followed by usage priority and a necessary caveat. Every sentence contributes actionable information, and the structure makes the tool's role immediately understandable.
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 that an output schema exists, the description does not need to explain return values in detail. It covers the input signals, the invocation order relative to other tools, what to do with the results, and a critical estimateness caveat. A slight gap is the absence of guidance for conflicting or incomplete inputs, but for a simple 3-parameter optional tool this is a minor omission.
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 and the description does not need to add much parameter detail. The description does map '지명' to the region parameter and '좌표' to lat/lng, which is helpful context, but the schema already describes each parameter accurately, including the coordinate fallback role. No additional semantic value beyond the schema is provided.
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 clearly states a specific function: converting place names and coordinates into climate, culture, and jurisdiction conditions. It also positions the tool as the first one to call when geographic references appear, which differentiates it from the sibling tools even without naming a direct alternative. However, it does not explicitly distinguish itself from a specific sibling by name, so it falls just short of a 5.
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 usage context: when site, region, administrative district, or coordinates are mentioned, call this tool before others, and pass the returned scope and jurisdiction into downstream queries. It also includes a clear instruction about labeling unconfirmed coordinate results as estimates. It does not explicitly mention when not to use the tool or name alternative tools for exclusions, so it is strong but not maximal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
시공 순서와 선후 관계를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. relation=requires 는 선행 조건, enables 는 후속 가능 작업이다. 빈 결과는 den 이 그 순서를 아직 갖고 있지 않다는 뜻이다 — 순서를 지어내지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | 순회 홉 수 (1~4). | |
| limit | No | 최대 스텝 수. | |
| start | Yes | 시작 개념 이름/구문 (예: 거푸집). | |
| relation | No | 순회할 관계 (requires/enables/causes/contrasts 등). 생략 시 전체. | |
| direction | No | out(정방향) 또는 in(역방향). | out |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It meaningfully discloses what an empty result means and explicitly states that the tool will not invent order relationships, which is important trust-relevant behavior for an AI agent.
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 well-structured: purpose, typical use cases, relation semantics, and empty-result behavior each get exactly one sentence. There is no filler or redundancy.
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?
For a traversal tool with an output schema and fully described parameters, the description covers the crucial domain context: what order means, how relations map to prerequisites vs. follow-ups, and how to interpret empty results. It could be slightly more complete by explaining remaining relation types like 'contrasts', but it is sufficient for 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the semantic difference between 'requires' (선행 조건) and 'enables' (후속 가능 작업), which is not fully captured by the schema's terse relation description.
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 clearly states that the tool follows construction order and precedence relations, with concrete example questions. It is specific enough to distinguish 'traverse' from siblings like answer_why or compare, though it does not explicitly name the closest alternative.
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?
It gives clear guidance on when to use the tool ('공정 질문에 쓴다') with concrete examples such as '기초부터 골조까지 순서'. It does not explicitly state when not to use it or name alternatives, but the intended context is well established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0answer_whycompareemotional_paletteenumerateevidence_forfeedbackk_snippetspath_betweenreview_planscenariosite_contexttraverseSeveral tools operate on the same graph/traversal space: path_between, traverse, and scenario all involve connected nodes and ordering, while answer_why and evidence_for both relate to causal links. The descriptions try to differentiate them, but an agent may still hesitate when choosing among sequence-related tools.
All names are lowercase snake_case, but the semantic pattern is mixed: some are verb-led (compare, enumerate, traverse, review_plan), some are noun-led (scenario, site_context, emotional_palette), and k_snippets is an identifier-like exception. The set is readable but not as predictable as a consistent verb_noun scheme.
Twelve tools is squarely in the ideal range for a domain-specific server. Each tool addresses a distinct mode of querying the construction knowledge graph, and none feels redundant enough to cut.
The surface covers causal reasoning, standards lookup, ordering, comparison, enumeration, site context, plan review, and feedback, which is comprehensive for a construction knowledge assistant. Minor gaps exist: there is no simple general concept/definition retrieval tool, and some graph functions overlap rather than fill a missing lifecycle stage.
A paid remote MCP for CodeG, built to return verdicts, receipts, usage logs, and audit-ready JSON.
MCP server for querying Forkast documentation
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/odd-Innocent/den_archi_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
