Skip to main content
Glama

linkedin_unipile_profile

Read-only

A LinkedIn member or company: read their profile and their activity. Acting on a member (endorsing a skill, a Sales Navigator / Recruiter action) is linkedin_unipile_act (op="endorse" / "update_member").

identifier = public slug (marie-dupont; a full linkedin.com/in/… or /company/… URL is brought back to it) or URN (ACoAA…). NOT the numeric member_id from linkedin_unipile_search: the v2 API rejects it (400 Invalid User ID) — go through the slug, which these ops resolve for you.

op:

  • "person" (default): full profile (dated career, schools, network). ⚠️ LinkedIn may throttle a section (often experience): the response then carries throttled_sections=[…] with the section empty despite a *_total_count > 0. This is an UPSTREAM rate-limit, not an absence of data: retry later (minutes), reduce concurrency (≤8 in parallel), and in a batch handle these targets in a deferred catch-up pass. Also CHECK that the returned public_identifier/id == the requested one before writing (reject + retry otherwise).

  • "company": company profile. Cached 6h per account (~static profiles) — the same company looked up again does not consume the upstream quota (~100 profiles/12h per account).

  • "me": profile of the connected account itself (the "me" under which the other ops act). No identifier.

  • "posts" / "comments": what a member publishes / comments — to spot a post to comment on/like, or what a prospect engages with. Each item's text is served as an EXCERPT (600 characters, cut marked text_truncated: true): the raw is 55-75 KB for 10 posts, and triage is done on the header. text_max_chars=None returns the full text, op="get" of linkedin_unipile_post a specific post. To slim further, fields (e.g. ["text","posted_at","social_id"]) keeps only those fields — id/ social_id are always kept so you can chain.

  • "reactions": posts a member has liked.

  • "followers" / "following": followers of the connected account, or of a member via identifier. Paginated.

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_unipile_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNoperson (default) | company | me | posts | comments | reactions | followers | following.person
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
limitNopage size.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
cursorNopagination (posts, comments, reactions, followers, following).
fieldsNoop="posts"/"comments" — field projection (slims heavily).
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_accountNoCompte à OPÉRER quand plusieurs existent. `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
sectionsNoop="person" — sections to include ("*" = all), comma separated: experience, education, languages, skills, certifications, volunteer_experience, projects, recommendations, interests, recruiting_activity (Recruiter only). `<name>_preview` = its first entries only (lighter, less throttling), `*_preview` = every section that way. Any other name is refused, naming these. The About text is NOT a section: it always comes back, as `bio`.*
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
identifierNopublic slug or URN of the member / company. Required except op="me"; optional for followers/following (default = you).
text_max_charsNoop="posts"/"comments" — text length of each item (default 600; `None` = full text).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=true, and the description stays consistent with that while adding substantial behavior the annotations cannot express: upstream throttling of sections with `throttled_sections` populated despite `*_total_count` > 0, retry/deferral advice, a ≤8 parallel concurrency hint, 6h caching for companies against a ~100 profiles/12h quota, and a consistency check on returned `public_identifier` before writing.

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?

Front-loaded with a one-line purpose, then a bolded identifier rule, then a bulleted op list — well structured for a 13-parameter tool. It is long and repeats a few schema points (e.g. the default 600 chars appears in both), but nearly every sentence carries operational value such as the throttle warning and quota numbers.

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?

For a complex multi-op, no-output-schema read tool, it covers defaults, pagination (cursor/limit), truncation markers (`text_truncated`, 600-char excerpt), quota and caching behavior, and failure modes. An agent could call every op correctly from this text alone.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaning the schema does not: `identifier` is a public slug or URN (with full URLs normalized) and explicitly not a numeric member_id; `sections` supports `<name>_preview` and `*_preview` shorthands with About always returned as `bio`; `text_max_chars=None` means full text; `fields` always retains `id`/`social_id` for chaining.

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?

Opens with a specific resource statement ("A LinkedIn member or company: read their profile and their activity") and then enumerates every supported op (person/company/me/posts/comments/reactions/followers/following). It also explicitly contrasts itself with the mutating sibling `linkedin_unipile_act`, so an agent can separate read-profile from act-on-member without opening either schema.

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?

Gives explicit routing rules: acting on a member goes to `linkedin_unipile_act`, full post text goes to `linkedin_unipile_post` op="get", and `op="me"` takes no identifier. It also states a real constraint ('do NOT use the numeric member_id from `linkedin_unipile_search`; the v2 API rejects it with 400') and names the workaround, which is exactly the when/when-not guidance agents need.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources