req_nps_deduction_cert국민연금 소득공제용 납부확인서를 위한 본인 간편인증을 요청합니다. 휴대폰 알림 발송과 접수 과금이 발생하므로 사용자 확인 후 호출하세요. transactionId와 status를 반환하면 휴대폰 승인을 안내하고, 승인 후 get_nps_deduction_cert에 transactionId를 전달하세요. 승인 대기 중 인증 요청을 반복하거나 자동 승인하지 마세요. [인증 발송 성공 시 20P; 조회 범위와 무관]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 본인 이름 | |
| phone | Yes | 본인 명의 휴대전화 번호 (숫자만) | |
| years | No | 납부확인서 조회 연수 (1~5, 생략 시 1) | |
| birthDate | Yes | 생년월일 8자리 (YYYYMMDD) | |
| authProvider | Yes | 휴대폰에서 승인할 간편인증 방식 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and openWorldHint=true, but the description adds critical non-obvious behavior: it sends a mobile push notification, incurs a billing event (20P on successful send, unrelated to lookup scope), returns transactionId/status, and requires the user to approve on their phone. It also warns against repeated requests during waiting and automatic approval. This is rich context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded: purpose, caution, return values, next step, and prohibitions. It is dense but every sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (transactionId and status) and the post-approval workflow. It covers billing, safety, and sequencing with a sibling tool. Complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the 5 parameters is already documented in the schema. The description adds no additional parameter details beyond what the schema provides (e.g., format or constraints). Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: requests identity authentication (본인 간편인증) for a 국민연금 소득공제용 납부확인서. It clearly distinguishes itself from its sibling get_nps_deduction_cert by describing this as the request step that precedes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit about when to use: after user confirmation because of push notification and billing. Also contains precise when-NOT-to-use guidance: '승인 대기 중 인증 요청을 반복하거나 자동 승인하지 마세요.' It routes the agent to the correct next tool (get_nps_deduction_cert) with transactionId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.