protogrid

Search / io.github.pipeworx-io/china-news

China News

R0· no sign-in

China / Hong Kong / Taiwan news search.

v0.1.2 · active · repository · website · descriptor JSON · versions

An agent can connect right now, no human step.Remote endpoint, no authentication, reachable on the last probe.
Quality–not scored
Trust96of 100
Uptime, 30 days99%
Latency p5028 ms

Connect

8 clients · secrets stay placeholders
{
  "mcpServers": {
    "china-news": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/china-news/mcp"
    }
  }
}
claude mcp add --transport http china-news https://gateway.pipeworx.io/china-news/mcp
[mcp_servers.china-news]
url = "https://gateway.pipeworx.io/china-news/mcp"
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "china-news": {
      "type": "remote",
      "url": "https://gateway.pipeworx.io/china-news/mcp",
      "enabled": true
    }
  }
}
{
  "mcpServers": {
    "china-news": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/china-news/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=china-news&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vZ2F0ZXdheS5waXBld29yeC5pby9jaGluYS1uZXdzL21jcCJ9"
}
{
  "servers": {
    "china-news": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/china-news/mcp"
    }
  }
}
{
  "mcpServers": {
    "china-news": {
      "httpUrl": "https://gateway.pipeworx.io/china-news/mcp"
    }
  }
}
extensions:
  "china-news":
    enabled: true
    name: "china-news"
    type: streamable_http
    uri: "https://gateway.pipeworx.io/china-news/mcp"
    timeout: 300

Quality – / 100not scored

Not scored: fewer than three checks apply, usually because no remote answered a credential-free probe or the server is a local package.

protocol75 · weight 25
  • warn
    protocol.modernnewest supported version is 2025-03-26; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
  • n/a
    protocol.statelessonly applies to 2026-07-28 servers
  • pass
    protocol.transportstreamable HTTP
  • n/a
    protocol.list_ttlonly applies to 2026-07-28 servers
authorizationn/a · weight 15
  • n/a
    auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
  • n/a
    auth.secret_in_urlno templated URL
tool hygienen/a · weight 30
  • n/a
    tools.descriptions, tools.description_length, tools.schemas, tools.annotations, tools.directory_hints, tools.token_cost, tools.api_dumptool list unknown (behind auth, not probed, or empty)
stabilityn/a · weight 15
  • n/a
    stability.changes, stability.rug_pulltool list unknown
dependenciesn/a · weight 15
  • n/a
    deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

Tool list unknown · tools last changed 2026-10-20 · checked 2026-10-20 21:18 UTC

