🧠 Blurt became much smarter [🤖 Talk to Blurt]
<center </center
---
Hello Blurtians!
Here is a question I honestly did not expect to ask so soon:
How will you use Blurt from now on?
Will you manually search for posts, check notifications, inspect accounts, compare communities, follow trails of reblogs, and look for the right page in a frontend…
…or will you simply ask your AI assistant to find the answer, summarize what matters, and take you directly to the right place?
That does not mean Blurt frontends become less important.
Quite the opposite.
Frontends remain where the experience happens: where you read, explore, manage your wallet...
But AI can become the layer that helps you get there faster.
Instead of spending time searching, filtering, opening tabs, checking profiles and comparing information manually, you can start with a simple request:
"Check my Blurt notifications and tell me if there are comments I have not read yet."
or:
"Find out if there is a Blurt community for cats or animals. Show me the best match, subscribe me to it, and give me the link to the latest post in it so I can read it."
or:
"Find me a recent high-quality Blurt post about travel that I have not upvoted yet, and give me the link so I can read it."
or even:
"I forgot to reply to @megadrive on my last Blurt post. Reply to him: Haha, the Eye sees all now 👁️🔥 Honored that Grok ranked it via the MCP — that's the whole dream working in real time. Thanks for lighting the fire again, @megadrive 🚀"
That is the shift.
Not replacing Blurt frontends.
Making Blurt easier to navigate, understand and use.
And after what happened in less than 48 hours since my last post, this shift feels much closer than I expected.
Last Saturday evening, I published Talk to Blurt: The Blockchain You Can Finally Talk To , where I introduced the first public version of the Blurt MCP Server .
At that moment, the idea was already powerful:
You could ask your AI questions about Blurt, and it could read the blockchain for you.
No block explorer. No API calls. No copy-pasting account names between websites.
Just ask.
But that was Saturday night.
It is now Monday.
And the gap between that first public version and what exists today is much bigger than I expected.
Because the Blurt MCP Server is no longer just a read-only connector that helps your AI understand Blurt.
It now has:
25 read tools to reason more deeply about accounts, communities, referrals, delegations, notifications and content propagation, a new local stdio mode for desktop clients and local AI agents, and, most importantly, 9 opt-in write tools that allow your AI to act on Blurt — locally, safely, and only when you explicitly configure it.
So this post is not just about a new version.
It is about a change in how Blurt can be used.
By the end of this post, you may not look at Blurt the same way anymore.
Saturday, Blurt learned how to answer.
Today…
<center </center
🧠 Blurt became much smarter
The biggest improvement is not that the connector now has 25 read tools instead of 20 .
That is just the number.
The real improvement is this:
The AI can now reason about Blurt in ways that were simply not possible Saturday.
Before, it could already answer useful questions about accounts, posts, witnesses, communities, prices and curation.
Now it can go deeper.
It can follow relationships between accounts. It can inspect referrals. It can read notifications. It can analyse delegations. It can understand how content spreads through reblogs. It can even help discover accounts when you only remember part of a username.
Those may sound like small additions.
They are not.
They turn the MCP from a blockchain reader into something much closer to a real Blurt assistant.
---
<center </center
For example, you can now ask:
"How many affiliates has socialgraph referred to Blurt? Give me the last 5 and tell me what they published."
That sounds like a simple question.
But behind the scenes, the AI has to do several things:
find the accounts referred by socialgraph , identify the most recent ones, inspect their profiles, check whether they actually published, open their posts when they exist, summarize what they wrote, and finally explain which referred users became active creators.
That is not just data retrieval anymore.
That is onboarding analysis .
It helps answer a much more important question:
Are referrals bringing real users to Blurt — or just empty accounts?
<center </center
---
<center </center
Another example:
"Do I have any notifications on Blurt?"
The AI can now read your recent notifications, summarize what matters, separate unread from already-read items, and tell you what happened without you opening a frontend.
Mentions. Replies. Votes. Follows. Reblogs.
All summarized in plain language.
And when combined with the new write tools, this becomes even more powerful:
"Mark my notifications as read."
That is the moment where the difference becomes obvious.
Saturday, your AI could help you understand Blurt.
Now it can start helping you manage your Blurt account.
<center </center
---
The same idea applies to the other new read capabilities.
You can ask things like:
"Show me the outgoing delegations of beblurt and explain who benefits from them."
or:
"Who reblogged this post, and what does that tell us about its reach beyond votes?"
or:
"I only remember that the account starts with blur... ; help me find possible matches."
These are not spectacular because they are technical.
They are useful because they match how real people think.
Nobody wakes up thinking:
"I need to call a blockchain endpoint."
People think:
"Who supported this post?" "Did this referral campaign work?" "Who is delegating to whom?" "Did anyone mention me?" "Where did this content spread?"
That is exactly where MCP becomes interesting.
It lets the AI translate a normal human question into the right blockchain calls, chain several tools together, and come back with an answer you can actually use.
So yes, technically, this release adds five new read tools.
But that is not the point.
The point is that Blurt just gained five new ways for AI to understand the ecosystem.
And that matters, because the next step is much bigger.
<center </center
✍️ From reading… to acting.
And this is where things become really interesting.
Until Saturday, the Blurt MCP Server was intentionally read-only .
That was the right first step.
Reading is safe. Reading is simple. Reading requires no private key. Reading can be exposed publicly through a remote MCP endpoint.
That is why the public server at:
will remain read-only.
It is there so anyone can connect Claude, ChatGPT, Grok, Mistral or another MCP-capable assistant and start asking questions about Blurt without risk.
But once the read-only foundation was working, the next question became obvious:
What happens when your AI can not only understand Blurt… but also help you act on it?
That is what this new phase introduces.
Not on the public HTTP server.
Not with your active key.
Not with your owner key.
Not in a way that lets an AI move funds.
But locally, under your control, with a posting key, through the new stdio server.
---
With the local version, your AI can now perform real social actions on Blurt:
claim your pending rewards upvote a post or comment reply to a post publish a new post follow or unfollow an account subscribe to a community reblog a post mark your notifications as read
This is the moment where the project crosses an important line.
Saturday, your AI could answer:
"Do I have any notifications on Blurt?"
Now it can also help with:
"Mark my notifications as read."
Saturday, your AI could say:
"This post deserves more visibility."
Now it can also help with:
"Upvote it with 25%."
Saturday, your AI could help you draft a comment.
Now it can also help you publish that comment — after you approve the action.
That difference matters.
Because the AI is no longer just a blockchain reader.
It becomes a local Blurt assistant.
<center </center
<center </center
<center </center
---
Of course, this had to be designed very carefully.
A blockchain action is not like editing a local note.
A vote is public. A comment is public. A post is public. A reblog is public. And once something is broadcast, it becomes part of the chain.
So the write mode follows a simple principle:
The AI may suggest. You remain in control.
Write tools are off by default .
They only appear when you run the MCP server locally through stdio and explicitly configure a valid posting authority.
And even then, the system is intentionally limited.
It accepts a posting key only .
That means the MCP can perform social operations such as voting, commenting, posting, following, reblogging or claiming rewards.
But it cannot transfer funds.
It cannot power down.
It cannot change ownership.
It cannot touch your active or owner authority.
---
The recommended setup is even safer:
use a delegated posting authority.
In plain English, that means you can create or use another account, grant it posting permission on your main account, and configure the MCP with that delegated account's posting key.
If one day you want to revoke access, you simply remove that posting authority.
No need to rotate your main posting key.
No need to expose more authority than necessary.
This is exactly the kind of security model Blurt needs if we want AI agents to become useful without becoming dangerous.
---
There are also several guardrails:
write tools are local only write tools are never exposed over HTTP the HTTP server refuses to start if a key is present every write tool supports dry run tools are separated by action, not hidden behind one generic broadcast tool each tool has its own validation each tool has rate caps specific write tools can be disabled with a denylist AI clients can ask for approval before executing an action
This is not "give your key to a chatbot and hope for the best."
It is a controlled local signing layer.
The AI can prepare the action.
The MCP validates it.
Your local server signs it.
And you decide what is allowed.
If you want to try this local mode yourself, I documented the setup here:
👉 Run locally as a stdio server 👉 Write operations — opt-in, local only
---
This opens the door to a completely different way of using Blurt.
Imagine asking:
"Read my latest notifications, summarize what matters, then mark them as read."
or:
"Find three high-quality posts from today that deserve support, explain your reasoning, then prepare a 20% upvote for the best one."
or:
"Draft a thoughtful reply to this post, show it to me first, then publish it if I approve."
or:
"I just discovered this author. Follow the account and reblog their latest post."
That is the real shift.
The MCP is no longer only a window into Blurt.
It becomes a bridge between your intent and the blockchain.
You still decide.
But the friction is much lower.
And for a social blockchain, that is a very big deal.
<center </center
💻 One connector. Two ways to use it.
At this point, the project needed two different ways to run.
Because not everyone uses AI the same way.
Some people want the simplest possible experience:
open Claude, ChatGPT, Grok or Mistral, add one remote connector URL, and start asking questions.
Others want something more local:
a desktop app, a local agent, a development environment, or a self-hosted AI stack running the MCP server directly on their own machine.
So the Blurt MCP Server now supports both.
---
🌐 Remote HTTP — simple, public, read-only
This is the version I introduced in the previous post.
You give your AI one URL:
And that is enough.
No installation. No wallet. No private key. No local setup.
This mode is perfect for reading Blurt.
You can use it to ask about accounts, posts, communities, witnesses, curation, referrals, notifications, delegations, reblogs, market data and more.
It is also the safest public mode, because it remains read-only .
The hosted HTTP server can help your AI understand Blurt.
But it cannot post. It cannot vote. It cannot reblog. It cannot sign anything.
That public boundary is intentional.
It keeps the remote connector useful for everyone, while keeping signing out of the hosted layer.
---
🖥️ Local stdio — private, powerful, under your control
The new piece is the local stdio server .
Instead of calling a remote URL, your AI client launches the MCP server as a local child process on your own machine.
That may sound technical, but the idea is simple:
the AI talks to a local Blurt MCP process, and that process talks to the blockchain.
This matters for several reasons.
First, it removes the hosted dependency.
If you want your own local Blurt MCP instance, you can run it yourself.
Second, it works naturally with desktop and developer tools that prefer local MCP servers.
Think of clients like:
Claude Desktop Claude Code Codex Cursor VS Code / Copilot agent mode Hermes Agent local AI workflows self-hosted assistants
And this list is only a sample.
I also started maintaining a broader compatibility matrix with remote HTTP support, local stdio support, config paths and notes for many MCP clients:
👉 MCP client compatibility
And third, this is what makes safe write operations possible.
A private key should not live on a public HTTP server.
A private key should not be sent to a hosted connector.
A private key should stay local.
That is why write tools only exist in the stdio mode.
The remote server is for reading.
The local server is for reading — and, if you explicitly configure it, acting.
---
The important part is that this is not two different projects.
It is the same Blurt MCP Server.
Same core. Same architecture. Same tools. Same logic. Two transports.
One for public, frictionless access.
One for local control.
<center </center
---
This also opens Blurt to a much wider AI ecosystem.
The question is no longer:
"Does this specific website support Blurt?"
The question becomes:
"Does this AI client support MCP?"
If the answer is yes, then Blurt can be connected.
That is a big shift.
Blurt is no longer limited to its own frontends, wallets, explorers or custom integrations.
It can now be plugged into AI assistants, coding agents, local LLM interfaces, IDEs, automation tools and self-hosted AI environments.
In practical terms, that means a developer can ask an AI agent to inspect Blurt data while working in an IDE.
A curator can ask a local assistant to review posts and prepare votes.
A witness can ask an AI to check blockchain health and compare infrastructure.
An author can ask where to publish, who engaged, who reblogged, and what happened since the last post.
And a power user can run everything locally, with their own configuration, their own account, and their own rules.
---
This is why the stdio server matters.
Not because "stdio" is an exciting word.
It is not.
It matters because it turns the Blurt MCP Server from a hosted read-only demo into something people can actually integrate into their own workflows.
Remote HTTP makes Blurt easy to try.
Local stdio makes Blurt powerful to own.
Together, they make the connector much more than a public endpoint.
They make it a real bridge between Blurt and the AI tools people already use.
<center </center
🙌 Closing thoughts
When I published the first Talk to Blurt post on Saturday evening, the message was simple:
Blurt is no longer only something you browse. It is something your AI can understand.
Two days later, the message has changed.
Blurt is becoming something your AI can help you use .
That is a much bigger shift.
Because once an AI can read accounts, posts, communities, witnesses, delegations, referrals, notifications and curation data…
…and once it can also prepare actions like votes, comments, posts, follows, reblogs or notification updates…
…the way we interact with a social blockchain starts to change.
You do not have to think first in terms of menus, pages, APIs or explorers.
You can start from intent.
"What happened on my account?" "Which post deserves support?" "Who brought real users to Blurt?" "Where should I publish this?" "Prepare a reply." "Upvote this." "Mark my notifications as read."
That is the direction I find exciting.
Not because AI should replace frontends.
Frontends still matter.
Wallets still matter.
Explorers still matter.
Human judgment still matters.
But AI can become a new interaction layer on top of Blurt.
A layer that helps people understand faster, decide better, and act with less friction.
---
Of course, this also means the project has to grow carefully.
That is why I spent time on the less visible parts too:
documentation, tests, client compatibility, dynamic RPC node selection, release notes, and a dedicated security model.
Those things are not the exciting part of the story.
But they matter.
Because if Blurt is going to become usable through AI agents, the connector cannot remain a weekend experiment.
It has to be something people can inspect, run locally, improve, and trust.
That is the direction this project is now taking.
---
The current state is already very different from Saturday:
25 read tools 9 opt-in write tools remote HTTP for easy read-only access local stdio for private workflows and signing delegated posting authority support dry-run support client compatibility documentation a dedicated security model testnet support open-source GPL-3.0 code
And this is still only the beginning.
The long-term vision is not just:
"Can an AI read Blurt?"
We already know it can.
The real question is now:
How far can we take Blurt as an AI-ready blockchain?
Can curators use AI to discover overlooked authors more fairly?
Can witnesses use AI to monitor infrastructure and governance more transparently?
Can authors use AI to publish better, find better communities, and understand their audience?
Can investors use AI to analyse the ecosystem with real on-chain data instead of assumptions?
Can developers build new Blurt tools without first learning every blockchain API detail?
I think the answer is yes.
And this release is one more concrete step in that direction.
---
If you want to try it right now:
Use the hosted read-only endpoint:
Explore the source code and documentation:
Try the local stdio version if you want full control.
Read the write operations documentation carefully before enabling signing.
And most importantly:
test it.
Ask real questions. Try real workflows. Push it. Break it. Tell me what is missing.
Because the most useful next tools will not come from a roadmap written alone.
They will come from real Blurtians using the connector with real needs:
authors, curators, witnesses, investors, developers, community owners and power users.
Saturday, Blurt learned how to answer.
Today, Blurt can start helping you act.
And I think that is only the beginning of what Talk to Blurt can become.
---
<center @nalexadre <div Top 20 Witness on Blurt</div </center
---
<center </center
Beyond Block Production
Running a witness node is only one part of my contribution to Blurt.
I actively operate and maintain:
- a public RPC server → - the BeBlurt frontend → - open-source tools available on my GitLab → - advanced on-chain analytics - a delegation system via @beblurt & manual curation - experimental integrations connecting Blurt with AI environments and external systems
My role is not limited to producing blocks.
It is about:
- strengthening infrastructure - improving accessibility - increasing transparency - enabling data-driven understanding - supporting organic curation - experimenting with new integrations
Supporting my witness is not about increasing my rewards — it is about maintaining an actively developed infrastructure node within the Top 20.
If you believe that infrastructure, transparency, curation balance, and innovation matter, your support is always appreciated.
Komentarze