XBOSS

고용보험 및 산재보험 가입 사업장 조회

opendata__comwel__workplace

공공데이터포털에 개방된 고용보험과 산재보험 가입 사업장 정보(data.go.kr 15059256)를 사업자등록번호로 조회합니다. 사업장명, 보험 구분, 보험가입구분, 성립일자, 상시인원, 업종, 우편번호, 주소를 사업장(적용 단위)마다 한 행으로 돌려주고 summary 에 보험별 사업장 수와 상시인원 합계를 담습니다. 결과가 비어 있어도 미가입 확인서는 아닙니다. 별도 연동 없이 사용할 수 있습니다. Files: a document generated from this result, as Excel (xlsx) only when requested in output_formats, listed in artifacts[] of the result with a download_url that works for 15 minutes; each file is kept for 7 days. If a link has expired, call xdata__job__result with the job_id from the result for fresh links. For an anonymous result, keep its private recovery_receipt and send it with the original job_id or pack_run_id to xdata__job__result. It grants access to that result only, until the original file retention expires. Do not publish it. Losing it cannot be repaired by signing up. The receipt also works if the client later signs in; it does not grant access to other results. Without a receipt, results require the original account and lane. 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "bizno": "<bizno>"
    },
    "name": "opendata__comwel__workplace"
  }
}

Input Schema

Name	Required	Description
`bizno`	Yes	사업자등록번호 10자리(하이픈 허용).
`pageNo`	No	페이지 번호(선택, 기본 1).
`insurance`	No	보험 구분(선택, 기본 all). industrial 은 산재보험, employment 는 고용보험 행만 돌려줍니다.
`numOfRows`	No	한 페이지 행 수(선택, 기본 100).
`output_formats`	No	Optional. Also return this result as a file (Excel (xlsx)) in artifacts[] of the result. Omit it for data only.
`request_idempotency_key`	No	Optional same-request recovery key for authenticated calls; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With readOnlyHint=false declared, the description adds real context: each call consumes one token, spawns an XBOSS job and persists the result, and the call is explicitly not pure read-only even though the underlying agency query is a read. It also discloses file behavior (xlsx in artifacts[], 15-minute download link, 7-day retention), the recovery_receipt semantics for anonymous results, and the idempotency_key lifecycle. That is substantive disclosure beyond the annotations; only the destructiveHint=false implication (no institution-side data change) is left to be inferred from the closing sentence.

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?

Purpose and return shape are correctly front-loaded in the first two sentences, and the empty-result caveat is well placed. But a large share of the text is generic boilerplate — artifact retention, receipt lifetime, idempotency-key rules — that is either conditional on output_formats being used or verbatim cross-tool policy, and it sits between the core description and the token-cost note. The hyphenation-free block of policy text dilutes the signal for an agent that just wants to call the 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?

There is no output schema, so the description must carry the return shape, and it does: field list, row granularity, and what summary contains. It further covers the file-artifact path, recovery for anonymous vs authenticated calls, and the non-read-only job side effect, which matches the openWorldHint/readOnlyHint=false annotations. Slight over-coverage of artifact lifecycle is the only redundancy.

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 bizno format, insurance enum values, pageNo/numOfRows defaults and the output_formats contract are already documented in the schema. The description adds only indirect meaning (one row per workplace/applied unit, summary holds per-insurance counts and headcount totals) rather than clarifying any parameter's format or constraints. Baseline 3 applies when the schema carries the parameter burden.

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 first sentence gives a specific verb and resource: look up employment/industrial-accident insurance–enrolled workplaces by business registration number, naming the source dataset (data.go.kr 15059256). It also enumerates the returned fields (workplace name, insurance type, enrollment type, establishment date, headcount, industry, zip, address) and the summary contents, so the agent knows exactly what it gets. It does not name or contrast sibling lookups such as opendata__nps__workplace or nhis_edi__business__basic_info, which keeps it short of 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?

It states the tool works without a separate integration/registration and warns that an empty result is not proof of non-enrollment — genuinely useful invocation caveats. However, it never says when to prefer this over the adjacent workplace lookups (NPS workplace, NHIS basic_info, fourinsure workplace tools), and the only selection guidance is implicit in the insurance enum. Adequate but with a clear routing gap.

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

All XBOSS tools Inspect

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

Need Help?