Skip to main content
Glama

건강보험 자료 목록 조회

nhis_edi__public__resources__list

No credential or login required. 쪽 번호로 공개 자료실 게시판의 한 쪽을 읽어 자료마다 번호나 공지 표시, 제목, 등록일과 글 주소를 돌려주고, 첨부가 있는 자료에는 첨부 안내가 붙습니다. 파일 자체는 받지 않습니다. For an authenticated call, generate and save request_idempotency_key before the first request. Reuse it with the same arguments only to recover that request after a lost response; use a new key for a new execution. Without it, calling again remains a new request. This optional key is not available to anonymous taste calls. Keep any provider-specific idempotency_key unchanged; it is a different field. 호출마다 토큰 1소진 요청 처리 시 XBOSS 작업을 생성하고 처리 결과를 저장합니다. 기관 원본의 조회 여부와 별개로 이 호출은 순수 읽기 전용이 아닙니다. 기관 데이터 변경은 도구별 실행 내용과 기존 확인 절차를 따릅니다.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nhis_edi__public__resources__list"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default: 1)
request_idempotency_keyNoOptional same-request recovery key for authenticated calls; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=false already declared, the description goes further and explains why: each call creates a XBOSS job and stores the processing result, so it is not a pure read even if the institution's source is only queried. It also discloses the per-call token cost and states no credentials are needed, which are traits the annotations do not express. It loses a point for the boilerplate about a key 'not available to anonymous taste calls', which reads as copied generic text and muddies the disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and return-shape information is front-loaded and earns its place. The remainder mixes Korean and English, repeats idempotency guidance at length, and includes at least one artifact ('anonymous taste calls') that does not apply. It is not bloated to the point of unreadability, but it is longer than the tool requires.

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 two-parameter list tool with no output schema, the description covers what is returned per item, what is not returned (the attachment files), the auth posture, and the per-call cost. Little that an agent needs in order to call it correctly is missing, other than explicit routing guidance versus sibling list 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 100%, so both parameters are already documented and the baseline is 3. The description does add real semantics for request_idempotency_key (generate before the first request, reuse only to recover a lost response with identical arguments, new key for a new execution), plus clarifies page means a single board page. That is genuine added meaning, but it is tangled with unrelated warnings.

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 gives a specific verb and resource: it reads one page of the public resource board (공개 자료실 게시판) by page number. It also enumerates the returned fields (number/notice flag, title, registration date, post URL, attachment notice) and states an explicit boundary that the file itself is not downloaded, so an agent can tell it apart from a document-download tool. It does not name or contrast the neighboring forms/notices list tools, which keeps it below a 5.

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?

Useful contextual guidance is present: no credential or login is required, and the tool is page-scoped, which implies paging through results. However, there is no explicit statement of when to choose this over the sibling public forms or notices list tools, and no exclusion or prerequisite guidance. Usage must largely be inferred from the name and the target board.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources