DAPA MCP

by ai-studying-man

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
The 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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.4/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

DAPA MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![DAPA MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ai-studying-man/DAPA-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ai-studying-man/DAPA-MCP)

Score Badge

Copy to your README.md:

[![DAPA MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ai-studying-man/DAPA-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ai-studying-man/DAPA-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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