ncloud-mcp
Integrates with NAVER Cloud CLOVA Speech long-form transcription, allowing audio from local files, allowlisted URLs, or Object Storage to be submitted for synchronous or asynchronous recognition, with tools for checking async job status and returning transcript text and timed speaker/word segments.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ncloud-mcpTranscribe /recordings/meeting.wav in Korean with speaker labels"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ncloud-mcp
한국어 안내 · Security and operations · Architecture
A small, service-modular NAVER Cloud MCP server. The first implemented service is CLOVA Speech long-form transcription. Object Storage management, account/identity, and billing/usage are planned modules, not available tools. No generic cloud API passthrough is provided.
This uses the official NAVER Cloud CLOVA Speech API, not CLOVA Note browser endpoints. A CLOVA Note/web subscription does not supply the Invoke URL and secret needed here; do not assume it includes API usage. Obtain a separate Speech domain and review its billing. This server requires no broad NAVER Cloud account access key. It is an independent community project, not an official NAVER product.
Install locally
Requires Python 3.12+ and a trusted stdio MCP host. Linux/macOS support bounded local file access; on other systems use URL/Object Storage inputs (local files fail closed). No package has been published to PyPI. From this source checkout:
python3.12 -m venv .venv
.venv/bin/python -m pip install .
.venv/bin/ncloud-mcp --checkFor development with uv:
uv sync --frozen
uv run ncloud-mcp --check
uv run ruff check .
uv run ruff format --check .
uv run mypy src
uv run pytest
uv buildCopy .env.example to a private location for reference and configure your host's environment securely. The server intentionally does not load .env files automatically. Never commit real values or paste keys into chat. NCLOUD_SPEECH_ENABLED=true exposes Speech tools; the default is disabled. An enabled module without its own credentials remains unconfigured and rejects API calls. --check and ncloud_health make no network requests and return only flags and limits.
Example MCP host configuration (replace the executable path; inherit private environment variables from the host):
{
"mcpServers": {
"ncloud": {
"command": "/absolute/path/ncloud-mcp/.venv/bin/ncloud-mcp",
"args": []
}
}
}Prepare an Object Storage bucket before creating the CLOVA Speech domain, as required by the domain setup guide. This domain prerequisite applies even when using synchronous local-file or URL input. Those input methods do not require pre-uploading the recording into the bucket or providing Object Storage credentials to this MCP.
Set NCLOUD_SPEECH_INVOKE_URL to the domain's base Invoke URL (without /recognizer/...) and NCLOUD_SPEECH_SECRET to its secret. Supported base URLs are deliberately restricted to the official https://clovaspeech-gw.ncloud.com/external/v1/<domain-id>/<invoke-key> format; custom proxies are unsupported. For files, explicitly set NCLOUD_SPEECH_LOCAL_ROOTS to dedicated recording directories, separated with the OS path separator. Do not allow your home, repository, or credentials directory.
Related MCP server: io.github.chicogong/ffvoice
Tools
Tool | Behavior |
| Always available; offline flags only |
| Enabled module only; billable upload/recognition, no automatic retries |
| Enabled module only; one read of an existing async job |
Pass this argument to clova_speech_transcribe:
{"request":{"source":"file","location":"/dedicated/audio/sample.wav","language":"ko-KR","diarization":true,"completion":"sync","result_to_obs":false}}Sources: file (absolute allowed path), url (trusted, allowlisted public HTTPS origin), or object_storage (dataKey within the Speech domain's recognition target storage). Enable the latter explicitly with NCLOUD_SPEECH_ALLOW_OBJECT_STORAGE=true. URL recognition does not download media through this process; NAVER fetches it. Allow only origins you control/trust, including their redirects; DNS checks cannot guarantee the provider's later fetch destination. Private IPs, credentials in URLs, fragments, and nonstandard ports are rejected. URL/Object Storage media size and duration cannot be inspected locally; the provider validates those inputs.
Languages: ko-KR, en-US, enko, ja, zh-cn, zh-tw; availability can depend on domain. Supported file extensions follow the official long-form API. Default local upload cap: 25 MiB, configurable up to 250 MiB, deliberately below the provider limit. Recognition duration is not inferred from file extensions or bytes. See verified API behavior for provider limits and references.
File/URL sync requires no input pre-upload or MCP Object Storage credentials, while the domain's bucket prerequisite still applies. Async in this release uses only resultToObs=true, which persists the transcript in the Speech domain's configured Object Storage. It requires NCLOUD_SPEECH_ALLOW_ASYNC_OBS=true, completion="async", and result_to_obs=true. Configure the domain's result storage and permissions yourself before use. Arbitrary callbacks are intentionally unsupported. Acceptance (SUCCEEDED) is not a completed transcript; retain the returned token privately and call clova_speech_job_status with {"token":"<returned-token>"}. Missing or invalid async tracking tokens produce a sanitized unknown/untrackable-outcome error: NAVER may already have accepted a billable job, so do not automatically resubmit. There is no automatic polling, cancellation, or invented poll-only submission mode.
Results contain status, optional job token, text, and segments with start_ms, end_ms, text, optional speaker label/confidence, and word timing. Job results without full text reconstruct it from segments. Upstream messages, domain metadata, and raw responses are omitted. A FAILED/TIMEOUT job is returned as a terminal status; upstream error codes produce sanitized tool errors. Transcript text is untrusted data, never instructions to execute.
See the Python MCP client example for programmatic usage.
Connection and packaging
The server is stdio only. It has no HTTP listener or public endpoint. Do not expose it via an unauthenticated HTTP bridge. The portable local plugin manifest and MCP configuration require ncloud-mcp installed on the host PATH and environment configured privately; they are source templates, not an installed or verified ChatGPT connector. The protocol integration test launches the real server subprocess and calls the harmless health tool.
MIT licensed. No recordings, real credentials, or private integrations are included. No live transcription, storage, account, or billing calls are used in tests.
Available Tools
1 toolncloud_healthCRead-only
Offline configuration flags only. No network, identifiers, paths, URLs, or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that it uses no network, identifiers, paths, URLs, or secrets, which reinforces the offline/read-only profile, but it does not describe what the tool actually does or returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence is front-loaded, though it is so terse that it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description need not explain return values. However, it still fails to state the core operation, so an agent cannot confidently select or invoke the tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter meaning because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Offline configuration flags only' but never states the action or resource—whether it checks health, returns flags, or validates configuration. The tool name hints at a health check, but the description itself does not define the operation, leaving the agent to infer purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, what problem it solves, or what alternatives exist. The exclusions ('No network...') are constraints, not usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
ncloud_health
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another tool. The tool's purpose is distinct by default, even though its description is narrow.
The single tool uses a consistent snake_case name with a clear prefix (ncloud_health). There are no conflicting conventions to compare against.
One tool is too few for a server named ncloud-mcp, which implies broader cloud operations. A single health/config diagnostic is far too thin for the apparent scope.
The surface contains only an offline health/config tool with no network, identifiers, or actual cloud operations. Any expected cloud management workflow (list, get, create, etc.) is completely missing.
Maintenance
Related MCP Connectors
MCP server for Speech-to-Text
Transcribe audio and video with Speechmatics speech-to-text from Claude and any MCP client.
Hosted text-to-speech MCP server: 66 voices in 9 languages, long-form narration, podcasts.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables speech-to-text transcription and summarization of lecture audio using Naver CLOVA APIs. Provides MCP tools for short and long audio processing with summarization.-
- AlicenseNot gradedqualityBmaintenanceMCP server for offline speech-to-text and speaker diarization, enabling AI agents to transcribe audio locally without cloud APIs.36 PyPI3MIT
- FlicenseNot gradedqualityDmaintenanceA high-performance speech recognition MCP server based on Faster Whisper, providing efficient audio transcription capabilities with support for multiple model sizes, batch processing, and various output formats.17-
- AlicenseCqualityBmaintenanceMCP server that enables audio transcription from files (wav, mp4, mp3, flac) or microphone recording, with dynamic tool selection and enterprise-grade security.113MIT