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., "@CTC Monitor MCP What's the top tech news in China today?"
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.
Global tech intelligence for any AI agent that speaks MCP. Point Claude, Cursor, Windsurf, Zed, or any other MCP-aware tool at this server and ask what the world's tech press is reporting right now, in any region you care about.
Most AI assistants see the internet through a narrow US-tech-Twitter lens. CTC Monitor pulls stories from 500+ sources across China, South-East Asia, India, MENA, Africa, Latin America, Europe, Korea, Taiwan, Japan, and the Pacific, scores them for velocity and geographic novelty, caps western-source dominance, and translates non-English headlines. Your agent gets a genuinely global view of what's moving in tech.
Seven tools, plain JSON-RPC over stdio. Ask your agent things like:
"What's breaking in cloud and AI across Asia today?"
"Summarise the last 24 hours from China, Korea, and Taiwan."
"Search everything we've indexed for 'post-quantum cryptography'."
"Which countries have the most stories right now, and what's the top headline in each?"
"Give me the propagation picture for cluster 4812."
Tool | Does what |
| Top-scored stories, optionally filtered by region or category. Western sources capped so you don't get a US-only feed. |
| Full-text search across every indexed story, including translated titles. |
| Seven-day rolling overview: story counts, regions, categories, top sources, highest scorers. |
| Geographic distribution: which countries are hot, story counts, top headline per country. |
| Detailed view of a story cluster — related items, blast radius, velocity, propagation tag. |
| Lists every region key and category the feed supports. |
| Pass an array of regions, get a summarised digest per region in one call. |
Stories carry their original source, translated title where applicable, region, country, category, a relevance score, a cluster ID, a velocity score, and a propagation tag for how the story is spreading.
Related MCP server: AgentDB
npm install -g ctc-monitor-mcpOr run without installing:
npx ctc-monitor-mcpThe feed is free. You need a key so we can rate-limit fairly and so the digest emails know where to go.
Sign in with a work email. A verification link lands in your inbox.
Click it. Your API key is auto-generated and emailed to you. Save it somewhere safe; it isn't shown again in plain text.
Work emails only. Personal inboxes (gmail, outlook, yahoo and the like) are blocked at registration.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on your OS:
{
"mcpServers": {
"ctc-monitor": {
"command": "npx",
"args": ["ctc-monitor-mcp"],
"env": {
"CTC_MONITOR_API_KEY": "nk_your_key_here"
}
}
}
}Restart Claude Desktop. The tools appear in the tool menu.
In the MCP settings panel, add a server entry with:
Command: npx
Arguments: ctc-monitor-mcp
Environment: CTC_MONITOR_API_KEY=nk_your_key_here
If your client takes an MCP stdio command, run:
CTC_MONITOR_API_KEY=nk_your_key_here npx ctc-monitor-mcp100 requests per minute per key. Plenty for interactive use; if you're building something higher-volume, get in touch via the site and we'll talk.
A typical get_stories call comes back grouped by region, with featured CTC/Disruptive Live content at the top, then region sections ordered so you see non-western markets before western coverage:
## CTC Monitor — Top Stories
### Europe (8)
- Alibaba Cloud expands Frankfurt region with AI-specific zones (0.87)
South China Morning Post · Europe · 2h ago · 4 related
https://...
### China (5)
- ...
### South-East Asia (4)
- ...
### Western (3) ← capped to prevent US dominance
- ...Clusters group related stories so a single headline doesn't drown out the rest of the news. Velocity scores and propagation tags surface stories that are spreading fast across languages and regions.
CTC Monitor ingests from ~500 global tech sources including state-backed outlets, regional trade press, specialist analyst sites, and official feeds from every major cloud, chip, and AI vendor. Stories are de-duplicated, clustered across languages, scored for relevance and geographic novelty, and translated where needed. The dataset refreshes continuously.
Compare the Cloud has run enterprise tech coverage since 2013 and Disruptive Live produces the video layer. The Monitor is our editorial feed, exposed as an MCP so your agent can read the same intelligence our analysts do.
Set your region preferences at https://www.comparethecloud.net/monitor/preferences and we'll send a daily or weekly digest matching your picks. Unsubscribe from any email.
Issues and feature requests: https://github.com/comparethecloud/nolan/issues
Help and integration questions: https://www.comparethecloud.net/monitor/help
Press and partnership enquiries: the press page on comparethecloud.net
MIT.
Get details of a story cluster — related stories grouped by topic, with blast radius and propagation data.
| Name | Required | Description | Default |
|---|---|---|---|
| clusterId | Yes | Cluster ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returned data but does not disclose read-only nature, side effects, or other behavioral traits beyond the data content.
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 efficiently conveys purpose and what data is included. No unnecessary words.
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?
Simple tool with one parameter and no output schema. Description provides high-level return content (related stories, blast radius, propagation), which is sufficient for an agent to understand what to expect.
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 has one parameter (clusterId) with description 'Cluster ID' (100% coverage). Description does not add additional meaning beyond schema, so 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 details of a story cluster, specifying it includes related stories, blast radius, and propagation data. This distinguishes it from siblings like get_stories (individual stories) and search_stories (search).
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 explicit guidance on when to use versus alternatives. The description implies usage for cluster details, but lacks when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a regional digest — top stories summarised per region. Provide the regions you want coverage for.
| Name | Required | Description | Default |
|---|---|---|---|
| regions | Yes | Array of region keys (e.g. ["europe", "china", "sea"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states a read-like action without detailing safety, rate limits, or required authentication. The description lacks sufficient transparency for a tool with no annotations.
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 that are direct and to the point with no unnecessary information. Every sentence adds value.
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 tool (one parameter, no output schema), the description covers the basic operation and input. However, it could mention the format of the digest or constraints like maximum regions, and it does not differentiate from siblings, leaving some gap for an 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?
Schema coverage is 100% with a clear description for the 'regions' parameter. The description adds 'Provide the regions you want coverage for' which largely repeats the schema. It provides context on what the digest contains but does not enhance parameter semantics beyond 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?
Description clearly states 'Get a regional digest' with verb and resource, and specifies 'top stories summarised per region'. This distinguishes it from siblings like get_stories and search_stories which focus on individual stories.
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?
Description instructs to 'Provide the regions you want coverage for', giving clear usage context. However, it does not explicitly indicate when to use this tool versus alternative siblings like get_stories or search_stories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get geographic story distribution — which countries have active tech stories, how many, and what the top headline is per country.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by region key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that the tool returns countries with stories, counts, and top headlines. However, it does not clarify behavior regarding the optional 'region' filter (e.g., whether it filters or selects) or mention any limitations like pagination.
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, dense sentence that efficiently conveys purpose and output content. Every phrase is meaningful and front-loaded, with no wasted words.
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 tool (one optional parameter, no output schema, no annotations), the description provides adequate context for an agent to understand the output. Minor gap: no explanation of the 'region' parameter's effect on results, which is partly covered by the schema.
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% for the single parameter 'region'. The description adds no extra meaning beyond the schema's 'Filter by region key' line. Baseline of 3 is appropriate as the description does not enhance parameter understanding.
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's purpose: retrieving geographic story distribution, including which countries have active tech stories, counts per country, and top headlines. This verb+resource is specific and distinguishes from siblings like get_stories (individual stories) and get_stats (aggregate statistics).
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 does not explicitly specify when to use this tool versus alternatives like get_stats or get_regions. Usage context is implied by the name and output description, but no direct guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the current user's newsletter digest preferences — which regions they subscribe to and frequency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly indicates read-only behavior via 'View'. Mentions 'current user' implying authentication. Lacks details on rate limits or error states, but sufficient for simple tool.
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 concise sentence with all essential information. No redundancy or unnecessary words.
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?
Adequately describes inputs (none) and outputs (regions, frequency). No output schema, so description fills gap. Could mention example values or scope, but completeness is 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?
No parameters exist. Baseline score 4 for zero-param tools. Description adds no parameter information, but none needed.
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?
Clearly states verb 'View', resource 'newsletter digest preferences', and specifics 'regions' and 'frequency'. Differentiates from siblings like get_digest (content) and get_regions (list only).
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?
Implied usage when checking preferences, but no explicit when-to-use, when-not-to-use, or alternative tool guidance. Simple tool limits need, but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available regions and categories in CTC Monitor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds little beyond the action and resource; it does not disclose any behavioral traits such as safety, authentication needs, or side effects.
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 single sentence with no extraneous information, front-loaded with the key action and resource.
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 absence of annotations and output schema, the description is minimal but sufficient for a simple list operation; however, it could include whether the data is static or requires authentication.
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?
With zero parameters, the description cannot add parameter meaning beyond the schema; baseline 4 applies as per rules.
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 specifies the verb 'list' and the resource 'regions and categories', clearly distinguishing it from sibling tools that focus on stories, stats, map, etc.
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 over alternatives or any context for its use; it simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a 7-day rolling intelligence overview from CTC Monitor — story counts, region/category/country breakdowns, trending categories, top sources, and highest-scoring stories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool retrieves a 7-day rolling overview, implying a non-destructive, read-only operation. However, it does not disclose any behavioral traits such as rate limits, caching behavior, or whether data is real-time or computed. The description is adequate but lacks depth.
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, highly informative, front-loaded with the core purpose. Every word earns its place. No unnecessary repetition.
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 exists, so the description should clarify return format. It lists what the overview includes (counts, breakdowns, etc.) but does not describe the structure (e.g., is it a JSON object with keys like 'story_counts'?). Adequate but not fully complete given the complexity of the output.
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 tool has zero parameters and the input schema is empty. Per guidelines, the baseline is 4 even with no param info in description. Description correctly does not add parameter details since 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 clearly states the tool returns a 7-day rolling intelligence overview with specific breakdowns (story counts, region/category/country breakdowns, trending categories, top sources, highest-scoring stories). This is a specific verb+resource combination that distinguishes it from siblings like get_stories or get_map.
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 implicitly suggests using this tool for aggregated intelligence summaries, but does not explicitly state when to use it versus alternative tools. For example, no mention of when to prefer get_stats over get_digest or get_map. Usage context is implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top scored tech stories from CTC Monitor with global diversity. Stories are scored by relevance, geographic novelty, and velocity. Results are grouped by region with Western sources capped to prevent US dominance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of stories (default 20, max 100) | |
| region | No | Filter by region key (e.g. europe, china, sea, western) | |
| category | No | Filter by category (e.g. ai, cloud, security, startups) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains scoring criteria, regional grouping, and the Western source cap. This gives the agent insight into result sorting and diversity, though it omits details like rate limits or pagination.
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?
Three sentences front-load the core purpose, then add scoring and grouping details. Every sentence is informative with no wasted words.
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 three optional parameters, no output schema, and 100% schema coverage, the description sufficiently explains the tool's key behavior—scoring, grouping, and diversity—making it complete for a filtered list retrieval tool.
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 baseline is 3. The description adds indirect context by explaining how results are scored and grouped, but does not elaborate on the parameters' semantics beyond what the schema already 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?
Description clearly states it gets top scored tech stories with global diversity. It highlights key differentiators: scoring by relevance, novelty, and velocity; grouping by region; and a Western source cap. This sets it apart from siblings like search_stories and get_regions.
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?
Description implies usage for retrieving top scored stories, but lacks explicit guidance on when to use this tool versus alternatives like search_stories or get_digest. No exclusions or context for when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all CTC Monitor stories. Searches titles in all languages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (default 10, max 50) | |
| query | Yes | Search query (minimum 2 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry behavioral transparency. It discloses that the search is full-text, across all stories, and limited to titles in all languages. However, it does not mention pagination, ordering, or what fields are returned.
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 extremely concise with two sentences, no filler words. Every sentence adds value.
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 2 parameters, no output schema, and no annotations, the description is adequate but not comprehensive. It covers the search scope (titles, all languages) but omits details like result format or pagination. Sibling tools are not contextualized.
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% (both query and limit have descriptions). The description adds no extra semantic meaning beyond the schema; it does not elaborate on query syntax or behavior.
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 uses the verb 'search' and specifies the resource 'CTC Monitor stories', indicating a full-text search. It mentions searching titles in all languages, which differentiates it from sibling tools like get_stories (likely ID-based retrieval). However, it does not explicitly compare itself to siblings.
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 search_stories versus other tools like get_stories or get_cluster. The description does not provide context for proper usage or alternatives.
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. Dates show when Glama detected each change.
v1.0.4get_clusterget_digestget_mapget_preferencesget_regionsget_statsget_storiessearch_storiesScored across 8 tools
Each tool has a clearly distinct purpose: get_stories returns top scored stories, search_stories performs full-text search, get_stats gives an overview, get_map shows geographic distribution, get_cluster provides cluster details, get_regions lists available options, get_digest delivers regional summaries, and get_preferences shows user settings. No overlapping functionality.
Seven tools follow the pattern get_<noun> or get_<noun>_<noun> using snake_case. The outlier is search_stories, which uses a different verb. This is a minor inconsistency but still predictable.
With 8 tools, the set feels well-scoped for a tech monitoring service. Each tool serves a specific purpose without redundancy, and the count is neither too few nor too many for the apparent domain.
The tool surface covers major functions: browsing, searching, stats, geographic view, clusters, regions, digest, and preferences. However, missing tools like get_story (by ID) and update_preferences leave minor gaps for a fully self-contained experience.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free cross-lingual news briefings for AI agents across 89 languages. Read-only, hosted.
Agent-first tech news: ranked story clusters, coverage and discussion links, trends, and events.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
News for agents: 100k+ articles/day deduplicated into situations with timelines. Free, no key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielctc/ctc-monitor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
