mcp-x-brand-presence-mapper

Map X Twitter Brand Presence

map_x_brand_presence

Read-onlyIdempotent

Resolve a company domain to its official X (Twitter) handle and profile URL, with follower count, bio, and account age. Identify the real brand account and key audience metrics in one lookup.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools

map_x_brand_presenceA