This server provides AI assistants access to real-time and historical internet conversation trends ('Bubbles') to identify, analyze, compare, and create content from emerging topics gaining momentum. You can:
Discover high-priority Bubbles with get_bubbles – retrieve trending conversations filtered by category, timeframe (6h, 24h, 7d), and minimum score, returning up to 20 results.
Search for specific topics with search_bubbles – find Bubbles by keyword, company, product, or industry, with optional platform and timeframe filters (up to 30 days).
Get detailed insights with get_bubble_details – see why a Bubble is growing, including its timeline, pain points, opportunities, and verified sources.
Compare opportunities with compare_bubbles – rank 2–5 Bubbles against a goal (content, product idea, launch, distribution) and get a recommendation.
Generate content drafts with generate_content – create evidence-based drafts in multiple formats (X/Twitter, LinkedIn, Reddit, newsletter, Product Hunt comment) with customizable tone and goal, without auto-publishing.
Access workspace context via the resource bubble://workspace/profile for personalized results based on company and audience data.
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., "@bubble-agent-mcp What are today's strongest AI infrastructure Bubbles?"
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.
Read what people are actually posting — in a browser that is never signed in.
An MCP server that opens a browser on your own machine, reads the public posts a signed-out visitor is shown on X, LinkedIn and Hacker News, and hands them back as structured data your agent can reason about.
Install · Tools · What signed-out access buys you · Blocks · Security
Ask your agent "what have @naval and @paulg been posting about onboarding this week?" and it opens a real browser window, reads those two timelines, and answers with the posts, their engagement counts and their links.
Everything happens locally. There is no API key, no account, no cloud service and no data leaving your machine except the page requests themselves.
It never signs in. Session cookies are deleted from its browser profile before every run. It reads exactly what a logged-out visitor is shown — nothing behind a login, nothing behind a challenge. It does not solve CAPTCHAs, does not disguise that it is automated, and does not retry a refusal.
That constraint is the point, and it shapes what the tool can and cannot do. The sections below are honest about both.
Related MCP server: contextium-mcp-server
claude mcp add subio-scrape -- npx -y github:alijancb/subio-mcpThen ask, in plain language:
собери, что @naval и @paulg писали за неделю про онбординг
Using a different agent — Codex, Cursor, Windsurf, Cline, Zed, VS Code? See INSTALL.md, which has a one-page guide per client that your agent can follow for you.
For Claude Code there is also a plugin, which adds a /scrape command and a
workflow skill on top of the tools:
git clone https://github.com/alijancb/subio-mcp.git ~/subio-mcp && cd ~/subio-mcp && npm installclaude plugin marketplace add ~/subio-mcp && claude plugin install subio-scrape@subioNode.js 20 or newer.
A browser. It uses Chrome or Edge if you have one. If not, run
npx playwright install chromium once.
A desktop session. The window has to be visible — see below for why. This does not run on a headless server.
Tool | What it reads |
| Posts from named X accounts, with exact view / like / repost / reply counts. |
| Bio, followers, post count for one account |
| A public company or person page, from its JSON-LD |
| A company's posts, when LinkedIn serves them signed out |
| Hacker News stories and comments on a topic |
| Which browser will be driven, from where, how fast, and what happens on a block |
| Close the window early |
Every tool returns the same item shape, so results from four sources merge into one report:
{
"source": "x",
"externalId": "1960...",
"url": "https://x.com/naval/status/1960...",
"author": "naval",
"text": "…",
"publishedAt": "2026-08-27T02:22:11.000Z",
"engagement": { "views": 8499257, "likes": 14021, "replies": 689, "reposts": 1367 },
"via": "@naval"
}Collector tools answer with { items, notes, partial }, and notes is not
decoration. A source that was blocked, walled or misspelled returns zero items
— and so does a genuinely quiet week. Without the notes, an agent reports the
second for both:
notes: [
"@naval: 2 items",
"@paulg: 2 items",
"@definitely-not-real: FAILED — not-found: X sent @definitely-not-real to its
signup page instead of a profile. Either the handle does not exist, or X
declined to serve it signed out."
]
partial: trueWorth reading before you plan anything around this.
X serves account timelines to a signed-out browser, and serves search to
nobody. x.com/search, hashtags and explore all redirect to a login wall.
There is deliberately no search tool here, because there is no signed-out
search. A topic on X is answered by reading the accounts that discuss it and
filtering with match.
X answers a headless browser with a bare 403 and an empty document. The
window is visible by default for that reason, and not as a preference.
SUBIO_MCP_HEADLESS=1 exists and mostly does not work.
A missing X handle is not a 404. X answers 200 and redirects into its signup flow, which reads exactly like an empty timeline. The final URL is what gives it away, and is checked.
LinkedIn gives the least and takes it away fastest. A public company or
person page renders, usually with JSON-LD on it. After a handful of pages from
one client it becomes a sign-in wall — served with a 200 status and carrying an
og:title of its own, so a wall parses as a page named "Sign Up | LinkedIn"
unless you check for the JSON-LD. Expect to be walled within a session.
Hacker News has a real public API and is the one source with no ceiling.
Reddit was removed rather than worked around. It closed /*.json to
clients without a session, and its public RSS feed carries neither score nor
comment count, so what remained could not be ranked against anything else.
Nothing here retries a refusal. A 403, a 429, a challenge or a sign-in wall is the site answering, and asking again is how being throttled becomes being banned. The first block also ends the whole run: the accounts that were not read are listed in the notes, with an instruction not to retry them now.
If you are getting blocked, what helps, in order:
Read fewer accounts per run. This is the whole answer most of the time.
Widen the gap — SUBIO_MCP_MIN_INTERVAL_MS=10000. Reads are already
jittered by ±25% so they do not arrive on a metronome.
Wait. A signed-out quota refills on its own, and nothing you change locally makes it refill faster.
What does not help is a fresh browser per account. Blocks are counted against
your IP address, and a new browser profile does not change your address — a
hundred brand-new fingerprints from one address is a stronger bot signal than one
returning visitor. SUBIO_MCP_ISOLATE=1 exists if you want to try anyway: it
opens a throwaway browser on a throwaway profile per account and deletes it
afterwards. It costs a browser launch per account, and it resets the
cookie-scoped guest quota — which is working around a limit rather than
respecting one, and is the opposite of every other decision here. Off by default.
A scan does not open a browser per account. The server keeps a single browser with a single tab and drives every account, company and page through it, one load at a time — lighter on your machine than a tab per source, and less conspicuous to the sites being read.
The window closes itself five minutes after the last read, and immediately if the client goes away, so nothing is ever left running with nobody driving it.
Everything has a working default. Set these only if you need to.
Variable | Default | |
|
| Browser profile, kept apart from your own Chrome |
|
| Read cache |
|
| How long a read counts as fresh |
|
| Minimum gap between two loads of one host |
|
| Close the window after this long idle. |
| unset |
|
| unset | Force |
| unset |
|
Session cookies (auth_token, ct0, li_at, …) are deleted from the profile
before every run, so the promise on the tin holds even if you once opened that
profile by hand and signed in.
npm installnpm run check && npm run build && node scripts/probe.mjsscripts/probe.mjs starts the built server over stdio the way a client does and
exercises the tools that need no browser. It catches a broken build, a bad tool
schema, or anything accidentally written to stdout — all of which look like a
silent hang from inside an agent. scripts/live.mjs is the manual counterpart
that reads the real sites; it is not in CI, because CI should not scrape.
Where things live:
Path | |
| The tool surface |
| One window, pacing, signing out, idle close |
| One module per source |
| Everything known about X's markup — the only file to edit when X changes |
| The same for LinkedIn, parsed as HTML in node |
| The Claude Code plugin's workflow |
The X parser runs inside the page. The LinkedIn parser deliberately does not: LinkedIn redirects on entry, and anything evaluated in the document loses its execution context when it does. It reads the HTML as a string instead, which makes it immune to that rather than lucky about it — and testable from a fixture.
Contributions welcome: see CONTRIBUTING.md.
This repository previously held a different Subio MCP server — one that brought a
live Subio workspace into MCP clients over the Subio API. It was replaced rather
than extended, because a local signed-out scraper and an API client share a name
and nothing else. That work is preserved on the
legacy/subio-api-server
branch and under the v0.1.0 tag.
MIT.
Compare two to five Bubbles and recommend the strongest one for a specific goal.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| bubble_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, so the safety profile is covered. The description adds the comparative/analytical behavior but does not disclose output format or determinism. With annotations, this is acceptable but adds limited extra context beyond the purpose.
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, concise sentence that front-loads the verb 'compare' and avoids any fluff. Every word contributes to the core purpose.
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?
There is no output schema, and the description does not state what the tool returns (e.g., a bubble ID or explanation). The goal parameter is optional per schema but implied as required in the description, and usage context could be more explicit regarding prerequisites and alternatives.
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%, and the description does not explain the goal enum values (content, product_idea, launch, distribution) or what 'strongest' means. bubble_ids is self-explanatory but still not explicitly described, leaving the agent with limited guidance on parameter semantics.
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 verb ('compare'), resource ('Bubbles'), scope ('two to five'), and outcome ('recommend the strongest one for a specific goal'). This differentiates it from sibling tools like get_bubbles, search_bubbles, and get_bubble_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when comparing multiple bubbles for a goal) but does not explicitly state when not to use it or name alternative tools. The context is clear enough with no exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an evidence-based content draft from a Bubble. This tool never publishes automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| tone | No | ||
| format | Yes | ||
| bubble_id | Yes | ||
| instructions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-destructive, and the description adds the key behavioral trait that it 'never publishes automatically,' providing a safety guarantee beyond annotations. It doesn't address side effects or response format, but with annotations covering the basic profile, this is sufficient context. A 4 reflects the added safety disclosure.
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 short sentences, the first states the action, the second adds a crucial constraint. No filler or redundancy. A 5 is appropriate.
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?
With 5 parameters, no output schema, and no parameter descriptions, the description should have guided the agent on what inputs are needed and what the output looks like. It only mentions the Bubble source and the non-publishing behavior, missing the required format parameter and usage context. Therefore, the description is incomplete.
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% and the description fails to explain any of the 5 parameters beyond implying 'from a Bubble' maps to bubble_id. It doesn't clarify the meaning of 'format,' 'goal,' 'tone,' or 'instructions,' leaving the agent to rely solely on parameter names and enums. Since the description must compensate for the low coverage and does not, the score is 1.
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 a specific verb ('Generate') and resource ('content draft from a Bubble'), with a qualifier 'evidence-based'. It clearly distinguishes the tool from siblings (which are all retrieval/search tools) by being the only generation tool, and the statement 'never publishes' confirms its draft-only scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for producing a draft but offers no explicit 'use when' conditions or alternatives. It doesn't reference sibling tools or explain that a Bubble must first be fetched via get_bubbles/get_bubble_details. It only gives a safety guideline about not publishing, which is helpful but insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain why a Bubble is growing and return its timeline, pain points, opportunities, and verified sources.
| Name | Required | Description | Default |
|---|---|---|---|
| bubble_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds value by specifying the return contents (timeline, pain points, opportunities, verified sources), which is useful behavioral context especially with no output schema. No contradiction exists with the annotation.
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, front-loaded sentence that states the core purpose first and then lists the return items. Every word earns its place, with no filler or redundancy.
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 single-parameter, read-only tool, the description covers the primary behavior and explicitly lists what is returned, which is important because there is no output schema. It could be more complete by pointing to sibling tools or clarifying the parameter, but overall it is sufficient for basic use.
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%, and the description does not mention the bubble_id parameter or explain how to specify which Bubble to explain. The parameter name is self-explanatory, but since the schema provides no description, the tool description should compensate; it does not, leaving the mapping from 'a Bubble' to bubble_id implicit.
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 a specific verb 'Explain' and names the resource 'Bubble' along with concrete outputs (timeline, pain points, opportunities, verified sources). This clearly distinguishes it from sibling tools like get_bubbles or search_bubbles that likely list or find bubbles rather than explain a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deep-diving into a specific bubble's growth story, which gives a clear use case. However, it does not explicitly state when to prefer this tool over siblings like get_bubbles, search_bubbles, or compare_bubbles, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the highest-priority internet conversations currently gaining momentum.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No | ||
| min_score | No | ||
| timeframe | No | 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description aligns with this. However, it does not disclose return shape, pagination, sorting details, or any restrictions, leaving behavioral transparency only partially addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the action 'Return' and the resource. Every word contributes, with no filler or redundancy.
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?
With four parameters, no output schema, and no parameter descriptions in the schema, the description is too brief to fully support invocation. It communicates the high-level purpose but omits parameter semantics, return format, and usage context, making it only partially complete.
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%, and the description provides no explanation for limit, category, min_score, or timeframe. The parameter names are self-explanatory to some degree, but the description fails to add any meaning beyond the raw schema fields.
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 a specific verb 'Return' and identifies the resource as 'highest-priority internet conversations currently gaining momentum,' clearly distinguishing this from sibling tools like get_bubble_details or search_bubbles. It conveys a read operation focused on trending content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining top trending conversations but does not explicitly state when to use this over alternatives, nor does it mention search_bubbles or other siblings. Context is clear, but no exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current and historical Bubbles about a company, product, technology, industry, or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| platforms | No | ||
| timeframe | No | 7d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates a safe read operation. The description adds the 'current and historical' scope but does not disclose other behavioral aspects such as pagination or filtering behavior. This is acceptable given the annotation, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, yet the description provides minimal context. It lacks details about return format, filtering by platform/timeframe, or what constitutes a 'Bubble'. The description is too skeletal for a tool with these options.
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 0% schema description coverage, the description should compensate, but it only partially hints at the 'query' parameter by listing example search subjects. It does not explain the limit, platforms, or timeframe parameters, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Bubbles about specified topics, with a specific verb and resource. It indicates scope (current and historical) but does not explicitly differentiate from sibling tools like get_bubbles or get_bubble_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword-based searching but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The use case is inferred from the listed search subjects.
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.0compare_bubblesgenerate_contentget_bubble_detailsget_bubblessearch_bubblesScored across 5 tools
Each tool targets a distinct step in the bubble workflow: listing current, searching, getting details, comparing, and generating content. There is no functional overlap.
All tools use a consistent verb_noun snake_case pattern with clear verbs (get, search, compare, generate). Naming is predictable and follows a uniform convention.
With 5 tools, the surface is well-scoped for the domain. Each tool serves a necessary purpose without redundancy or bloat.
The toolkit covers the full lifecycle of bubble analysis: discovery, deep dive, comparison, and content generation. No critical operations are missing for the intended use case.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
