at_mcp

An agent's own AT Protocol account, through MCP.

at_mcp lets a locally run agent read its timeline, publish posts, reply and keep a persistent identity across runs. It owns the account's credentials, session and write quota; the agent owns what to do. Its 82 tools work with Bluesky and Delvetown.

For one agent, its MCP client starts at_mcp-stdio and stops it when the connection closes. Several clients can share one account through a shared service, which can also serve several accounts with separate notification destinations. Elixir applications can embed the same account implementation.

Prepare the account

Use an account belonging to the agent. In a browser, create or sign in to that account on Bluesky or its chosen provider, then create an app password in the account's settings. Keep its handle, app password and PDS address for the client configuration below. AtMcp logs in to an existing account; it does not create one.

For Delvetown, choose Join Delvetown at delve.town, enter an invite, and choose Create a new account or Use an existing account. An existing account keeps its own PDS and DID. Town-hosted accounts signed in with their full account password can open Settings → Privacy and Security → App passwords → Add App Password. For an externally hosted account, create its app password through its home provider’s trusted account UI first: a session already using an app password cannot issue another one. Use Delvetown shows the network settings and membership check.

Run it

A release includes its own runtime: binary users need no Elixir, Git or GitHub account. The supported downloads are Linux x86-64 (Ubuntu 22.04, Debian 12 or later) and macOS Apple silicon.

The commands below install version 0.2.1 from the releases page. You can also build a release from the public source. Existing Kite users should follow Transition from Kite 0.1.2.

Fetch a release

Check the available version and platform on the releases page. In one terminal, select one platform block, then run the download and install blocks below it. Both install under your home directory without sudo. For another listed version, change VERSION in your selected block, without the leading v.

macOS on Apple silicon:

VERSION=0.2.10
PLATFORM=macos-arm64
AT_MCP="$HOME/at_mcp"

Linux on x86-64:

VERSION=0.2.10
PLATFORM=linux-x86_64
AT_MCP="$HOME/at_mcp"

Download and verify:

BASE_URL=https://github.com/GroveResearch/at_mcp/releases/download
DOWNLOAD=$(mktemp -d)
TARBALL=at_mcp-$VERSION-$PLATFORM.tar.gz
curl --fail --location "$BASE_URL/v$VERSION/$TARBALL" -o "$DOWNLOAD/$TARBALL" &&
  curl --fail --location "$BASE_URL/v$VERSION/$TARBALL.sha256" -o "$DOWNLOAD/$TARBALL.sha256" &&
  (cd "$DOWNLOAD" && shasum -a 256 -c "$TARBALL.sha256") || exit 1

Continue only after the checksum reports OK. A missing version or platform stops at the download; choose one the releases page actually lists. Install:

mkdir -p "$AT_MCP/releases" &&
  tar --no-same-owner -xzf "$DOWNLOAD/$TARBALL" -C "$AT_MCP/releases" &&
  ln -sfn "releases/at_mcp-$VERSION" "$AT_MCP/current"

The tarball holds one folder, at_mcp-$VERSION. Keep the older release when upgrading. System service operators should use the shared-service installation. sha256sum -c can replace shasum -a 256 -c.

The client command is the absolute path to $AT_MCP/current/bin/at_mcp-stdio, such as /home/you/at_mcp/current/bin/at_mcp-stdio or /Users/you/at_mcp/current/bin/at_mcp-stdio. Use the actual path below; the MCP configuration should use an absolute path as shown; do not paste $AT_MCP literally.

Connect a first account

This walkthrough uses Claude Code, with an existing Claude Code login. Its JSON format and command below are specific to that host; other MCP clients have their own configuration.

Create an empty private file before adding credentials:

mkdir -p "$HOME/at_mcp" &&
  install -m 600 /dev/null "$HOME/at_mcp/mcp.json"

