Skip to main content
Glama
Sign In
LinkedIn Company Page Mapper MCP Server

LinkedIn Company Page Mapper MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Map LinkedIn Company Page Presence

map_linkedin_company_presence
Idempotent

Resolve a company domain to its verified LinkedIn page and return the page name, tagline, and optional follower count from public search results, without contacting LinkedIn.

Instructions

Free to run apart from Apify's start fee. Resolve a company domain to its LinkedIn company page, verified against the company's own site, and return the page name and tagline, plus a follower count when public search results show one (2 of 6 test domains on 2026-10-12). No request is sent to LinkedIn: the page comes from the company homepage (structured data or a link) or from a search result whose name matches the name the company site declares or the company_name you pass. A page that cannot be verified is not returned; the row says why in linkedin_verification. The follower count is the search engine's copy and can lag the live page. Industry, size band, headquarters, founded year, specialties and website are no longer returned. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
handleNoOptional. The company slug from linkedin.com/company/<slug>, for example shopify. Supplying it skips discovery; the page is returned as given.
skipCacheNoWhen "false" (default) a successful lookup is cached for seven days and reused. Set "true" to force a fresh lookup.
company_nameNoOptional. A LinkedIn page whose name is identical to this name verifies (score 80), so supplying it raises the share of companies that get a URL.
company_domainNoBare company domain, for example shopify.com. Supply this or a handle. With a domain the actor reads the company homepage and searches for its LinkedIn page; with a handle it skips discovery.
minConfidenceScoreNoA page is returned only when its match score is at least this, 0 to 100. Default 70. Homepage sameAs 95, homepage link 92, name identical to the site's declared name 85 or to company_name 80, slug and name matching the domain 75.
includeFollowerCountsNoWhen "true" (default) the follower count, page name and description are read from the search result for the page. Set "false" to return the URL only. No request is sent to LinkedIn either way.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.2.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / company_domain / description
      Previous value: -"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."New value: +"Bare company domain, for example shopify.com. Supply this or a handle. With a domain the actor reads the company homepage and searches for its LinkedIn page; with a handle it skips discovery."
    • changedInput schema / properties / company_name / description
      Previous value: -"Optional. Improves search accuracy and is what the identity gate checks a discovered profile against, so supplying it reduces wrong matches."New value: +"Optional. A LinkedIn page whose name is identical to this name verifies (score 80), so supplying it raises the share of companies that get a URL."
    • changedInput schema / properties / handle / description
      Previous value: -"Optional. The company slug from linkedin.com/company/<slug>, for example shopify. Supplying it skips discovery and goes straight to the fetch."New value: +"Optional. The company slug from linkedin.com/company/<slug>, for example shopify. Supplying it skips discovery; the page is returned as given."
    • removedInput schema / properties / includeFirmographics
      Removed value: -{
-  "description": "When \"true\" (default) industry, company size band, headquarters, founded year and website are parsed off the page alongside the follower count. Set \"false\" for the URL and follower count only. Sent as a string for Clay compatibility.",
-  "type": "boolean"
-}
    • changedInput schema / properties / includeFollowerCounts / description
      Previous value: -"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."New value: +"When \"true\" (default) the follower count, page name and description are read from the search result for the page. Set \"false\" to return the URL only. No request is sent to LinkedIn either way."
    • addedInput schema / properties / minConfidenceScore
      Added value: +{
+  "description": "A page is returned only when its match score is at least this, 0 to 100. Default 70. Homepage sameAs 95, homepage link 92, name identical to the site's declared name 85 or to company_name 80, slug and name matching the domain 75.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / skipCache / description
      Previous value: -"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."New value: +"When \"false\" (default) a successful lookup is cached for seven days and reused. Set \"true\" to force a fresh lookup."
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Substantial disclosure beyond the annotations: it names the required APIFY_TOKEN, the per-call credit cost, the no-request-to-LinkedIn behavior, the 7-day cache, the ~2-of-6 observed yield, the staleness of follower counts, and the fields that were removed. One tension worth noting: the text claims 'Read only' while readOnlyHint=false; the credit-consuming side effect the description itself admits plausibly explains the annotation (readOnlyHint false is also the MCP default), and destructiveHint=false supports the data-safety claim, so this reads as loose wording rather than a serious contradiction.

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?

Cost and purpose are front-loaded, then mechanics, then caveats, with almost no filler. It is dense and sentence-heavy (seven sentences, several long), and the removed-fields sentence could sit later, but every sentence carries information an agent needs.

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?

With no output schema, the description must carry the return contract and it does: page name, tagline, follower count when available, and the verification failure explanation. Auth requirements, cost, caching, and reliability limits are all present, leaving nothing an agent needs before calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning the schema does not: it explains that the page must be 'verified against the company's own site,' that failure rows carry a reason in linkedin_verification, and that company_name materially raises resolution odds. It does not restate the minConfidenceScore thresholds, which the schema already covers.

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 precise verb+resource+outcome: 'Resolve a company domain to its LinkedIn company page, verified against the company's own site, and return the page name and tagline.' It also names the exact inputs (domain, handle, company_name) and the verification gate, so an agent knows exactly what this tool produces and when it will produce nothing.

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?

It gives clear operating conditions: supply a domain to trigger homepage discovery or a handle to skip it, and supply company_name to raise the share of companies that resolve (score 80). It also explains that unverifiable pages are withheld with a reason in linkedin_verification. It does not state explicit when-not-to-use exclusions, but with no sibling tools there is no alternative to route against.

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