Taproot: AT Protocol MCP

Read public AT Protocol profiles, records, threads, backlinks and lexicons.

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Read public AT Protocol profiles, records, threads, backlinks and lexicons. No API key required.

Список инструментов сервера (27)

Технические названия из tools/list. Нужны только разработчикам.

resolve	Resolve any AT Protocol identifier to JSON. Accepts an at:// URI (at://<did-or-handle>/<collection>/<rkey>), a bare handle (alice.bsky.social), or a DID (did:plc:...). Returns a profile, a collection page, or a single record depending on how specific the input is. PDS-agnostic: works for any AT Protocol PDS, not just Bluesky.
get_profile	Get an account's repository overview (handle, DID, PDS, and the list of collections it contains). Input is a handle or DID.
get_record	Fetch a single record by its full at:// URI (must include collection and rkey). Returns the record's value, CID, and resolved identity.
list_records	List records in a collection for an account, with pagination. Provide the repo (handle or DID) and the collection NSID (e.g. app.bsky.feed.post).
get_backlinks	Index of who/what references a target,the inbound likes, reposts, quotes, replies, and follows,as COUNTS per category, via the Constellation backlink index. Target is a record's at:// URI or an account DID. This returns aggregate counts only; each category also includes a `source` string. To list the actual records and their author DIDs for one category (e.g. WHO liked a post), call list_backlink_records with that `source`.
list_backlink_records	List the actual records (author DID + verified handle + at:// URI, newest first) that reference a target for ONE category,i.e. WHO liked, reposted, quoted, replied to, mentioned, or follows it. Workflow: call get_backlinks first to get a category `source`, then pass it here. To read WHAT a referencing record says (e.g. the text of a mention or reply), call get_record on its at:// URI. Author handles are resolved via identity resolution (verified), not search.
count_records	Count the total records in an account's collection (e.g. how many likes a user has given). Scans server-side so you don't page manually. AT Protocol has no cheap exact count, so for very large collections this returns exact:false with a lower-bound count and a cursor,call again with that cursor and ADD the counts to keep going.
search_accounts	Search for AT Protocol accounts by handle or display name (paginated, via the Bluesky AppView app.bsky.actor.searchActors, so accounts unknown to that index may be missing). Returns candidate accounts with DID + handle, to turn a name into a DID. Results are search CANDIDATES, not verified handle-to-DID mappings: call verify_handle before trusting that a handle really belongs to a DID (resolve/get_profile only confirm an account exists, not that the handle is authentic).
get_account_history	An account's history from its PLC audit log: handle changes, PDS migrations, signing-key rotations, and creation time. did:plc accounts only (did:web has no PLC log). Input is a handle or DID.
search_lexicons	Browse or search the registry of published AT Protocol lexicon schemas. The response's `total` field is the exact registry size and `matched` is the exact match count. Substring matches the NSID or description (query 'profile' → anything containing 'profile'); prefix the query with a DOT for a suffix match (query '.profile' → only NSIDs ENDING in .profile, i.e. profile record types). Filter by schema kind with `type` — 'give me every space lexicon' is type='space' with NO query, since an NSID does not imply its type (space.saebyeok.permissionSet is a permission set; app.kimbia.circle is a space). Types: the spec's primary types are record, query, procedure, subscription, and permission-set; a main def may also be a non-primary type (object, token, string); space comes from proposal 0016 (permissioned data), which is not in the ratified spec; defs-only marks a schema file with no main definition. Every response carries a `typeCounts` breakdown of the returned matches (it sums to `matched`), so one call with no arguments shows which kinds exist and how many; when you filter by type, `otherTypes` reports what the filter excluded, so a too-narrow or misspelled type still shows you the real options. Without a query or type, returns the total plus a sample. Results are paginated by `limit`; to see matches beyond the first page, call again with the `offset` printed at the end of the list. Use resolve_lexicon for a specific schema's full definition.
resolve_lexicon	Explain what a record type means by resolving its lexicon schema. Input is a collection NSID (e.g. app.bsky.feed.post). Returns the schema's description and definition.
describe_pds	Describe a Personal Data Server: its DID, whether registration requires an invite, the handle domains you can register there, and ToS/contact links. Works for any PDS, not just Bluesky. Input is the PDS origin (e.g. https://pds.example.com).
list_repos	List the accounts (repositories) hosted on a PDS, via com.atproto.sync.listRepos: each repo's DID and active/takedown status, paginated. Answers 'who is hosted on this PDS?' / 'how many accounts does this PDS have?'. By default returns DIDs only (one request, large page — best for counting); pass enrich=true to also resolve handles (slower, smaller page). Input is the PDS origin (e.g. https://pds.example.com). Works for any PDS.
get_repo_status	Liveness/moderation status of an account's repository: whether it is active, its current revision, and any takedown/suspended/deactivated/deleted state. Answers 'has @alice been taken down?' which get_profile can't. Input is a handle or DID.
get_latest_commit	The current head commit of an account's repository (com.atproto.sync.getLatestCommit): its commit CID and revision. The cheapest way to fingerprint a repo or detect whether it changed since you last looked, without downloading data. Complements get_repo_status (which has the rev but not the commit CID). Input is a handle or DID.
verify_handle	Bidirectionally verify that a handle is really owned by its DID, via DNS TXT and HTTPS well-known. Returns whether each method passed. Use this to check for impersonation/spoofing,search results and resolve give candidates, this gives cryptographic binding.
get_did_document	Fetch the raw DID document for any DID or handle: all aliases (alsoKnownAs), every service entry (PDS, labeler, custom AppView), and verification methods. Broader than get_profile, and works for did:web accounts. Input is a handle or DID.
get_app_link	Turn an at:// URI (or handle/DID) into shareable web links,a Bluesky/Blacksky app URL to open in a browser, plus the canonical PDS getRecord URL. Use when the user wants a clickable/pasteable link.
get_pds_directory_info	A cached health card for a PDS from pds.directory: version, DID, approximate user count, reachability, last-checked time, available domains, and which relays index it. Input is the PDS hostname (e.g. pds.example.com). Best-effort/cached data.
get_relay_directory_info	A cached overview of a relay from firehose.directory: counts of PDSes it indexes (total/active/offline/banned) and total accounts. Input is the relay hostname (e.g. bsky.network). Best-effort/cached data.
query_labels	What moderation labels a labeler has applied to a subject (com.atproto.label.queryLabels),e.g. 'has @alice or this post been labeled spam/nsfw/hidden by labeler X?'. Anonymous and service-agnostic: the labeler's own service endpoint is found from its DID document (no hardcoded aggregator). Subject is a DID/handle (account labels) or an at:// URI (record labels); labeler is the handle or DID of a labeler service (e.g. moderation.bsky.app).
list_repos_by_collection	Network-wide: which accounts publish a given collection/lexicon,e.g. 'who has an app.bsky.feed.generator (a custom feed)?' or who uses a custom lexicon. Via a relay's com.atproto.sync.listReposByCollection (anonymous). By default returns DIDs only (one request, large page); pass enrich=true to also resolve handles (slower, smaller page). For just a total, use count_repos_by_collection. NOTE: relay-served (defaults to the public Bluesky relay; pass `relay` to query another), not the account's own PDS. Pairs with search_lexicons / resolve_lexicon.
count_repos_by_collection	Count how many accounts across the network publish a given collection/lexicon,e.g. 'how many accounts have an at.glean.subscription?'. Walks a relay's com.atproto.sync.listReposByCollection with NO per-account handle resolution, so it's cheap and returns an exact total for typical collections. For very large collections it returns exact:false with a cursor,call again with that cursor and ADD the counts (like count_records). Relay-served (defaults to the public Bluesky relay; pass `relay` for another).
list_blobs	List the blobs (uploaded media/attachments,images, video, etc.) hosted in an account's repository, via com.atproto.sync.listBlobs. Returns each blob's CID and its canonical PDS getBlob URL (PDS-native, works for any PDS,not a CDN). Answers 'what media does this account host?'. Records reference blobs by CID; use this (or get_blob_info) to turn a CID into a fetchable URL. Input is a handle or DID.
get_blob_info	Get metadata for a single blob: its canonical PDS getBlob URL plus a best-effort content-type and byte size (via a HEAD request). Returns the URL, never the bytes. Use to turn a blob ref (CID) found in a record into a downloadable link and learn what it is. Input is the owning repo (handle or DID) and the blob CID.
list_labelers	List the labeler (moderation) services known to the labeler relay,each labeler's DID, resolved handle, and service endpoint. The discovery step BEFORE query_labels, which needs a labeler DID/handle up front: use this to find moderation.bsky.app and any third-party/regional labelers, then pass one to query_labels.
get_thread	Reconstruct the conversation around a post: its ancestor chain up to the thread root (following reply.parent, root-first) PLUS a bounded descendant reply TREE,replies, replies-to-replies, and so on, each tagged with its depth and parent,walked breadth-first and capped for cost. NOTE: descendant expansion assumes the Bluesky reply model (app.bsky.feed.post with reply.parent); ancestor walking follows reply.parent generically, but the reply tree is specific to that lexicon and will be empty for record types that model replies differently. Answers 'show me this whole conversation / what is this replying to?'. If the tree is truncated, use list_backlink_records on a specific post's URI to expand it further. Input is a post's at:// URI.