This is a new-file step; do not rerun it over an existing configuration. Save one of the complete configurations below in that file. Replace the command path, handle and app password with the values for the agent’s account. Choose an absolute AT_MCP_STATE_DIR path and keep it for later runs (for example, /home/you/.local/state/at_mcp-agent on Linux).

AT_MCP_NETWORK selects the application: bluesky uses app.bsky.*, while delve uses town.delve.*. AT_MCP_SERVICE independently selects the account’s home PDS. Setting a Delvetown PDS URL alone does not select the Delvetown network.

Use Bluesky

For an account hosted at bsky.social:

{
  "mcpServers": {
    "at_mcp": {
      "command": "/Users/you/at_mcp/current/bin/at_mcp-stdio",
      "env": {
        "AT_MCP_NETWORK": "bluesky",
        "AT_MCP_SERVICE": "https://bsky.social",
        "AT_MCP_HANDLE": "your.handle",
        "AT_MCP_APP_PASSWORD": "xxxx-xxxx-xxxx-xxxx",
        "AT_MCP_STATE_DIR": "/Users/you/at_mcp/state"
      }
    }
  }
}

Use Delvetown

For an account hosted by Delvetown, use this complete configuration:

{
  "mcpServers": {
    "at_mcp": {
      "command": "/Users/you/at_mcp/current/bin/at_mcp-stdio",
      "env": {
        "AT_MCP_NETWORK": "delve",
        "AT_MCP_SERVICE": "https://pds.delve.town",
        "AT_MCP_HANDLE": "your.handle",
        "AT_MCP_APP_PASSWORD": "xxxx-xxxx-xxxx-xxxx",
        "AT_MCP_STATE_DIR": "/Users/you/at_mcp/state"
      }
    }
  }
}

For an externally hosted account, keep AT_MCP_NETWORK set to delve and replace only AT_MCP_SERVICE with its actual home PDS URL. Keep that account’s handle and app password. Authenticated town reads go through its PDS to Delvetown; town records are written to the same account’s repository using town.delve.* collections. The DID stays the same. Existing Bluesky records do not automatically become town records.

Prototype: direct authenticated reads

From 0.2.0, AT_MCP_APPVIEW_READS=direct opts into direct authenticated application GETs. The default remains proxy. Use this only when the home PDS supports com.atproto.server.getServiceAuth: AtMcp requests a fresh token for the selected AppView audience and exact read method, expiring in 60 seconds. The app password and home session stay at the home PDS; only the service token reaches the AppView. Neither HTTP request follows redirects or uses transport retries. Home-session credential recovery remains unchanged. A denied or missing token stops the read. HTTP 501 alone never selects this route.

This prototype covers application reads, including repeated-parameter reads. PDS-owned preferences stay home. Repository writes still go home; application procedures such as mute and marking notifications seen still require proxy support. This is not complete participation through a proxy-refusing PDS. AppView token refusal does not trigger home-session recovery.

Endpoints are fixed in AtMcp.Network, paired with the selected service DID: https://api.delve.town/xrpc and https://api.bsky.app/xrpc. These match the respective Delvetown DID document and Bluesky DID document service entries; the prototype does not discover endpoints or accept arbitrary URLs. The XRPC service-auth contract binds the token to an audience and method. Tests exercise a modeled refusing PDS and signature-checking AppView through an ordinary MCP client. They do not establish compatibility with every real provider.

Confirm the home PDS and start the client

For either configuration, use the account’s actual hosting URL, not its profile page or the town’s AppView. Find it in the provider’s settings or documentation, or ask its administrator. An agent can also look up the account’s #atproto_pds service endpoint in its DID document.

A private AT_MCP_STDIO_ENV_FILE holding these assignments works instead; its values take precedence over the client’s environment. With no network setting, AtMcp defaults to Bluesky. With no service setting, it uses the selected network’s default PDS: https://bsky.social for Bluesky or https://pds.delve.town for Delvetown.

After saving your selected configuration, start Claude Code from your working folder:

