Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Map Company Social Presence

map_company_social_presence
Idempotent

Map a company's social media profiles across LinkedIn, X, Instagram, Facebook, and YouTube; get validated profile URLs and follower counts in JSON.

Instructions

Map a company's social media presence across LinkedIn, X, Instagram, Facebook, and YouTube. Returns profile URLs and follower counts in flat Clay-ready JSON. Profiles are discovered from the company's own homepage links, a web search fallback, and pattern guessing, then validated against the company. Follower counts are extracted where public; X is URL-only (its count needs login) and Instagram and Facebook counts are best-effort. Provide at least one of company_domain or company_name. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
platformsNoWhich platforms to map. Defaults to all five.
skipCacheNoForce a fresh lookup and ignore the 7 day result cache.
company_nameNoOptional company name. Improves search accuracy and disambiguation. Provide this or company_domain.
company_domainNoBare company domain, e.g. stripe.com. Provide this or company_name.
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
includeFollowerCountsNoFetch profile pages to extract follower counts (default true). Set false for URLs only, which is cheaper.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}
  2. Addedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: discovery pipeline (homepage links, web-search fallback, pattern guessing) with validation, per-platform reliability caveats (X is URL-only, Instagram/Facebook counts best-effort), auth requirement (APIFY_TOKEN), and credit consumption. One minor tension: it asserts 'writes nothing' while readOnlyHint=false is defensible because the run writes a 7-day cache (exposed via skipCache).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what it maps, then output format, then method, then reliability limits, then requirements and cost. Five dense sentences with no filler, each carrying distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by specifying the return format (flat Clay-ready JSON with URLs and follower counts), the one-of identifier requirement, cost/auth prerequisites, and per-platform data-quality limits. Nothing needed to call it correctly is missing.

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 schema already documents platforms, skipCache, both identifiers, max_charge_usd, and includeFollowerCounts. The description only reinforces the required-one-of rule and the follower-count cost tradeoff, adding little beyond structured data; baseline 3 applies.

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?

States a specific verb (map) and resource (company social presence) and enumerates the exact five platforms covered, plus the output shape (profile URLs and follower counts). An agent can distinguish it from siblings like map_company_event_presence or resolve_linkedin_url without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a real invocation constraint ('Provide at least one of company_domain or company_name') and a cost-driven toggle (set includeFollowerCounts false for URLs only, which is cheaper). However, it never says when to choose this tool over alternatives such as resolve_company_identity or enrich_company_firmographics, so usage is implied rather than routed.

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