📚 Talk to Blurt: Welcome to the User Guide

<center </center

---

Hello Blurtians!

Last week, I introduced something that still feels a little strange to say out loud:

You can now talk to the Blurt blockchain through your AI assistant.

First, I wrote about the public Blurt MCP Server — the connector that lets Claude, ChatGPT, Grok, Mistral and other MCP-capable assistants read Blurt blockchain data directly.

Then, only two days later, I wrote about the next step:

Blurt was no longer only something your AI could understand. It was becoming something your AI could help you use .

That second post was about the jump from a simple read connector to a much more capable MCP server.

That was already a big step.

But after publishing it, something became obvious.

A tool is only useful if people can actually connect it, understand it, trust it, and run it in the way that matches their own workflow.

So this new post is not mainly about adding one more flashy feature.

It is about something less spectacular, but much more important if we want this project to become useful beyond a demo:

The Blurt MCP Server now has proper documentation.

Not just a README.

Not just a list of commands.

A real documentation site for users, AI-assistant users, developers, operators and people who want to self-host their own MCP instance .

Because if we want Blurt to become AI-ready , the bridge itself must be understandable.

---

🧩 Why documentation matters for an MCP

When people hear “documentation”, they often think about something boring.

A page you read only when something breaks.

A long list of parameters.

A technical manual hidden somewhere in a repository.

But for an MCP server, documentation plays a much bigger role.

It is a contract between three different worlds:

the Blurt blockchain , the AI assistant , and the human user asking questions in plain language.

The AI needs to know which tools exist.

The user needs to know what is safe.

The developer needs to know how to run it.

And everyone needs to understand one simple thing:

Which mode am I using, and what can it do?

That is why I spent time building a real documentation site instead of leaving everything in a README.

👉 Documentation:

👉 Source code:

<center </center

---

🧭 Start here

The documentation is organized around how people actually use the Blurt MCP Server.

The best place to begin is:

👉 Installation & usage

It explains the two supported connection styles:

- Remote HTTP — connect directly to the public hosted endpoint.

- Local stdio — run the MCP server as a local process.

Once you've chosen your setup, the next stop is:

👉 Install snippets

No long explanations.

Just copy, paste and connect your favorite MCP client.

Claude Desktop.

ChatGPT.

Codex.

Cursor.

Gemini CLI.

Hermes Agent.

VS Code.

And many more.

The goal is simple: make Blurt easy to plug into the AI tools you already use.

<center </center

---

🤖 The client compatibility matrix

Another important addition is the MCP client compatibility page:

👉 MCP client compatibility

This is not just a marketing list.

It shows, at a glance:

which clients support local stdio , which support remote HTTP , where their configuration files live, whether they are open-source, and notes or references for each one.

Why does this matter?

Because the question for Blurt is no longer:

"Does this frontend support my workflow?"

The question becomes:

"Does my AI client support MCP?"

If the answer is yes, then Blurt can usually be connected.

That opens Blurt to many environments:

web assistants like ChatGPT and Claude, desktop applications like Claude Desktop, coding agents like Codex and Claude Code, IDEs like VS Code, Cursor and JetBrains, local AI assistants, self-hosted AI platforms, and future MCP clients that have not even reached the Blurt community yet.

This is the part I find exciting.

For years, Blurt users had to choose a frontend.

With MCP, they can simply choose the AI client they prefer.

The MCP does not force everyone into one interface.

It lets Blurt travel to where people already work.

<center </center

---

✍️ Write operations

The previous post introduced the most sensitive part of the project:

Optional write tools.

Reading public blockchain data is one thing.

Publishing a blockchain transaction is another.

A vote is public.

A comment is public.

A post is public.

A reblog is public.

And once a transaction is broadcast, it becomes part of the blockchain.

That is why the documentation now includes a dedicated guide for write operations:

👉 Write operations

Rather than simply listing the available tools, it explains the safety model behind them.

By default:

write tools are disabled ; local stdio is the recommended signing mode; only a posting key is accepted; owner and active keys are refused; the public hosted endpoint never exposes signing; every write tool supports dry run .

For most people, the safest way to begin is simply:

Start with a minimal set of capabilities.

Enable more only when you actually need them.

Because this is the principle I want for AI on Blurt:

Start small. Stay local. Keep control.

<center </center

---

---

🏗️ Self-hosting is now properly documented

Not everyone wants to use the public hosted endpoint.

Some people want to run their own MCP server .

The documentation now includes dedicated deployment guides covering local HTTP deployments, reverse proxies, operational endpoints and process managers.

