Skip to main content
Glama

일일 현금영수증 수정

hometax__cash_receipt__daily_issue__modify
Destructive

REQUIRES prior hometax__session__login call with same account_link_id. 오늘 발급한 현금영수증을 수정합니다. aprv_no 는 hometax__cash_receipt__daily_issue__search 에서 얻습니다. 보낸 칸은 그 값으로 전송합니다. 다만 바꾼 용도, 거래유형, 발급수단을 기관이 반영하는지는 보장되지 않습니다(발급수단 변경 표시는 항상 N 으로 전송합니다). 보내지 않은 용도, 발급수단, 거래일시, 봉사료, 메모는 오늘 발급한 원본의 값으로 전송합니다. 봉사료를 없애려면 0 을 입력합니다. 원본으로 부가가치세 적용 여부를 알 수 없으면 추측하지 않고 cshpt_trs_type_cd 를 요청합니다. 이 도구는 기관의 기록을 바꿉니다. 첫 호출은 실행되지 않고, 전송할 내용의 미리보기와 1회용 confirmation_token 을 돌려줍니다(오류 WRITE_CONFIRMATION_REQUIRED). 그 미리보기를 사용자에게 그대로 보여 줍니다. 사용자가 동의한 뒤에만 같은 인자에 그 confirmation_token 을 더해 다시 호출합니다. 사용자의 동의 없이 토큰을 넣지 않습니다. 인자를 하나라도 바꾸면 토큰은 무효가 됩니다. 그때는 토큰 없이 호출해 새 미리보기를 받습니다. 호출마다 토큰 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": {
      "aprv_no": "<aprv_no>",
      "tota_trs_amt": "<tota_trs_amt>"
    },
    "name": "hometax__cash_receipt__daily_issue__modify"
  }
}

Input Schema

NameRequiredDescriptionDefault
tipNo봉사료. 입력하지 않으면 오늘 발급한 원본의 봉사료를 유지합니다. 봉사료를 없애려면 0 을 입력합니다.
trs_dtNoTransaction date YYYYMMDD. Default: the original receipt's date (only today's receipts can be modified).
aprv_noYesApproval number (승인번호)
rcpr_tinNoRecipient TIN. Taken from today's original receipt when omitted.
trs_timeNoTransaction time HHMMSS. Default: the original receipt's time.
tota_trs_amtYesTotal transaction amount (총 거래금액, min 1 KRW, string)
account_link_idNo연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 기관에 인증서를 여러 개 연동했을 때만 직접 입력해 주세요. 기관마다 ID 가 다릅니다.
cshpt_usg_cl_cdNoUsage class code (용도구분코드): 0=소득공제용, 1=지출증빙용 Optional — defaults to the original receipt's value.
spst_cnfr_cl_cdNoIssue-means class code (발급수단구분코드): 01=주민등록번호, 02=사업자등록번호, 03=휴대전화번호, 04=카드번호 Optional — defaults to the original receipt's value.
cshpt_trs_type_cdNoTransaction type code (거래유형코드): 01=과세, 02=면세, 03=간이 Optional — inferred from the original receipt's VAT; asked for when it cannot be inferred.
confirmation_tokenNo첫 호출이 돌려준 1회용 확인 토큰입니다(오류 WRITE_CONFIRMATION_REQUIRED). 같은 인자에 이 값을 그대로 넣어 다시 호출하면 실행됩니다. 10분 뒤 만료되고 한 번만 쓸 수 있습니다.
cshpt_isn_mmo_cntnNo메모(최대 300바이트). 입력하지 않으면 오늘 발급한 원본의 메모를 유지합니다.
spst_cnfr_no_enc_cntnNoIssue-means number (발급수단번호) matching the class code, digits only. It is sent to the institution exactly as given - never encrypt or hash it, and never put an approval number here. Optional — defaults to the original receipt's value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, destructiveHint=true, openWorldHint=true; the description goes far beyond by spelling out the two-step confirmation flow (first call returns a preview plus a one-time confirmation_token with WRITE_CONFIRMATION_REQUIRED), that tokens are invalidated by any argument change, and that unsent fields are resent with the original's values. It also discloses the important caveats that changed usage/transaction-type/issue-means may not be reflected by the institution and that the issue-means-change flag is always sent as N.

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 and the confirmation mechanics are ordered sensibly, but the text is long, mixes Korean and English unevenly, and repeats the consent rule across several sentences ('그 미리보기를 사용자에게 그대로 보여 줍니다', '사용자의 동의 없이 토큰을 넣지 않습니다'). The closing line about institution data following per-tool procedures is filler.

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 destructive tool with no output schema, the definition covers prerequisites, the confirmation protocol, defaulting behavior, and known non-guarantees. What it omits is what a successful or failed execution response actually contains, though the preview contract is described adequately.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics: aprv_no's provenance, that omitted fields inherit the original receipt's values, that tip=0 is the way to erase a service charge, and that cshpt_trs_type_cd is requested rather than guessed when VAT status is unknown. Some of this overlaps the schema's own default notes, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — modifying cash receipts issued today — and pins the scope ('오늘 발급한 현금영수증'), which separates it from cancel/issue siblings. It also names where the key identifier comes from (hometax__cash_receipt__daily_issue__search), so the agent can identify the tool without opening the schema.

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?

Gives an explicit prerequisite (prior hometax__session__login with the same account_link_id) and the lookup path for aprv_no, plus the constraint that only today's receipts qualify. It does not explicitly route to the cancel or re-issue siblings when modification is the wrong choice, so it stops short of full when/when-not guidance.

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