Skip to main content
Glama

홈택스 원천세 신고 삭제신청 준비

hometax__tax__withholding__delete_request__prepare

REQUIRES prior hometax__session__login call with same account_link_id. candidates 에서 고른 원천세 신고와 신청인 이름, 연락처, 개인정보 동의를 제출 전에 확인합니다. 조회만 하고 기관에 제출하지 않습니다. 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": {
      "businessNo": "<businessNo>",
      "sourceJobId": "<sourceJobId>",
      "expectedSnapshotHash": "<expectedSnapshotHash>",
      "originalFilingReference": "<originalFilingReference>",
      "originalReceiptNo": "<originalReceiptNo>"
    },
    "name": "hometax__tax__withholding__delete_request__prepare"
  }
}

Input Schema

NameRequiredDescriptionDefault
consentNo개인정보 동의 여부입니다. 사용자 동의를 받았을 때만 JSON 불리언 true 로 입력하며 문자열로 쓴 true 는 입력 오류로 거절하고, false 는 입력하지 않은 것과 같습니다. 제출할 때 이 동의가 기록으로 남습니다. 이 값이 없으면 준비 결과의 required_inputs 에 빠진 항목으로 나오고 그 결과로는 제출(submit)할 수 없으므로, 값을 채워 같은 후보 조회(candidates) 결과로 prepare 를 다시 부릅니다.
taxCodeNo세목 코드입니다. 원천세를 뜻하는 14 만 받으며 입력하지 않으면 14 입니다.14
businessNoYes삭제신청할 원천세 신고의 사업자등록번호입니다. 하이픈 없이 숫자 10자리로 입력하며 이전 단계 작업의 사업자와 다르면 403 으로 거절합니다.
sourceJobIdYes이어서 진행할 이전 단계 작업의 job_id 를 그대로 입력합니다(job_ 으로 시작하는 작업 번호). 삭제 대상 후보 조회(candidates) 결과를 받습니다. 같은 조직과 환경, 같은 기관 연결에서 성공한 원천세 삭제신청 작업이어야 하고 아니면 진행하지 않고 거절하며, 받지 않는 상태의 결과이면 409 로 거절합니다.
receiptJobIdNo선택. 원 신고의 접수 결과와 대조할 때만 입력합니다. 성공한 원천세 전자파일 변환신고, 수정신고, 기한후신고의 제출 또는 접수증 조회 작업 ID 입니다. 정기신고 제출 작업 ID 는 입력하지 않습니다.
applicantNameNo삭제신청에 함께 입력하는 신청인 이름입니다. 1자에서 100자까지이고 공백만 입력하면 입력 오류로 거절합니다. 이 값이 없으면 준비 결과의 required_inputs 에 빠진 항목으로 나오고 그 결과로는 제출(submit)할 수 없으므로, 값을 채워 같은 후보 조회(candidates) 결과로 prepare 를 다시 부릅니다.
applicantPhoneNo신청인 연락처입니다. 하이픈 없이 숫자 9자리에서 11자리로 입력하며 다른 모양이면 입력 오류로 거절합니다. 이 값이 없으면 준비 결과의 required_inputs 에 빠진 항목으로 나오고 그 결과로는 제출(submit)할 수 없으므로, 값을 채워 같은 후보 조회(candidates) 결과로 prepare 를 다시 부릅니다.
account_link_idNo연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 기관에 인증서를 여러 개 연동했을 때만 직접 입력해 주세요. 기관마다 ID 가 다릅니다.
originalReceiptNoYes삭제를 신청할 원 신고의 접수번호입니다. originalFilingReference 와 같은 후보 항목의 receipt_no 를 그대로 입력하며 비어 있으면 입력 오류로 거절합니다.
receiptSnapshotHashNo선택. receiptJobId 를 입력할 때 함께 입력하는 그 작업 결과의 해시입니다.
expectedSnapshotHashYessourceJobId 작업 결과의 snapshot_hash 를 그대로 입력합니다(소문자 16진수 64자리). 그 작업의 내용과 맞지 않으면 진행하지 않고 작성 내용이 바뀌었다는 오류(409)로 거절합니다.
originalFilingReferenceYes삭제를 신청할 원 신고의 민원 ID 입니다. 후보 조회(candidates) 결과 candidates 항목의 filing_reference 를 그대로 입력합니다. 비어 있으면 입력 오류로 거절하고, originalReceiptNo 와 함께 후보 하나로 정해지지 않으면 409 로 거절하며, 경정청구 신고서는 삭제신청할 수 없어 거절합니다. 후보 조회 뒤 기관의 신고 정보가 바뀌었으면 거절하므로 후보 조회(candidates)부터 다시 합니다.
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.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely new behavior: each call consumes one token, it creates an XBOSS job and stores the processing result, and it is explicitly not a pure read-only operation even though it does not file with the agency. It also gives idempotency-key recovery semantics. Points are lost for the confusing mention of 'anonymous taste calls' and a 'provider-specific idempotency_key' field that does not exist in the schema.

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 core purpose and the read-only caveat are front-loaded, which is good. However, the middle block is verbose boilerplate mixing Korean and English, repeats the token/job/XBOSS disclosure twice, and contains a garbled reference to 'anonymous taste calls' and a non-existent idempotency field, all of which dilute the message.

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 13-parameter preparation tool with no output schema, the description covers the prerequisite session, the upstream candidates step, the token cost, the side effects of job creation, and the fact that it is not purely read-only. The remaining gaps (what the preparation result contains, how required_inputs is surfaced) are partly covered by the schema and are minor.

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 all 13 parameters in detail, including patterns, defaults, and 403/409 failure conditions. The description adds only a loose mapping of the candidate filing and applicant fields, which the schema states more precisely. Baseline 3 is appropriate 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 description states a specific action on a specific resource: it verifies the withholding-tax filing selected from candidates plus applicant name, phone, and consent before submission, and explicitly says it only looks up and does not file with the agency. This clearly separates it from the sibling submit tool. It falls short of a 5 only because the purpose statement is buried under boilerplate about tokens, XBOSS jobs, and idempotency.

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 names the prerequisite (a prior hometax__session__login call with the same account_link_id) and the upstream step (pick a filing from candidates), and it explains the retry loop: if required_inputs are missing, fill the values and call prepare again with the same candidates result. It does not explicitly exclude or contrast with the sibling requirements or receipt tools, so the guidance is strong but not complete.

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