Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ncloud_sens_get_sms_status

Read-only

Retrieve the delivery status of a single SMS message using its message ID, including carrier result code, success state, and completion time.

Instructions

Get one SMS delivery result (GET /sms/v2/services/{serviceId}/messages/{messageId}): status READY|PROCESSING|COMPLETED, statusCode (carrier result code), statusName success|fail, telcoCode, completeTime.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageIdYesMessage ID (from the send response or ncloud_sens_list_sms_requests)
serviceIdNoSMS service ID in NRN form (e.g. ncp:sms:kr:1********2:myproject). Defaults to NCLOUD_SENS_SMS_SERVICE_ID / NCLOUD_SENS_SERVICE_ID. Find it with ncloud_sens_list_projects (smsService.serviceId). A 'Forbidden' reply means the project does not have this channel enabled.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.0
    • changedInput schema / properties / messageId / description
      Previous value: -"Message ID to check delivery status"New value: +"Message ID (from the send response or ncloud_sens_list_sms_requests)"
    • addedInput schema / properties / serviceId
      Added value: +{
+  "description": "SMS service ID in NRN form (e.g. ncp:sms:kr:1********2:myproject). Defaults to NCLOUD_SENS_SMS_SERVICE_ID / NCLOUD_SENS_SERVICE_ID. Find it with ncloud_sens_list_projects (smsService.serviceId). A 'Forbidden' reply means the project does not have this channel enabled.",
+  "type": "string"
+}
  2. First observedv1.10.1

TDQS

A4.2/5.0
Behavior3/5

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

Annotations declare readOnlyHint: true, so the read-only nature is covered, but the description adds value by detailing response fields and status codes (e.g., READY|PROCESSING|COMPLETED, success|fail). It does not disclose other behavioral aspects like rate limits or that the status may change over time, but it provides useful context beyond the annotation.

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 concise, one sentence, but packed with essential information: endpoint, response fields, and status values. It front-loads the purpose and avoids any redundant phrasing. Every part earns its place.

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?

No output schema exists, but the description enumerates the response fields, which compensates. It covers the query parameters and provides hints on how to obtain them. The only minor gap is absence of typical error scenarios (beyond the Forbidden hint) and polling guidance, but overall it's sufficient for an agent to call it correctly.

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%, with both parameters described in the schema. However, the description adds meaning by referencing 'from the send response or ncloud_sens_list_sms_requests' for messageId and providing NRN format and environment variable defaults for serviceId, plus the 'Forbidden' hint. This enriches parameter understanding beyond the schema alone.

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 tool retrieves one SMS delivery result via a specific GET endpoint, and enumerates the key response fields (status, statusCode, statusName, telcoCode, completeTime). The verb 'Get' combined with the resource 'SMS status' and the explicit endpoint distinguishes it from related tools like ncloud_sens_list_sms_requests and ncloud_sens_send_sms.

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?

The description includes a direct API path and indicates it returns delivery results, implying it should be used to check individual message status. It does not explicitly state when to use it versus listing requests or checking reservations, but the context of 'one SMS delivery result' and the sibling names (list_sms_requests, get_sms_reservation_status) provide clear differentiation without needing explicit exclusions.

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