👉 Deployment

👉 PM2 deployment

This may sound less exciting than asking an AI to analyze witnesses.

But it is just as important.

Good infrastructure is not only about writing code.

It is about making deployment predictable, repeatable and easy to understand.

Whether you use the public endpoint, run a local stdio server or operate your own HTTP instance, the documentation now explains each path clearly.

Because good documentation is what turns a project into infrastructure people can actually rely on.

<center </center

---

⚙️ Built for the AI ecosystem

One thing I wanted from the beginning was to build more than a collection of MCP tools.

The Blurt MCP Server represents the Blurt blockchain outside of Blurt itself .

For many AI assistants, it will become the first — and sometimes the only — interface they ever see.

That means the protocol contract matters just as much as the features.

To support that, the documentation now includes two references aimed primarily at developers.

👉 Generated tool contract reference

Rather than simply listing tools, it documents the contract behind every one of them.

Every response follows the same structured result envelope, carrying not only the requested data but also metadata about its origin, freshness, confidence and retrieval context.

The Source column is equally important.

It makes explicit whether information comes from Blurt Layer 1, Nexus, external services or a combination of them.

For AI agents, provenance matters.

The second reference is the architectural compatibility register:

👉 MCP compatibility register

Instead of simply claiming "MCP compatible" , it documents the project's compatibility decisions, protocol assumptions and intentional design choices against the evolving MCP specification.

As the AI ecosystem continues to evolve, I believe documentation like this is just as important as writing new code.

Because infrastructure is not only measured by what it can do.

It is also measured by how clearly it defines its contracts.

<center </center ---

📦 What changed since v0.3.0?

The previous post focused on what the Blurt MCP Server could do.

Since then, the biggest improvements have not been new tools.

They have been about giving users and developers much more control over how the MCP behaves.

One important change is the evolution of the BLURT ENV FILE .

What started as a simple configuration file has become the central place where you can tailor the server to your own workflow.

It now controls far more than credentials.

RPC selection.

Timeouts.

Caching.

Failover behavior.

Write capability profiles.

Logging.

And many other operational settings.

Whether you simply want to explore Blurt through AI or operate your own MCP server, the same configuration model scales with you.

The second major improvement is full testnet support .

By configuring the chain ID and address prefix, developers can now build and test complete AI workflows against a Blurt testnet instead of the production blockchain.

From the AI assistant...

...all the way to the blockchain.

For me, these two changes perfectly illustrate the direction of the project.

Less about adding features.

More about building an MCP server that is flexible enough for users, operators and developers alike.

---

💬 What I want people to try now

If you are a normal Blurt user, start with the public endpoint:

Ask your AI questions like:

"What happened recently on my Blurt account?"

"Which communities could fit a post about photography?"

"Compare these three accounts and explain the differences in stake, activity and rewards."

"Show me the biggest curators on this post and explain their impact."

If you are a developer or power user, try the local package.

If you are a curator, look carefully at the curator write profile.

If you are an operator, read the deployment and security docs before exposing anything.

And if you are building AI tools, inspect the generated tool reference and tell me what contract is missing.

Because this is where feedback becomes useful.

<center </center

---

🙌 Closing thoughts

When I published the first Talk to Blurt post, my goal was simple.

To prove that an AI assistant could finally understand the Blurt blockchain .

The second post went one step further.

It showed that AI could also help us use Blurt through carefully designed local write operations.

This post is about something quieter.

Documentation.

At first glance, that may not sound exciting.

But I believe it is one of the most important parts of the project.

Because documentation is no longer written only for humans .

With MCP, it also becomes part of the interface the AI sees.

The better we describe our tools...

...the better AI assistants can understand Blurt.

And the better they understand Blurt...

...the more they can help people use it.

Not by replacing anyone.

But by removing friction .

Helping someone understand a long technical article.

Summarizing a post written in another language .

Explaining an unfamiliar blockchain concept.

Helping write a thoughtful reply.

Suggesting the right community.

Finding the information you were looking for without opening ten different pages.

For years, one of Blurt's biggest challenges has not been publishing content.

It has been interaction.

If AI can help more people read...

...understand...

...and confidently join the conversation...

...without replacing their own voice...

...then I believe it can strengthen the community itself.

That has always been my vision for Talk to Blurt .

Not building another connector.

Not adding another API.

But lowering the barriers between people and the blockchain they want to use .

Because every barrier we remove makes the next conversation a little more likely to happen.

And perhaps...

that is one of the most valuable things AI can bring to Blurt.

---

<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.