Skip to main content
Glama
Sign In

XBOSS

by kr.xdata
OverviewDiscussionsAdmin

건강보험 전체서식 화면 정보 조회

nhis_edi__public__forms__list

REQUIRES prior nhis_edi__session__login call with same account_link_id. 연동 계정으로 부르면 이 세션의 업무 화면을 준비한 뒤 전체서식 화면의 화면 번호와 그 메뉴로 가는 연결 번호를 받습니다. 그 화면을 열지는 않으며, 서식 목록이나 서식 파일은 이 결과에 담기지 않습니다. 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__forms__list"
  }
}

Input Schema

NameRequiredDescriptionDefault
account_link_idNo연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 기관에 인증서를 여러 개 연동했을 때만 직접 입력해 주세요. 기관마다 ID 가 다릅니다.
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.9/5.0
Behavior4/5

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

Beyond the annotations, the description discloses the real cost and side effects: each call consumes one token, request processing creates an XBOSS job and persists the result, and the call is explicitly not purely read-only. That last statement is consistent with readOnlyHint=false, explaining why the flag is set that way rather than contradicting it. The idempotency-key lifecycle (reuse for same-argument recovery, new key for new execution, not available to anonymous calls) adds genuine behavioral context, though some of the trailing institutional-change text is generic boilerplate.

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 most important content — the login prerequisite and the returned screen/menu numbers — is front-loaded correctly. However, the description is long, alternates between Korean and English mid-paragraph, and devotes several sentences to reusable idempotency and institutional-data boilerplate that is not specific to this tool. A tighter two-to-three sentence core would carry the same information.

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?

There is no output schema, so the description correctly takes on the burden of describing returns: a screen number and a menu navigation number, with an explicit statement that form listings and files are absent. Combined with the prerequisite, token cost, and idempotency rules, an agent has what it needs to invoke this correctly. The only shortfall is that nothing describes the shape of the response object or error behavior on a missing/expired login session.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: account_link_id must match the account used in the prior login call, which is a cross-tool constraint. It also elaborates the request_idempotency_key semantics that the schema only gestures at with 'see the tool description'. The remaining gap is that the account_link_id fallback behavior is left entirely to 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 states a concrete verb+resource: it prepares the session's business screen and returns the screen number of the all-forms screen plus the menu navigation number. It also explicitly bounds the purpose by saying the screen is not opened and no form list or files are returned, which separates it from a real forms-list tool despite the 'list' in the name. It loses a point only because the intent is expressed across two languages and reads more abstractly than a single crisp purpose sentence.

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 precondition is stated up front and unambiguously: a prior nhis_edi__session__login call with the same account_link_id is required. It also tells the agent what this call does not accomplish (it does not open the screen or yield forms), which implicitly routes a forms-listing need elsewhere. It stops short of naming a specific alternative sibling, so it is clear context rather than full when/when-not guidance.

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

All XBOSS toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources