ncloud-mcp-server

ncloud_sens_list_sms_requests

Read-only

List SMS delivery requests from the last 90 days, filtering by request ID, time window, recipient, or status. Paginate results with nextToken to manage large volumes.

Instructions

List SMS delivery requests of the last 90 days (GET /sms/v2/services/{serviceId}/messages). Requires requestId, or requestStartTime+requestEndTime (≤30 days), or completeStartTime+completeEndTime (≤24 h). Paginate with nextToken. An empty HTTP 404 reply means no matching records for this service (observed live 2026-09), not a wrong path.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Filter by recipient number (digits only)
`from`	No	Filter by sender number (digits only)
`type`	No	Filter by message type
`status`	No	Filter by request status
`pageSize`	No	Items per page (1-100, default 20)
`messageId`	No	Filter by message ID
`nextToken`	No	Page token from the previous response
`requestId`	No	Request ID from the send response. One of requestId, requestStartTime+requestEndTime, completeStartTime+completeEndTime is required
`serviceId`	No	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.
`statusName`	No	Filter by delivery result
`contentType`	No	Filter by content type
`countryCode`	No	Filter by country code
`requestEndTime`	No	Window end by request time (SMS: within 30 days, Alimtalk/Brand: within 31 days of start)
`completeEndTime`	No	Window end by completion time (within 24 hours of start)
`requestStartTime`	No	Window start by request time 'YYYY-MM-DD HH:mm:ss'
`completeStartTime`	No	Window start by completion time 'YYYY-MM-DD HH:mm:ss'

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv1.16.0Sep 23, 2026

addedInput schema / properties / completeEndTime / $ref
```
Added value: +"#/properties/requestStartTime"
```

changedInput schema / properties / completeEndTime / description

Previous value: -"Query end time based on delivery completion (within 24 hours of completeStartTime)"New value: +"Window end by completion time (within 24 hours of start)"

removedInput schema / properties / completeEndTime / type
```
Removed value: -"string"
```
addedInput schema / properties / completeStartTime / $ref
```
Added value: +"#/properties/requestStartTime"
```

changedInput schema / properties / completeStartTime / description

Previous value: -"Query start time based on delivery completion (YYYY-MM-DD HH:mm:ss format)"New value: +"Window start by completion time 'YYYY-MM-DD HH:mm:ss'"

removedInput schema / properties / completeStartTime / type
```
Removed value: -"string"
```

addedInput schema / properties / contentType

Added value: +{
+  "description": "Filter by content type",
+  "enum": [
+    "COMM",
+    "AD"
+  ],
+  "type": "string"
+}

addedInput schema / properties / countryCode

Added value: +{
+  "description": "Filter by country code",
+  "type": "string"
+}

changedInput schema / properties / from / description

Previous value: -"Filter by caller ID (numbers only)"New value: +"Filter by sender number (digits only)"

changedInput schema / properties / nextToken / description

Previous value: -"Page location token for pagination"New value: +"Page token from the previous response"

changedInput schema / properties / pageSize / description

Previous value: -"Number of items per page (1-100, default: 20)"New value: +"Items per page (1-100, default 20)"

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```

changedInput schema / properties / pageSize / type

Previous value: -"number"New value: +"integer"

addedInput schema / properties / requestEndTime / $ref
```
Added value: +"#/properties/requestStartTime"
```

changedInput schema / properties / requestEndTime / description

Previous value: -"Query end time based on delivery request (within 30 days of requestStartTime)"New value: +"Window end by request time (SMS: within 30 days, Alimtalk/Brand: within 31 days of start)"

removedInput schema / properties / requestEndTime / type
```
Removed value: -"string"
```

changedInput schema / properties / requestId / description

Previous value: -"Request ID (conditional: one of requestId, requestStartTime+requestEndTime, or completeStartTime+completeEndTime required)"New value: +"Request ID from the send response. One of requestId, requestStartTime+requestEndTime, completeStartTime+completeEndTime is required"

changedInput schema / properties / requestStartTime / description

Previous value: -"Query start time based on delivery request (YYYY-MM-DD HH:mm:ss format)"New value: +"Window start by request time 'YYYY-MM-DD HH:mm:ss'"

addedInput schema / properties / requestStartTime / pattern

Added value: +"^\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2}:\\d{2}$"

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"
+}

changedInput schema / properties / statusName / description

Previous value: -"Filter by reception status"New value: +"Filter by delivery result"

changedInput schema / properties / to / description

Previous value: -"Filter by recipient number (numbers only)"New value: +"Filter by recipient number (digits only)"

First observedv1.10.1Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the burden of behavioral context. It adds valuable, non-obvious behavior: the empty-404 response means no matching records rather than a wrong path, and it documents the 90-day retention window. This goes well beyond what the schema or annotation already provide.

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?

Three dense sentences with no filler. The main action is front-loaded, followed by the required parameter logic, pagination, and the 404 edge case. Every sentence 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?

For a 16-parameter tool with no output schema, the description covers the most critical invocation requirements, pagination, and an important error-behavior gotcha. It does not describe the response shape, but that is not strictly needed to select and invoke the tool correctly; the missing piece is minor.

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 the baseline is 3. The description adds meaning beyond the schema by specifying which mutually exclusive parameter groups actually need to be supplied, and by clarifying the time-window constraints in the same sentence. This helps an agent choose the right parameter combination without having to infer it from scattered field descriptions.

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 states a specific verb ('List'), resource ('SMS delivery requests'), and time scope ('last 90 days'), while also giving the exact REST endpoint. This clearly distinguishes it from sibling tools like ncloud_sens_list_alimtalk_requests and ncloud_sens_list_brandmessage_requests.

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 gives clear invocation context: which parameter combinations are required (requestId, request time range, or completion time range) and their limits (30 days / 24 hours), plus nextToken pagination. It does not explicitly name alternatives or state when not to use this tool, but the resource-specific wording makes the usage context unambiguous.

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

Deploy Server

ncloud_sens_list_sms_requests

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools