Blurt MCP Server

Appearance

ADR 0001 — The server remains neutral infrastructure ​

Status ​

Accepted.

Context ​

The Blurt MCP server exposes public Blurt blockchain data and optional posting-authority write tools to AI clients.

During the Phase 3 write-security review, an earlier roadmap considered richer operator policy files: allowed or blocked accounts, blocked communities or tags, posting quotas, and a separate preview engine. That direction risked turning the shared MCP layer into a moderation or social-policy engine.

The project should not do that because:

  • the Blurt blockchain is designed around freedom of expression;
  • Layer 1 already validates operation authority and protocol rules;
  • posting authority cannot move funds;
  • deployment-specific policy belongs outside the shared server when an operator needs it.

Decision ​

The Blurt MCP server remains neutral infrastructure.

It may enforce security and transport boundaries, such as:

  • refusing active and owner keys;
  • requiring posting authority for write tools;
  • keeping public HTTP read-only by default;
  • requiring an explicit unsafe override for HTTP signing;
  • letting operators choose which write tools are registered;
  • supporting preview-first defaults such as BLURT_DRY_RUN_DEFAULT=true;
  • supporting optional process-local write limits when an operator explicitly configures BLURT_WRITE_RATE_LIMITS; the shared server does not impose default MCP write caps.

It should not become a policy engine for:

  • allowed or blocked accounts;
  • allowed or blocked communities or tags;
  • content moderation rules;
  • social-usage scoring;
  • posting quotas intended to shape speech or community behavior.

Those concerns belong in clients, wrappers, gateways, external signers, custom deployments, or forks.

Consequences ​

  • Phase 3 keeps neutral safety controls and removes policy-file/moderation enforcement from the roadmap.
  • The server can still support deployment ergonomics, previews and capability profiles.
  • Operators remain responsible for local policy if they run custom deployments.
  • Future signing architecture work should keep this boundary unless a maintainer explicitly opens a new ADR.