Skip to main content
Glama

증명서 신청 처리결과 검색

nps_edi__b1__certificates__application_results__search
Read-only

REQUIRES prior nps_edi__auth__npki_session__login call with same account_link_id. Search NPS certificate application and issuance results. For an authenticated call, generate and save request_idempotency_key before the first request. Reuse it with the same arguments only to recover that request after a lost response; use a new key for a new execution. Without it, calling again remains a new request. This optional key is not available to anonymous taste calls. Keep any provider-specific idempotency_key unchanged; it is a different field. 호출마다 토큰 1소진

Input Schema

NameRequiredDescriptionDefault
page_noNoPage number (default: 1)
end_dateNoEnd date YYYYMMDD
start_dateNoStart date YYYYMMDD
template_codeNoTemplate code (서식 코드)
page_per_countNoItems per page (default: 10)
account_link_idNoAccount link ID (UUID v4). Optional — the server auto-resolves from your API key when omitted. Provide explicitly only when you have multiple certificates for the same provider. Each institution has a separate ID (Hometax != NHIS != NPS != FourInsure).
installment_roundNoInstallment round (회차)
notice_year_monthNoNotice year-month YYYYMM
row_text_containsNoPartial row text match
request_idempotency_keyNoOptional same-request recovery key for authenticated calls; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / request_idempotency_key
      Added value: +{
      +  "description": "Optional same-request recovery key for authenticated calls; see the tool description.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "pattern": "^[\\x20-\\x7E]+$",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real context beyond them: session prerequisite, one token consumed per call, and the fact that the idempotency key is unavailable to anonymous calls and is distinct from provider-specific keys. It doesn't describe result shape or pagination behavior, but the safety profile and cost model are covered.

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?

Front-loading the auth requirement is good, but five sentences are devoted to a single optional parameter, and a terse Korean cost note ('호출마다 토큰 1소진') is appended without an English gloss. The content is useful but the balance is skewed.

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 read-only, ten-parameter tool with a fully documented schema, the description covers the two things the schema cannot: the login prerequisite and the retry/cost semantics. Only the nature of the returned result rows is unaddressed, which is a minor gap given there is no output schema.

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 baseline is 3, and the description earns above that by explaining request_idempotency_key's recovery semantics and by distinguishing it from the provider's own idempotency_key field. Other parameters are left entirely to the schema.

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 and resource: 'Search NPS certificate application and issuance results.' An agent can distinguish it from write siblings like membership__apply/issue, though the description doesn't explicitly name an alternative search tool to contrast with.

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?

Explicitly states the prerequisite ('REQUIRES prior npki_session__login with same account_link_id') and gives the idempotency-key decision rule: reuse only to recover a lost response, new key for new execution. It doesn't say when this search is preferable to sibling searches, so not a 5.

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