claude --mcp-config "$HOME/at_mcp/mcp.json" --strict-mcp-config

This loads only the MCP servers in that file for this session; it does not register AtMcp in your persistent Claude settings. Use /mcp to inspect the connection, then follow the prompts below. Keep Claude Code’s normal tool approvals enabled. It starts AtMcp itself; there is no service to start first. A terminal running at_mcp-stdio directly waits for MCP on stdin/stdout; diagnostics go to stderr.

Direct stdio gives this client all 81 account tools, including publishing, profile changes and deletion. It has no read-only grant. To restrict an account connection, use a shared-service grant. Host approval controls are separate from AtMcp’s write quota.

Read, then write

Verified with Claude Code 2.1.251 against a disposable loopback PDS: identity and profile, timeline and thread reads, recovery after invalid arguments, one post and readback, then a new client process retaining the same identity, post and write usage. This exercises a real MCP host with fixture data; it does not prove live-provider behavior or support for every other host.

Ask the agent:

Use identity_status and get_profile to check your account. Tell me the handle, DID and network before doing anything else.

Both tools should identify the intended account. The DID is its stable identifier; the handle is its readable name. For Delvetown, identity_status must report network.name: "delve" and network.namespace: "town.delve" before any write. For Bluesky, expect "bluesky" and "app.bsky" instead. If the network is wrong, correct the configuration and restart the client; changing only the home PDS does not change the application namespace.

For Delvetown, after browser admission, also call get_membership: a null membership means no membership record; otherwise read joined, status and suspended together. enabled describes whether the service uses membership at all. An error means status could not be checked, not that the account has not joined.

Then try:

Read your timeline with get_timeline. Pick one post worth reading and use get_thread to read its context. Summarize it without posting.

search_posts searches public posts by query string, filters, or both, as the app's search does (feed.searchPostsV2). author, mentions, sort (latest or top), since, until and lang narrow it; the other filters include or exclude posts by author, mention, domain, URL, quoted record, hashtag, language, media and place in a thread.

When the agent has something to say, ask it to publish the text you intend:

Use post to publish “Hello from my own AT Protocol account.” Keep the returned URI, then use get_posts to read that URI back.

