Project

ActivityPub MCP Server

Discover users, fetch posts, and traverse the Fediverse social graph from any MCP client

Lets AI assistants explore the Fediverse: WebFinger discovery, actor profiles, and timelines across Mastodon and any ActivityPub-compatible server.

Astro MCP WebFinger ActivityPub Fediverse Fedify
View on GitHub Documentation Read the write-up
Screenshot of ActivityPub MCP Server

Architecture

flowchart LR
    subgraph Client["AI Client"]
        AI["Claude / LLM"]
    end
    subgraph Server["MCP Server"]
        Tools["MCP Tools"]
        Resources["Resources"]
        Fedify["Fedify"]
    end
    subgraph Fediverse["Fediverse"]
        WF["WebFinger"]
        AP["ActivityPub"]
        Mastodon["Mastodon"]
        Pixelfed["Pixelfed"]
    end
    AI --> Tools
    AI --> Resources
    Tools --> Fedify
    Fedify --> WF
    Fedify --> AP
    AP --> Mastodon
    AP --> Pixelfed

The Problem

The Fediverse spans thousands of decentralized servers, but AI assistants have no way to access this ecosystem. The ActivityPub protocol's complexity and the need for WebFinger discovery create significant barriers to AI integration.

The Solution

Built an MCP server for ActivityPub on the Fedify framework for robust protocol support. The server enables AI assistants to discover users via WebFinger, fetch profiles and posts, and explore the social graph across any ActivityPub-compatible instance.

The Results

  • First publicly released MCP server for the Fediverse (published May 2025)
  • WebFinger discovery across federated instances
  • Compatible with Mastodon, Pixelfed, and all ActivityPub servers
  • Built on Fedify for reliable protocol implementation

The ActivityPub MCP Server connects AI assistants to the Fediverse - the decentralized social network including Mastodon, Pixelfed, and thousands of other instances. Built with Fedify for robust ActivityPub support.

MCP Tool Explorer

activitypub-mcp
# Request
{
  "tool": "webfinger_lookup",
  "account": "@user@mastodon.social"
}
webfinger

Discover a user via WebFinger lookup

This is a simulated demo. The actual MCP server processes requests from AI assistants like Claude.

Key Features

  • Fediverse Access: Connect to any ActivityPub-compatible server
  • WebFinger Support: Discover users across federated instances
  • MCP Tools & Prompts: Standardized interface for AI interaction
  • Fedify Integration: Built on the Fedify framework for reliability

The engineering challenge

ActivityPub is valuable precisely because it is decentralized, but that decentralization creates the core challenge for AI integration. There is no single canonical API surface, implementations vary across servers, and even simple tasks like resolving an account handle require protocol-aware discovery through WebFinger.

The goal of this server was to hide the friction without flattening away the protocol. An assistant should be able to explore the Fediverse as a network of actors, inboxes, outboxes, and objects, not as a brittle collection of server-specific REST calls.

Why Fedify was the right foundation

I built the server on Fedify because correctness mattered more than speed of a one-off integration. Fedify gave me a durable protocol layer for:

  • WebFinger resolution
  • ActivityPub actor and object handling
  • cross-instance compatibility
  • a cleaner abstraction over the differences between Fediverse implementations

That choice let the MCP layer focus on tool design and response shaping instead of re-implementing protocol details from scratch.

Design tradeoffs

There is a tension between exposing a rich social graph and keeping tool calls understandable for an LLM. I addressed that by making the tools explicit and composable: discover an account, fetch the actor, inspect the outbox, then traverse outward. That produces a better agent experience than trying to hide everything behind one overloaded endpoint.

The other tradeoff was resiliency. In a federated network, partial failure is normal. Different instances may be slow, unavailable, or slightly inconsistent. The server therefore had to prefer graceful degradation and clear error reporting over pretending every node behaves the same way.

Outcome

The hardest constraint turned out to be partial failure. In a federated network some instances are always slow, unreachable, or slightly nonstandard, so the server treats graceful degradation and clear error reporting as core features rather than edge cases — an assistant exploring the Fediverse gets an honest answer about a dead instance instead of a hung request.

Was this helpful?

Want to learn more?

Ask can answer questions about this project's implementation, technologies, and more.