Skip to main content
Glama

지급명세서 제출내역 조회

hometax__tax__payment_statement__search_submit_history
Read-only

REQUIRES prior hometax__session__login call with same account_link_id. Search the submission history of payment statements such as daily-worker and simplified payment statements, including whether submitted and the year-month. Use sbms_ym_strt/sbms_ym_end (YYYYMM). 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
page_numNoPage number (default 1)
page_sizeNoPage size (default 10)
mate_knd_cdNo자료종류코드(document type) - 비우면 그 달 제출분 전체: A0161=일용근로소득 간이지급명세서, A0162=연말정산 간이지급명세서, F0025=사업장제공자 등 과세자료 제출명세서, F0026=일용근로소득 지급명세서. Optional.
sbms_ym_endYesSubmission end year-month YYYYMM
txtn_ym_endNoTaxation end year-month YYYYMM
sbms_ym_strtYesSubmission start year-month YYYYMM
txpr_dscm_noNoTaxpayer number (hyphens allowed)
txtn_ym_strtNoTaxation start year-month YYYYMM
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. Changed1 schema field changed
    • changedInput schema / properties / mate_knd_cd / description
      Previous value: -"Document type code"New value: +"자료종류코드(document type) - 비우면 그 달 제출분 전체: A0161=일용근로소득 간이지급명세서, A0162=연말정산 간이지급명세서, F0025=사업장제공자 등 과세자료 제출명세서, F0026=일용근로소득 지급명세서. Optional."
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already mark this as readOnly and non-destructive, and the description adds useful behavior beyond them: login prerequisite, idempotency-key recovery semantics, anonymous/test-call limitation, and token consumption ('호출마다 토큰 1소진'). It does not describe pagination or return shape in detail, but the added auth and idempotency context is substantial.

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 front-loaded with the login prerequisite and tool purpose, then moves through date-range usage and idempotency guidance. The idempotency section is somewhat verbose, but its detail is relevant for correctly recovering lost responses and avoiding accidental duplicate requests.

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 read-only history search with no output schema, the description covers the essential context: authentication prerequisite, date-range parameters, what is included in the result, idempotency behavior, and token cost. It is fairly complete, though it could better differentiate this tool from the sibling payment statement search and summarize the return shape.

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 description coverage is 100%, so the schema already documents all ten parameters and establishes a baseline of 3. The description adds useful semantics for request_idempotency_key beyond the schema's pointer, explaining when to generate, reuse, or replace it, and it reiterates the YYYYMM date-range usage.

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 and resource: 'Search the submission history of payment statements' and specifies daily-worker/simplified statements plus submitted status and year-month. It is clear what the tool does, though it does not explicitly distinguish it from the sibling hometax__tax__payment_statement__search tool.

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 gives an important prerequisite ('REQUIRES prior hometax__session__login call with same account_link_id') and tells the caller to use sbms_ym_strt/sbms_ym_end in YYYYMM. However, it does not explain when to choose this tool over the sibling payment_statement__search tool or when not to use it.

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