Resolves a company domain (or X handle) to that company's official X/Twitter presence — handle, profile URL, and public profile metrics — returned as one flat, Clay-ready JSON row.
Resolve the official X handle and profile URL for a company, starting from a bare domain like shopify.com (full discovery) or from a supplied handle like Shopify (skips discovery, goes straight to fetch).
Fetch follower, following, and post counts plus verification status, display name, bio, and account creation date — where X serves them.
Get the profile URL only by setting includeFollowerCounts to false — cheaper and needs no proxy.
Improve match accuracy by supplying company_name; it's what the identity gate checks discovered profiles against, reducing wrong matches.
Scale reliably with your own X API v2 bearer token (xApiBearerToken) — without it, keyless runs are rate limited by X and some rows in a large batch return not_extractable instead of counts. Your token is used for your run only, never stored or shared.
Control caching with skipCache — successful lookups are cached for seven days by default; set it to true to force a fresh fetch.
Cap spend with max_charge_usd, which stops the run before any charge that would exceed the cap while keeping already-charged rows.
Read status before trusting numbers — x_status distinguishes ok, not_found (no X account), not_extractable (rate limited), and identity_mismatch (guessed handle failed the gate); the wrapper never collapses these. x_fetch_route shows which route produced the counts and x_discovery shows how the handle was found.
Per-row cost events on your own Apify account: company-checked, profile-resolved, and follower-count-extracted (which does not fire on rate-limited rows).
Note: this is a read-only, thin client — it requires an APIFY_TOKEN, consumes Apify credits per call, and holds no lookup logic of its own.
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.
max_charge_usd (optional): spending cap for this call, in USD. The actor stops before any charge that would take the run past this amount and keeps every row already charged.
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
You pay per event on Apify, billed to your own Apify account. Prices from the live pricing record, read 2026-10-16:
Event | Price per event (USD) | Fires when |
| $0.00005 | Charged when the Actor starts running. Number of events charged depends on Actor memory (one event per GB, minimum one event). |
| $0.0035 on the Free plan, down to $0.00245 on higher Apify plans | Once per company for which the discovery cascade completed and a non degraded row was produced, whether or not an X account was found. Does not fire on a degraded row, because on a degraded row no discovery was performed. |
| $0.003 on the Free plan, down to $0.0021 on higher Apify plans | Once per company whose candidate X URL passed the identity gate. Fires on the validation work, not on a populated count. This is the event that carries the actor in keyless mode, because handle resolution succeeds whether or not X served a count. |
| $0.0025 on the Free plan, down to $0.00175 on higher Apify plans | Once per company where a numeric follower count was actually read, from either route. A rate limited row does not fire it and is not charged for the count, which is deliberate: an event firing on a not_extractable row would be charging for the string not_extractable. |
The actor's Apify page carries the current prices. Running this server consumes Apify credits.
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, and a company with no X account reports x_status not_found. Read x_status before any count. 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?
Goes well beyond the readOnly/idempotent annotations by disclosing keyless operation, aggressive X rate limiting on large batches, the not_extractable degradation, identity_mismatch on failed identity checks, x_status not_found for absent accounts, the APIFY_TOKEN requirement, and per-call credit consumption.
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 and return shape are front-loaded, and every sentence carries operational information. It is somewhat dense and repeats the token/rate-limit story already present in the xApiBearerToken schema description, which is the only real waste.
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 and all six parameters optional, the description supplies the missing pieces: return shape, failure statuses, auth/credit requirements, and caching behavior. An agent has everything needed to call it and interpret results.
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 baseline is 3, but the description adds meaning the schema doesn't: the handle path skips discovery, company_name drives the identity gate that produces identity_mismatch, and the token removes the rate limit. These tie parameters to observable outcomes rather than restating field docs.
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?
Opens with a specific verb+resource+output: 'Resolve a company domain to that company's official X (Twitter) handle and profile URL, with follower count, bio and account age'. It also states the return shape ('one flat Clay ready row'), so the agent knows exactly what the tool produces.
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 conditional guidance: supplying a handle skips discovery, a domain runs full discovery, and 'Read x_status before any count' tells the agent how to consume results. No siblings exist to differentiate against, and it doesn't explicitly say when not to use the tool, so it falls short of a 5.
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_x_brand_presence1 field changedInput schema / additionalPropertiesRemoved value: -falsev1.0.0map_x_brand_presenceScored across 1 tool
There is only one tool, so there is no possibility of misselection or overlapping purpose. Its scope (domain → X handle/profile) is unambiguous from the name and description.
The single tool follows a clear verb_noun convention (map_x_brand_presence) in snake_case, matching the server name's domain. No inconsistency is possible with one tool, and the name is descriptive rather than vague.
One tool is thin for a server, though it is a substantive, focused operation rather than a trivial wrapper. A richer surface (e.g. reverse handle→domain lookup or batch helpers) would justify the server better.
For its narrow stated purpose, the tool covers the core lookup with thoughtful edge-case statuses (not_extractable, identity_mismatch, x_status not_found). Minor gaps exist, such as no reverse lookup or multi-platform presence mapping, but the essential operation is fully covered.
Official twitterapi.io hosted MCP: Twitter/X tweets, users, followers, trends. OAuth or API key.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
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
MCP server for Tomba email finder, verification, and contact enrichment API
