ncloud-gov-mcp-server

ncloud_kms_verify

Read-only

Verify a digital signature against base64-encoded data using RSA2048 or ECDSA keys to confirm authenticity and integrity.

Instructions

Verify a digital signature against data. Only RSA2048 or ECDSA key types supported.

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": {
      "keyTag": "<keyTag>",
      "data": "<data>",
      "signature": "<signature>"
    },
    "name": "ncloud_kms_verify"
  }
}

Input Schema

Name	Required	Description
`data`	Yes	Base64-encoded original data that was signed
`keyTag`	Yes	Key tag - unique identifier derived from key name
`signature`	Yes	Signature value to verify

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Aug 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds behavioral context beyond this: it specifies that only RSA2048 or ECDSA key types are supported, warning that other key types will fail. This is useful operational knowledge not present in the annotations. It does not contradict the read-only hint.

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

Conciseness5/5

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

The description is extremely concise—two short sentences. The action is front-loaded ('Verify a digital signature'), and the key type constraint is stated in a single additional sentence. No wasted words or redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with no output schema, the description does not disclose the return value or behavior on signature mismatch (e.g., does it return false or throw an error?). This is important for an agent to interpret the result correctly. The key type limitation is covered, but the outcome semantics are missing, leaving a gap in completeness for a simple tool.

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?

The input schema provides 100% coverage with descriptions for all three parameters ('data', 'keyTag', 'signature'), so the schema already explains each parameter. The description adds minimal parameter-level meaning, only implicitly linking 'data' and 'signature' via the verb 'verify'. This meets the baseline for fully documented schema parameters but does not exceed it.

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?

The description clearly states the action: 'Verify a digital signature against data' with a specific verb (verify) and resource (digital signature/data). It distinguishes from sibling tools like ncloud_kms_sign, encrypt, or decrypt by focusing on verification. The added constraint 'Only RSA2048 or ECDSA key types supported' further clarifies scope.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives is provided. The description merely states what it does and a key type limitation, but does not mention scenarios such as 'use to confirm authenticity of signed data' or exclude cases where another KMS operation might be more appropriate. The sibling ncloud_kms_sign is not referenced, leaving the agent to infer the relationship.

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

Deploy Server