This server allows AI assistants to search, retrieve, and analyze Dongguk University's regulations from rule.dongguk.edu.
Search regulations by keyword (title/full-text) with campus filtering using search_rule.
Deep-search with automatic extraction of relevant articles using search_rule_deep.
Retrieve full rule content as markdown (optionally filtered by article/chapter/keyword) with get_rule_content.
View a rule's table of contents via get_rule_toc.
List revision history with list_rule_history.
Recommended: lookup_dongguk_rule for one-shot comprehensive search and original document retrieval (note: may not be in the current tool schema).
Compare two versions of a rule with compare_rule_versions (also may not be available in schema).
Supports HTTP mode for integration with remote clients like Notion AI and Claude Desktop.
Returns structured JSON with error codes for programmatic use.
Enables custom Notion AI agents to interact with Dongguk University's rule management system using the MCP server's tools.
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., "@dongguk-rule-mcp 동국대학교 장학 규정 검색해줘"
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.
동국대학교 통합규정관리시스템(rule.dongguk.edu)을 AI에서 직접 검색·조회하는 MCP 서버.
korean-law-mcp에서 영감. 공무원에게 korean-law-mcp가 있다면, 대학 교직원에게는 dongguk-rule-mcp가 있다.
도구 | 설명 |
| v0.8 — 선택 연결한 재무지식 팩에서 필수 사실·판단카드·절차·완료 증빙 조회 |
| v0.8 — 기준일 교내 규정 후보와 Korean Law MCP의 현행 법령·요청 조문 조회, 부분 실패·개정 차이 표시 |
| 기본 권장 — 검색→최신 HWP 원문→관련 조문·별표를 한 번에 조회 |
| v0.7 신규 — 기안문·공문 텍스트의 규정 인용을 실존·조문 제목·항 번호까지 대조 (환각 게이트) |
| v0.7 신규 — 기준일의 개정일 기준 후보 선택 + 부칙 시행일 대조 + 현행 대비 변경 요약 |
| 키워드 검색 (제목/전문, 캠퍼스 필터) |
| 규정 본문 마크다운 조회 (조문/장/키워드 필터) |
| 목차만 빠르게 조회 |
| 개정 연혁 목록 |
| 두 HISTORY_ID의 조문별 추가·삭제·변경 비교 |
| 전문검색 → 본문에서 조문까지 자동 추출 |
lookup_dongguk_rule은 HTML 본문에 포함되지 않는 원문 HWP의 별표와 금액표까지 파싱합니다.
Notion AI가 보내는 전체 자연어 query와 짧은 규정명 rule_keyword를 모두 지원합니다.
일반적인 규정 질문에는 이 도구를 먼저 사용하면 여러 도구를 반복 호출할 필요가 없습니다.
verify_rule_citations는 결재 전 인용 점검용입니다. 「규정명」 낫표·가운뎃점 표기(·ㆍ‧•・)·"같은 규정" 조응
(문단 경계에서 승계 중단)을 처리하고, 검색 0건은 ✗(미존재)가 아닌 ⚠(확인필요)로 보고합니다 — ⚠는 통과가 아닙니다.
applicable_rule은 연혁의 '개정일' 기준으로 기준일 적용본을 특정하되, 본문 부칙에서 명시 시행일을 추출해
시행일이 기준일 이후면 직전 개정본 적용 가능성을 경고합니다 (개정일≠시행일 한계 상시 고지).
검색어에는 별칭 사전이 적용됩니다 — 내장 별칭에 더해 DONGGUK_RULE_ALIASES(JSON 경로)로 부서별 약칭을 확장할 수 있습니다.
모든 도구는 기존 Markdown content와 함께 structuredContent를 반환합니다. 자동화에서는
ok, tool, data 또는 error.code를 사용하면 텍스트를 다시 파싱하지 않아도 됩니다.
대표 오류코드는 INVALID_ARGUMENT, NOT_FOUND,
UPSTREAM_UNAVAILABLE, UPSTREAM_FORMAT_CHANGED, HISTORY_NOT_FOUND, CONTENT_UNAVAILABLE입니다.
통합 조회는 검색 결과의 오래된 HISTORY_ID 대신 연혁의 첫 개정본을 선택합니다. 연혁 캐시는 최대 10분이며, 최신 개정본이 특정 기준일에 시행 중이라는 뜻은 아닙니다. 개정 비교는 두 HISTORY_ID가 해당 규정 연혁에 있는지 확인하며, HTML 조문만 비교합니다. HWP 별표·첨부 변경과 시행일 판단은 비교 범위에 포함되지 않습니다.
Related MCP server: hansung-university-regulation-mcp
Node.js 18 이상 (node --version으로 확인)
원문 서버에 접근 가능한 네트워크 (HTTP 503은 일시 장애·접속 제한 등 원인을 추가 확인해야 함)
Claude Desktop 설정에 아래만 추가하면 설치·실행이 자동으로 됩니다 (Node 18+ 필요):
{
"mcpServers": {
"dongguk-rule": {
"command": "npx",
"args": ["-y", "github:buenosiempre-cmd/dongguk-rule-mcp"]
}
}
}Releases에서 tgz 다운로드 후:
npm install -g ./dongguk-rule-mcp-0.8.0.tgz
dongguk-rule-mcp --version # 0.8.0 나오면 성공git clone https://github.com/buenosiempre-cmd/dongguk-rule-mcp.git
cd dongguk-rule-mcp
npm install
npm test # 오프라인 회귀 검증
node src/index.js --versionnpm install -g dongguk-rule-mcpclaude_desktop_config.json 위치:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
글로벌 설치(방법 A/C) 시:
{
"mcpServers": {
"dongguk-rule": {
"command": "dongguk-rule-mcp"
}
}
}소스 폴더(방법 B) 시:
{
"mcpServers": {
"dongguk-rule": {
"command": "node",
"args": ["/절대경로/dongguk-rule-mcp/src/index.js"]
}
}
}설정 후 Claude Desktop 완전 종료 → 재시작.
Notion 등 원격 MCP 클라이언트는 공개 URL만 연결할 수 있습니다. rule.dongguk.edu가 해외/데이터센터 IP를 차단하므로, 국내 IP의 상시 가동 머신(예: Mac Mini)에서 HTTP 모드로 실행하고 Cloudflare Tunnel로 URL을 노출하는 구성을 권장합니다.
dongguk-rule-mcp --http --port 3845 --token '아무-긴-비밀문자열'
curl -s http://127.0.0.1:3845/health # {"status":"ok",...} 확인--token 생략 시 무인증(테스트용) — 공개 노출 시엔 반드시 설정하세요.
옵션: --host 0.0.0.0, env DONGGUK_MCP_TOKEN / DONGGUK_MCP_PORT.
brew install cloudflared
cloudflared tunnel --url http://127.0.0.1:3845
# → https://xxxx.trycloudflare.com 발급 (임시 URL)
# 상시 운영은 named tunnel + 도메인 연결 권장워크스페이스 관리자: 설정 → 연결 → MCP → Custom MCP
URL https://xxxx.trycloudflare.com/mcp + 표시 이름 + Bearer 토큰 → 연결
일반 Notion AI 새 채팅에서 연결 이름을 명시해 질문
읽기 전용 도구를 반복 승인하지 않으려면 해당 연결의 모든 도구를 항상 허용
커스텀 에이전트의 Tools & Access에서도 동일 URL을 연결할 수 있습니다.
curl -s -X POST https://xxxx.trycloudflare.com/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'Authorization: Bearer 아무-긴-비밀문자열' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'참고: HTTP 모드는 stateless(POST 전용)이며 GET /health로 모니터링합니다.
연결 UI가 Bearer 헤더를 지원하지 않으면 지원되는 인증 게이트웨이를 구성해야 합니다.
URL을 숨기는 것만으로는 인증을 대체할 수 없습니다.
"동국대 보수규정 검색해줘"
"lookup_dongguk_rule로 여비규정에서 국내, 철도운임, 숙박비, 일비 기준을 한 번에 찾아줘"
"LAW_ID 491 본문 보여줘"
"취업규칙 HISTORY_ID 3478과 3619의 제86조를 비교해줘"
"제10조의2만 보여줘" / "부칙 제2조만 보여줘"
"그 규정에서 퇴직금 관련 조문만" (grep 필터)
"제5장만 보여줘" (chapter 필터)
"이 규정 개정 이력 알려줘"
"이 품의서 초안의 규정 인용 검증해줘: (본문 붙여넣기)" (v0.7)
"2024년 3월 15일 당시 여비규정 제9조 보여줘" (v0.7)
npm test오프라인 테스트는 운영 파서·별칭·시점·인용·MCP·HTTP·신뢰성 회귀를 검증합니다.
npm pack --dry-run으로 필수 소스와 테스트 포함 여부를 검증합니다.
npm run test:live # 검색어 "재정"
npm run test:live -- --keyword 보수rule.dongguk.edu에 실제 접속해 검색·본문·연혁·HWP 원문 경로를 확인. 503이면 "국내 IP에서 실행하라"고 안내 후 종료.
증상 | 원인 | 해결 |
| 해외/데이터센터 IP 차단 | 가정·캠퍼스 등 국내망에서 실행 |
| 의존성 미설치 | 프로젝트 폴더에서 |
| 권한 부족 |
|
Claude에 도구 안 보임 | config 오타/캐시 | JSON 문법 확인 후 Claude 완전 재시작 |
구버전 Node 에러 | Node <18 |
|
검색 0건 | 캠퍼스 코드 불일치 |
|
변수 | 용도 |
| 비공개 규정 열람용 로그인 쿠키 주입. 쿠키별 전용 캐시 사용 |
| 디스크 캐시( |
| 별칭 사전 확장 JSON 경로. |
캠퍼스 LAWGROUP 코드(seoul=1, wise=2)는 추정값 — npm run test:live의 [5] 섹션 결과가 0행이면 브라우저 개발자도구 Network 탭에서 LAWGROUP= 실제 값 확인 필요.
공식 API가 아닌 HTML 파싱이므로 사이트 개편 시 파서 갱신 필요. 그 경우 실제 HTML로 test/fixtures.js를 갱신하고 npm test로 재검증.
비공개 규정 캐시는 쿠키 해시별로 분리하고 디렉터리 0700, 파일 0600 권한으로 저장합니다.
원본 Python 구현: 서준호
Node.js MCP 포팅·하드닝·npm 배포 구조: 오승훈 (동국대 재무팀)
영감: korean-law-mcp (류승인, 광진구청)
MIT
기존 9개 규정 도구는 그대로 동작합니다. 두 재무 도구는 운영자가 검토한 비식별 지식팩 JSON을
DONGGUK_FINANCE_PACK_PATH로 연결해야 합니다. 개인별 급여·계좌·신고 원시행은 팩에 넣지 않습니다.
팩은 공개 소스 저장소와 별도로 보관하고 배포합니다.
get_finance_context: 질문을 업무 경로로 연결하며, 부족한 사실과 검토 필요 상태를 반환합니다.
get_finance_evidence: 규정 최대 2건, 법령 최대 2건을 조회합니다. 교내 규정은 기준일의 개정일 후보, 국가 법령은 검색 시점 현행 후보입니다. 시행일·경과조치와 실제 적용성은 별도 확인합니다.
HWP 대체·발췌 누락·법령 실패는 partial로 표시합니다. 개정본 식별자 변경은 특정 조항의 변경을 뜻하지 않습니다.
신고·납부·결재·지급·Slack 발송을 수행하지 않습니다.
Korean Law MCP는 DONGGUK_LEGAL_MCP_ENABLED=1, LAW_OC, 고정 버전 실행 경로를
DONGGUK_LEGAL_MCP_COMMAND와 DONGGUK_LEGAL_MCP_ARGS (JSON 배열)로 설정합니다.
비밀값은 소스·로그가 아닌 접근제한 환경파일이나 서비스 비밀변수에 둡니다.
test/evaluate-finance.js는 50개 라우팅·입력·법령 식별 파싱 사례를 검증합니다.
DONGGUK_FINANCE_PACK_PATH를 지정하면 실제 팩을, 생략하면 비식별 테스트 픽스처를 사용합니다.
자동 통과율은 법률 정답률이나 실제 업무시간 절감률이 아닙니다.
규정 본문 마크다운 조회. history_id 생략 시 최신. article/chapter/grep 필터 지원.
| Name | Required | Description | Default |
|---|---|---|---|
| grep | No | 키워드 포함 조문 | |
| head | No | 상위 N줄 | |
| law_id | Yes | LAW_ID | |
| article | No | 특정 조문만 | |
| chapter | No | 특정 장만 | |
| history_id | No | HISTORY_ID (생략=최신) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses output format (markdown) and default behavior (history_id omitted yields latest). It adds value beyond the input schema by explaining the result type and filter capabilities.
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 a single concise sentence in Korean that efficiently conveys the primary function, default behavior, and filter options. Every word adds value with no 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?
Given the lack of output schema, the description adequately explains the return format (markdown) and filtering parameters. It covers essential behavioral traits for a content retrieval tool, though more detail on response structure could be helpful.
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's mention of filters and default history_id behavior mostly repeats what is already in the schema descriptions, adding no significant new meaning.
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 retrieves regulation body content in markdown format, uses a specific verb (retrieve), and distinguishes from siblings like get_rule_toc (table of contents) and list_rule_history (history list).
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 provides context on when to omit history_id (defaults to latest) and mentions supported filters (article/chapter/grep). However, it lacks explicit guidance on when to use alternatives like get_rule_toc or search_rule, though sibling tool names give context.
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 |
|---|---|---|---|
| law_id | Yes | ||
| history_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only says 'quick lookup,' implying a read operation, but does not confirm whether it is safe or idempotent, nor does it mention any side effects, authentication needs, or rate limits.
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 extremely short (one sentence), which is concise, but it sacrifices necessary detail. It is front-loaded with the core purpose, yet every word is earned; still, it is underspecified for a tool with no other documentation.
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 complexity (2 parameters, 1 required, no output schema, sibling tools), the description is insufficient. It does not explain the return format, how to use history_id, or how this tool fits into the overall workflow of the regulation tools.
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?
With 0% schema description coverage, the description must compensate but fails. It does not explain the meaning of law_id or history_id, nor how they relate to the table of contents lookup. The description adds no value beyond the parameter names.
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 ('quick lookup') and resource ('regulation table of contents, chapters, sections, articles'), clearly indicating the tool's purpose. However, it does not differentiate from sibling tools like get_rule_content or search_rule, which could cause confusion.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, typical use cases, or when to choose a sibling tool.
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 |
|---|---|---|---|
| law_id | Yes | LAW_ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or output format. It merely restates the tool's purpose.
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?
Single concise sentence that conveys the essential purpose without 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?
Given the simplicity (one parameter, no output schema), the description covers the purpose but lacks details on the output structure or expected behavior.
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% with description for law_id, but the tool description adds no additional meaning beyond the schema. 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 clearly states the action (list/retrieve) and the resource (rule amendment history). It is specific and differentiates from sibling tools like get_rule_content and get_rule_toc.
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?
No guidance on when to use this tool versus alternatives. No exclusions or prerequisites mentioned beyond the required law_id parameter.
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 |
|---|---|---|---|
| limit | No | ||
| campus | No | all/seoul/wise | all |
| offset | No | ||
| keyword | Yes | 검색어 | |
| full_text | No | 전문검색 여부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates both title and full text search, but the 'full_text' parameter defaults to false, creating ambiguity about default behavior. No mention of pagination, result structure, or required permissions.
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?
One sentence with an example; no wasted words. However, it could be more structured (e.g., bullet points) for clarity.
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 5 parameters, no output schema, and sibling tools, the description is too brief. Lacks details on output format, campus usage, pagination, and when to use 'full_text'. Incomplete for effective selection.
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 60% (3 of 5 parameters described). The description adds minimal parameter context: 'keyword search (title/full text)' implies keyword and full_text relevance but does not explain 'limit', 'offset', or 'campus'. Examples help but don't compensate for undocumented params.
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 searches Dongguk University regulations by keyword in title or full text, with examples. This is specific and distinct from sibling tools like 'get_rule_content', but does not explicitly differentiate from 'search_rule_deep'.
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?
No guidance on when to use this tool vs. siblings, no prerequisites or exclusions. The description only implies a keyword search use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
전문검색 → 상위 N개 규정 본문에서 키워드 조문 자동 추출.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| query | Yes | ||
| per_doc | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It mentions 'automatically extracts' but does not disclose whether the tool is read-only, requires authorization, or has limitations on the extraction process.
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 a single concise sentence that front-loads the core functionality. However, it could be expanded slightly without losing conciseness.
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 no output schema, 3 parameters, and no annotations, the description is too minimal. It does not explain the output format or how to use the 'per_doc' parameter, making it incomplete for an agent to invoke 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 0%, and the description only loosely maps 'top N' to the 'top' parameter and 'keyword' to 'query'. The 'per_doc' parameter is not explained, leaving its meaning ambiguous.
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 performs full-text search and automatically extracts keyword clauses from the top N regulation texts. It distinguishes itself from sibling 'search_rule' by adding 'deep' extraction capability.
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?
No guidance on when to use this tool versus alternatives like 'search_rule'. The description lacks context on prerequisites or conditions for use.
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.
v0.4.0get_rule_contentget_rule_toclist_rule_historysearch_rulesearch_rule_deepEach tool targets a distinct operation on university regulations: retrieving full content, table of contents, revision history, shallow keyword search, and deep article extraction. No overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_rule_content, search_rule_deep), making the set predictable and easy to navigate.
With 5 tools for a narrow domain (university regulations), the count is well-scoped. Each tool serves a clear need without redundancy or missing essentials.
The set covers all major read operations: retrieving content, structure, history, and keyword search. A minor gap is the lack of a tool to list all rule titles without a search query, but the search tools can compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Full-text search over FSS/FSC accounting supervision documents for Korean accounting professionals
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
Curated Korean AEC expertise for AI agents — codes, practice, and the reasoning between them.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/buenosiempre-cmd/dongguk-rule-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server