Skip to main content
Glama
Sign In

APICK Convert

by app.apick
OverviewDiscussionsAdmin

서식 자동작성

form_document
Read-only

Generate a Korean business form (contract, certificate, application) from free-form text or explicit fields and return it as PDF, DOCX, HWPX, RTF, HTML, Markdown, TXT, JSON, or XLSX. 자유 문장 또는 정형 필드로 계약서·증명서·신고서 등 200종 서식을 만들어 파일로 돌려줍니다. form 에 서식 키(예: labor_contract_standard), text 에 자유 문장, data 에 정형 필드(이름·전화·주소·금액·날짜 등)를 넣습니다. data 가 text 보다 우선하며, 입력하지 않은 항목은 오류가 아니라 빈칸으로 출력됩니다. signature_image·stamp_image 로 서명·도장 그림을 서명란에 넣을 수 있습니다. 서식 키·필드 정의는 /rest/form_list·/rest/form_fields(무료)에서 확인할 수 있습니다. [호출당 100포인트]

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": "<form>"
    },
    "name": "form_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNo정형 필드. 서식별 키는 /rest/form_fields(무료)로 확인하며, 같은 키는 text 보다 우선합니다
formYes서식 키 (예: labor_contract_standard, biz_estimate). 전체 목록은 /rest/form_list(무료)
textNo자유 문장. 라벨 없이도 전화·주소·금액·날짜를 형식으로 인식합니다
formatNo결과 형식, 기본 pdf. 문서(pdf·docx·hwpx·rtf)는 과금, 값·미리보기 포맷은 낮은 단가
stamp_imageNo도장·직인 이미지. signature_image 와 같은 형식·크기 제한
signature_imageNo서명 이미지. data:image/png 또는 data:image/jpeg 의 base64 data URL, 300KB 이하. 서명란에 그대로 들어갑니다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / signature_image
      Added value: +{
+  "description": "서명 이미지. data:image/png 또는 data:image/jpeg 의 base64 data URL, 300KB 이하. 서명란에 그대로 들어갑니다",
+  "type": "string"
+}
    • addedInput schema / properties / stamp_image
      Added value: +{
+  "description": "도장·직인 이미지. signature_image 와 같은 형식·크기 제한",
+  "type": "string"
+}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Goes well beyond the annotations (readOnlyHint/openWorldHint) by disclosing that `data` overrides `text`, that unspecified fields silently render as blanks rather than erroring, that signatures/stamps are stamped into the signature box, and that each call costs 100 points with cheaper non-document formats. It does not describe the response payload shape (binary vs base64 vs URL), which is the main remaining behavioral unknown.

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

Conciseness4/5

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

Front-loaded with the core action and output formats, then moves to inputs, precedence, images, lookup endpoints, and price in a logical order with no filler. The one inefficiency is near-verbatim bilingual duplication of every point in English and Korean, which doubles length without adding information for a bilingual agent.

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?

Substantial for a 6-parameter, nested-object tool with no output schema: it covers inputs, precedence, failure tolerance, images, discovery endpoints, and cost. The gap is the return value — an agent still cannot tell whether it receives base64, a data URL, or a download link, which matters for a file-producing tool with no output schema.

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 every parameter, and much of the description restates it (form key examples, data-overrides-text precedence). It adds some genuine semantics — blank rendering for omitted fields, the 200-form catalog, and stamp/signature placement — but does not explain the nested `data` key space beyond pointing at form_fields.

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 ('Generate a Korean business form ... from free-form text or explicit fields') plus the full set of output formats, so an agent immediately knows it produces a filled document file from a form key. The scope ('200종 서식', contract/certificate/application) distinguishes it from generic generation or template-listing tools.

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 clear usage context: put the form key in `form`, free sentences in `text`, structured fields in `data`, and fetch keys/field definitions from the free form_list/form_fields endpoints. It does not explicitly route the agent to sibling tools such as form_preview, form_bundle, or form_ai_fill, so the 'when not to use this one' dimension is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All APICK Convert toolsInspect
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