Skip to main content
Glama
Sign In

LinkMCP: hosted LinkedIn MCP server

by io.linkmcp
OverviewDiscussionsAdmin

Get LinkedIn Company

linkedin_get_company
Read-onlyIdempotent

Get a company's LinkedIn page, for example its website, industry, size, headquarters and follower count. Use this to research one company, for example before a sales call; it does not search for lists of companies by industry or location. Pass identifier (a LinkedIn company URL, slug, or numeric ID) when you know it. If you only know the company name, pass name instead of guessing a slug: LinkedIn slugs often differ from the name. A name returns the company when it is a clear match, otherwise a short list of candidates to choose from. Pacing: a lookup by name runs a LinkedIn company search, and LinkMCP sends at most 3 of these per minute from one account. Look up companies by name one at a time. A company URL, slug or ID needs no search.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "linkedin_get_company"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe company name (e.g. "Acme Corporation"), when you do not know its LinkedIn URL. Searches LinkedIn through your connected account. Use this or identifier, not both.
identifierNoLinkedIn company URL (e.g. https://www.linkedin.com/company/acme), company slug (e.g. "acme"), or numeric ID. Use this or name, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds real operational context beyond them: a rate limit of at most 3 name-based LinkedIn company searches per minute per account. It also discloses the fallback behavior (a name returns a match when clear, otherwise a short candidate list) and the slug-mismatch pitfall, which an agent could not infer from annotations.

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?

It is front-loaded with purpose, then usage exclusions, then parameter guidance, then pacing — a logical order. It is somewhat long for a two-parameter tool, and the "one at a time" instruction partially repeats the pacing sentence, costing a point.

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, so the description carries the burden and does so: it names the fields returned and explains the variable-shape case (single match vs. candidate list). Combined with the rate-limit and input-selection guidance, an agent has everything needed to call this correctly.

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 100% and the schema already states mutual exclusivity, so the baseline is 3. The description goes further by explaining why to prefer `name` over guessing a slug ("LinkedIn slugs often differ from the name") and what each mode returns, adding genuine decision value rather than restating types.

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 uses a specific verb and resource ("Get a company's LinkedIn page") and enumerates the returned attributes (website, industry, size, headquarters, follower count). It also draws an explicit boundary against list/search behavior ("does not search for lists of companies by industry or location"), which separates it from siblings like linkedin_search_sales_navigator or linkedin_bulk_get_companies.

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

Usage Guidelines5/5

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

It names the concrete use case ("research one company, for example before a sales call") and states when not to use it (list-by-industry/location searching). It further routes the agent between the two input modes and instructs looking up by name one at a time, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All LinkMCP: hosted LinkedIn MCP server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources