Skip to main content
Glama

등기·증명서 발급확인

registry_doc_verify
Read-only

Verify an issued Korean registration certificate by the verification number printed on it. 증명서에 인쇄된 발급확인번호(12자리)로 발급 사실과 증명서 종류·발급일·등기소를 확인합니다. kind: realestate 부동산(기본), corporate 법인, movable 동산·채권담보. 증명서 원문은 돌려주지 않습니다. [호출당 60포인트]

Input Schema

NameRequiredDescriptionDefault
kindNo문서 종류 (기본 realestate)
issue_noYes발급확인번호 12자리. 하이픈·공백 표기도 받습니다 (예: 2024-1234-5678)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the readOnly/openWorld annotations, the description discloses a concrete return limitation ('증명서 원문은 돌려주지 않습니다' — the original certificate is not returned) and the cost ('[호출당 60포인트]' — 60 points per call). These add real operational context the annotations don't carry.

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 purpose in English, followed by supporting detail and the parameter enumeration. Bilingual repetition costs a little density but every sentence contributes (purpose, parameter meaning, return scope, cost).

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?

With no output schema, the description compensates by stating what is confirmed (issuance fact, certificate type, date, registry office) and explicitly that the original certificate is not returned. It also covers read-only nature and cost, leaving little an agent needs 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 semantic meaning by mapping each enum value to its domain in Korean (realestate=부동산 default, corporate=법인, movable=동산·채권담보), which the bare enum list does not provide.

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?

States a specific verb+resource: 'Verify an issued Korean registration certificate by the verification number printed on it,' and enumerates what it confirms (issuance fact, type, issuance date, registry office). This is clearly distinct from the sibling search/jobs tools, but it doesn't explicitly name any sibling to reinforce the distinction.

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

Usage Guidelines3/5

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

The description implies the usage context (you must have the 12-digit verification number printed on the certificate), which naturally frames when to use it. However, it offers no explicit when/when-not guidance or comparison to alternatives like registry_realestate_search or registry_corporate_search.

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.