Resolve a company domain or Bluesky handle to its official Bluesky account and return a flat, Clay-ready profile row.
Look up Bluesky presence by company_domain or handle; a handle skips discovery and goes straight to the profile fetch.
Return a single flat row with 18 snake_case fields: profile URL, handle, DID, exact follower/following/post counts, display name, bio, account creation date, domain-verified flag, discovery route, and status.
Supply company_name to improve search accuracy and reduce wrong identity matches.
Set includeFollowerCounts to false to resolve only the profile URL, which is cheaper, instead of fetching counts.
Set skipCache to true to force a fresh fetch instead of using a 7-day cached result.
Set useActorSearch to false to avoid Bluesky account search and rely only on the company homepage and domain-as-handle evidence.
Handle real outcomes such as not_found and other statuses without treating them as failures.
Read-only; requires APIFY_TOKEN and consumes Apify credits per call.
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.
The tool starts the actor run and polls it to a finished status, so a long run is not cut off at 300 seconds. The run is allowed 1,800 seconds. If it is still going two minutes after that, the call stops waiting and returns the run ID with a link to it in the Apify Console, where the results land when it finishes. A run that does not succeed comes back as an error with its run ID and status.
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.
max_charge_usd (optional): a cost cap in USD for this run. The actor stops before an item that could take its charges past this amount. Omit it to rely on the maximum cost per run set in Apify.
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_bio": "The Verge covers the intersection of technology, science, art, and culture.",
"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
Price per event on the Apify FREE plan, from the live pricing record; paid Apify plans pay less per event.
Event | Price (USD) |
Actor Start ( | 0.00005 |
Company checked ( | 0.0035 |
Profile resolved ( | 0.003 |
Follower count extracted ( | 0.0025 |
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?
Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses the auth requirement (APIFY_TOKEN), the cost model (consumes Apify credits per call), the seven-day cache with skipCache override, and the meaningful failure mode (not_found is a real and common answer). That is exactly the contextual behavior an agent needs before spending credits.
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?
Purpose is front-loaded in the first sentence and the return payload is enumerated immediately after. The remaining sentences each add a distinct fact (exact counts, domain-handle identity evidence, not_found, auth/cost), though the description is longer than strictly necessary and the identity-evidence sentence could be tightened.
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 fully compensates by enumerating the returned fields (profile URL, handle, DID, counts, display name, bio, creation date) and the flat Clay-ready row shape. Auth requirements, cost, caching, and the not-found case are all present, so nothing an agent needs to call this correctly is missing.
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% and each parameter is already thoroughly documented, so the schema carries the load. The description adds mostly output-oriented context (exact vs rounded counts, the domain-as-handle identity signal) rather than new parameter-level meaning, so the baseline 3 fits.
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?
States a specific verb (resolve) plus both accepted inputs (company domain, Bluesky handle) and the target resource (the company's official Bluesky account), naming the underlying API. An agent immediately knows what comes in and what comes out, and there are no siblings to confuse it with.
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?
Gives clear conditional guidance: supply a domain for full discovery, a handle to skip straight to the fetch, and it explains the useActorSearch and includeFollowerCounts tradeoffs (cheaper, avoids similarly named matches). It lacks an explicit 'when not to use' statement, but with no sibling tools there is no alternative to route to, so the gap is minor.
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.1.1map_bluesky_brand_presence1 field changedInput schema / additionalPropertiesRemoved value: -falsev1.0.0map_bluesky_brand_presenceScored across 1 tool
There is only one tool, so there is no possibility of confusing it with another tool in this server. Its purpose is singular and clearly stated.
The sole tool uses a clear snake_case verb_noun pattern: map_bluesky_brand_presence. With only one tool, there are no naming conflicts or inconsistencies to evaluate.
A single tool is slightly thin for a server, but it is appropriately scoped for the specific operation of mapping one Bluesky brand account. It does not feel bloated or arbitrary.
The tool covers the core resolution and profile-metrics use case, including exact counts, identity evidence, and a not_found response. Minor gaps exist, such as batch lookups or broader brand-search operations, which agents would need to work around with repeated calls.
Hosted MCP server for DataLikers — Instagram & TikTok data API. 51 tools: Instagram user search by demographics (gender/age/race/country/city), profiles, bulk lookup, engagement, posts & reels, comments, hashtags, locations, stories, highlights, music, business accounts, top users; TikTok users, videos, comments, hashtags, playlists and top charts. Streamable HTTP, Bearer API key. Free tier: 100 requests on signup at https://datalikers.com/p/1by27bwg
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.
