XBOSS

부가세 삭제신청 준비

hometax__tax__vat__delete_request__prepare

REQUIRES prior hometax__session__login call with same account_link_id. 최종 제출 전에 선택한 신고, 신청인, 전화번호, 개인정보 동의를 준비합니다. 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": {
      "business_no": "<business_no>",
      "year": "<year>",
      "half": "<half>",
      "source_job_id": "<source_job_id>",
      "expected_snapshot_hash": "<expected_snapshot_hash>",
      "original_filing_reference": "<original_filing_reference>",
      "original_receipt_no": "<original_receipt_no>",
      "applicant_name": "<applicant_name>",
      "applicant_phone": "<applicant_phone>",
      "consent": "<consent>"
    },
    "name": "hometax__tax__vat__delete_request__prepare"
  }
}

Input Schema

Name	Required	Description	Default
`half`	Yes	과세 기수입니다. 1 은 1기(1월부터 6월), 2 는 2기(7월부터 12월)입니다. 원 신고 작업의 기간과 다르면 거절합니다.
`year`	Yes	삭제신청할 원 신고의 과세 연도입니다. 네 자리 정수로 입력합니다. 원 신고 작업의 기간과 다르면 거절합니다.
`consent`	Yes	삭제신청에 필요한 사용자의 개인정보 동의입니다. 사용자에게 동의를 받은 뒤 JSON 불리언 true 로 입력합니다. true 가 아니면 준비하지 않고 거절합니다.
`business_no`	Yes	삭제신청할 신고의 사업자등록번호입니다. 하이픈 없이 숫자 10자리로 입력합니다. 원 신고 작업의 사업자와 다르면 거절합니다.
`period_kind`	No	신고 구분입니다. PRELIMINARY 는 예정신고(기수의 앞 석 달), FINAL 은 확정신고(기수 여섯 달)이고 입력하지 않으면 PRELIMINARY 입니다. 원 신고와 같은 구분을 입력합니다.	PRELIMINARY
`source_job_id`	Yes	삭제신청할 원 신고의 작업 job_id 입니다. 이 서비스에서 제출해 접수가 확인된 신고의 작업이어야 하고 아니면 거절합니다.
`applicant_name`	Yes	삭제신청서에 적을 신청인 이름입니다. 1자에서 100자까지 입력합니다.
`account_link_id`	No	연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 기관에 인증서를 여러 개 연동했을 때만 직접 입력해 주세요. 기관마다 ID 가 다릅니다.
`applicant_phone`	Yes	삭제신청서에 적을 신청인 연락처입니다. 하이픈 없이 숫자 9자리에서 11자리로 입력합니다.
`original_receipt_no`	Yes	원 신고 작업 결과의 접수번호(receipt 의 receipt_no)를 그대로 입력합니다. 기관의 접수번호와 맞지 않으면 거절합니다.
`expected_snapshot_hash`	Yes	source_job_id 작업 결과의 snapshot_hash 를 그대로 입력합니다(16진수 64자리). 다르면 거절합니다.
`request_idempotency_key`	No	Optional same-request recovery key for authenticated calls; see the tool description.
`original_filing_reference`	Yes	원 신고 작업 결과의 filing_reference 값을 그대로 입력합니다. 기관의 신고 목록과 맞지 않으면 거절합니다.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description adds context beyond that: each call consumes one token (토큰 1소진), it creates an XBOSS job and stores the processing result, and it is explicitly not a pure read-only call despite not mutating data. The idempotency-key behavior is also spelled out (reuse the same key only to recover a lost response, new key for a new execution, provider-specific idempotency_key is a different field). The only muddy part is the boilerplate about 'anonymous taste calls' and provider-data-change procedure, which don't map cleanly to this tool.

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 is correctly front-loaded, but the body mixes Korean and English, repeats the idempotency rule in both languages, and carries generic boilerplate about XBOSS jobs and provider original records that adds noise. Several sentences could be cut without losing guidance the agent needs.

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?

For a 13-parameter, 10-required mutation-adjacent preparation tool with no output schema, the description covers prerequisites, side effects, and cost, which is substantial. However it never says what the call returns or how the prepared result is carried forward to submission, which is the key missing piece given there is no output schema to fall back on.

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 baseline is 3, but the description compensates for the one field the schema defers on: request_idempotency_key's schema text only says 'see the tool description,' and the description supplies the full semantics (when to reuse versus regenerate, and that omitting it makes each call a new request). It also clarifies why account_link_id matters (multiple certificates under one institution).

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: preparing the selected filing, applicant, phone number, and privacy consent 'before final submission' (최종 제출 전에 ... 준비합니다), so the agent can tell this is a pre-submission step rather than the submission itself. It does not explicitly name the submit sibling (hometax__tax__withholding__delete_request__submit or a VAT equivalent), so differentiation is implied through the 'before final submission' phrasing rather than stated.

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 gives a hard prerequisite ('REQUIRES prior hometax__session__login call with same account_link_id') and places the call before final submission, which is clear context for when to invoke. It never explicitly says when NOT to use it or names the submit tool to route to afterwards, so it stops short of full alternative routing.

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?