Featured

ActivityPub MCP Server

First MCP server for the Fediverse, connecting AI to millions of decentralized users

A comprehensive Model Context Protocol (MCP) server that enables LLMs like Claude to explore and interact with the existing Fediverse through standardized MCP tools, resources, and prompts.

Astro MCP WebFinger ActivityPub Fediverse Fedify
View on GitHub Live Demo
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 represents millions of users across 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

Developed the first MCP server for ActivityPub, built 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 MCP server enabling AI access to the Fediverse
  • WebFinger discovery across federated instances
  • Compatible with Mastodon, Pixelfed, and all ActivityPub servers
  • Built on Fedify for reliable protocol implementation
10M+
Fediverse Users
1000s
Instances
ActivityPub
Protocols
WebFinger
Discovery

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": "@[email protected]"
}
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

This project shows how protocol-heavy infrastructure can be turned into a practical developer surface. It also demonstrates an important portfolio theme: I like building the connective tissue between ambitious systems, not just the UI layered on top of them.

Was this helpful?

Want to learn more?

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