Tool changes

  • archive_evidenceremoved

    What did a web page say on a given date? Finds the archived capture of a URL nearest that date across the Internet Archive Wayback Machine, Common Crawl and Arquivo.pt, reads it, and returns the readable text (HTML stripped) with the capture timestamp, a link to the archived copy, and the GAP between the date asked for and the capture actually used (e.g. "Captured 1.5 day(s) before the requested date"). One call replaces the find-capture, fetch-record, parse-HTML chain. If no archive holds a capture within max_gap_days (default 30) it answers status "no_capture" and names the nearest capture before and after the date with their gaps, so a distant capture is never passed off as the page on that date. Every archive's outcome is listed in sources[]; one that timed out or errored says so with its upstream status, and if all of them failed the answer is error "archives_unavailable", not no_capture. Captures are immutable and cached by capture id; served_from says whether the text came from cache or upstream. Use archive_compare to see what changed between two dates.

  • polymarket_edgesremoved

    Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price. Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets. FIVE MODEL FAMILIES grouped into three response segments under by_segment: (1) MODEL_DRIVEN — crypto_price (lognormal barrier from 90d FRED log-returns) and news_momentum (GDELT 7d/21d article-volume ratio, soft signal w/ halved Kelly). (2) STRUCTURAL_ARBITRAGE — partition_overround on mutually-exclusive events; per-leg favorite-longshot bias correction with per-sport α (tennis 1.02, soccer 1.10, MMA 1.15, default 1.0); placeholder-slug filter drops will-person-X / will-team-Y / will-manager-Z / will-someone-else- backstops; partitions with >20% placeholder fraction skipped entirely. (3) CONCENTRATED_LONGSHOT — basket trade when one leg ≥75% AND ≥2 longshots ≤8% AND portfolio return ≥25:1; rare-by-design (gates relaxed Run 8 from prior 85%/5%/50:1). EVERY OPPORTUNITY carries edge_pp_net (net of slippage AND Polymarket's own taker fee — fees_pp_applied itemises the fee component; see fees.ts for the published per-category schedule), kelly_fraction + kelly_fraction_half (capped at 0.25), market.liquidity, market.spread_pp, market.volume, plus a 24h-move warning ("Market moved X.Xpp in 24h") when the recent move alone exceeds the edge — your edge may already be in the price. TRADEABLE-EDGE KNOBS: min_liquidity / max_spread_pp drop opportunities where edge isn't realizable; min_partition_leg_kelly filters partitions by best per-leg Kelly. RESPONSE TOP-LEVEL: by_segment{model_driven,structural_arbitrage,concentrated_longshot}, fed_candidates/fed_note (Fed bets surface here, excluded from ranking — 1m-T vs EFFR signal is unreliable at meeting-month horizons without paid OIS/SOFR-futures data), and _diagnostics{concentrated_longshot:{...funnel counters},category_counts,filter_skips} so callers can see WHY a segment is empty (top-N stale, all candidates failed gates, knob dropped them). Cached 1h at the KV level keyed on all knobs.

  • polymarket_arbitrageremoved

    Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FEES: every opportunities[] row and partition_check.arbitrage carry edge_pp_gross (== gap_pp / overround_pp), fees_pp, edge_pp_net, net_positive, plus polymarket_fee_pp, fee_basis and fee_categories[]. BOTH cost components are modeled: Polymarket's own per-category TAKER FEE (fee = shares × rate × p × (1-p), rates crypto 0.07 / sports-economics-culture-weather-other 0.05 / finance-politics-mentions-tech 0.04, geopolitics and world events fee-free; verified against Polymarket's own docs as of 2026-09-13) and Polygon gas (~$0.02/leg). The taker fee dominates: ~$1.75 per 100 shares on a crypto market at 50c versus $0.02 of gas, so rows that looked profitable before fleet #1927 may now show net_positive:false — that is the correction, not a regression. Each leg is priced at ITS OWN market's rate and price (the fee curve peaks at 50c and falls toward both extremes). fee_basis says where the rate came from: 'payload' (read off the market, the normal case), 'category' (mapped from its fee category), 'fee_free', or 'fallback' (rate unknown — charged at the modal 0.05 rather than assumed free, so an unreadable market is never reported as costless). Where fill_check reprices against live depth, this does NOT double-count that spread cost. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.

  • ask_pipeworx_betaremoved

    Beta version of ask_pipeworx: identical universal router (same 7,013 tools, same arguments, same response shape) with candidate routing improvements enabled live whenever one is under test. No candidate is active right now (the last was retired on outcome evidence 2026-07-26), so this currently matches ask_pipeworx exactly. Use it exactly like ask_pipeworx when you want the newest routing; results are compared against the stable router to decide what merges. Falls back to nothing — this IS a full working router, just the experimental edge.

  • china_news_articleremoved

    Look up one indexed China/Hong Kong/Taiwan news article by its URL and return everything known about it: publisher, headline, publication time, GDELT theme tags, average article tone and the places it mentions. Pass a url exactly as china_news_search returned it. There is no article text — GDELT indexes metadata only — and this tool says so explicitly rather than returning an empty body field.

  • pipeworx_trendingremoved

    What other AI agents are calling on Pipeworx right now. Returns the top tools, top packs, and total call volume over a recent window (24h, 7d, or 30d). Useful for: (1) discovering what data sources are hot for current events, (2) confirming a popular tool is the canonical choice before asking your own question, (3) seeing whether your use case aligns with what most agents need. Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.

  • classify_rowremoved

    Cheap categorization: given a company and a list of candidate labels, decide which labels apply — the most common GTM/AI usage shape (tagging a list by industry, ICP fit, etc.), one small model call. Same evidence contract as research_row: each label comes back {label, applies, evidence_url, quote, status: found|inferred|not_established} — "found" only when the model's quote is independently verified as a verbatim substring of the text used. Pass text directly (cheapest — no fetch) or entity.domain to fetch the homepage once as a fallback. No text and no domain means every label is not_established with no model call made.

  • resolution_auditremoved

    Extract the settlement clause of a single Polymarket or Kalshi market: who publishes the settling number (source), the clock time + timezone it is taken at, the precision of the computation (e.g. "1-minute candle close" vs "60-second trailing average" vs "election outcome"), the evidence standard (official_source | consensus_reporting | any_credible_report | unspecified), and void_handling (cancellation/postponement settlement — reused verbatim from bet_research's cancellation_rule detector, not re-derived). Parses Polymarket's `description` field (fetched via polymarket_market) or Kalshi's `rules_primary` + `rules_secondary` fields (fetched via kalshi_market) with regex + a small vocabulary — no LLM pass, so an unusual clause reports confidence:"low" rather than a guess. Pass `market` as a Polymarket slug/URL or a Kalshi market ticker (e.g. "KXBTCD-26SEP1317-T66999.99"); a Kalshi EVENT ticker (e.g. "KXBTCD-26SEP1317") also works — it picks one representative market under that event, since the settlement mechanism is normally shared across all strikes/legs in one event. Use this before treating a polymarket_kalshi_spread row as a real arbitrage: two ladders that look alike can settle on different sources, at different times, with different precision — this tool is how you check. Pair with resolution_diff to compare two markets directly. KNOWN GAP: idiosyncratic phrasing that doesn't match the vocabulary returns confidence:"low" and evidence_standard:"unspecified" rather than an LLM-guessed answer.

  • polymarket_kalshi_spreadremoved

    Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 11 pre-mapped macro subjects ("fed", "btc", "eth", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. You do NOT have to use those exact keys: the topic is resolved through aliases and keywords, so "bitcoin", "fed rate decision", "inflation", "s&p 500" and "next pope" all land on the right subject, and `resolution.topic_matched_by` tells you whether it was an exact key, a known alias, a phrase found inside a longer question, or a single-keyword guess — treat "phrase" and "token" as a GUESS at what you meant. An unresolvable topic returns error:"mapping_failed" with mapping_stage:"topic_unrecognized" and known_topics[]; it never silently falls back to a default subject. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. `resolution` is returned in BOTH modes and says how each side's identifier was picked (which Kalshi series was queried, how many events came back, whether the chosen one had quoted markets; which Polymarket search query ran and why that event won). Fleet #2064: when two Polymarket candidates tie on resolution time `polymarket_selected_by` now SAYS so, names every tied slug, names the tie-break that actually decided it (the candidate whose metric_type matches the Kalshi series, else lexicographic slug order), and states whether the winner's metric matches the Kalshi series — it used to assert "picked the soonest-resolving" byte-identically on calls that returned DIFFERENT events, because the tie was settled by upstream fetch arrival order. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (the two events are about different SUBJECT months — e.g. Kalshi "CPI in October" vs Polymarket "September Inflation"), temporal_alignment_unknown (the subject month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events are about the same SUBJECT calendar period, in EITHER mode — this is the period the question is ABOUT (e.g. "September" for a CPI release that settles in October), not necessarily when either side settles; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. Fleet #2062: this used to compare Polymarket's settlement date against Kalshi's subject month and call a match — fixed to compare subject month to subject month on both sides. FEES: every top_spreads_pp and low_confidence_pairs[] row carries edge_pp_gross (== |sp

  • recent_changesremoved

    "What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since `since`), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). `since` accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 96 / 100

provenance85
liveness100
freshness100
hygiene100

+repository +namespace-matches-repo +website -thin-description +reachable +uptime-99% +updated-25d-ago

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remoteauthreachableuptime 30dp50protocollast ok
https://gateway.pipeworx.io/china-news/mcp streamable-httpnoneyes99%28 ms2025-03-262026-10-20

Tools (0)

No tools observed. Tools appear once a credential-free probe can list them.

Schemas: list_tools.

Similar MCP servers

More from io.github.pipeworx-io

And 1,855 more from this publisher.

Official server.json
{
  "name": "io.github.pipeworx-io/china-news",
  "title": "China News",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://gateway.pipeworx.io/china-news/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "0.1.2",
  "repository": {
    "url": "https://github.com/pipeworx-io/mcp-china-news",
    "source": "github"
  },
  "websiteUrl": "https://pipeworx.io/packs/china-news",
  "description": "China / Hong Kong / Taiwan news search."
}