Skip to main content
Glama

linkedin_unipile

Read-only

Reads LinkedIn messaging (DM) via Unipile. Sending, reacting and changing a thread — like every act on LinkedIn — is linkedin_unipile_act.

op:

  • "list" (default): the conversations, paginated (limit + cursor) — 25 at most per page (LinkedIn's limit): beyond that, paginate by cursor. Each 1-to-1 thread is enriched with attendee_name/attendee_headline/ attendee_profile_url (resolved in batch — the raw name of 1-to-1 threads is null and attendee_provider_id is opaque). with_names=False turns off this enrichment (raw payload, one API call fewer). ⚠️ The enrichment may not happen, and the response SAYS so: an attendee_names field then appears, with its status and its reason. An absent attendee_name on a thread therefore does NOT mean "no counterpart" — read attendee_names before concluding, and fall back on name or last_message.sender. ⚠️ Do NOT use last_message.is_sender to know whether YOU wrote last. Observed as false on all of an account's threads on 03/09/2026 — including the 22 whose last message came from the account itself, exactly like the threads where the counterpart had replied. The field distinguishes nothing: relying on it leads to concluding a reply on every thread, or the opposite. Compare last_message.sender_id (or last_message.sender.display_name) with the account's identity.

  • "read": the messages of a thread (chat_id). Each attachment carries a source: pass it to oto_import (target="project_file") to file it, or to any tool taking a source — the server fetches the file.

  • "attendees": participants of a thread (chat_id).

  • "contacts": your messaging contact book (counterparts). Paginated.

A page of threads with their full last message is heavy (~100,000 characters for 20): for a sweep, slim it with fields (e.g. ["id", "name", "timestamp", "last_message.sender_id", "last_message.text"]) and text_max_chars (e.g. 200) — op="list" and op="read".

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

Input Schema

NameRequiredDescriptionDefault
opNolist (default) | read | attendees | contacts.list
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
limitNopage size (list, read, contacts).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
cursorNopagination (list, contacts).
fieldsNoop="list"/"read" — keys kept per item (`parent.key` for a sub-key; `id` always kept); a key absent from the whole page is refused. Omitted = every field.
_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.
chat_idNothread id (read, attendees).
_accountNoCompte à OPÉRER quand plusieurs existent. `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
with_namesNoop="list" — enrichment of counterpart names.
text_max_charsNoop="list"/"read" — excerpt length of `text` and `last_message.text`, the cut marked `text_truncated`. Omitted = full.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the `readOnlyHint` annotation, the description discloses critical behavioral caveats: enrichment may fail and how to detect it, `last_message.is_sender` is unreliable and should be replaced by sender identity comparison, pagination is capped at 25 per page, and thread pages can be very heavy. These are non-obvious operational facts that materially affect correct use.

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 long but well structured: a one-line purpose statement, a sibling reference, then bulleted `op` semantics with warnings. Most content earns its place through operational caveats, though the density and long warning sentences could be trimmed slightly.

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 13-parameter, multi-operation read tool with no output schema, the description covers all operation modes, pagination behavior, enrichment failure modes, payload weight, and response-shaping options. It supplies enough context for an agent to call the tool correctly without opening the schema.

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%, so the baseline is 3, but the description adds practical meaning beyond the schema: the 25-item page cap for `limit`, example `fields` projections, `text_max_chars` behavior, and the `with_names` enrichment trade-off. It does not explain the org/group/run scoping parameters, but those are already documented in the schema.

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: 'Reads LinkedIn messaging (DM) via Unipile.' It immediately distinguishes itself from the mutation sibling by naming `linkedin_unipile_act` and clarifying that sending/reacting/thread changes belong there.

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 explicitly enumerates each `op` mode (`list`, `read`, `attendees`, `contacts`) and explains when each applies, including that `list` is the default. It also routes write actions to the sibling tool and gives practical guidance for sweeping large result sets using `fields` and `text_max_chars`.

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