Skip to main content
Glama

홈택스 원천세 전자파일 변환신고 작업 시작

hometax__tax__withholding__file_conversion__init

REQUIRES prior hometax__session__login call with same account_link_id. filing_type 으로 신고 구분을 정해(regular 정기, amendment 수정, late 기한후, 기본 regular) 원천세 전자파일 변환신고를 시작합니다. 기관이 받는 원본 파일 크기 범위와 진행 중인 변환 작업을 읽기만 하고 기관에 아무것도 올리지 않습니다. 기관에 진행 중인 작업이 있으면 그 작업 번호를 resume_batch_id 로 보내 이어 갑니다. 이 단계의 job_id 와 snapshot_hash 로 원본을 등록하고 upload 를 부릅니다. 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": "hometax__tax__withholding__file_conversion__init"
  }
}

Input Schema

NameRequiredDescriptionDefault
filing_typeNo변환할 신고의 종류입니다. regular(정기신고), amendment(수정신고), late(기한후신고) 가운데 하나를 입력하며 입력하지 않으면 regular 입니다. 이 값은 이어지는 단계에 그대로 이어지고, 이미 접수된 신고를 다시 올리는 재신고는 regular 에서만 할 수 있습니다.regular
account_link_idNo연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 기관에 인증서를 여러 개 연동했을 때만 직접 입력해 주세요. 기관마다 ID 가 다릅니다.
resume_batch_idNo기관에 이미 진행 중인 변환 작업을 이어갈 때 그 작업의 식별자입니다. 진행현황에 나온 작업 ID 를 그대로 입력하며 1자 이상 100자 이하입니다. 입력하지 않으면 새 변환 작업으로 시작하고, 기관에 진행 중인 변환 작업이 있는데 이 값을 입력하지 않으면 기존 변환 작업이 있다는 오류(409)로 거절합니다.
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?

Adds substantial behavior beyond the annotations: token consumption per call, creation and persistence of an XBOSS job, and that the call is not purely read-only despite only reading agency data. The internal tension is actually resolved (reads agency originals, uploads nothing, but still creates a backend job), which is consistent with readOnlyHint=false and destructiveHint=false.

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

Conciseness2/5

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

Very front-loaded dependency is good, but a long English boilerplate paragraph on request_idempotency_key plus generic token/XBOSS notes inflate length, and the Korean/English mixing reduces scanability. Several sentences restate the read-only nuance rather than adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers workflow position, prerequisites, and resume logic for a multi-step init tool. However, since there is no output schema, the description should clarify what the call returns (job_id, snapshot_hash) and how they feed upload; instead it only mentions them in passing.

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 coverage is 100%, so the schema already documents all four parameters thoroughly. The description reinforces filing_type semantics and resume_batch_id's 409 behavior, but adds little meaning beyond what the rich schema descriptions already provide; baseline 3 applies.

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?

Starts with a specific dependency and then states the action: starts a withholding tax e-file conversion filing, with filing_type selecting regular/amendment/late. The verb+resource is identifiable, though the surrounding sentences about resume and upload blur the primary purpose somewhat.

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?

Explicitly states the prerequisite (prior hometax__session__login with the same account_link_id) and the sequencing to the next stage (register original with job_id/snapshot_hash, then call upload). It also explains when to pass resume_batch_id (when an in-progress job exists), including the 409 rejection when omitted. No explicit exclusion against sibling validate/preview stages, but the workflow context is clear.

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