This server is an MCP tool that lets AI clients fetch, read, and search recent dispatches from 29 tech/AI sources in English, Chinese, and Russian, without storing any history.
wire_latest — Get what selected sources published in the last N hours (or since a timestamp), grouped by source, newest first, with titles and IDs; supports headlines-only or full-body detail.
wire_read — Retrieve the full stored text of specific dispatches by ID, with teasers clearly marked as not the full article.
wire_search — Search archived headlines from all sources that carried a story, with multi-language support (Chinese/Russian indexed in their original language) and configurable time range.
wire_sources — List the available sources, their language/tags, last response time, and current health/failures.
MCP server deployment — Runs as a remote MCP server via uvx cablegram-mcp serve, usable with Claude Code, Claude Desktop, Cursor, and other MCP clients.
Prompt shortcuts — Ships two built-in prompts: /briefing for a dated 24h digest and /verify for checking a claim against the sources only.
No persistence — Each call fetches fresh data, builds an in-memory SQLite index, and discards everything after responding; nothing is stored or uploaded.
Source-aware output — Replies include metadata like CUT (how many dispatches were omitted), COVER (per-source archive depth), and CROSS (how many sources carried the same URL), so models can judge coverage and gaps.
Fetches and stores recent posts from Habr as a news source, making them searchable and retrievable through the cablegram tools.
Aggregates content from multiple RSS feeds as a source type, allowing the server to collect, search, and retrieve recent posts from those feeds.
Fetches and stores messages from public Telegram channels as a news source, supporting search and retrieval of recent dispatches.
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., "@cablegram-mcp What did Chinese and Russian sources say about OpenAI in the last 24 hours?"
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.
An MCP server for Claude Code, Claude Desktop, Cursor and any other MCP
client: uvx cablegram-mcp serve.
Twenty-nine sources on AI and tech — English, Chinese and Russian — written to be read by a model rather than by a person. Nothing is stored: each call fetches what it needs, answers, and discards it.
A model's knowledge ends at its training cutoff, and it has no way to notice that it has ended. It will recommend the tool that was superseded last month and say nothing at all about the release that changes the answer. This server is where it goes to find out what it missed: what those sources published in the last N hours, the text of whichever dispatches it wants to read, and a search across what they are serving right now.
Dispatches arrive raw. They are filtered by date and never ranked, because ranking means deciding what matters with far less context than the model reading them has. A cablegram was the unedited message that came over the submarine cables, before an editor turned it into a story: this server is the cable, and your model is the editor.
The point is the cable, not the news. A launch discussed in Chinese or Russian today reaches English-language coverage days later, filtered through whoever decided it was worth translating — and often it never arrives at all. It runs every way: the Chinese press covers OpenAI and not a Russian Telegram channel; the Russian press covers OpenAI and not 36Kr. No press covers the other two blocs, and each of them is somebody else's other bloc.
Twenty-nine sources in three languages, read directly, put the reader in the same week as all three at once — and the reader here has no home press to be behind, because it is a model. It reads what it is handed, in whatever language it arrives.
Headlines are never translated. Each dispatch carries its language, and the model reading it has more context for that than any translation step would. It also means the same story is kept in every language that carried it: OpenAI titles a post "Pacing model development in an era of cyber-critical capabilities" while a Russian channel titles the same URL "OpenAI stopped RL for two weeks on its latest models". Both are stored against the same id, and either can be searched.
CABLEGRAM v0.2.6 | 2026-09-03T00:43:54Z..2026-09-03T08:43:54Z
CUT cls=2/25 hn=2/241 (newest kept)
COLS id hh:mm title times UTC | body: wire_read(ids=[...])
---
## cls zh early,finance 2/25
-- 2026-09-03
6060520f9036 08:28 外滩大会下周上海开幕：首次聚焦AI新经济，观众报名人数已突破5万
f5fd40b8040a 08:02 财联社9月3日电，AI服务器制造商慧与科技（HPE）尽管财报强劲且业绩指引上调，但美股盘前跌近6%。该股今年已累涨近120%。
## data_secrets ru telegram 2/2
-- 2026-09-03
a616ad4d8e77 08:02 Продолжаем следить за главными конференциями по машинному обучению. 19 сентября команда Data Secrets поедет на Practical ML Conf, чтобы посмотреть всё вживую и рассказать вам о самом интересном. Что точно идем смотреть:
e2bf7cf25acf 06:13 Правительство США встало на сторону OpenAI в суде по иску об авторских правах NYT против OpenA
## hn en community 2/241
-- 2026-09-03
be0d90661a35 08:43 The Filesystem Explained [video] (youtube.com)
fcba7e8174fd 08:43 Ask HN: How much does licensing approach influence purchase decisions? (news.ycombinator.com)Eight hours of three sources at limit_per_source=2, verbatim, and
466 tokens. Three passes took 2.3s, 2.3s and 3.3s. Every line above
the rule is something the reader cannot work out for itself, and this
morning there was only one: CUT, saying cls held 25 dispatches in those
eight hours and hn 241, two of each printed. No SILENT, because all three
published; no CEILING, because none of them served less than the window
asked for. There is no tally, because every source asked for is either a
block or a name above.
What it costs. A reply is priced by what the sources published, not by this code, so these are ranges from repeated measurement rather than figures:
24h, everything, defaults 3,200-5,900 tokens
6h, everything, defaults 1,000-3,400
6h, three busy sources 1,000-1,400
6h, three, limit_per_source=2 ~300The whole-catalogue numbers move with the calendar, not the code: the low ends
are a Saturday night with eighteen of twenty-nine feeds silent, the high ends a
weekday.
The narrow ones move by half again within an hour: two measurements of the same
call, sixty minutes apart, gave 3,324 and 2,515 with no change to the code —
Chinese wire services publish in bursts. Treat a narrow selection as costing
whatever it costs and read CUT, which says what was left out and how much
there was.
v0.2.6 — the sources work; the tool API may still move. All twenty-nine have an adapter and were verified against the live endpoints: eleven RSS feeds, Hacker News through its search index, a signed Chinese financial API, six public Telegram channels, the Hugging Face model hub plus six labs read from their own namespaces on it, and three sections of a lab that publishes no feed, read out of the data its own pages ship. 527 tests, on 3.12, 3.13 and 3.14.
Three sources are worth knowing about before you rely on them:
cls.cn is reverse-engineered. An undocumented internal API with a signed
request. It holds 3.34 days at most and cannot page backwards, so a gap is
permanent. wire_sources marks it fragile.
Anthropic has no feed at all. Its three sections are read out of the data
its own pages ship inline, which is an internal Next.js format with no
contract. Also marked fragile. A shape change comes back as a broken
source, never as a quiet week.
Telegram is HTML with no contract. The public preview view can change without a version number to notice it by.
All three are declared in the output rather than explained afterwards.
Related MCP server: NewsAgent Data MCP server
Requires Python 3.12+. Nothing to clone:
uvx cablegram-mcp sources # what it knows about
claude mcp add cablegram --scope user -- uvx cablegram-mcp serveOr from a checkout, if you would rather read it first:
git clone https://github.com/levongabrielyan/cablegram-mcp
cd cablegram-mcp && uv sync
claude mcp add cablegram --scope user -- \
/path/to/cablegram-mcp/.venv/bin/python -m cablegram.cli serveThat is the whole setup. Each call fetches what it needs and keeps nothing.
Claude Desktop, Cursor, Codex and anything else that reads an mcpServers
block:
{ "mcpServers": { "cablegram": { "command": "uvx", "args": ["cablegram-mcp", "serve"] } } }serve is the subcommand. Without it the command prints its usage and exits,
which a client reports as a server that would not start.
The server also ships two prompts, which Claude Code lists as slash commands and any client with prompt support can call. They are the two calls a model should make unasked — and, measured over a week, never did — written down so a person can make them in one line:
/mcp__cablegram__briefing 24 lab,early what changed in 24h across those sources,
dated, with a line on what was not covered
/mcp__cablegram__verify "n8n is dead" a claim checked against the sources, and
only the sourcesEach names the tool to call, the lines to read before the blocks, and how to say what the sources did not reach.
Tool | Question |
| What did the sources publish in the last N hours? |
| Give me the text of these ids |
| Who is carrying this term right now, and since when |
| What exists, and what is currently broken? |
All four are read-only and return plain text. The same information as JSON with indent costs roughly six times the tokens and truncates.
Fetching is per source, and what it costs is Telegram: those six channels
go one at a time, three seconds apart, because t.me drops the sixth request in
a row. Everything else is fetched in parallel, so the nineteen English sources
together cost what two do — under two seconds. Bring the channels in and it is
twenty to forty-five, which is also what sources=["ru"] costs, since six of
the seven Russian sources are channels. Language is not the axis; channel count
is. The tool description carries the same table, so a model can ask before
spending it.
There is no database file, no cache directory and no state between calls. Each tool call builds a SQLite database in memory, fills it with one pass over the sources you asked for, answers from it, and throws it away when the reply is sent. SQLite is there for what it does inside that one call — the trigram index that makes a Chinese query work at all, and the join that names every source which carried the same URL — not to keep anything.
This has a cost and it is worth stating: wire_search cannot reach past what
the feeds are serving today, and the floor is lower than it sounds. Measured
as the oldest item each feed actually served — the same quantity wire_search
prints on its COVER line, one floor per source:
openai 2015 the whole back catalogue, in one fetch
huggingface 2020
anthropic 2021 news and research; engineering, 2024
hub 2022
deepseek 2024-12 the six Chinese labs are read from their own
minimax 2025-01 namespaces: the newest fifty repos of each,
moonshot 2025-02 which reaches back as far as the lab is slow
zhipu 2025-04
mcp 2025-07
deepmind 2025-10
qwen 7 months
tencent 5 months
testingcatalog 2 months
llm_under_hood 6 weeks Telegram is one page of posts per channel,
techsparks 1 month so each floor is how often that channel posts
n8n 3 weeks
ai_newz 11 days
cls.cn 1-3 days at its ceiling, and it cannot page backwards, so
anything older is gone from everywhere
data_secrets 3 days
denissexy 3 days
seeallochnaya 3 days
alternativeto 2 days
36Kr 2 days
qbitai 2 days
Habr 2 days
Hacker News 1 day a thousand stories is the cap, so days=7 and
days=30 return the same rows
producthunt today the day's front page, fifty posts dated the day
they were featured; the feed has no yesterdayTwo COVER lines, measured 2026-09-06, all twenty-nine sources. Eleven reach back a year or more, four of them the Chinese labs; the wires, the channels, Habr and Hacker News reach back days; and no parameter asks for more than the endpoint volunteers. That floor is a property of the feeds and never of the subject.
Every reply carries its own rather than leaving it to be discovered: the COVER line names the floor per source, which is what this table is made of. One number for the whole call would be the deepest feed in it — and that feed may have matched nothing, so a search that reached back one day would report eleven years of coverage behind a miss.
cablegram check fetches every source once and prints what each one said, for
deciding whether the catalogue still works. It stores nothing either.
Nothing is uploaded anywhere and no database ships with this repository: the
server fetches on your behalf and keeps no copy. The only third-party bytes
here are the small captured fixtures under tests/samples/, kept so the
parsers can be tested offline.
Separate from what this deliberately never does — the design notes list that — these are things it would reasonably do and does not:
No history. Every call starts from nothing, so the same question asked twice costs two fetches, and a question about last month cannot be answered from here at all. That is the trade for leaving no file on your disk.
Sources are fixed in code. Adding one means editing sources.py, and an
adapter too if it is not RSS. That is the design rather than an oversight, but
it does mean a fork rather than a config file.
Coverage is uneven and not controllable. A feed either serves its back catalogue or it does not; there is no way to ask for more history than the endpoint volunteers, and one source reaching 2015 says nothing about the next.
Nothing checks a source's terms for you. The endpoints are public and the requests are bounded and rate-limited, but the responsibility is yours.
Every reply this server sends is a claim about the world that nobody checks — the reader is a model, and a model cannot tell a quiet day from a broken fetch. So the work is mostly finding the places where it says something it does not know, and the commit history is the record of that. A few of them, verbatim:
Refuse a window that ends before it starts
Stop the ENGINE line claiming an index ran over nothing
Report no floor for a call that consulted no feed
Declare the source ceiling where the window is stated, not only in the catalogue
Date the window fixtures relative to now, so the suite stops expiring
Serve one hit per story, not the post and the link it carriedEach one names the measurement that found it. since=2027-01-01 produced a
window ending before it began and a line underneath reading SILENT hn (answered, published nothing in this window). hours=10000000 wrote the year
885 without its leading zero, and because those timestamps are compared as
strings it excluded all 982 items and reported the same affirmative silence.
Seven tests went green to red overnight with no code change, and CI stayed green
only because it runs on push and nobody had pushed.
git log --format='%s%n%n%b'docs/design.md
is the reasoning rather than the API: why the identity of an item is a pure
function of its URL and what breaks in each direction when that is wrong, why a
failure is a value rather than an exception, why the full-text index needs a
trigram tokenizer for Chinese to work at all, why third-party input is treated
as hostile, and what this server deliberately does not do. It carries a
Marking / Without it table for every mark a reply can print — what each one
says, and what a reader would conclude if it were absent.
Only public endpoints are used: no credentials, no authentication bypass, no scraping behind a login. Keeping nothing means every call is a full download, which is heavier on somebody else's server than a poller with a cache behind it — that is the price of not keeping a copy of their site, and it is why the tool descriptions teach a model to ask before spending a full sweep. Intended for personal research — respect each source's terms of service.
MIT. Built by Levon Gabrielyan.
What 19 tech/AI sources published in a time window, grouped by source, newest first within each. English, Chinese and Russian, untranslated. Filtered by DATE ONLY — never ranked, never scored. The order says nothing about importance. A source listed as DOWN means UNKNOWN, not 'nothing happened there'. A declared CUT (hn=25/57) means more exist in the window; raise limit_per_source or narrow the window. CROSS counts how many sources carried the same URL. It is arithmetic, not a ranking — but a story in six feeds across three languages within hours is the earliest signal this server can give you. detail='headlines' (the default) returns titles and ids; pass those ids to wire_read for the text. detail='full' includes each stored body inline and drops to 5 per source, because bodies are expensive — a teaser is marked as one, and is NOT the article.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| since | No | ||
| detail | No | headlines | |
| sources | No | ||
| max_tokens | No | ||
| limit_per_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it explains DOWN means unknown rather than no activity, CUT indicates truncation, CROSS is arithmetic and not a ranking, ordering is not importance, and teasers are marked and are not the article. This is exactly the behavioral nuance an agent needs.
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 dense but every sentence earns its place, with the core purpose front-loaded and caveats organized into digestible paragraphs. It avoids filler while covering crucial edge-case meaning.
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 an optional-parameter read tool with an output schema, it covers the domain caveats, the headline/full modes, language coverage, and how to proceed to wire_read. An agent can call it safely with defaults or with an informed detail/limit_per_source choice.
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 0%, so the description carries the burden. It explains detail values and the effect of raising limit_per_source, but it leaves hours, since, sources, and max_tokens to their schema properties with no added semantics beyond 'time window'.
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 opening states precisely what the tool returns: recent dispatches from 19 tech/AI sources in a time window, grouped by source and ordered newest-first within each. It also distinguishes itself by language scope and by positioning wire_read as the follow-up for article text.
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?
It gives clear usage context: this is a date-only, unranked view and the CROSS metric is an early-signal indicator, not a ranking. It names wire_read for the next step, though it does not explicitly contrast with wire_search or state when to choose wire_latest over it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The stored text of specific dispatches, by the ids wire_latest or wire_search returned. Read body=teaser literally: that feed ships a truncated excerpt, and the text you get is NOT the article. Do not draw conclusions from it — open the url or say the full text was not available. Ids not in the archive are named in the reply rather than dropped: re-run wire_latest or wire_search for the same window to get current ones.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses two important behaviors: body=teaser is truncated and must not be used for conclusions, and missing IDs are named in the reply rather than silently dropped. No contradiction with 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?
Three sentences with no filler: first states the purpose, second delivers a critical caveat, third explains missing-ID behavior. Each sentence adds essential information and the most important usage guidance is 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?
Given a simple one-parameter signature, an existing output schema, and annotations covering read-only behavior, the description covers all remaining ambiguity: how IDs are obtained, the teaser truncation trap, and recovery steps for stale IDs. Nothing important is missing.
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 0%, so the description carries the full burden for the 'ids' parameter. It explains that IDs come from wire_latest or wire_search and describes what happens when IDs are not in the archive, giving the agent enough context to supply valid values.
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 states it retrieves stored text of specific dispatches by IDs returned from wire_latest or wire_search, which clearly identifies the operation and distinguishes it from the sibling list/search tools. The title 'Read dispatches' reinforces the verb and resource.
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?
It explicitly instructs the agent to supply IDs returned by wire_latest or wire_search, and advises re-running those tools if IDs are stale or missing. It also warns not to treat teaser text as the full article, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the archived headlines of every source that carried a story. IMPORTANT: this searches only what this server has archived since it was first run — not the whole internet and not the sources' own history. '0 hits' means 'not in what we can search'. It does NOT mean nobody is talking about it, and must never be reported as such. Chinese and Russian sources are indexed in their own language: a company is 智谱 here and Zhipu on Hacker News. If a query comes back empty, retry it transliterated or translated before concluding anything.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| query | Yes | ||
| sources | No | ||
| max_tokens | No | ||
| limit_per_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It goes beyond the readOnly/openWorld annotations by explaining that only the server's archive is searched, that '0 hits' does not mean absence in the world, and that Chinese/Russian content is indexed in its original language. It also tells the agent to retry transliterated or translated queries before concluding anything.
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 compact, front-loaded with the core purpose, and uses a clear IMPORTANT warning for the most critical limitation. Every sentence adds necessary operational context without 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?
It fully covers the search scope and result interpretation, and the output schema covers return shape, but it omits parameter semantics and does not route the agent among sibling tools. For a 5-parameter search tool, this leaves some practical 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 0%, so the description must compensate, but it only implies the meaning of 'query' through phrases like 'If a query comes back empty.' It never explains days, sources, max_tokens, or limit_per_source, leaving the agent to guess their behaviors and interactions.
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 opening sentence names a specific operation and resource: searching archived headlines across every source that carried a story. It clearly distinguishes archive search from a live feed, though it never names sibling tools explicitly.
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 no when-to-use versus alternative guidance; it does not mention wire_latest, wire_read, or wire_sources or state which tool to choose for current headlines or reading articles. The retry/transliteration advice is about query formulation, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The catalogue and its health: which sources exist, their language and tags, when each last answered, and which are failing. Read this before concluding a topic is quiet. A source that has never been polled holds nothing, which is a different fact from a source that holds nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and open-world. The description adds valuable interpretive context: absence of data may mean a source was never polled, not that it is empty, and it surfaces failing sources. This goes beyond what the annotations alone convey.
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 filler. The first sentence front-loads the catalogue and health facts; the second adds a concise, important usage caution. 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 zero-parameter read-only tool with an output schema and open-world annotation, the description fully covers why an agent would invoke it and how to interpret one of its key signals. Nothing essential is missing.
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, so the baseline for this dimension is 4. There is no parameter ambiguity for the description to resolve, and no additional parameter meaning is 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?
Describes the resource ('the catalogue and its health') and the specific facts it exposes: which sources exist, language, tags, last-answered time, and failing status. It is distinguishable from content-focused siblings like wire_read or wire_search, though it lacks an explicit action verb such as 'list' or 'retrieve'.
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?
Gives an explicit use case: 'Read this before concluding a topic is quiet.' It also warns about the distinct meaning of a never-polled source versus one with no content. It does not name alternatives or state when not to use the tool, but the context is clear.
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.1wire_latestwire_readwire_searchwire_sourcesScored across 4 tools
Each tool has a clearly distinct role: browsing by time window, searching archived headlines, reading stored dispatches, and checking source health. The overlap between wire_latest and wire_search is resolved by their descriptions (chronological feed vs archive query).
All names share the wire_ prefix and use lowercase snake_case, so the set feels predictable and cohesive. The second element is not consistently a verb or noun (latest, read, search, sources), but the pattern is still clear enough to be navigated without confusion.
Four tools is well-scoped for a read-only news/archive monitoring server. Each tool earns its place and there is no bloat.
The server covers its apparent workflow completely: discover via latest or search, retrieve via read, and assess archive coverage/health via sources. The descriptions also explicitly address edge cases like teasers and unindexed queries, leaving no dead ends in normal use.
The only News based AI MCP your agents will ever need — custom categories, global regions, and time-scoped results in one tool. We use multi-vector & sparse-hybrid search to search through thousands of articles across the world to find the exact news you're looking for.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
Search and monitor source-backed AI agent ecosystem signals, briefings, deltas, and source health.
Live X/Twitter and Reddit research. 10 read-only MCP tools, Google/GitHub sign-in. Free tier.
