Skip to main content
Glama

산재 신청 도우미 (sanjae-apply)

서식 채우기(정본 PDF 오버레이 · 한글)

fill_form
Read-onlyIdempotent

form_id 의 정본 서식에 값을 넣어 base64 로 돌려준다. format='pdf'(기본)는 정본 PDF 오버레이, format='hwpx'는 한글 문서(한글 2014+ 로 열어 고칠 수 있다). 먼저 get_form_catalog(form_id) 의 slot_labels 로 칸을 고른다(칸 이름은 두 형식이 같다). 서식의 선택지(사업주여부·친인척여부·근로자유형·신청 구분·예/아니오·개인정보 동의 등)는 해당 체크 칸에 true 를 넣어야 찍힌다. 아는 값은 빠짐없이 넣는다. 서버에 저장하지 않는다. 주민번호 등은 보내지 않아도 된다(빈칸으로 남는다). 사용자가 도장·날인·인감을 말하면 stamp 를 넣는다(넣지 않으면 서명란이 빈다). F_INDUSTRIAL_ACCIDENT_REPORT(산업재해조사표)는 고용노동부(관할 지방고용노동관서)에 내는 서식이다 — 서술 칸은 get_accident_report_guide 로 쓰고 check_accident_report 로 점검한 뒤 채운다. 칸이 모자란 서술은 칸에 「(별지에 적음)」을 쓰고 끝에 별지 쪽을 붙인다(report.annexed). 도장 기본 자리는 사업주(applicant)이고, 근로자대표 확인란(worker_rep)은 근로자대표 본인 것만 spot='worker_rep' 로 따로 찍는다. 결과의 labor_office 에 workplace_address 로 찾은 관할 관서·접수 부서·전화·팩스·확인방법(find_labor_office 와 같은 내용)과, labor_office 칸에 적은 값·제안 값(slot)을 붙인다. 건설업 칸(발주자·원수급·현장명·공사종류·공정률·공사금액)에 값이 있으면 건설 전담 과로 찾는다.

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": {
      "form_id": "<form_id>",
      "values": "<values>"
    },
    "name": "fill_form"
  }
}

Input Schema

NameRequiredDescriptionDefault
stampNo도장. PDF·한글(hwpx) 출력 모두 신청인 서명란에 찍는다. 본인 또는 명의자 동의가 있는 이름만. 등록 인감 대용이 아니다(사용인감 성격)
formatNopdf(기본) 또는 hwpx(한글)
valuesYes칸 이름 → 값
form_idYes예: F_YOYANG_APPLY, F_HUYEOP_CLAIM …

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, which is potentially confusing for a tool called 'fill_form'; the description resolves it by stating '서버에 저장하지 않는다' and that personal data like 주민번호 may simply be omitted and left blank. It further discloses that unset stamp leaves the signature box empty, the employer default spot vs worker_rep, hwpx being editable in 한글 2014+, and what gets appended to the result (labor_office, report.annexed).

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 purpose is front-loaded, but the remainder is a dense run-on covering parameters, workflow, annex fallback, stamp spots, output enrichment and construction-office lookup with no paragraph or list structure. Most content earns its place, yet the packing makes it hard to scan and several rules (건설업, labor_office) are compressed to the point of needing re-reading.

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 complex tool with nested stamp object and no output schema, the description does explain key returns (base64, report.annexed, labor_office contents) and the blank-field policy. It stops short of describing error behaviour or the full result shape beyond labor_office, but nothing an agent needs to invoke it correctly is missing.

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 meaning the schema does not: checkbox choices (사업주여부·친인척여부·예/아니오·동의 등) must receive boolean true, and '아는 값은 빠짐없이 넣는다' guides completeness. Minor tension: the text says the stamp default spot is 사업주(applicant) while the schema says the default is all applicant·delegation·consent spots, which could mislead on defaults.

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?

Opens with a specific verb+resource+return: 'form_id 의 정본 서식에 값을 넣어 base64 로 돌려준다', then names the two output flavours (pdf overlay vs hwpx). This clearly separates it from the single-form sibling fill_yoyang_apply and from non-writing siblings like get_form_catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit prerequisites and routing: consult get_form_catalog(form_id).slot_labels first; for F_INDUSTRIAL_ACCIDENT_REPORT write narrative with get_accident_report_guide and validate with check_accident_report before filling. It also states the when-not rule for stamps (only when the user mentions 도장·날인·인감) and the overflow rule using '(별지에 적음)' + report.annexed.

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.