mcp-meta-brand-presence-mapper
Instagram Threads Facebook Brand Presence Mapper MCP Server
MCP 服务器,用于 Apify 上的 Mamba Labs Instagram Threads Facebook Brand Presence Mapper actor。
将公司域名解析为它的 Instagram、Threads 和 Facebook 账号,并包含粉丝数和帖子数。
它能做什么
将公司域名解析为它的 Instagram、Threads 和 Facebook 账号,并返回粉丝数和帖子数,作为一条扁平、可直接导入 Clay 的记录。Threads 的 handle 由解析出的 Instagram 用户名直接得出,无需额外的发现成本。Instagram 和 Threads 的计数由 Meta 四舍五入,记录中同时包含四舍五入后的整数和平台自己的展示字符串。Facebook 是尽力而为:Meta 对匿名访客设置登录墙,因此 blocked 是该平台正常返回的答案,而绝不是零。该服务为只读;需要 APIFY_TOKEN,并且每次调用都会消耗 Apify Credits。
Related MCP server: mcp-domain-to-linkedin-url-resolver
快速开始
在你的 MCP 客户端配置中添加以下内容:
{
"mcpServers": {
"mamba-meta-brand-presence-mapper": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-meta-brand-presence-mapper"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}先决条件
Node.js 18 或更高版本
来自 console.apify.com/account/integrations 的 Apify API token
该 actor 按事件付费,每次调用消耗 Apify Credits。价格信息请actor 页面。
示例提示词
"获取 glossier.com 的 Instagram 和 Threads 粉丝数。"
"oatly.com 是否已采用 Threads?他们发布了几条帖子?"
"查找 everlane.com 的 Facebook 页面。"
工具与输入
工具:map_meta_brand_presence
输入 | 类型 | 含义 |
| string | 裸域名,例如 shopify.com。请提供此值或一个 handle。提供域名时,actor 会执行完整发现;提供 handle 时,它会直接跳转至 |
| string | 可选。提高搜索准确性,也是身份检查门锁定对已发现 profile 进行核对的依据,因此提供它可减少错误匹配。 |
| string | 可选。Instagram 用户名(可带或不带开头的 @)。提供它可跳过 Instagram 发现,并免费为 Threads 获得其 handle,因为 Th |
| array | 要映射三个 Meta 平台中的哪些。默认全部映射。放弃 Facebook 是常见选择:它是三者中最不可靠的,并且它 co |
| boolean | 当为“true”(默认)时,会获取并解析个人资料中的粉丝数。设置为“false”则仅解析个人资料 URL,成本更低且需要 |
| boolean | 当为“false”(默认)时,外部成功结果会被缓存并复用 7 天。设置为“true”会强制重新获取。以字符串形式发送以兼容 Clay compatibi |
解读输出
每行都包含一个按平台区分的 _status 字段,也是首先需要读取的字段。整个 Mamba Labs 社交产品线统一使用相同的词汇:
状态 | 含义 |
| 已抓取并解析,值已存在 |
| 我们查找过,但没有发现该 profile |
| profile 存在,但该值不在返回的数据中 |
| 平台拒绝了我们,是否有稍后重试的价值 |
| 找到了真实 profile,但它属于其他人 |
| 你没有请求此平台 |
false 和 null 永远不能互换。 false 表示我们查过,答案是“没有”;null 表示我们无法查询。如果你想筛选没有对应“存在”的公司,应筛选 false,因为 null 行代表“未知”,而非“缺失”。
完整的 actor 文档
apify.com/mambalabs/meta-brand-presence-mapper
Mamba Labs GTM Suite
Mamba Labs 构建了一套 GTM 数据增强 actor,它们共享统一的扁平化、直接可被 Clay 使用的输出格式,因此可以通过 company_domain 将各行连接在一起,无需清理步骤。完整工具集:apify.com/mambalabs
许可证
MIT
Available Tools
1 toolmap_meta_brand_presenceMap Instagram Threads and Facebook PresenceARead-onlyIdempotent
Resolve a company domain to its Instagram, Threads and Facebook accounts with follower and post counts, as one flat Clay ready row. The Threads handle is derived from the resolved Instagram handle at no extra discovery cost. Instagram and Threads counts are rounded by Meta and the row carries both the rounded integer and the platform's own display string. Facebook is best effort: Meta serves a login wall to anonymous clients, so blocked is a normal answer there and never a zero. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Optional. The Instagram handle with or without the leading @. Supplying it skips Instagram discovery AND gives Threads its handle for free, because Threads handles are Instagram handles (5 of 5 measured). | |
| platforms | No | Which of the three Meta surfaces to map. Default is all three. Dropping Facebook is the common choice: it is the least reliable of the three and it costs a fetch to find that out. | |
| 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. | |
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses several non-obvious behaviors: Threads handle is derived from Instagram at no extra cost, counts are rounded by Meta and include both integer and display string, Facebook is best-effort with login walls making 'blocked' a normal response, and each call consumes Apify credits. These are significant operational details an agent needs.
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 yet well-organized: the main purpose is stated first, followed by platform-specific caveats, then parameter behavior and operational constraints. Every sentence adds information and none are redundant with the schema or annotations. It is appropriately sized for the tool's complexity.
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?
Despite having no output schema, the description explains the output format (flat Clay row, rounded counts, display strings), failure modes (Facebook 'blocked'), and prerequisites (APIFY_TOKEN, credits). It also covers pricing implications and caching semantics, making it fully self-sufficient for an agent to call 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?
Although schema coverage is 100%, the description adds valuable context: the handle is used for both Instagram and Threads ('5 of 5 measured'), platforms can be pruned to reduce cost, cache duration is seven days, and includeFollowerCounts trades completeness for speed and proxy freedom. This goes well beyond the schema's property 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?
The description opens with a specific verb and resource: "Resolve a company domain to its Instagram, Threads and Facebook accounts with follower and post counts, as one flat Clay ready row." It clearly states what the tool produces and differentiates its behavior for each platform, leaving no ambiguity about its function.
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?
Though there are no sibling tools, the description provides detailed guidance on when to use specific options: supplying a handle skips discovery, dropping Facebook is common due to unreliability, includeFollowerCounts=false is cheaper and needs no proxy, and skipCache forces fresh fetches. This qualifies as clear usage context and decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
map_meta_brand_presence
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The sole tool has a clear, singular purpose of mapping a domain to Meta platform accounts.
The tool name follows a consistent verb_noun pattern ('map_meta_brand_presence'), which is descriptive and predictable, though there is only one example to assess.
A single tool feels thin for a server, even if the task is narrowly focused. The server could benefit from splitting functionality (e.g., separate tools for Instagram, Threads, Facebook) or adding related capabilities, but the count is not unreasonable for a dedicated mapper.
The tool covers the core workflow of resolving a domain to social accounts and retrieving follower/post counts, with a noted limitation on Facebook due to login walls. However, it handles this limitation explicitly, so the surface is functionally complete for its stated purpose, though slightly constrained by external factors.
Maintenance
Related MCP Connectors
Domain & brand intelligence: company enrichment, tech stack detection, brand research.
Enrich any domain into a full company profile with firmographics and buying signals.
WHOIS/RDAP, DNS, SSL, live subdomains with IPs, and SPF/DMARC/DKIM for any domain.
Company social handles (LinkedIn, Instagram, X, Facebook, YouTube) via Apify MCP.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceDomain -> company intelligence for AI agents. Look up company name, country, contacts, and social profiles from any MCP-compatible client.6MIT
- AlicenseAqualityAmaintenanceResolves a company domain to its LinkedIn company page URL. Lightweight enrichment tool for sales and prospecting workflows.152 npm2MIT
- AlicenseAqualityAmaintenanceMaps a company domain to its official social media URLs and follower counts across LinkedIn, X, Instagram, Facebook, and YouTube.138 npmMIT
- AlicenseAqualityBmaintenanceResolves TikTok handles or company domains to brand accounts, returning follower, like, video counts, verification status, and more.128 npmMIT