Skip to main content
Glama
Sign In

XBOSS

by kr.xdata
OverviewDiscussionsAdmin

4대보험 보험료 조회

si4n__premium__inquiry
Read-only

REQUIRES prior si4n__session__login call with same account_link_id. Read-only. Returns the premium the workplace owes and what is still unpaid. Pick by_insurance with insurance_type to list the notice rows of that one insurance, or regular_batch / batch to list the notice rows of whichever insurances the institution shows, in one table. The summary and arrears always show all four insurances. Does not pay anything. 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소진

Input Schema

NameRequiredDescriptionDefault
viewYesby_insurance lists the notice rows of one insurance and needs insurance_type; regular_batch and batch list the notice rows of whichever insurances the institution shows, in one table, and take no insurance_type.
insurance_typeNoRequired when view is by_insurance (the one insurance whose notice rows are listed); leave it out for regular_batch and batch.
output_formatsNoOptional. Also return this result as a file (Excel (xlsx)) in artifacts[] of the result. Omit it for data only.
account_link_idNoAccount link ID (UUID v4). Optional — the server auto-resolves from your API key when omitted. Provide explicitly only when you have multiple certificates for the same provider. Each institution has a separate ID (Hometax != NHIS != NPS != FourInsure).
request_idempotency_keyNoOptional same-request recovery key for authenticated calls; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / request_idempotency_key
      Added value: +{
+  "description": "Optional same-request recovery key for authenticated calls; see the tool description.",
+  "maxLength": 128,
+  "minLength": 1,
+  "pattern": "^[\\x20-\\x7E]+$",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / insurance_type / description
      Previous value: -"Optional. Narrows the by_insurance view to one insurance."New value: +"Required when view is by_insurance (the one insurance whose notice rows are listed); leave it out for regular_batch and batch."
    • changedInput schema / properties / view / description
      Previous value: -"by_insurance splits the four insurances; the others read the notice as one total."New value: +"by_insurance lists the notice rows of one insurance and needs insurance_type; regular_batch and batch list the notice rows of whichever insurances the institution shows, in one table, and take no insurance_type."
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true/destructiveHint=false, yet the description adds real behavior: it does not initiate payment, summary/arrears always cover all four insurances, xlsx artifacts carry a download_url valid for 15 minutes with 7-day file retention, and expired links are refreshed via xdata__job__result. The recovery_receipt and idempotency details are relevant but read as generic platform boilerplate rather than tool-specific behavior.

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 prerequisite and purpose are correctly front-loaded, but the body then sprawls into long anonymous-result recovery_receipt rules and idempotency-key policy that are tangential to executing this query. For a five-parameter read-only lookup, several sentences (e.g. the receipt does not grant access to other results, losing it cannot be repaired) could be trimmed without losing agent-relevant 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?

With no output schema, the description does carry the burden of describing returns, and it does so at a high level (owed vs unpaid premium, summary and arrears covering all four insurances, artifacts[] with download links). Prerequisites, view semantics and file retention are all covered; only a more concrete picture of the returned rows/summary fields is missing.

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 the schema already documents view, insurance_type, output_formats, account_link_id and request_idempotency_key. The description restates the view/insurance_type pairing and the xlsx-only output_formats but adds no semantics beyond what the schema provides, warranting the baseline 3.

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 opens with a concrete verb+resource: it returns the premium the workplace owes and what is still unpaid. That is specific enough to distinguish it from a payment tool, reinforced by 'Does not pay anything.' However it never differentiates itself from the closely named sibling si4n__premium_calculation__inquiry or from the nhis_edi premium notice tools, so an agent must guess which inquiry to pick.

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 states an explicit prerequisite ('REQUIRES prior si4n__session__login call with same account_link_id') and gives a clear decision rule for the view parameter: by_insurance + insurance_type for one insurance, regular_batch/batch for all shown insurances. It does not name a sibling alternative or say when to prefer premium_calculation__inquiry instead, so it stops short of the top score.

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