Use this MCP server to fetch China news, platform hot lists, and deletion-watch flags from the China News Feed Apify actor with configurable language, sources, platforms, and billing caps.
get_china_news: Retrieve news rows in zh, en, or both; optionally filter by query, sources (e.g., xinhua, bbc, mfa), and sourceTypes (State media, Party-gov, Commercial platform, Overseas independent, Dissident, Censorship tracker); cap billed rows with maxItems (1–500).
get_hot_lists: Retrieve hot-list rows for selected platforms (Weibo, Baidu, Zhihu, Toutiao, Douyin, Bilibili, Kuaishou) with maxRank (5–50) and maxItems (1–500); language projection controls headlines.
get_deletions: Retrieve rows with non-null censorship/deletion flags, including status, label, rank, peak rank, first/last seen, and both headlines; optionally filter by highRank (3–50) and platforms.
Apply language projection (en, zh, both) and local query/deletion filtering after billing, so returned count may be smaller than billed rows.
Costs $8 per 1,000 dataset rows on your Apify account; default 50-row call costs up to $0.40; no automatic retries; fetch timeout is 300 seconds.
Deploy via stdio in Claude Desktop, Cursor, Docker, or Smithery by supplying APIFY_TOKEN.
Provides tools for retrieving Baidu hot-list rankings and deletion-watch/censorship flags, including status, label, rank, peak rank, and first/last seen timestamps when available.
Provides tools for retrieving Bilibili hot-list rankings and deletion-watch/censorship flags, including status, label, rank, peak rank, and first/last seen timestamps when available.
Provides tools for retrieving Kuaishou hot-list rankings and deletion-watch/censorship flags, including status, label, rank, peak rank, and first/last seen timestamps when available.
Provides tools for retrieving Zhihu hot-list rankings and deletion-watch/censorship flags, including status, label, rank, peak rank, and first/last seen timestamps when available.
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., "@china-news-feed-mcp show me today's top Weibo and Zhihu hot topics in English"
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.
A TypeScript MCP server for China news, platform hot lists, and deletion-watch flags, wrapping the China News Feed Apify actor (CeTIPfpcWcDrEhrPV). Uses Node.js 20 native fetch and MCP over stdio.
Actor usage costs $8 per 1,000 dataset rows, billed to your own Apify account. Supply your API token through APIFY_TOKEN. Each call starts an actor run with emitOnlyNew: false, snapshotCount: 1, and maxItems as the billed-row cap. A default 50-row call costs up to $0.40 at this row price.
Tool | Inputs | Result |
|
| News rows only; |
|
| Hot-list rows only; |
|
| Rows with non-null censorship flags, including status, label, rank, peak rank, and first/last seen when present. Both headlines are included. |
Supported platforms: Weibo 微博 (weibo), Baidu 百度 (baidu), Zhihu 知乎 (zhihu), Toutiao 今日头条 (toutiao), Douyin 抖音 (douyin), Bilibili 哔哩哔哩 (bilibili), Kuaishou 快手 (kuaishou).
News sourceTypes accepts the actor's exact values: State media, Party-gov, Commercial platform, Overseas independent, Dissident, Censorship tracker. Omitting sources or source types uses actor defaults; an empty source-type array selects no news types. An empty platform array selects no hot lists.
language controls output projection: en includes headline_en, zh includes headline_original, and both includes both. Missing translations are omitted. The actor has no language or query input. query filters both headlines locally, case-insensitively, after fetching. Deletion filtering also happens locally, so the returned count can be smaller than the fetched/billed row count. No automatic retries are made.
Install Node.js 20 or newer and obtain a token from your Apify account. For Claude Desktop, add the following to claude_desktop_config.json (open it through Settings → Developer → Edit Config). For Cursor, add it to .cursor/mcp.json in your project or ~/.cursor/mcp.json for global use. Merge it with existing mcpServers entries, then restart the client.
{
"mcpServers": {
"china-news-feed": {
"command": "npx",
"args": ["-y", "github:joydai2026-del/china-news-feed-mcp"],
"env": {
"APIFY_TOKEN": "<your-apify-token>"
}
}
}
}GitHub installation builds dist/ using the prepare script. Git must also be available for installation from GitHub. Keep your real token in private client configuration or your process environment; never commit it.
For a local build:
git clone https://github.com/joydai2026-del/china-news-feed-mcp.git
cd china-news-feed-mcp
npm install
npm run buildUse this server entry in either client's mcpServers object, replacing the path with your absolute checkout path:
{
"china-news-feed": {
"command": "node",
"args": ["/absolute/path/china-news-feed-mcp/dist/index.js"],
"env": { "APIFY_TOKEN": "<your-apify-token>" }
}
}For manual startup with APIFY_TOKEN already exported, run npm start. The server reserves stdout for MCP messages. Missing tokens produce a clear tool error; tokens and raw upstream errors are never logged. The fetch timeout is 300 seconds; configure a longer tool timeout in your client if supported. A timed-out request may leave an actor run active in Apify.
Related MCP server: HotNews MCP Server
docker build -t china-news-feed-mcp .
# APIFY_TOKEN must already be exported in your shell.
docker run --rm -i -e APIFY_TOKEN china-news-feed-mcpTo use Docker from Claude Desktop or Cursor, set command to docker, args to ["run", "--rm", "-i", "-e", "APIFY_TOKEN", "china-news-feed-mcp"], and provide APIFY_TOKEN in the server's env. Use -i to keep stdin open for stdio transport.
The included smithery.yaml declares a stdio start command and requires the apifyToken configuration value. Smithery maps that value to APIFY_TOKEN and starts node dist/index.js; the included multi-stage Dockerfile supplies the build and runtime. Supply your own token when configuring the server.
The official Apify MCP also works generically with this actor. This wrapper adds dedicated tools, local headline filtering, language projection, and compact output.
Shortened from the two fixture rows in sample-rows.json, illustrating a get_deletions response. The tool returns compact JSON text; null and empty fields are dropped. Flags such as likely_censored are actor assessments and retain their status and evidence.
{
"count": 2,
"rows": [
{
"kind": "hot",
"source_id": "toutiao",
"headline_en": "The 20th Asian Games Come to a Close",
"headline_original": "第20届亚运会闭幕",
"rank": 1,
"peak_rank": 1,
"first_seen": "2026-10-04T18:07:26Z",
"last_seen": "2026-10-04T23:28:50Z",
"censorship": { "status": "likely_censored", "label": "Likely censored" }
},
{
"kind": "hot",
"source_id": "weibo",
"headline_original": "蔡康永",
"rank": 14,
"peak_rank": 11,
"censorship": { "status": "likely_censored", "label": "Likely censored" }
}
],
"note": "billed rows: 2 at $8/1000"
}npm install
npm run build
npm testTests use mocked fetch responses and the provided fixtures, with no paid actor runs. Input reference: actor-input-schema.json. Licensed under MIT, copyright 2026 Ownly.
Free sample rows on GitHub: https://github.com/joydai2026-del/china-news-feed-samples
Hugging Face dataset: https://huggingface.co/datasets/freedom-press/china-news-feed-sample
Apify actor: https://apify.com/china.unofficial/china-news-feed
Fetch China news. Costs $8 per 1,000 dataset rows on your Apify account. Query and language are applied locally after billing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| sources | No | ||
| language | No | both | |
| maxItems | No | Actor cap on billed dataset rows, before client-side filtering. | |
| sourceTypes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two valuable traits: the $8/1,000-row cost on the Apify account and that query/language filtering happens client-side after billing (i.e., filtering does not reduce cost). It remains silent on auth requirements, return shape, and how sources/sourceTypes are resolved.
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 tight sentences, front-loaded with the purpose and immediately followed by the cost implication. No filler, though it is quite terse for a five-parameter tool.
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?
No output schema and low schema coverage mean the description should do more. Billing and filtering semantics are covered, but the meaning and valid values of sources (vs the enum-constrained sourceTypes) are never addressed.
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 only 20% (just maxItems), so the description must compensate. It clarifies that query and language are applied locally post-billing, which is real semantic value, but sources and sourceTypes are left entirely undocumented in both schema and description.
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?
States a specific verb ('Fetch') and resource ('China news'), which is distinct from the sibling resources (hot lists, deletions) without needing to name them. No explicit sibling differentiation, but the resource itself is unambiguous.
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 indication of when to use this versus get_hot_lists or get_deletions, and no prerequisites or exclusions. The only contextual guidance is billing mechanics, which is not a use-case signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch deletion-watch flags (including provisional and returned statuses). Costs $8 per 1,000 fetched dataset rows; unflagged rows also count toward billing.
| Name | Required | Description | Default |
|---|---|---|---|
| highRank | No | ||
| maxItems | No | Actor cap on billed dataset rows, before client-side filtering. | |
| platforms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It usefully discloses billing cost ($8 per 1,000 fetched dataset rows, including unflagged rows) and status coverage, but omits auth requirements, rate limits, and return 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?
Two sentences with zero waste: the purpose is front-loaded and the billing nuance is a crucial second sentence. Every sentence 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?
Given a 3-parameter tool with no output schema and no annotations, the description is missing too much: parameter semantics, return value structure, auth, and usage alternatives are all absent. Only billing and status scope are covered.
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 only 33%, so the description should compensate for undocumented parameters. It mentions 'dataset rows' loosely aligning with maxItems but does not explain highRank or platforms, nor the enum choices for platforms.
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 gives a specific verb (Fetch) and resource (deletion-watch flags), and adds scope detail ('including provisional and returned statuses'). It does not explicitly distinguish itself from the sibling tools get_china_news and get_hot_lists, but the resource is self-evidently different.
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?
There is no guidance on when to use this tool versus alternatives, nor are prerequisites or exclusions stated. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Chinese platform hot lists. Costs $8 per 1,000 dataset rows on your own Apify account.
| Name | Required | Description | Default |
|---|---|---|---|
| maxRank | No | ||
| language | No | both | |
| maxItems | No | Actor cap on billed dataset rows, before client-side filtering. | |
| platforms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a genuinely useful behavioral fact: cost of $8 per 1,000 dataset rows billed to the caller's own Apify account, which implies the user must supply Apify credentials. It stops short of describing whether rows are deduplicated, how filtering interacts with billing, or what the response contains.
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, no filler, with the capability statement front-loaded and the cost caveat immediately after. Every sentence 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 4-parameter tool with 25% schema coverage, no annotations, and no output schema, the description is far too thin. An agent cannot tell what platforms are returned by default, how language filtering works, or what distinguishes the two count-style parameters.
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 only 25% (just maxItems), and the description adds nothing about maxRank, language, or platforms. The billing note tangentially relates to maxItems but does not explain the important distinction that maxRank and maxItems govern different things (ranking depth vs. billed rows).
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?
States a specific verb and resource ('Fetch Chinese platform hot lists'), so the core action is unambiguous. However, it never distinguishes itself from siblings get_china_news and get_deletions, nor does it name which platforms qualify as 'hot list' sources, leaving overlap with news-fetching unaddressed.
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?
There is no statement of when to use this tool versus get_china_news or get_deletions, and no prerequisites or exclusions. The only contextual sentence concerns billing, not usage selection.
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.
v1.0.0get_china_newsget_deletionsget_hot_listsScored across 3 tools
Each tool targets a clearly distinct dataset: general news, platform hot lists, and deletion-watch flags. The boundaries are reasonably clear, though all three are read-only fetchers over overlapping Chinese-content sources, so an agent might occasionally hesitate between get_china_news and get_hot_lists.
All three tools follow a strict get_<noun> pattern (get_china_news, get_hot_lists, get_deletions), making the surface highly predictable. No verb or casing deviations.
Three tools is on the thin side, but the server's scope is narrow (three distinct Chinese data feeds), so each tool earns its place. No redundant or filler tools.
Coverage is fetch-only with no tool to discover available sources, platforms, or date ranges, and query/language handling is deferred to local parameters rather than exposed operations. For a read-only feed server this is workable, but the surface offers little beyond the three raw endpoints.
Real-time trending from major Chinese platforms (Weibo, Douyin, Baidu, Zhihu).
Google News for any topic or company: headline, source, publish time, snippet and the publisher's article URL, with time filters (past hour to past year) and sort by date. Runs on Apify, $1 per 1,000 articles.
Google News headlines, sources, and links via the Apify Google News API, hosted MCP.
Trending topics from Weibo, Baidu, Zhihu & Google Trends for content and market research.
