The ATProto MCP Server provides both public read‑only and authenticated write access to Bluesky and the AT Protocol.
Public operations (no credentials needed):
get_profile – Fetch detailed profile information.
resolve_handle – Resolve a Bluesky handle to its DID.
search_posts – Search public posts (up to 100 results).
get_author_feed – Retrieve an author’s post feed (paginated).
get_post_thread – Get a post and its conversation thread.
get_suggestions – Suggested accounts to follow.
get_actor_likes – View posts an actor has liked.
get_followers / get_follows – List followers/following.
Authenticated operations (requires Bluesky credentials):
get_timeline – Access your personal timeline.
create_post / delete_post – Create or delete posts.
follow / unfollow – Follow or unfollow accounts.
like / unlike – Like or unlike posts.
Cursor‑based pagination is supported for feeds and lists, accepting a cursor from a previous response for seamless traversal.
Provides tools for interacting with the AT Protocol ecosystem, enabling profile retrieval, social discovery, and feed fetching for Bluesky.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ATProto MCP Server find posts about AT Protocol"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives compatible clients access to Bluesky and the AT Protocol over stdio. It works without credentials for public reads and enables account actions when Bluesky credentials are configured.
Independent project; see the trademark notice.
Public tools: get_profile, resolve_handle, search_posts, get_author_feed, get_post_thread, get_suggestions, get_actor_likes, get_followers, and get_follows.
Authenticated tools: get_timeline, create_post, delete_post, follow, unfollow, like, and unlike.
Cursor-based tools accept the cursor returned by a previous response. Write operations use AT URIs (and, for likes, the target CID) so callers can safely refer to exact records.
Related MCP server: bluesky-mcp
Requires Node.js 20 or newer.
npm install
npm run build
npm startThe default read-only endpoint is https://public.api.bsky.app. To use another service, set BSKY_SERVICE.
For authenticated tools, set BSKY_HANDLE and BSKY_PASSWORD. A Bluesky app password is recommended instead of the account password. When credentials are present, the default service changes to https://bsky.social.
Build the project first, then add it to your client's MCP configuration:
{
"mcpServers": {
"atproto": {
"command": "node",
"args": ["/absolute/path/to/atproto-mcp-server/build/index.js"],
"env": {
"BSKY_HANDLE": "alice.bsky.social",
"BSKY_PASSWORD": "xxxx-xxxx-xxxx-xxxx"
}
}
}
}Omit env for read-only use. The server writes logs to stderr, leaving stdout reserved for MCP messages.
npm testThe tests build the TypeScript project and validate that the advertised MCP tool surface is backed by handlers, including argument validation and AT Protocol request mapping.
If you find this project useful, consider supporting its development:
Retrieve the post feed for a specific author.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Handle or DID of the author. | |
| limit | No | Number of feed items to return (default 50). | |
| cursor | No | Pagination cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits like read-only nature, rate limits, authentication needs, or any side effects. Minimal transparency beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. However, lacks structural elements like examples or separate sections. Efficient but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return format, pagination behavior (despite cursor parameter), error conditions, or content of the feed. Incomplete for a feed retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), but description does not add extra meaning beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('Retrieve') and resource ('post feed') with scope ('for a specific author'). Differentiates well from sibling tools like get_post_thread, get_profile, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. Does not indicate when to use this tool versus alternatives, nor any context about prerequisites or scenario suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific post and its surrounding conversation thread.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | AT URI of the post. | |
| depth | No | How many levels of replies to include (default 6). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action without mentioning read-only nature, authentication needs, rate limits, or any side effects. The minimal disclosure leaves agents guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally mention what is returned (e.g., post object, thread structure). It is adequate for a simple retrieval but leaves completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions in the schema are clear. The tool description adds no extra meaning beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific post and its thread, which is a specific verb+resource combination. It is easily distinguished from siblings like get_author_feed or get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a post and its thread, but provides no explicit when-to-use, when-not-to-use, or alternatives. Usage context is only implicitly suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed profile information for a Bluesky actor (handle or DID).
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | The handle or DID of the user to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the purpose but does not disclose what 'detailed' means, response format, rate limits, or any side effects. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the key action and resource. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema), the description provides the minimum viable purpose. However, it lacks details about response format, error handling, or examples, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'actor' as 'The handle or DID of the user to fetch.' The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'detailed profile information', and the actor type 'handle or DID'. It effectively distinguishes from sibling tools like get_author_feed or resolve_handle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives, or when not to use it. For a simple retrieval tool, purpose implies usage but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get suggested actors to follow.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of suggestions (default 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It fails to mention how suggestions are generated (e.g., based on user history, trending), whether it's safe/idempotent, or any state changes. Only the basic purpose is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks detail. It is not overly long, but could be more informative without becoming verbose. Adequate structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the basic purpose. However, it omits context like the source of suggestions, frequency of updates, or typical use cases, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (limit) documented. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves suggested actors to follow, with a specific verb and resource. It distinguishes from siblings like get_author_feed or search_posts, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as searching for users or browsing feeds. The description does not provide context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Bluesky handle to its persistent Decentralized Identifier (DID).
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The handle to resolve (e.g., 'atproto.com'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as authentication requirements, caching behavior, or error handling for the resolution process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and concise, containing no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is nearly complete but could mention that the return is a DID string for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the description adds no extra meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resolve) and the resource (Bluesky handle to DID), distinguishing it from sibling tools like get_author_feed which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool vs. siblings, but the simple nature of handle resolution makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for public posts on Bluesky using keywords or phrases.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query string. | |
| limit | No | Number of posts to return (default 25, max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only states the basic action, but fails to disclose any behavioral traits like authentication requirements, result ordering, rate limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is concise, though it could be slightly expanded without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should provide more context about what the tool returns, any required auth, or usage limits. It does not, leaving the agent underinformed for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description's mention of 'keywords or phrases' adds minimal value beyond the schema's 'Search query string.' Baseline 3 applies; no additional semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'public posts on Bluesky', with the method 'using keywords or phrases'. It distinguishes from sibling tools like get_author_feed and get_post_thread, which are for specific feeds or threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search vs alternatives (e.g., get_author_feed for a specific user's posts). No when-not or contextual hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_author_feedget_post_threadget_profileget_suggestionsresolve_handlesearch_postsEach tool targets a distinct aspect of the AT Protocol: feed, thread, profile, suggestions, handle resolution, and search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores, using verbs like get, resolve, and search paired with specific nouns.
With 6 tools, the server is appropriately scoped for its purpose, covering key read operations without being excessive or insufficient.
The tools cover common read and query operations for Bluesky, but lack write capabilities (e.g., posting, following), which may be intentional but leaves a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for interacting with the Supabase platform
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Trust, freshness, policy, and discovery layer for public MCP servers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ewanc26/atproto-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
