DAPA MCP es un servidor de Model Context Protocol de solo lectura que apoya el trabajo de adquisición de defensa de la República de Corea. En lugar de la memoria del LLM, consulta la Open API 국가법령정보 공동활용 de 법제처 y DAPA_info, con las fuentes indicadas. El principio central es Search → Retrieve → Verify → Compare → Cite → Explain.
v0.1.0 implementa el Core y la primera fase de paridad MCP de información legal. Proporciona stdio local, 17 herramientas, el catálogo oficial de leyes y reglamentos administrativos de DAPA, la estructuración detallada de las leyes, la consulta del historial y la búsqueda por fecha de referencia. Streamable HTTP, patentes, artículos, noticias, datos abiertos y comparación de disposiciones antiguas y nuevas aún no están implementados y se detallan en ROADMAP.md.
Se priorizan las fuentes oficiales para no confundir la legislación vigente con disposiciones pasadas o derogadas.
Se vuelve a consultar y verifica el nombre de la ley, los artículos y los números de caso citados.
Se distingue entre NOT_FOUND, que es un resultado normal de 0 casos, y SOURCE_UNAVAILABLE, que corresponde a timeout, 429, 5xx o respuestas corruptas.
Se añaden fuente, fecha de verificación y estado de validación también al conocimiento de la organización y los procesos de trabajo.
Related MCP server: Korean Law MCP Server
Claude / Gemini / Codex / MCP Client
│ stdio
▼
DAPA MCP Tool Registry
├── LawProvider ── 국가법령정보 Open API
├── DapaCatalogProvider ── DAPA 공식 목록 스냅샷
└── DapaInfoProvider ── DAPA_infoPara el diseño detallado y el registro de benchmarks, consulta docs/ARCHITECTURE.md.
Los requisitos son Node.js 20.19 o superior.
npm install
cp .env.example .env
npm run build
npm test
npm run startnpm run start es un servidor JSON-RPC por stdio, por lo que es normal que se quede a la espera en la terminal. No imprime registros normales en stdout.
Para actualizar la lista oficial de leyes y reglamentos administrativos de DAPA, ejecuta el siguiente comando.
npm run sync:dapa-catalogPara contrastar cada elemento del catálogo con los resultados vigentes de la Open API 국가법령정보 공동활용 y generar la lista de elementos no coincidentes, ejecuta el sigiente comando. El script de desarrollo recibe explícitamente el valor de autenticación báica público.
LAW_API_OC=dusgh4847 npm run audit:dapa-catalogEn PowerShell, se ejecuta de la sigiente manera.
$env:LAW_API_OC = "dusgh4847"
npm run audit:dapa-catalog
Remove-Item Env:LAW_API_OCEl resltado se guarda en DAPA_info/legal/coverage-report.json. missing sigifica que el títlo de la lista oficial de DAPA no se encotró de forma idéntica en la API de información legal nacional; no afima la inexistencia jurídica. Los elemetos con historial de derogación o promlgación, diferenias en la notación del títlo o cuyo texto original solo se oferce como archivo requieren una verificación adicioal. title_variant es el caso en que el títlo mostrado por DAPA y el títlo canónico de la API difieren, pero se ha confimado como documeto correspndiente. metadata_mismatch es el caso en que el títlo coincide, pero difieren el númeto de promlgación y la fecha de promlgación del reglameto adinistrativo; external_only es una ley para la que DAPA solo oferce un enlace exteno al texto original fuera de la información legal nacional.
Este iforme depede de la istantáea del catálogo. Si vuelves a sincronizar el catálogo, debes volver a ejecutar la auditoía; el númeto de missing no indica inexistencia jurídica, sino candidatos que aún no se han vinculado con los documetos de la API. Por tato, no se cosidera que todo el catálogo esté totalmete cubieto por el texto de la iformación legal nacional.
Para actualizar el meú 업무·정책 y el coetido de las pestañas secndarias de cada página en DAPA_info/policy/catalog.json, ejecuta el sigiete comando. Solo se recopilan las páginas iternas de 방위사업청 y se elimian duplicados según menuSeq y el ID final de la página. Si se ejecuta dos veces a la vez, se detecta el archivo de bloqueo y la seguda sincronización finaliza.
npm run sync:dapa-policyPara llamar secuencialmete a las 14 caterías oficiales y 40 APIs detalladas cotra el servido de producción actual y comprobar el enlace lista-cuerpo y los errores, ejecuta el sigiete comando. El código de muestra báico personalizado utiliza los códigos L/A/O de la guía oficial y puede sustituirse medinte variables de entorno.
LAW_API_OC=dusgh4847 npm run backtest:law-apiNombre | ¿Requerido? | Valor por defecto | Descripción |
| No |
| Valor de autenticación básica pública de la Open API |
| No |
| Timeout de solicitud |
| No |
| Límite de reintentos para 429/5xx |
| No |
| TTL de caché de búsqueda de API (ms); |
| No |
| Bytes máximos de respuesta de API JSON/HTML |
| No |
| Bytes máximos para archivos de anexos y formularios |
| No |
| Número máximo de caracteres de salida JSON de las herramientas MCP de la API de leyes |
| No |
| Raíz del conocimiento público |
El valor de autenticación básica dusgh4847 se publica en el código y la documentación para que cualquiera pueda usarlo de inmediato. Para usar un valor de autenticación distinto, redefine LAW_API_OC. .env está excluido de Git.
La API de leyes se puede usar con el valor de autenticación básica sin un procedimiento de autenticación adicional. Si tienes tu propio valor de autenticación, el cliente MCP lo pasa como variable de entorno LAW_API_OC al iniciar el servidor y verifica law: healthy en source_health.
Herramienta | Función |
| Búsqueda de leyes, reglamentos administrativos, jurisprudencia, decisiones del Tribunal Constitucional, interpretaciones legales y recursos administrativos |
| Consulta la lista de candidatos de la API de información legal nacional y, a continuación, el cuerpo detallado y los artículos de cada documento |
| Consulta detallada del |
| Consulta el historial de promulgación, modificación y derogación de leyes |
| Consulta el catálogo de las 14 categorías y 40 APIs de listado/cuerpo de información legal nacional relacionadas con DAPA |
| Consulta bajo demanda del listado y el cuerpo oficiales mediante el |
| Conexión automática de la API de cuerpo a partir del |
| Verifica artículos de leyes y números de caso |
| Búsqueda de conocimiento público de organización, terminología y trabajo |
| Consulta detallada de nombres de organización y alias |
| Búsqueda en el menú de trabajo/política y en el contenido de las pestañas secundarias |
| Consulta del contenido completo de trabajo/política mediante el ID del resultado de búsqueda |
| Búsqueda en el catálogo oficial de leyes y reglamentos administrativos de DAPA |
| Consulta detallada de un elemento del catálogo oficial de DAPA |
| Consulta de los elementos de DAPA vinculados al cuerpo de información legal nacional |
| Estado de sincronización del catálogo oficial de DAPA |
| Comprobación de la configuración y el estado del proveedor |
committee_decision solo proporciona el contrato de entrada; todavía no se configura un proveedor real. asOfDate se procesa mediante la búsqueda por fecha de referencia eflaw de 법제처; si no hay datos para esa fecha, devuelve NOT_FOUND. El valor predeterminado de currentOnly es true y también excluye los estados explícitos de historial o derogación de los reglamentos administrativos. Si necesitas datos históricos, usa currentOnly: false; si necesitas volver a consultar la API más reciente, usa forceRefresh: true. El TTL de caché predeterminado para resultados de búsqueda correctos es de 5 minutos.
list_legal_apis solo devuelve los metadatos de las APIs de las 14 categorías siguientes. Como query_legal_api consulta el listado en 법제처 en el momento de la solicitud y get_legal_api_body recibe el identificador del resultado del listado o el enlace adjunto para consultar el cuerpo, no se cargan todos los datos legales en el contexto MCP ni en DAPA_info. Cada API de list_legal_apis devuelve también un bodyTool ejecutable y, si existe una API de cuerpo separada, bodyApiId.
Categoría | Procesamiento de listado/cuerpo |
Informe de consulta previa | Listado/cuerpo de |
Primera interpretación de los ministerios centrales | Listado/cuerpo de |
Base de conocimiento de información legal | 9 tipos: términos, artículos, legislación relacionada y búsqueda inteligente |
Personalizada | Listados y artículos de leyes, reglamentos administrativos y ordenanzas locales, 6 tipos; requiere |
Terminología legal | Listado/cuerpo de |
Anexos y formularios | Listados de leyes, reglamentos administrativos y ordenanzas locales y extracción del texto original de HWP/HWPX/PDF/XLSX/DOCX |
Tratados | Listado/cuerpo de |
Decisiones del Tribunal Constitucional | Listado/cuerpo de |
Interpretaciones legales | Listado/cuerpo de |
Recursos administrativos | Listado/cuerpo de |
Leyes | Listado/cuerpo de |
Reglamentos administrativos | Listado/cuerpo de |
Ordenanzas locales | Listado/cuerpo de |
Jurisprudencia | Listado/cuerpo de |
Como los anexos y formularios no tienen una API de cuerpo independiente en la guía oficial, se pasa 별표서식파일링크 o 별표서식PDF파일링크 de la respuesta del listado a attachmentUrl de get_legal_api_body. El servidor descarga únicamente enlaces oficiales de 법제처 y convierte el archivo en cuerpo Markdown. El listado personalizado se interpreta mediante la API de cuerpo de legislación general vinculada, y la API de artículos personalizada mediante su propia respuesta.
El catálogo de DAPA conserva los metadatos de alcance, clasificación y emisión del sitio web oficial, mientras que los artículos reales y el cuerpo legal se consultan en la API 국가법령정보 공동활용 mediante search_legal y get_legal_detail.
En todos los ejemplos, reemplaza /absolute/path/to/DAPA MCP por la ruta absoluta real y compila primero.
El comando actual para registrar el stdio local en Codex CLI tiene la siguiente forma.
codex mcp add dapa-mcp -- node "/absolute/path/to/DAPA MCP/dist/index.js"
codex mcp listUsa el formato stdio de la documentación oficial de MCP de Claude Code.
claude mcp add --transport stdio dapa-mcp -- \
node "/absolute/path/to/DAPA MCP/dist/index.js"
claude mcp listClaude Desktop recomienda actualmente distribuir el servidor local como Desktop Extension. v0.1.0 no proporciona un paquete .mcpb, por lo que durante el desarrollo se usa la conexión stdio de Claude Code.
Según la documentación oficial de MCP de Gemini CLI, añádelo a mcpServers en ~/.gemini/settings.json.
{
"mcpServers": {
"dapa-mcp": {
"command": "node",
"args": ["/absolute/path/to/DAPA MCP/dist/index.js"],
"timeout": 30000,
"trust": false
}
}
}Las herramientas MCP del custom connector de ChatGPT y de la API de OpenAI Responses utilizan un server_url remoto de MCP. v0.1.0 es exclusivo de stdio local, por lo que no se indica que admita la conexión directa. A partir de la Fase 2, cuando se añadan Streamable HTTP y autenticación, se conectará según la documentación oficial de Remote MCP de OpenAI.
Los elementos estructurados se escriben como JSON con una matriz items. Los campos obligatorios son id, name, category, description, source, sourceUrl, lastVerifiedAt y verified. La información no verificada se guarda con verified: false y no se presenta como un hecho oficial. El material explicativo se mantiene en Markdown y se indica que no sustituye la base legal.
{
"items": [
{
"id": "term-example",
"name": "예시 용어",
"aliases": [],
"category": "terminology",
"description": "쉬운 설명",
"source": "공식 문서명",
"sourceUrl": "https://example.go.kr/source",
"lastVerifiedAt": "2026-08-27",
"verified": false
}
]
}npm run lint
npm run typecheck
npm test
npm run buildLas pruebas incluyen normalización, búsqueda local de conocimiento, simulacro de la API oficial (wire fake), respuestas 429/5xx/corruptas, verificación de citas y listado y llamadas reales de MCP por stdio.
Solo se almacena información que puede hacerse pública. Quedan prohibidos los datos personales, la información comercial no pública, los secretos militares y las direcciones de redes internas.
Los resultados de MCP no sustituyen una opinión legal ni una decisión de política.
verified: true significa que el dato se consultó en una fuente oficial; no es una garantía de juicio legal.
Las noticias, aunque se añadan más adelante, no se usarán como base legal.
Benchmark: korean-law-mcp, MIT
El código fuente se distribuye bajo la MIT License. Los derechos y las condiciones de uso de los datos proporcionados siguen las políticas de cada organización proveedora original. El aviso detallado se encuentra en NOTICE.
DAPA 공식 법령·행정규칙 카탈로그의 동기화 상태를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is well covered. The description adds that the returned value is about catalog synchronization, but it does not describe response freshness, format, possible failure modes, or any operational behavior beyond the annotated read-only nature.
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 states the resource and the returned information without filler or redundant phrasing. It is appropriately minimal for a zero-parameter status tool.
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 parameterless, read-only status tool, the description is mostly adequate, and the annotations cover side-effect safety. However, there is no output schema, and the description does not explain what 'synchronization status' means or what possible values an agent should expect, leaving some ambiguity about how to interpret the response.
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?
The input schema has no properties, so there are no parameters to document. With 0 parameters, the baseline of 4 applies, and the description justifiably contains no parameter-level detail.
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 action and resource: it returns the synchronization status of the DAPA official laws and administrative rules catalog. However, it does not explicitly differentiate itself from siblings such as source_health, which may also relate to status-like queries.
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 no guidance about when to use this tool versus alternatives, and no exclusions or preferred conditions. The only implied usage is 'when you need the catalog sync status,' but the description does not discuss sibling tools or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DAPA 공식 법령·행정규칙 카탈로그 항목을 ID로 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the domain scope but does not describe return shape, not-found behavior, or input errors; still, no contradiction exists and the annotations carry most of the burden.
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?
A single, front-loaded sentence with no filler. It immediately names the domain and operation, and is appropriately sized for a simple one-parameter lookup tool.
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 simple get-by-ID operation with rich annotations and a single required parameter, the description is mostly sufficient. It lacks an explicit statement of what is returned or how to obtain the ID, but the level of complexity is low and the basic retrieval contract is clear.
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?
The only parameter, id, is documented in the schema as a non-empty string, and the description adds only that the lookup is 'by ID'—which the tool name already conveys. With 0% schema description coverage, the description needed to compensate by explaining what kind of ID this is or how it relates to the catalog, but it does not.
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 (retrieve), a precise resource (DAPA official statutes/administrative rules catalog item), and the lookup method (by ID). This clearly distinguishes it from sibling search/list tools even though no sibling is named.
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 'by ID' phrasing implies this tool is for known catalog-item IDs rather than searching, but the description never explicitly says when to use it versus sibling tools such as search_dapa_legal_catalog or get_dapa_legal_content. Usage context is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DAPA 카탈로그 ID를 국가법령정보 문서와 연결해 실제 본문을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the mapping behavior from DAPA catalog ID to national legal document, but it does not disclose error behavior, availability limits, or output characteristics beyond 'actual body text.'
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?
A single, front-loaded Korean sentence states the input, the linking action, and the return object with no filler. Every phrase earns its place.
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, read-only, idempotent tool, the core call semantics are present: supply a DAPA catalog ID and receive the legal body text. However, the lack of sibling-differentiation guidance and any note on output format or errors leaves a moderate gap for an agent choosing among many similar legal-content 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?
The schema only defines 'id' as a required string with no description, so the tool description carries the burden; it usefully identifies the parameter as a DAPA catalog ID and explains its role in resolving the legal document. It stops short of providing a format, example, or accepted identifier pattern, which would add more value.
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 identifies the resource: it connects a DAPA catalog ID to a national legal information document and retrieves the actual body text. '실제 본문' signals that this is a content-fetching tool rather than a catalog or search tool, though it does not explicitly differentiate from siblings.
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 implies a use case (you have a DAPA catalog ID and need the legal body text) but provides no explicit when-to-use or when-not-to-use guidance. With siblings such as get_legal_api_body, search_legal_content, and get_dapa_legal_catalog_item, the agent is not given criteria for selecting this tool over 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 |
|---|---|---|---|
| query | Yes | 조직명 또는 별칭 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the method of lookup (by name or alias) but does not go beyond that; no contradictions exist.
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, tightly written Korean sentence that conveys the resource, the lookup key, and the operation. Every word earns its place; there is no redundancy or 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 simple, read-only lookup tool with one well-documented parameter and rich safety annotations, the description is complete enough for an agent to select and invoke it correctly. No output schema exists, but the phrase '조직 상세' sufficiently indicates the return is organization detail information.
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%: the single required parameter 'query' is already documented as '조직명 또는 별칭' (organization name or alias). The description essentially restates this same meaning without adding format, examples, or disambiguation guidance, so it adds no new semantic value 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 ('조회합니다' - retrieves) with a clear resource ('방위사업청 조직 상세' - DAPA organization details) and a clear lookup method (by organization name or alias). It is unambiguous and distinct from the legal/policy-focused sibling tools, though it does not explicitly contrast itself with any 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?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about when this lookup is appropriate. The sibling names imply it is organization-related rather than legal/policy-related, but that inference is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_dapa_policy에서 받은 ID로 업무·정책 페이지 전체 본문을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that the tool returns the entire page body, which is useful, but it doesn't disclose return format, error behavior, or any additional constraints. This is adequate but not rich.
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?
A single, front-loaded sentence with no filler. It efficiently communicates the action, resource, and parameter source in one compact statement.
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 is simple: one parameter, no output schema, and rich safety annotations. The description covers what the tool returns (full body text) and the prerequisite ID source. It is complete enough for the low complexity, though a bit more detail about response format would be ideal.
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 compensates by explaining that the single 'id' parameter is the ID received from search_dapa_policy. This gives the parameter semantic meaning beyond the raw schema, though it does not specify the ID format or how to extract it from search results.
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 ('retrieves the full body text') and the resource ('work/policy page'), and specifies that the ID comes from search_dapa_policy. This distinguishes it from sibling tools like get_dapa_legal_content and search_dapa_policy itself.
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 a clear usage context: call this after search_dapa_policy to fetch the full page body for a returned ID. It does not explicitly list exclusions or alternatives, but the ID-source constraint makes the intended workflow obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
목록 apiId와 결과 식별자로 대응 본문 API를 자동 호출합니다. 별표·서식은 목록의 공식 파일 링크를 내려받아 HWP/HWPX/PDF/XLSX/DOCX 본문을 텍스트로 추출합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| apiId | Yes | ||
| limit | No | ||
| query | No | ||
| customCode | No | 맞춤형서비스 vcode | |
| documentId | No | ||
| forceRefresh | No | 캐시를 사용하지 않고 API에서 다시 조회합니다. | |
| articleNumber | No | 조번호 4자리와 가지번호 2자리 | |
| attachmentUrl | No | 별표·서식 목록 응답의 공식 파일/PDF 링크 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, open-world, idempotent, non-destructive behavior. The description usefully adds implementation behavior beyond that: multiple underlying body APIs may be auto-invoked, and attachment/form bodies are obtained by downloading and text-extracting specific file formats. It does not cover failure/error or rate-limit behavior, but that is a minor gap for a read-only convenience wrapper.
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 front-loaded sentences accomplish the entire description: the primary behavior first, then the special attachment/form extraction path. There is no redundant or filler 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?
The description is complete enough for recognizing the tool's role, and the annotations cover safety. But with nine parameters, a large apiId enum, and no output schema, it does not specify return structure or which parameters are required for particular apiId categories, and it does not route the agent away from sibling body/detail 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?
Schema description coverage is only 44%, and the description partially compensates by explaining that apiId refers to a list API and attachmentUrl is the official file/PDF link used for file extraction. However, it leaves page/limit/query/documentId mapping implicit, referring only to a vague 'result identifier', so it does not fully make up for the missing 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 clearly states the operation: automatically call the corresponding body API using a list apiId and a result identifier, and for attachment/form results download the official file link and extract text from HWP/HWPX/PDF/XLSX/DOCX. It does not explicitly name a sibling tool or contrast itself with query_legal_api/get_legal_detail, so it stops short of full differentiation.
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 intended context is implied: use it when you already have a list apiId and a result identifier and need the full body, or when you need attachment/form text from an official file link. It gives no explicit when-not-to-use guidance or alternatives, so an agent must infer the boundary against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legal에서 받은 documentId로 공식 문서 상세를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | 검색 결과의 documentId | |
| sourceType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds that this is a detail retrieval for official documents but does not explain error handling, missing-document behavior, or whether sourceType must match the search result. With annotations covering the safety profile, this is adequate but not rich.
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?
A single compact sentence with the key precondition front-loaded and no filler. It is appropriately minimal while still conveying the core behavior and input origin.
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 is simple and annotations cover safety, but the required sourceType parameter is effectively unexplained in both schema and description, and no output shape is described. An agent could likely attempt the call, but the description leaves enough inferential gaps that correct invocation is not fully guaranteed.
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?
The description adds useful meaning to documentId by tying it to search_legal's result, though this largely echoes the schema's '검색 결과의 documentId'. sourceType has only enum values and no described semantics or relation to documentId, and with 50% schema coverage the description does not fully compensate for that gap.
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 verb ('조회합니다' – retrieves), the resource ('공식 문서 상세' – official document detail), and the input source ('search_legal에서 받은 documentId'). This makes it distinguishable from sibling content/list tools by anchoring it to search_legal's output.
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 provides a clear precondition: the documentId must come from search_legal, which tells the agent the appropriate calling sequence. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full guidance.
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 | ||
| lawName | Yes | 정확한 법령명 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description carries a lower burden. It adds scoping context for the kind of legal history returned, but says nothing about pagination, limit behavior, or response shape.
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 compact sentence with no filler. It front-loads the source, resource, and action, making the core meaning immediately accessible.
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?
Adequate for a simple read-only lookup: purpose is clear and annotations cover safety semantics. However, no output schema exists and there is no clarification of what the history response contains or how limit applies, leaving minor but real gaps for an agent.
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 only 50%: lawName has a brief description while limit has none. The tool description does not compensate by clarifying limit semantics or adding detail about how lawName should be formatted. With moderate-to-low coverage, this is a notable gap.
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 (조회) and a precise resource: the enactment/amendment/repeal history of statutes from official national legal information. The word '연혁' clearly differentiates this from sibling detail/content/search tools.
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 explicit alternatives or when-not-to-use guidance, despite many overlapping siblings such as get_legal_detail and search_legal. The scope of history retrieval implies usage, but explicit routing would be more helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
국가법령정보 공동활용의 DAPA 관련 14개 범주와 목록·본문 API target을 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, and the description's '조회합니다' is consistent with that. The description adds useful scope about the 14 categories and API targets, but does not disclose return format, pagination, or error behavior; this is acceptable but not rich.
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 short sentence with no filler, and the key domain scope is front-loaded. Every word contributes to identifying what the tool operates on.
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 and no explanation of return values, DAPA, or 'API target', the description leaves important context implicit. It also does not clarify how the optional category parameter affects the returned results, which is essential for a tool meant to list or filter API targets.
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 0%, so the description needed to explain the category parameter's meaning and behavior. It only mentions '14개 범주' without saying whether category is optional, what each enum value maps to, or how omitting it changes the result. The enum values themselves are left fully undocumented.
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 specifies a concrete retrieval action ('조회합니다') and a defined resource: 14 DAPA-related categories and the list/body API targets of the national legal information joint-use service. It is more specific than a mere restatement of the tool name, though 'API target' remains somewhat jargon-heavy.
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 no guidance on when to use this tool versus the many siblings like get_legal_detail, search_dapa_legal_catalog, or get_legal_api_body. An agent would have to infer its discovery/list role from context rather than from explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_legal_apis의 apiId로 공식 목록·본문을 온디맨드 조회합니다. 콘텐츠를 MCP에 사전 적재하지 않습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| apiId | Yes | ||
| limit | No | ||
| query | No | ||
| customCode | No | 맞춤형서비스 vcode | |
| documentId | No | ||
| forceRefresh | No | 캐시를 사용하지 않고 API에서 다시 조회합니다. | |
| articleNumber | No | 조번호 4자리와 가지번호 2자리 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by stating that content is not preloaded into MCP and that retrieval happens on demand. This goes beyond the annotations, though it does not detail caching, rate limits, or response behavior.
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 one concise sentence that front-loads the core action and includes only the most important distinguishing behavior. Every word earns its place, and there is no redundant restatement of the tool name or 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?
The tool has 8 parameters, a large apiId enum, and no output schema, yet the description is very short. It does not clarify which parameters apply to which apiId variants, what the response looks like, or how pagination works. For such a flexible and potentially complex tool, the description is not sufficiently complete.
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 8 parameters and only 38% schema description coverage, the description should compensate for undocumented parameters. It only explains the provenance of apiId and says nothing about page, limit, query, documentId, or how they interact with different apiId values. This leaves a significant parameter understanding gap.
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 action (on-demand retrieval of official lists and full texts) and a specific resource (content identified by the apiId from list_legal_apis). It also distinguishes itself from list_legal_apis by noting that it does not preload content into MCP, which helps separate the listing and querying responsibilities.
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 clear context: use this tool with an apiId obtained from list_legal_apis for on-demand retrieval. It does not explicitly list exclusions or alternative tools, but the reference to list_legal_apis provides a practical usage path. This is clear context without full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공개 출처 기반 DAPA_info에서 조직·용어·업무 지식을 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the search is based on public sources, which is useful context, but it does not disclose other behavioral details such as result ordering, filtering behavior, pagination, or any limitations. It is consistent with the annotations, so no 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 a single succinct Korean sentence with no filler or redundancy. It front-loads the key information—public-source basis, resource name, and subject scope—and every phrase earns its place. This is an appropriately sized description for a straightforward search tool.
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 three parameters, no output schema, and a large set of sibling tools, the description is too minimal to be contextually complete. It does not explain return values, how queries should be structured, what categories control, or how this tool relates to similar search tools. The read-only annotations cover safety but not operational completeness.
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 0%, so the description carries the full burden of explaining parameters like query, limit, and categories. It completely fails to do so, mentioning only the broad knowledge types that loosely correspond to category values without explaining their meaning, format, or defaults. The description adds no value beyond the schema's structural definitions.
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 (검색합니다, 'searches'), a clear resource (DAPA_info), and a scoped set of subjects (조직·용어·업무 지식, 'organization, terminology, and work knowledge'). This makes the tool's function clear at a glance, but it does not explicitly differentiate it from sibling tools such as search_legal or search_dapa_policy, relying on the resource and subject scope to imply the distinction.
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 implies when to use the tool: when searching DAPA_info for organizational, terminology, or work knowledge. However, it provides no explicit guidance about when not to use it, nor does it mention alternatives among the many sibling search tools. The usage context is present but not fully developed.
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 |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the search description is fully consistent with those. The description adds only the source/scope (official DAPA catalog of laws and admin rules) but does not disclose any additional behavioral details such as result pagination or data freshness.
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 entire description is one short sentence with no filler, and the key verb and resource appear immediately. It is efficiently front-loaded and has no redundant 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?
For a four-parameter tool with no output schema and several closely related sibling tools, this description is too thin. It fails to clarify parameter semantics, return shape, or how to choose among the sibling search tools, leaving important call decisions underspecified.
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 0% and the description provides no parameter semantics. Parameters like query, kind, limit, and especially category are left unexplained, so the description does not compensate for the schema's lack of field documentation.
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 ('searches') and a concrete resource: the DAPA official website catalog of laws and administrative rules. It is clear and tied to the tool name, but it does not explicitly differentiate itself from sibling search tools such as search_legal or search_legal_content.
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 usage guidance is given. The description never states when to choose this catalog search over sibling tools, nor does it name any conditions or exclusions, so the agent is left to infer selection criteria from names alone.
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 | ||
| query | Yes | ||
| section | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context that the content is public and synchronized from specific menus, but it does not disclose pagination, ranking, or synchronization freshness.
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 tight sentence with no filler. It front-loads the action and object, making it easy to scan.
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 simple read-only search with one required parameter, this is minimally viable: an agent can invoke it with just a query. However, the optional section parameter is unexplained, there is no output schema, and the definition does not differentiate it among 15 sibling 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?
Schema description coverage is 0%, and the description does not explain query syntax, the meaning of limit, or valid section values. The mention of 'menu and sub-tabs' hints at the section parameter's conceptual scope, but it does not actually map to the parameter.
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 verb and resource: it searches public body text synchronized from the DAPA work/policy menu and its sub-tabs. This makes the tool's scope reasonably distinct from legal-search and general-info siblings, though it does not name an 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?
The description gives no explicit when-to-use or when-not-to-use guidance. An agent must infer the appropriate context from the name and the phrase 'searches', leaving ambiguity against close siblings like search_dapa_info and search_legal_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공식 국가법령정보 API에서 법령·행정규칙·판례·해석례를 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | 법령·판례·해석례 검색어 | |
| types | No | ||
| asOfDate | No | 특정 시점 YYYY-MM-DD; 미지원 시 명시적 오류 반환 | |
| currentOnly | No | ||
| forceRefresh | No | 캐시를 사용하지 않고 API에서 다시 조회합니다. | |
| organization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, and the description is consistent with them. It adds some source context ('공식 국가법령정보 API') but does not disclose behavioral traits such as result shape, pagination, or API limitations.
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?
A single front-loaded Korean sentence with no filler; every phrase earns its place. It is concise but is arguably too thin for the tool's complexity, which is more a completeness issue than a conciseness one.
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 7 parameters, 43% schema coverage, no output schema, and many sibling tools, one sentence is insufficient for an agent to invoke the tool correctly and predict its response. Missing details include valid type categories in practice, default behavior of currentOnly, handling of asOfDate, return/response structure, and when to select this over sibling search 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?
Schema description coverage is only 43%; query, asOfDate, and forceRefresh have schema docs, but limit, types, currentOnly, and organization do not. The description's list of categories roughly maps to types but adds no detail on how parameters work, defaults, or unsupported values, so it fails to compensate for the coverage gap.
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 names the resource '공식 국가법령정보 API', enumerating the covered categories (법령, 행정규칙, 판례, 해석례). It makes the tool's scope clear but does not explicitly position it against siblings like search_legal_content or query_legal_api, so it stops short of full sibling differentiation.
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 given on when to prefer this tool over the many siblings such as search_legal_content, query_legal_api, or search_dapa_legal_catalog. The description states only what the tool searches; it gives no exclusions, preconditions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
국가법령정보 API에서 후보 문서를 검색하고 각 문서의 최신 상세 본문과 조문을 함께 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | 본문에서 찾을 법률·업무 내용 또는 법령명 | |
| types | No | ||
| asOfDate | No | ||
| currentOnly | No | ||
| forceRefresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to cover those. It adds useful context that the tool returns the latest detailed body and provisions together, but it does not explain how the combined operation handles pagination, missing versions, or API failures.
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, front-loaded sentence with no filler. It is concise and easy to parse, though it could be slightly better structured by separating the search step from the detail-retrieval behavior.
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 six parameters, no output schema, and many sibling tools, the description is too thin to be complete. It does not describe the return shape, which documents are considered 'candidates', how the latest version is selected, or what happens when a document has no matching provision.
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 only 17%, so the description carries the burden of explaining parameters, but it does not. The mention of 'latest' vaguely connects to asOfDate and currentOnly, but limit, types, and forceRefresh remain unexplained and uncompensated.
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 operation: searching candidate documents in the 국가법령정보 API and retrieving the latest full text and provisions for each. This goes beyond a generic verb and resource, though it does not explicitly differentiate itself from the many sibling search/detail tools.
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?
There is no explicit guidance about when to use this tool versus alternatives like search_legal, get_legal_detail, or query_legal_api. The phrase 'search and retrieve together' implies a combined workflow, but no exclusions or comparison are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
각 데이터 Provider의 설정 및 가용 상태를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the return content (configuration and availability), but it does not disclose behavior such as freshness, failure modes, or how availability is determined.
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 action ('returns') and the resource ('configuration and availability status of each data provider'). There is no redundancy or 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 no-parameter read-only status tool, the description is mostly complete and the annotations cover safety. However, there is no output schema and the description only vaguely names 'configuration and availability status' without specifying the exact response shape or fields.
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?
The tool has zero parameters, so the description is not expected to explain parameter semantics. The schema and description are consistent, with 100% coverage of an empty parameter set.
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 returns the configuration and availability status of each data provider, giving a specific verb and resource. It is distinct from the legal-focused sibling tools, though it does not explicitly contrast itself with 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 implies a health/status-check use case but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. An agent would need to infer applicability from the tool name and general 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 |
|---|---|---|---|
| citations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds useful context about checking against official sources rather than local data, but it does not disclose what the tool returns or how it behaves when a citation does not exist.
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, focused sentence with no filler. It front-loads the key resource ('statutory provisions or case numbers') and the action ('verify existence'), earning its place entirely.
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 one simple parameter and strong annotations, which help. However, there is no output schema and the description does not state the return format or per-citation behavior, leaving an important gap for an agent that needs to interpret the verification result.
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 0%, and the description adds some meaning by clarifying that the 'citations' strings are statutory provisions or case numbers. However, it does not provide format examples or further detail about accepted citation syntax, so the parameter semantics are only partially compensated.
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 ('verifies'), a clear resource ('statutory provisions or case numbers'), and the scope ('actual existence in official sources'). This clearly distinguishes it from the many search/get sibling tools by focusing on existence verification rather than retrieval.
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 implies the tool should be used when one needs to confirm whether legal citations actually exist, but it provides no explicit guidance about when to use this tool versus alternatives such as search_legal, search_legal_content, or get_legal_detail. No exclusions or conditions are mentioned.
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.1.0dapa_catalog_statusget_dapa_legal_catalog_itemget_dapa_legal_contentget_dapa_organizationget_dapa_policy_pageget_legal_api_bodyget_legal_detailget_legal_historylist_legal_apisquery_legal_apisearch_dapa_infosearch_dapa_legal_catalogsearch_dapa_policysearch_legalsearch_legal_contentsource_healthverify_citationsThe set is separated by source and action, but get_legal_detail, get_legal_api_body, get_dapa_legal_content, and search_legal_content all concern retrieving legal document text or detail, creating real selection risk. The five search_* tools are more distinct because their source targets are clearer.
Most tools follow a predictable verb_noun snake_case pattern such as search_*, get_*, and list_*. A few exceptions like source_health and dapa_catalog_status are noun-phrase status checks, and the placement of 'dapa' varies across names.
With 17 tools, this is on the heavier side but each covers a distinct area: official legal APIs, DAPA catalog, policy pages, organization lookup, citation verification, and provider health. The count is slightly above a lean toolkit but not bloated.
The read-only domain is broadly covered with search, detail retrieval, legal history, citation verification, catalog status, policy pages, and organization lookup. Minor gaps remain for enumerated browsing such as listing all policy pages or the full organization tree, but agents can work around them.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
Resolve, search and verify legal citations against the official sources, with provenance.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ai-studying-man/DAPA-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
