Resolves a company domain to its official Bluesky account and returns profile details such as handle, DID, follower/following/post counts, display name, and creation date.
An MCP server that resolves a company domain to its Bluesky account with exact follower, following and post counts. It wraps the Mamba Labs Bluesky Brand Presence Mapper actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-legal-entity-resolver
Give it a company domain, or a Bluesky handle if you already have one, and it finds that company's official Bluesky account through the public AT Protocol API. It returns the profile URL, handle, DID, exact follower, following and post counts, display name, bio and account creation date, as one flat row.
The counts are exact rather than rounded. When the resolved handle is the company domain itself, Bluesky granted that handle only after a DNS check the company had to pass, and the row flags that as the strongest identity evidence the platform offers. A company with no Bluesky account returns not_found, which is a real and common answer rather than a failure.
All of the lookup runs on Apify. This package is a thin client that calls the actor and hands back the result unchanged.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-bluesky-brand-presence-mapper": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-bluesky-brand-presence-mapper"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The map_bluesky_brand_presence tool will be available.
Node.js 18 or newer
An Apify account with an API token
"Find the Bluesky account for theverge.com and give me its follower count."
"Does shopify.com have a Bluesky account, and is the handle domain verified?"
"Look up the Bluesky handle theverge.com and tell me when the account was created."
"Map the Bluesky presence for npr.org without using Bluesky account search."
company_domain (optional): bare company domain, for example shopify.com. Supply this or a handle. With a domain the actor runs full discovery; with a handle it skips straight to the fetch.
company_name (optional): improves search accuracy and is what the identity gate checks a discovered profile against, so supplying it reduces wrong matches.
handle (optional): a Bluesky handle such as shopify.com, mamba.bsky.social, or a DID. Supplying it skips discovery entirely. A company that has verified its domain with Bluesky uses the bare domain as its handle, which is why this often equals company_domain.
includeFollowerCounts (optional): when true (the default) the profile is fetched and the counts are extracted. Set false to resolve the profile URL only, which is cheaper.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
useActorSearch (optional): when true (the default) and the domain is not itself a verified handle, Bluesky's own account search is used. Set false to rely only on the company homepage and the domain as handle, which avoids any chance of matching a similarly named account.
Supply either company_domain or handle.
The tool returns the actor's flat JSON row for the company, with 18 snake_case fields and no nested objects. Read bluesky_status before reading any count: ok, not_found, not_extractable, blocked, identity_mismatch, auth_failed or skipped are different answers and the wrapper never collapses them. bluesky_discovery says which route found the account, from domain_handle (strongest) down to pattern_guess. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "theverge.com",
"company_name": "The Verge",
"bluesky_url": "https://bsky.app/profile/theverge.com",
"bluesky_handle": "theverge.com",
"bluesky_did": "did:plc:7exlcsle4mjfhu3wnhcgizz6",
"bluesky_domain_verified": true,
"bluesky_followers": 357220,
"bluesky_following": 141,
"bluesky_posts": 14584,
"bluesky_followers_exact": true,
"bluesky_display_name": "The Verge",
"bluesky_created_at": "2023-05-23T19:11:25.009Z",
"bluesky_discovery": "domain_handle",
"bluesky_status": "ok",
"run_date": "2026-08-22T19:26:58.474Z"
}Resolves a brand Bluesky account starting from a company domain
Exact follower, following and post counts, not rounded
Stable DID returned alongside the handle, so an account can be tracked over time
Domain verification status, which Bluesky grants only after a DNS check
Account creation date, so a new presence is distinguishable from an established one
The discovery route is reported on every row in bluesky_discovery
18 flat snake_case fields, one row per company
This server is a thin client and holds no lookup logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/bluesky-brand-presence-mapper
This server is one of the Mamba Labs GTM Suite MCP servers. Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything. The actor behind this server is the Bluesky Brand Presence Mapper, immutable Apify actor ID eLpxzP4IuXznlFVND.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Resolve a company domain, or a Bluesky handle, to that company's official Bluesky account through the public AT Protocol API. Returns the profile URL, handle, DID, exact follower, following and post counts, display name, bio and account creation date, as one flat Clay ready row. Counts are EXACT here, not rounded, unlike every other platform in this family. When the resolved handle IS the company domain, Bluesky granted it after a DNS check the company had to pass, and the row flags that as the strongest identity evidence available. A company with no Bluesky account returns not_found, which is a real and common answer. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Optional. A Bluesky handle such as shopify.com, mamba.bsky.social, or a did. Supplying it skips discovery entirely and goes straight to the profile fetch. A company that has verified its domain with Bluesky uses the bare domain as its handle, which is why this often equals company_domain. | |
| skipCache | No | When "false" (default) a successful lookup is cached for seven days and reused. Set "true" to force a fresh fetch. Sent as a string for Clay compatibility. | |
| company_name | No | Optional. Improves search accuracy and is what the identity gate checks a discovered profile against, so supplying it reduces wrong matches. | |
| company_domain | No | Bare company domain, for example shopify.com. Supply this or a handle. With a domain the actor runs full discovery; with a handle it skips straight to the fetch. | |
| useActorSearch | No | When "true" (default) and the domain is not itself a verified handle, Bluesky's own account search is used to find the company. Set "false" to rely only on the company homepage and the domain as handle, which avoids any chance of matching a similarly named account. Sent as a string for Clay compatibility. | |
| includeFollowerCounts | No | When "true" (default) the profile page is fetched and the counts are extracted. Set "false" to resolve the profile URL only, which is cheaper and needs no proxy. Sent as a string for Clay compatibility. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description goes further by disclosing that it consumes Apify credits and requires an APIFY_TOKEN, that successful lookups are cached for seven days, that counts are exact rather than rounded, and that a missing Bluesky account returns not_found. 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?
The description is a compact set of sentences, each earning its place: purpose, output shape, exactness caveat, DNS-evidence nuance, not_found expectation, and operational requirements. It is front-loaded with the core purpose and avoids nested jargon. Slightly dense but still efficient.
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?
With no output schema, the description compensates by enumerating the returned fields (profile URL, handle, DID, counts, display name, bio, creation date) and the flat row format. It also covers auth requirements, credit consumption, caching behavior, and the not_found outcome. For a read-only resolver with six fully documented optional parameters, this is complete enough for an agent to call it correctly.
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%, so the baseline is 3. The main description adds useful context about the DNS-check meaning when a handle equals the company domain, but the individual parameter meanings are already fully documented in the schema. The description does not materially improve parameter understanding beyond that.
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 opens with a specific verb, 'Resolve', names the exact resource (a company's official Bluesky account), and states the mechanism (public AT Protocol API). It further clarifies output contents and highlights that counts are exact 'unlike every other platform in this family,' giving the tool a clear identity even without sibling names.
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 contextual usage guidance: it explains when discovery runs versus when a handle skips straight to fetch, and it prepares the agent for a common not_found result. It does not name explicit alternatives or when-not-to-use conditions, but with no sibling tools present, the context is still clear and actionable.
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.
v1.0.0map_bluesky_brand_presenceScored across 1 tool
With only one tool, there is no possibility of overlap or misselection. The tool name and description unambiguously define the single operation available.
The single tool uses a clear snake_case verb_noun pattern. There are no mixed conventions or inconsistent verbs to confuse an agent.
One tool is small but appropriate for this narrowly scoped read-only resolver. The tool covers domain-or-handle resolution in one call, so no extra tools are necessary.
The server's apparent purpose is to map a brand to its official Bluesky profile, and the tool returns all key identity and presence fields with exact counts. It also handles the not_found case, so there are no obvious dead ends.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Apify MCP — run web-scraping Actors and fetch their dataset results.
Hosted MCP server for live public-data APIs and Skills for AI agents.
