AT Protocol MCP Server

Appearance

AT Protocol ​

A short background page on the Authenticated Transfer Protocol (atproto) — just enough context to understand what this MCP server talks to. For authoritative, up-to-date details, follow the links to the official documentation rather than relying on this summary.

What is AT Protocol? ​

The Authenticated Transfer Protocol (AT Protocol or atproto) is an open, decentralized protocol for large-scale social applications, created by Bluesky. Users own their identity and data, and can move between services without losing their social graph or content.

This MCP server is a client of the AT Protocol: it authenticates against a Personal Data Server (by default bsky.social) and exposes protocol operations as MCP tools, resources, and prompts.

If you want to understand the protocol itself in depth, start here:

Core concepts (and the tools that use them) ​

The table below maps the AT Protocol building blocks to the MCP tools this server exposes. See the API Reference for the full catalog of 51 tools.

AT Protocol conceptWhat it isRelated MCP tools
Identity — DIDs (did:plc:...) and handles (name.bsky.social)A portable, cryptographic account identifier plus a human-readable handle that maps to itget_user_profile, update_profile
Records — typed entries in your repositoryPosts, follows, likes, etc., each described by a Lexicon such as app.bsky.feed.postcreate_post, like_post, repost, follow_user
Feeds & timelines — aggregated views over recordsThe home timeline and other feeds assembled by App Viewsget_timeline, search_posts
Embeds & blobs — images, video, external linksMedia is uploaded as blobs and referenced from a post's embedupload_image
Moderation — mutes, blocks, reports, labelsPer-user and service-level moderation primitivesmute_user, block_user, report_content

Identifiers worth knowing ​

  • DID — did:plc:abc123...: the stable account identifier that survives handle and PDS changes.
  • Handle — name.bsky.social or a custom domain: a human-readable alias for a DID.
  • AT-URI — at://did:plc:abc123.../app.bsky.feed.post/xyz789: addresses a single record as at://<DID>/<collection>/<record-key>.
  • CID — a content-addressed hash of a record, used to pin and verify an exact version.

For the precise formats and rules, see the AT Protocol specifications.

Authentication ​

This server connects to a Personal Data Server and signs requests on your behalf.

App passwords are the supported authentication path. Create one in Bluesky Settings → App Passwords, then provide it to the server via ATPROTO_IDENTIFIER and ATPROTO_PASSWORD. App passwords are scoped, can be revoked individually, and never expose your main password. See Authentication for setup.

Run without credentials and only the public/enhanced tools work (notably get_user_profile and search_actors); search_posts and most other tools require authentication.

OAuth (planned) ​

AT Protocol supports OAuth 2.0, and Bluesky has shipped it. In this server, OAuth login is planned but not yet functional, so it is not exposed as a tool — use app passwords for working authentication. See Experimental & Roadmap for the current state.

Rate limits ​

The AT Protocol enforces its own rate limits at the PDS, separate from this server's per-tool limiting. The published numbers change over time, so do not hard-code them — see the official Bluesky rate limits documentation for current values.

This server additionally applies a local limit of 100 requests per minute per tool. When you hit a limit (local or upstream), back off and retry. See Error Handling for handling rate-limit responses.

Where to go deeper ​

The protocol covers much more than this server uses — federation (relays, App Views, feed generators), the firehose, custom Lexicons, labeling services, and rich-text facets. Rather than restate it here (and risk drifting out of date), consult the authoritative sources:

Next Steps ​

Previous: MCP Protocol ← | Next: Tools & Resources →