Servidor MCP de Den

• Nombre en el registroarchi.den/den_archi_mcpverificado en el registro MCP

El nombre en el registro está bajo den.archi. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-24
• Herramientas13
• El servidor se llamaden-mcp
• Versión del servidor1.28.1
• Versión del protocolo2025-06-18

El 2026-10-24 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 473 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 4 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 4 hasta ahora
• Respondiómidiendo4 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta543 ms
• Espacio en el contexto del agente≈ 4080 tokenslas definiciones de todas sus herramientas (13), que el agente lleva en cada turno
• Definiciones de herramientasA · 100 de 100
• Resultados tipados13 de 13 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Todas las herramientas pasan las seis comprobaciones.

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• answer_why

  건축·공간의 **왜·원리·득실**을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. → 대신 쓸 것: 이미 아는 인과 **한 줄의 근거만** 확인하려면 evidence_for · 두 개념이 **이어지는지만** 보려면 path_between · **수치·조문**이 필요하면 k_snippets · 용어 **뜻**만 물으면 define. ★파라미터…

• path_between

  두 개념이 **어떻게 이어지는지** 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 **출발·도착이 분명할 때** 쓴다. → 대신 쓸 것: 한 지점에서 **관계를 따라가며** 훑으려면 traverse · 공정 **전체 흐름**이면 scenario · **왜 그런지 설명**이 필요하면 answer_why · **한 연결의 근거**만이면 evidence_for. ★파라미터: a·b 는 문장이 아니라…

• evidence_for

  "A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 **경로를 찾는** 것이면 path_between · **왜 그런지 설명**이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 **이미 아는 한 엣지**를 겨눈다. ★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다…

• k_snippets

  한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: **용어 뜻**은 define · **종류 열거**는 enumerate · **공정 순서**는 scenario · **두 공법…

• scenario

  공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 **시퀀스·시나리오** 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k_snippets · **두 지점 사이**만 궁금하면 path_between · 한 노드의 **선후 이웃**만이면 traverse · 두 공법 **차이**는…

• compare

  두 공법·개념의 **차이**를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 **비교/차이** 요청에 호출하라. → 대신 쓸 것: 단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k_snippets. ★파라미터: a·b 는 **개념/공법 이름**이다(질문 문장 아님). 'A vs B' 를 a 에 한 번에 주면 b 를 비운다…

• enumerate

  어떤 것의 **종류·구성요소·분류**를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 **'X의 종류/체계'** 요청에 호출하라. → 대신 쓸 것: 순서는 scenario · 비교는 compare · **한 용어의 뜻**은 define · 수치·조문은 k_snippets. ★파라미터: query 는 'X의 종류/체계/구성요소' 꼴로 준다. 낱말 하나만 주면(예: '하중')…

• define

  건축·건설 **용어 하나의 뜻**을 돌려준다 — '이형철근이 뭔가', '방화구획이란', '옹벽과 흙막이의 정의' 같은 **'X가 무엇인가'** 질문에 호출하라. → 대신 쓸 것: **수치·조문**이 필요하면 k_snippets · **종류/체계 열거**는 enumerate · **왜 그런지**는 answer_why · **두 개념 차이**는 compare · 두 개념이 **어떻게 이어지는지**는 path_between. 이…

• traverse

  **시공 순서와 선후 관계**를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. → 대신 쓸 것: 출발·도착 **두 지점이 분명하면** path_between · 공정 **전체 흐름**을 한 번에 구성하려면 scenario · 두 공법 **차이**는 compare · 단순 수치·조문은 k_snippets. ★파라미터…

• site_context

  지명·좌표를 **기후·문화·관할** 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 **먼저** 부른다. → 그다음: 돌아온 scope 를 k_snippets·answer_why 에, jurisdiction 을 review_plan 에 넘긴다. 이 도구 자체는 기준·수치를 주지 않는다 — 수치는 k_snippets, 도면 검토는 review_plan. ★파라미터: region 을 **먼저** 본다…

• emotional_palette

  공간을 순서대로 지날 때의 **분위기 전이**를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방"처럼 이동 순서와 체험 목표가 있을 때 쓴다. → 대신 쓸 것: 작품 평가나 "왜 걸작인가" 같은 **이유**는 answer_why · 법규 관점 평면 검토는 review_plan · 공정 순서는 scenario. 이 도구는 **체험 순서**만 다룬다. ★파라미터: spaces 는 **실제 이동 순서**로 넣는다…

• review_plan

  평면도·배치도를 **건축 법규 관점에서 검토**한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. → 대신 쓸 것: 특정 **수치·조문 하나**의 근거면 k_snippets · **왜 그 요건인지**는 answer_why · 체험·분위기 관점이면 emotional_palette. 대지의 관할이 걸리면 site_context 를 **먼저** 부르고 그…

• feedback

  사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다…