ncloud-gov-mcp-server

ncloud_get_activity_logs

Read-only

Retrieve cloud activity logs within a specified time range, with optional filters for resource, service, and user, to audit actions.

Instructions

Get cloud activity tracer logs with filtering by period, service, and user. Uses POST method with JSON body. Time parameters accept ISO 8601 strings and are converted to epoch milliseconds internally.

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": {
      "startTime": "<startTime>",
      "endTime": "<endTime>"
    },
    "name": "ncloud_get_activity_logs"
  }
}

Input Schema

Name	Required	Description
`nrn`	No	Ncloud Resource Name to filter specific resource activities
`page`	No	Page number (0-based, default 0)
`size`	No	Page size (default 20)
`endTime`	Yes	End time in ISO 8601 format (e.g., "2024-01-31T23:59:59Z"). Converted to epoch ms internally. (Required)
`startTime`	Yes	Start time in ISO 8601 format (e.g., "2024-01-01T00:00:00Z"). Converted to epoch ms internally. (Required)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Aug 2, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description appropriately reflects a read operation. It adds useful context about the POST method and internal epoch conversion, which goes beyond the schema, but it omits behavioral details like pagination behavior or response format.

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

Conciseness4/5

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

Two sentences, front-loaded with purpose and followed by transport/time details. No filler or repetition, but the mention of 'service and user' could be more explicit about parameter correspondence.

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?

The description covers core functionality, HTTP method, and time handling, but for a 5-parameter tool with no output schema, it lacks details on return value structure, pagination expectations, and how to achieve service/user filtering. Given the large sibling set, more guidance would be beneficial.

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 descriptions cover 100% of parameters, including time format and conversion details, so the baseline is 3. The description adds a high-level mapping to 'period, service, and user' but does not clarify how 'user' maps to the parameters, and 'service' aligns loosely with nrn.

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 clearly states the tool fetches 'cloud activity tracer logs' with filtering capabilities, which distinguishes it from other log-related tools in the sibling list. However, it does not explicitly differentiate from ncloud_get_activity_detail or ncloud_search_events, making the distinctiveness slightly incomplete.

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 is provided on when to use this tool versus the many sibling log/event tools. The description implies usage by describing filters, but it does not state prerequisites, exclusions, or alternatives.

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

Deploy Server