Allows interaction with Naver's Chzzk live-streaming platform, providing tools for channel metadata, live status, search, and VOD lookups.
Click on "Install 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., "@mcp-chzzk What's the live status of channel '우왁굳'?"
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.
MCP (Model Context Protocol) server for Chzzk, Naver's Korean live-streaming platform.
Exposes Chzzk channel, live, search, and VOD lookups as MCP tools so Claude (or any MCP client) can query them.
⚠️ Chzzk does not publish an official public API. This server calls the same undocumented endpoints the web client uses. They may change without notice.
Tool | Description |
| Channel metadata (name, follower count, description, verified mark) |
| Live status — is broadcasting, title, category, viewer count, start time |
| Extended live info including 720p thumbnail URL |
| Search channels by keyword |
| Search VOD by keyword |
| Search currently live broadcasts by keyword |
| List currently live broadcasts (popularity order) |
| List recent VOD for a channel |
Channel arguments accept either a 32-hex channel id or a chzzk.naver.com/[live/]<id> URL.
Related MCP server: Naver Search MCP Server
npm install
npm run buildAll Chzzk endpoints exposed here are public — no authentication is required.
For private or restricted content (adult-only channels, subscriber views), provide Naver session cookies via env vars:
export CHZZK_NID_AUT="..."
export CHZZK_NID_SES="..."You can extract these from your browser's DevTools → Application → Cookies → naver.com while logged in.
Direct:
node build/index.jsWith MCP Inspector (browser-based debugger):
npm run inspectAdd to ~/.claude/settings.json or .mcp.json:
{
"mcpServers": {
"chzzk": {
"command": "node",
"args": ["/absolute/path/to/mcp-chzzk/build/index.js"],
"env": {
"CHZZK_NID_AUT": "",
"CHZZK_NID_SES": ""
}
}
}
}Then in Claude Code, run /mcp to confirm the chzzk server appears and the tools are listed.
hacs-chzzk — Home Assistant integration with the verified Chzzk endpoints this server is built on.
twitch-mcp-server — structural reference.
MIT
Get Chzzk channel metadata: name, image, description, follower count, openLive flag, verified mark.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Chzzk channel — either a 32-hex channel id or a chzzk.naver.com URL (e.g. https://chzzk.naver.com/live/<id>). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what metadata is returned, but does not mention behavior like error handling, authentication needs, or rate limits. Adequate but not rich.
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?
The description is a single sentence that efficiently conveys the tool's purpose and key output fields. Every word earns its place.
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?
For a simple one-parameter tool with no output schema, the description covers the basics well. It specifies the return fields, though it could improve by noting that it's a read-only operation.
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?
Schema coverage is 100% and the schema already describes the parameter in detail (channel ID or URL). The description adds no additional meaning beyond that, meeting the baseline 3.
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 clearly states the verb (Get) and resource (Chzzk channel metadata), and lists specific fields (name, image, description, follower count, openLive flag, verified mark). It distinguishes from siblings like get_channel_videos and get_live_status.
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?
The description implies usage when you need channel metadata, but it provides no explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent VOD (videos) for a specific Chzzk channel.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Chzzk channel — either a 32-hex channel id or a chzzk.naver.com URL (e.g. https://chzzk.naver.com/live/<id>). | |
| size | No | Maximum number of items to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not mention permissions, rate limits, side effects, or whether it is read-only, relying solely on the implied meaning of 'list'. This is insufficient for safe invocation.
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?
The description is a single, direct sentence with no extraneous information. It is front-loaded with the core action and scope, achieving maximum conciseness.
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?
The tool is simple (2 params, no output schema), but the description lacks information about the return format, pagination, or any constraints (e.g., 'recent' is undefined). Without an output schema, the description should at least hint at the response structure.
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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. For example, it does not clarify the format of the 'channel' parameter beyond what the schema provides.
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 clearly states the action (list), resource (recent VOD/videos), and scope (for a specific Chzzk channel). It effectively distinguishes from siblings like 'search_videos' which searches across channels, and 'list_lives' which deals with live streams.
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?
The description implies usage through the tool name and context, but provides no explicit guidance on when to use this tool versus alternatives like 'search_videos'. An agent must infer from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get extended live info including 720p thumbnail URL. Falls back to live status if the channel is offline.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Chzzk channel — either a 32-hex channel id or a chzzk.naver.com URL (e.g. https://chzzk.naver.com/live/<id>). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the fallback behavior and mentions the thumbnail URL, which is transparent for a retrieval tool, though it lacks details on authentication or error cases.
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 concise sentences with no fluff; the first sentence states the main purpose, and the second adds crucial fallback behavior.
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?
For a simple tool with one parameter and no output schema, the description is complete: it explains the purpose, the key output (thumbnail URL), and the fallback behavior.
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?
Schema coverage is 100%, so the schema already describes the parameter. The description adds value by mentioning the 720p thumbnail URL output, which is not in the schema.
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 clearly states the verb 'Get' and the resource 'extended live info including 720p thumbnail URL', and distinguishes from siblings like get_live_status by promising extended info and a fallback behavior.
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?
The description implies usage when extended info or thumbnail is needed, and mentions fallback when offline, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the lightweight live status for a Chzzk channel — whether it is currently broadcasting, title, category, viewer counts, start time.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Chzzk channel — either a 32-hex channel id or a chzzk.naver.com URL (e.g. https://chzzk.naver.com/live/<id>). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adequately states the tool is lightweight and lists returned data. However, it does not disclose any potential side effects, authentication needs, or rate limits. For a read-only status tool, this is acceptable but leaves expectations implicit.
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?
The description is a single sentence that front-loads the purpose and lists key outputs. Every word adds value, with no redundancy or unnecessary detail.
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?
Given the tool has one required parameter and no output schema, the description adequately covers what the tool does and what it returns. It could benefit from specifying the return type (e.g., JSON object) or field types, but the listed fields (broadcasting, title, etc.) provide sufficient context for an AI agent.
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?
The schema description coverage is 100% (the parameter 'channel' is described with both id and URL format). The description adds context that the tool is for Chzzk channels but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
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 clearly states the tool retrieves 'lightweight live status' for a Chzzk channel and enumerates the specific fields returned (broadcasting, title, category, viewer counts, start time). This distinguishes it from siblings like get_live_detail (which likely provides more detail) and list_lives (which returns multiple channels).
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?
The description implies this tool is for lightweight status checks, but does not explicitly state when to choose it over get_live_detail or list_lives. No exclusion criteria or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently live Chzzk broadcasts, ordered by the platform's popularity ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Maximum number of items to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions ordering by popularity but does not disclose data freshness, pagination behavior, or what constitutes 'popularity'. Adequate for a simple list tool but minimal.
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?
Single sentence, no fluff, directly communicates purpose and ordering. Highly concise.
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?
Given the simple 1-parameter tool and no output schema, the description covers the main purpose and ordering. Minor gap: could mention typical return fields, but overall sufficient.
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?
The input schema covers 100% of parameter details, so the description adds no additional meaning. Baseline score of 3 is appropriate.
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 clearly states the tool lists currently live broadcasts ordered by popularity, distinguishing it from sibling search tools like search_lives which allow filtering. Specific verb 'list' and resource 'live broadcasts' with ordering detail.
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 versus siblings like get_live_detail or search_lives. Lacks context on preferred use cases or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Chzzk channels by CHANNEL NAME. Use this to look up a specific streamer by their handle. Each result includes an openLive flag indicating whether the channel is currently broadcasting — combine with get_live_status / get_live_detail for live info.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword. | |
| size | No | Maximum number of items to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the openLive flag in results, but does not cover pagination, matching behavior (partial/exact), rate limits, or error handling. The agent lacks key behavioral context.
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 sentences with no wasted words. The first sentence states the purpose directly, and the second provides actionable guidance (openLive flag and combination with other tools). Extremely concise and well-structured.
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?
Given no output schema, the description partially explains the return (includes openLive flag) but omits full response structure, order, or list vs. single result. With sibling tools like get_channel, the behavior is not fully specified, leaving gaps for the agent.
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?
The input schema has 100% coverage with descriptions for both parameters (keyword and size). The description adds no extra semantic value beyond what the schema provides, meeting the baseline but not exceeding it.
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 clearly states the tool searches Chzzk channels by channel name, with a specific verb (search) and resource (channels). It adds context by mentioning looking up a specific streamer by handle, but it does not explicitly differentiate from sibling tools like get_channel, which also looks up channels.
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?
The description gives a clear use case (look up a specific streamer by handle) and hints at combining with other tools for live info. However, it does not specify when not to use it or provide alternatives to distinguish from search_lives or get_channel, leaving room for confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search currently live Chzzk broadcasts by LIVE TITLE (the title the streamer set for this broadcast — NOT the channel name). If you want to find a specific streamer by handle, use search_channels instead.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword. | |
| size | No | Maximum number of items to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It briefly states it searches currently live broadcasts but does not disclose other behavioral traits like idempotency, rate limits, or authentication needs. For a simple search tool, this is minimally adequate.
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?
The description is two sentences: a clear main statement and an explicit alternative. No wasted words, front-loaded with key information.
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?
Given low complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains what it searches, how to use it (keyword, optional size), and what it doesn't do. Lack of return value description is acceptable since no output schema exists.
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?
Schema description coverage is 100%, with both parameters already described. The description adds no additional parameter meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the tool searches currently live broadcasts by live title, using specific verbs and resource. It distinguishes from search_channels by specifying what this tool does NOT search (channel names).
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?
The description explicitly tells when to use this tool (search by live title) and when to use an alternative (search_channels for streamer handles). It also implies it's for currently live content only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Chzzk VOD (recorded videos) by VIDEO TITLE / tags. Does NOT search live broadcasts — use search_lives or search_channels for those.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword. | |
| size | No | Maximum number of items to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states it searches by title/tags but omits behavioral details like pagination support, authentication requirements, or result format.
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?
Extremely concise: two sentences with no wasted words. The key purpose and exclusions are front-loaded.
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?
For a simple two-parameter search tool, the description covers the basics. However, without annotations or output schema, it lacks details on result format, authentication, and pagination behavior, leaving gaps.
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?
Schema description coverage is 100%, and the description adds clarifying context that 'keyword' refers to video title or tags, enhancing understanding beyond the raw schema.
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 clearly states the tool searches Chzzk VOD by title/tags and explicitly differentiates from sibling tools by noting it does not search live broadcasts, directing to search_lives or search_channels.
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?
The description provides explicit context on when to use this tool (VOD search) and when not (live broadcasts), with clear references to alternatives. However, it could better differentiate from get_channel_videos for channel-specific video searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_channelget_channel_videosget_live_detailget_live_statuslist_livessearch_channelssearch_livessearch_videosScored across 8 tools
Each tool targets a distinct resource or action: channel metadata, videos, live status/detail, live listings, and searches by channel, live title, or video. Even the two live-related tools (get_live_detail and get_live_status) have clearly different levels of detail.
All tool names follow a consistent verb_noun pattern in snake_case: get_channel, get_channel_videos, get_live_detail, get_live_status, list_lives, search_channels, search_lives, search_videos. Verbs are uniform (get, list, search).
8 tools cover the core read operations for the Chzzk streaming platform: channel info, VODs, live status/detail, and three search entry points. This is a well-scoped set without bloat.
The tool surface covers essential read operations for channels, videos, and live broadcasts. A minor gap is the lack of a dedicated tool to retrieve a single VOD by ID, though get_channel_videos and search_videos provide access. Overall, it supports common agent workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Multistream to Twitch, YouTube and Kick; generate OBS overlays from a plain-English prompt.
Clip Twitch, YouTube and Kick VODs, rank moments by viral score and schedule posts.
