Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425

ncloud_kms_create_token_set

Generates an access token and refresh token set for token-based authentication in Naver Cloud KMS; requires a key tag and an active token generator.

Instructions

Create a token set (access token + refresh token) for token-based authentication. Requires an active token generator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyTagYesKey tag - unique identifier derived from key name
accessTokenHoursNoAccess token validity in hours (1-17520, default 72); 'UL' for unlimited
refreshTokenHoursNoRefresh token validity in hours (1-17520, default 2160); 'UL' for unlimited

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.1
    • addedInput schema / properties / accessTokenHours
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 17520,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    {
      +      "const": "UL",
      +      "type": "string"
      +    }
      +  ],
      +  "description": "Access token validity in hours (1-17520, default 72); 'UL' for unlimited"
      +}
    • addedInput schema / properties / refreshTokenHours
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 17520,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    {
      +      "const": "UL",
      +      "type": "string"
      +    }
      +  ],
      +  "description": "Refresh token validity in hours (1-17520, default 2160); 'UL' for unlimited"
      +}
  2. First observedv1.10.1

TDQS

A3.5/5.0
Behavior3/5

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

Only destructiveHint=false is provided, so the description must carry most of the behavioral burden. It adds the prerequisite about an active token generator, which is genuinely useful, but says nothing about whether the issued token values are returned only once, whether the operation is idempotent, or whether existing token sets are affected.

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?

Two tight sentences with no filler; the core action is stated first and the prerequisite follows. Every clause earns its place.

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?

No output schema exists, so the description would ideally say what comes back (the token values) since that is the whole point of the call. The prerequisite is covered, but the return behavior and any one-time visibility of tokens are left unstated.

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 coverage is 100%, with per-parameter descriptions including ranges, defaults, and the 'UL' option, so the schema does the heavy lifting. The description names the two token concepts but adds no syntax, default, or keyTag details beyond what the schema already documents.

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?

The description states a specific verb and resource ('Create a token set') and clarifies the payload ('access token + refresh token') and its purpose ('token-based authentication'). It does not explicitly distinguish itself from the sibling ncloud_kms_create_token_generator beyond the prerequisite mention, so it falls just short of 5.

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?

It gives one real precondition, 'Requires an active token generator,' which routes the agent toward the generator lifecycle. However, it never names the sibling to call first (ncloud_kms_create_token_generator) or states when this tool should be used instead of other KMS credential operations, leaving the when-to-use guidance implicit.

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

Deploy Server

Other Tools