bluesky-mcp-server
Server Details
Search posts, profiles, feeds, threads, and trending topics on Bluesky.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Each tool targets a distinct aspect of Bluesky: user feed, social graph, thread, profile, trending, actor search, and post search. No overlap in functionality.
All tools follow a consistent 'bsky_verb_noun' pattern with underscores, e.g., bsky_get_author_feed, bsky_search_posts. No deviations.
7 tools is well-scoped for a Bluesky server, covering key read operations without redundancy. The count is appropriate for its purpose.
Covers essential read operations: profile, feed, thread, search, trending, and graph. Minor gaps like missing dedicated followers/following separation or write operations, but adequate for a read-oriented server.
Available Tools
7 toolsbsky_get_author_feedGet Bluesky Author FeedARead-onlyIdempotentInspect
Get a Bluesky user's recent posts ordered newest-first. Filter by post type: "posts_with_replies" (everything), "posts_no_replies" (original posts only), "posts_with_media" (posts with images or links), or "posts_and_author_threads" (posts the author started). Returns posts with full text, engagement counts, embeds, and AT-URIs for drilling into threads via bsky_get_post_thread. Supports cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Handle (e.g. "alice.bsky.social") or DID of the author whose feed to fetch. | |
| limit | No | Maximum number of posts to return (1–100). Default 25. | |
| cursor | No | Opaque pagination cursor from a previous response. Omit for the first page. | |
| filter | No | Filter for post types: "posts_no_replies" for original posts only, "posts_with_replies" for everything, "posts_with_media" for posts with images/links, "posts_and_author_threads" for threads the author started. | posts_no_replies |
Output Schema
| Name | Required | Description |
|---|---|---|
| posts | Yes | Posts from this author, ordered newest-first. |
| cursor | No | Opaque cursor for the next page. Absent on the last page. |
| notice | No | Guidance when the result set is empty or constrained. |
| totalReturned | Yes | Number of posts in this response page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral details: newest-first ordering, filter semantics, return contents (full text, engagement counts, embeds, AT-URIs), and cursor pagination support.
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 well-structured sentence that front-loads the main action, then concisely explains filters and output. Every word adds value with no redundancy.
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 rich annotations and presence of an output schema, the description provides sufficient context for an AI agent to select and invoke the tool correctly, including pagination and filter options.
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%, but the description adds significant meaning beyond the schema, explaining each filter value in detail and mentioning output fields. It also clarifies cursor usage and limit range.
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 gets a Bluesky user's recent posts ordered newest-first, specifying the resource (user feed) and verb (get). It distinguishes from sibling tools by mentioning bsky_get_post_thread for drilling into 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?
The description provides clear context for when to use the tool, including filter options. While it hints at alternatives (e.g., bsky_get_post_thread), it does not explicitly state when not to use this tool or compare with other siblings like bsky_search_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_get_followsGet Bluesky Social GraphARead-onlyIdempotentInspect
Fetch the social graph edges for a Bluesky account — who follows them, or who they follow. Returns paginated actor profiles (handle, DID, displayName, bio, follower count) plus a summary of the subject account. Accounts with large social graphs return only the first page; use cursor pagination to walk through the full list.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Handle (e.g. "alice.bsky.social") or DID of the account to query. | |
| limit | No | Maximum number of actors to return per page (1–100). Default 25. | |
| cursor | No | Opaque pagination cursor from a previous response. Omit for the first page. | |
| direction | Yes | "followers" returns accounts that follow this actor. "following" returns accounts this actor follows. |
Output Schema
| Name | Required | Description |
|---|---|---|
| actors | Yes | Actors in the requested direction of the social graph. |
| cursor | No | Opaque cursor for the next page. Absent on the last page. |
| notice | No | Guidance when the result set is empty or constrained. |
| subject | Yes | Profile summary of the queried actor. |
| totalReturned | Yes | Number of actors in this response page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by disclosing the return format (paginated actor profiles with specific fields plus a summary) and the pagination behavior. There is no contradiction.
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 two sentences, front-loaded with the core purpose, and contains no extraneous words. Every sentence provides essential 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 presence of an output schema and 4 parameters, the description covers the return value (paginated profiles and summary) and pagination behavior. It is complete enough for an agent to understand how to use the 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?
With 100% schema coverage, the schema already describes all parameters. The description does not add parameter-level details beyond what the schema provides, so baseline 3 is appropriate. It indirectly mentions pagination which relates to the cursor parameter.
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 fetches social graph edges (followers/following) for a Bluesky account, with a specific verb 'Fetch' and resource 'social graph edges'. It distinguishes from sibling tools like bsky_get_profile (single profile) or bsky_search_actors (search) by specifying the relational direction.
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 implicitly gives usage guidance by noting pagination: accounts with large graphs return only the first page, and cursor pagination should be used. It does not explicitly list when to use this tool vs siblings, but the context is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_get_post_threadGet Bluesky Post ThreadARead-onlyIdempotentInspect
Fetch the full conversation for a post by AT-URI — the parent chain upward and the reply tree downward. Enter the thread at any point and traverse the full discussion. AT-URIs have the format "at:////" and are returned by bsky_search_posts and bsky_get_author_feed in the "uri" field of each post. Returns the root post, parent chain, and nested replies with per-post author and engagement data. "truncated: true" on a reply node means there are more replies below — increase depth to load them.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | AT-URI of the post to fetch, e.g. "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/abc123". Obtain from bsky_search_posts or bsky_get_author_feed. | |
| depth | No | How many levels of replies to include in the reply tree. Default 6. | |
| parent_height | No | How many parent posts to include in the parent chain above the target post. Default 80. |
Output Schema
| Name | Required | Description |
|---|---|---|
| thread | Yes | The conversation thread rooted at the requested post. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: describes return structure (root, parent chain, nested replies, author, engagement data) and truncated flag meaning. Aligns with readOnlyHint, idempotentHint, openWorldHint.
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?
Extremely concise, front-loads purpose, uses efficient clauses. Every sentence adds value. No redundancy.
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?
Complete for a thread fetch tool with output schema. Covers input parameters, return structure, truncation behavior, and how to obtain AT-URI from siblings.
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 baseline is 3. Description adds context on AT-URI format and depth use for truncation but does not significantly expand beyond schema descriptions.
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?
Clearly states verb 'Fetch', resource 'full conversation for a post', and distinguishes from sibling tools like bsky_search_posts. Specifies AT-URI format and how to obtain it.
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?
Explains entering at any point and traversing full discussion, and how to handle truncated replies by increasing depth. Not explicit about when not to use but context clear via sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_get_profileGet Bluesky ProfileARead-onlyIdempotentInspect
Fetch a Bluesky actor's public profile by handle (e.g. "bsky.app") or DID (e.g. "did:plc:z72i7hdynmk6r22z27h6tvur"). Returns displayName, handle, DID, bio, follower/following/post counts, avatar URL, moderation labels, and pinned post AT-URI. Use this as the first step to resolve a handle to a DID before calling tools that require a DID or AT-URI. Handles and DIDs are interchangeable as input.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Handle (e.g. "bsky.app", "alice.bsky.social") or DID (e.g. "did:plc:z72i7hdynmk6r22z27h6tvur") of the actor to look up. |
Output Schema
| Name | Required | Description |
|---|---|---|
| did | Yes | Decentralized Identifier — the permanent, portable identity key for this account. |
| avatar | No | URL of the profile avatar image. |
| handle | Yes | Human-readable username, e.g. "alice.bsky.social". |
| labels | No | Moderation labels applied to this profile. |
| createdAt | No | ISO 8601 timestamp of account creation. |
| indexedAt | No | ISO 8601 timestamp when the AppView last indexed this profile. |
| postsCount | No | Total posts authored by this actor. |
| description | No | Biography / about text. |
| displayName | No | Display name set by the user. May differ from the handle. |
| followsCount | No | Number of accounts this actor follows. |
| pinnedPostUri | No | AT-URI of the pinned post, if any. Pass to bsky_get_post_thread to read it. |
| followersCount | No | Number of accounts following this actor. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, open-world, and idempotent. The description adds value by detailing the return payload (displayName, bio, counts, etc.) and the resolution behavior, though it omits rate limits or auth context.
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?
Three sentences with no redundancy: action+input, return values, usage guidance. Front-loaded with the verb 'Fetch' for immediate clarity.
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?
Complete for a single-parameter tool with an output schema. It explains the tool's role relative to siblings and describes all key returned fields, leaving no 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?
The schema description covers 100% of the parameter, but the description reinforces it with examples and clarifies that both handles and DIDs are acceptable, adding practical value beyond the schema.
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 explicitly states it fetches a Bluesky actor's public profile by handle or DID, listing return fields. It distinguishes itself from siblings by positioning it as a handle-to-DID resolution step.
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 provides clear when-to-use guidance: first step for resolving handles to DIDs before calling dependent tools. It also notes that handles and DIDs are interchangeable, giving concrete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_get_trendingGet Bluesky Trending TopicsARead-onlyInspect
Fetch the current real-time trending topics on Bluesky. Returns topics with display name, post count, category (politics, sports, pop-culture, etc.), status (hot/rising), and start time. Entry point for "what is Bluesky talking about right now". Pair with bsky_search_posts to drill into any trending topic. Note: uses the app.bsky.unspecced.getTrends endpoint, which is not part of Bluesky's stable lexicon and may change without notice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of trending topics to return (1–25). Default 10. |
Output Schema
| Name | Required | Description |
|---|---|---|
| trends | Yes | Current trending topics, ordered by prominence. |
| totalReturned | Yes | Number of trending topics returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds critical context beyond annotations: the tool uses a non-stable endpoint (app.bsky.unspecced.getTrends) that may change without notice. No contradictions.
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 two sentences, front-loaded with the main purpose. Every sentence adds value: first states action and return fields, second gives usage context and stability warning. Efficient and well-structured.
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 tool has only one optional parameter, no required parameters, and an output schema exists, the description covers purpose, return fields, usage context, and stability limitations. No gaps for agent decision-making.
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% for the single parameter (limit). The description does not add any additional semantics beyond what the schema's description already provides (max 25, default 10). Baseline 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 it fetches real-time trending topics on Bluesky, specifying return fields (display name, post count, category, status, start time). It distinguishes itself from sibling tools by positioning itself as the entry point for 'what is Bluesky talking about right now' and suggesting pairing with bsky_search_posts.
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 provides explicit guidance on when to use this tool (as entry point for trends) and how to follow up (pair with bsky_search_posts). It also warns about the unstable endpoint, helping the agent decide if this tool is appropriate. It could be more explicit about alternatives but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_search_actorsSearch Bluesky ActorsARead-onlyIdempotentInspect
Find Bluesky accounts by name or handle fragment. Returns ranked profiles with handle, DID, displayName, bio, and follower count. Use before bsky_get_profile or bsky_get_author_feed when you have a name but not a confirmed handle. Supports cursor-based pagination for browsing beyond the first page of results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of actors to return (1–100). Default 25. | |
| query | Yes | Name or handle fragment to search for, e.g. "alice" or "nytimes.com". | |
| cursor | No | Opaque pagination cursor from a previous response. Note: the public Bluesky AppView restricts cursor-based search pagination for unauthenticated requests — passing a cursor may return a 403 error. Cursor pagination is reliable only for bsky_get_author_feed and bsky_get_follows. |
Output Schema
| Name | Required | Description |
|---|---|---|
| actors | Yes | Matching actor profiles, ranked by relevance. |
| cursor | No | Opaque cursor returned by the API. Unreliable for unauthenticated search requests on the public AppView — passing it on a subsequent call may return a 403 error. |
| notice | No | Guidance when the result set is empty or constrained. |
| totalReturned | Yes | Number of actors in this response page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds important behavioral details: returns ranked profiles, supports cursor-based pagination, and warns that the public Bluesky AppView may return 403 for unauthenticated cursor requests. No contradiction with annotations.
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?
Two sentences: first states purpose and return data, second gives usage guidance and pagination note. Every sentence earns its place; no redundant or vague phrasing.
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 tool with 3 parameters and an output schema, the description covers purpose, usage, behavioral quirks, and parameter semantics. The output schema exists, so return values are adequately described. Complete and self-contained.
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 baseline is 3. The description adds value by clarifying that 'query' is a name or handle fragment, giving default/max for 'limit', and warning about the cursor pagination caveat (403 error). These supplement the schema descriptions justifying a 4.
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 finds Bluesky accounts by name or handle fragment and lists the returned fields (handle, DID, displayName, bio, follower count). It distinguishes itself from siblings by advising use before bsky_get_profile or bsky_get_author_feed when only a name is known.
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?
Explicitly says when to use this tool ('when you have a name but not a confirmed handle') and identifies alternatives (bsky_get_profile, bsky_get_author_feed). Also notes the cursor pagination limitation, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsky_search_postsSearch Bluesky PostsARead-onlyIdempotentInspect
Full-text search across public Bluesky posts. Filters by author (handle or DID), language (BCP-47 code, e.g. "en"), hashtag (without the # prefix), date range (ISO 8601), and sort order. Returns posts with text, author info, engagement counts (likes/reposts/replies), normalized embeds, AT-URIs for thread drilling, and hitsTotal when the API reports the total number of matching posts. This is the primary entry point for social listening — pass any AT-URI from results to bsky_get_post_thread to read the full conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Hashtag to filter by — provide without the # prefix, e.g. "ai" not "#ai". | |
| sort | No | "latest" returns posts in reverse-chronological order (default). "top" returns by engagement score. | latest |
| limit | No | Maximum posts to return (1–100). Default 25. | |
| query | Yes | Full-text search query, e.g. "climate change" or "#ai announcement". | |
| since | No | Return posts after this ISO 8601 datetime (inclusive), e.g. "2025-01-01T00:00:00Z". | |
| until | No | Return posts before this ISO 8601 datetime (inclusive), e.g. "2025-12-31T23:59:59Z". | |
| cursor | No | Opaque pagination cursor from a previous response. Note: the public Bluesky AppView restricts cursor-based search pagination for unauthenticated requests — passing a cursor may return a 403 error. Cursor pagination is reliable only for bsky_get_author_feed and bsky_get_follows. | |
| language | No | BCP-47 language code to restrict results to, e.g. "en", "ja", "es". | |
| author_handle | No | Filter to posts by this author. Accepts handle (e.g. "bsky.app") or DID. Use bsky_get_profile to resolve a name to a handle first. |
Output Schema
| Name | Required | Description |
|---|---|---|
| posts | Yes | Posts matching the search query. |
| cursor | No | Opaque cursor returned by the API. Unreliable for unauthenticated search requests on the public AppView — passing it on a subsequent call may return a 403 error. |
| notice | No | Guidance when the result set is empty or constrained. |
| hitsTotal | No | Total number of posts matching this query across all pages, when reported by the API. Use to communicate result scale without fetching every page. |
| totalReturned | Yes | Number of posts in this response page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly, openWorld, and idempotent. Description adds valuable context: cursor pagination may return 403 for unauthenticated requests, and hitsTotal is conditional. No contradictions.
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?
Concise but thorough: one sentence for purpose, one for parameters, one for return data, one for usage guidance. No fluff, every sentence adds value.
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?
Covers return fields (text, author, engagement, embeds, AT-URIs, hitsTotal) and how to use results with sibling tools. Fully adequate given the presence of an output schema.
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?
With 100% schema coverage, baseline is 3. Description adds significant extra meaning: explains tag without '#', BCP-47 language codes, ISO 8601 date formats, cursor limitations, and limit range. Goes well beyond schema.
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 'Full-text search across public Bluesky posts' and lists filter options. It distinguishes from sibling tools by positioning itself as the primary entry point for social listening, with a clear path to drill into threads using bsky_get_post_thread.
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?
Explicitly states when to use this tool (social listening) and how to chain with bsky_get_post_thread. Also warns about cursor pagination limitations for unauthenticated requests and directs users to bsky_get_profile for name resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!