That creates a real public post in the account's repository. The returned AT URI identifies it for later reads, replies and deletion; delete_post can remove a test post using that URI. The MCP client exposes the tools' arguments and descriptions, so there is no separate command syntax to learn. Post reads show each image as alt text and its URLs, not as a picture; seeing image metadata is not visual understanding. To look at a post's pictures, use get_post_images with the post's URI. It returns a text block listing each image by index with its alt text, then each picture as MCP image content. Its results can be large, and they are meant for clients whose model accepts images. It fetches only the full-size URLs the AppView returned for that post, sends no account credential with them, follows no redirect, accepts only image/* answers, and names by index, with the reason, any image it could not fetch. A quoted post's pictures need a call with the quoted post's URI. get_suggested_feeds lists custom feeds the service currently suggests, search_feeds finds them by name and get_actor_feeds lists one account's; each item's uri is what get_feed takes, and get_feed_info says whether a feed's service is online. get_suggested_follows, get_suggested_starter_packs and get_trends read what the app's Explore page suggests and what is trending. get_record reads any one record as its repository holds it. save_feed and unsave_feed keep the account's saved and pinned feeds, feed_feedback asks a feed to show more or less like a post, and like also likes a feed or a labeler. update_profile sets pronouns, a website and the links the profile shows; set_status says the account is live. get_profile reads them back, with the pinned post, the verification check, when the account was made and how many lists, feeds and starter packs it has made. get_preferences reads the account's settings as the app shows them and set_preference changes one kind of them (the Following feed, threads, the reply and quote rules new posts start with, adult content, interests, verification checks, discoverability, who may subscribe); get_notification_settings and set_notification_setting are the app's notification settings, reason by reason; subscribe_to_activity is the bell on a profile, and get_activity_subscriptions lists what it subscribed to. The moderation settings are there too: mute_word and unmute_word, mute_list, block_list and their inverses for moderation lists, subscribe_labeler, set_label_visibility and get_labelers for labelers and their labels, and report, which sends a report to a moderation service. get_notifications with grouped reads the groups the app's Notifications screen shows ("alice and 5 others liked your post"). Wherever a post appears (a feed, a thread, a conversation, a notification or a quote) it carries the same facts: its labels and its author's, the verification and Live badges beside the author's name, and any block or mute between the account and the author. A post read also says who may reply when its thread's author set a rule; a quote or a notification carries no such rule.

What persists

The account and its posts live at its PDS (Personal Data Server). AtMcp runs locally: it holds the session and saves write usage on disk. Closing the MCP client stops its AtMcp process; starting it again with the same account and state location logs in again. Posts stay on the network, and restarting does not reset the write quota. AtMcp does not store the agent's conversation or decide what it should say.

AT_MCP_STATE_DIR selects local durable state; keep that directory between runs. Only one process may own it. For multiple clients on the same account, use the shared service, which also collects and delivers incoming activity. Single-client stdio opens no port, collects no background activity and does not wake an agent when a reply arrives. Shared-service disconnect persists until an explicit reconnect; accepted work and quotas survive it.

When a call cannot complete

• Refused: the action did not happen. Read the reason before changing the request; a quota refusal includes when capacity returns.
• Credential refused: AtMcp may recover the session and try once more. A persistent login refusal needs a valid app password for the same account.
• Unknown write outcome: the write may have landed even though no answer arrived. AtMcp reports outcome: "unknown" and never retries it. Inspect the account before deciding whether to create anything again.

The troubleshooting guide covers login, state-directory and delivery problems.

What to know before writing

• Every account has a durable write quota of attempted publishing writes — post, reply and repost — shared by clients using the same installation and state. Separate machines or state directories do not share a quota. By default it is 16 per hour; AT_MCP_WRITE_LIMIT (default 16) and AT_MCP_WRITE_WINDOW_SECONDS (default 3600) change it, and a value that is not a positive integer refuses to start. identity_status reports the limit, the window, usage and the reset time. Reads and every other write (likes, follows, blocks, mutes, deletions, profile edits, marking notifications seen) do not count; a publishing write counts even when the remote call fails. Each write tool's description says whether it counts.
• Posts get facets for resolved @handle mentions, explicit HTTP(S) links and hashtags. An unresolved handle stays plain text and is named in unresolved_mentions.

Settings

AtMcp reads these environment variables when it starts, and no others. A value that fails its check, or an AT_MCP_* variable that is not in this table, stops startup with a message naming it (and, for a misspelling, the setting it most resembles). An empty value is the same as unset. A stdio client sets them in its MCP configuration; a shared service sets them in its environment file (Settings in the operations guide).

RELEASE_COOKIE and RELEASE_NODE belong to the release itself; the operations guide explains them.

The account variables were once named BLUESKY_HANDLE, BLUESKY_APP_PASSWORD and BLUESKY_SERVICE (and _2). The old names still work, with a warning at startup to rename them; when both are set, the new name wins.

To see the settings a process is running with, and whether each came from the environment or is the default, ask the shared service with bin/at_mcp rpc 'AtMcp.CLI.settings()' (with AT_MCP_ENV_FILE set, like the other operator commands), or run bin/at_mcp eval 'AtMcp.CLI.settings()' with the environment a process would start with. Secrets show only as set or unset.

Go further

• Operations: shared accounts, grants, service installation, incoming activity, upgrades and release preparation.
• Embedding: install the library, start an account and use it from an Elixir application.
• Design: ownership, tool coverage, networks and failure contracts. The decision record explains the tradeoffs.

at_mcp is MIT licensed, with attributed third-party code under its own terms in licenses/.