An MCP server that resolves a company domain to its X (Twitter) handle, profile URL and follower metrics. It wraps the Mamba Labs X Twitter Brand Presence Mapper actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-company-contact-details-extractor
Give it a company domain and it returns that company's official X handle and profile URL, with the follower, following and post counts, verification status, bio and account creation date where X serves them. One flat row per company.
It runs keyless out of the box. X rate limits the public route aggressively, so on a large batch some rows come back with the handle and URL populated and the counts marked not_extractable. Supplying your own X API bearer token removes that limit and returns full metrics at any batch size. The key raises effectiveness rather than unlocking the tool.
A guessed handle that fails the identity check is reported as identity_mismatch rather than returned as the company's. 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-x-brand-presence-mapper": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-x-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_x_brand_presence tool will be available.
Node.js 18 or newer
An Apify account with an API token
Optional: your own X API v2 bearer token, free to create at developer.x.com, if you want full metrics on a large batch
"Find the X account for shopify.com and give me its follower count."
"What is the X handle for stripe.com, and when was the account created?"
"Resolve the X profile URL for figma.com without fetching follower counts."
"Look up the X handle Shopify and return the bio and post count."
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): the X handle with or without the leading @, for example Shopify. Supplying it skips discovery and goes straight to the fetch.
includeFollowerCounts (optional): when true (the 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.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
xApiBearerToken (optional): your own X API v2 bearer token, free to create at developer.x.com. Without one the tool still resolves handles, profile URLs and follower counts, but X rate limits the public route so some rows in a large batch return not_extractable instead of counts. Your token is used for your run only, is never stored, and is never shared with another run.
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 x_status first: ok, not_found, not_extractable and identity_mismatch are different answers and the wrapper never collapses them. x_fetch_route says which route produced the counts and x_discovery says how the handle was found. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "shopify.com",
"company_name": "Shopify",
"x_url": "https://x.com/Shopify",
"x_handle": "Shopify",
"x_followers": 452243,
"x_followers_exact": true,
"x_following": 3423,
"x_tweet_count": 37167,
"x_verified": false,
"x_display_name": "Shopify",
"x_bio": "The entrepreneurship company",
"x_created_at": "2008-11-03T18:33:14.000Z",
"x_fetch_route": "syndication",
"x_discovery": "homepage_sameas",
"x_status": "ok",
"run_date": "2026-08-22T19:23:45.055Z"
}Resolves an official X handle and profile URL starting from a company domain
Follower, following and post counts, plus verification status
Account creation date, bio and display name
Runs keyless, with your own X API key available for scale
Domain first discovery from the homepage sameAs markup
The fetch route is reported per row in x_fetch_route
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/x-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 X Twitter Brand Presence Mapper, immutable Apify actor ID oLOgadhHUkNAyDA3w.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Resolve a company domain to that company's official X (Twitter) handle and profile URL, with follower count, bio and account age where X serves them. Returns one flat Clay ready row. Runs keyless out of the box and X rate limits that route aggressively, so on a large batch some rows return the handle and URL with the counts marked not_extractable; supplying your own X API bearer token removes that limit and returns full metrics at any batch size. A guessed handle that fails the identity check is reported as identity_mismatch rather than returned as the company's. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Optional. The X handle with or without the leading @, for example Shopify. Supplying it skips discovery and goes straight to the fetch. | |
| 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. | |
| xApiBearerToken | No | YOUR OWN X API v2 bearer token, free to create at developer.x.com. OPTIONAL: leave it empty and the actor still resolves handles, profile URLs and follower counts, but X rate limits the public route so on a large batch some rows return not_extractable instead of counts. Supplying a token removes that limit and every row returns full metrics. Your token is used for your run only, is never stored, and is never shared with another run. | |
| 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 readOnly/idempotent annotations, the description reveals rate-limit behavior, partial-result fallbacks (not_extractable), identity-mismatch handling, and the need for APIFY_TOKEN/credit consumption. It also discloses that results can vary by batch size and token presence. This is substantial behavioral context that annotations alone do not provide.
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 dense but well organized: purpose and output first, then rate-limit/token trade-off, then failure semantics, then auth/cost. It is slightly longer than strictly necessary and repeats the read-only hint already present in annotations, but each sentence adds meaningful operational 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?
With no output schema, the description compensates by naming the returned fields, the row shape, and the main failure modes. It could more explicitly state what happens when no X account is found for a domain, but it notes conditional availability ('where X serves them') and covers identity_mismatch, so it is largely 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%, so the input schema already documents all six parameters in detail. The description reinforces the bearer token trade-off and the identity-check role of company_name, but it does not need to add much beyond what the schema states. Baseline 3 is appropriate because the schema carries the semantic load.
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 and resource: resolving a company domain to the official X handle and profile URL, and lists the returned fields (follower count, bio, account age). It also names the output shape ('one flat Clay ready row'), so an agent knows exactly what the tool produces. No siblings exist, but the scope is precise enough to stand alone.
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 gives actionable context: keyless operation, when to supply an X API bearer token, and the large-batch consequence of rate limiting (not_extractable). It also communicates the cost requirement (APIFY_TOKEN and Apify credits) and the identity-check failure mode. It does not discuss alternatives because there are no sibling tools, but it clearly orients the agent on when to adjust behavior.
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_x_brand_presenceScored across 1 tool
The set contains a single tool, so there is no possible confusion between tools. Its purpose—resolving a domain to an X (Twitter) profile—is specific and distinct. An agent will not misselect because there are no alternatives.
The sole tool uses a clear verb-object pattern: 'map' + 'x_brand_presence'. It is descriptive and free of any naming style conflicts since no other tools exist. Consistency is trivially maintained.
A single tool perfectly matches the server's narrow stated purpose of mapping X brand presence. The tool is substantial, with configuration and error handling, not a trivial stub. This is an appropriate, well-scoped size for a focused microserver.
For a read-only domain-to-X lookup, the tool covers all core needs: resolving the handle, verifying identity, returning metrics, and managing rate-limit outcomes. It also supports optional authentication for full metrics. No obvious missing operations exist for this specific task.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
MCP server for Tomba email finder, verification, and contact enrichment API
Apify MCP — run web-scraping Actors and fetch their dataset results.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
