Linked API

get_inbox

Read-only

Default way to read LinkedIn messages (standard and Sales Navigator), newest first. Without personUrl returns new messages across all conversations since inbox monitoring was enabled; requires sync_inbox (or nv_sync_inbox) once per account. With personUrl returns the whole known conversation with that person, including history loaded by sync_conversation, as { messages, threads }: each message also carries inboxMessageId (its id in the result without personUrl, or null) and threadId may be null; each thread carries historyFrom and historyComplete. Check threads[].historyComplete – if false and you need earlier messages, call sync_conversation once, then call get_inbox again. Every message carries personUrn — the permanent LinkedIn member URN (urn:li:member:) of the person on the other side of the thread, or null when LinkedIn does not expose it. personHashedUrl is LinkedIn's hashed profile URL and is always present; personPublicUrl is the public vanity URL when that person has been resolved, otherwise null.

Linked API actions are queued into a cloud-browser workflow and may take several minutes. The server returns immediately after starting the workflow with {status: 'pending'|'running', pendingReason, workflowId, operationName, message}. To retrieve the final result, call get_workflow_result with the returned workflowId and operationName — it will long-poll until completion or the request budget elapses, then return either the final result or another in-progress snapshot. Do not retry the original tool while a workflow is still running; that creates duplicate queued work.

A pending workflow carries pendingReason: 'queued' means it is waiting its turn behind other work on the same account and will start within minutes. 'outsideWorkingHours' means the account has configured working hours and the workflow is parked until they reopen — possibly the next working day. In that case get_workflow_result returns immediately instead of polling, message states when the window opens, and you should report that to the user rather than looping.

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

Input Schema

Name	Required	Description
`type`	No	Optional inbox type filter: "st" for standard messages, "nv" for Sales Navigator messages. If omitted, both are returned.
`since`	No	Optional ISO 8601 timestamp to only retrieve messages at or after this date (e.g., '2024-01-15T10:30:00Z'). If not provided, all captured messages are returned. Message times are whole minutes.
`threadId`	No	Optional conversation thread identifier to restrict the result to a single thread.
`personUrl`	No	Optional LinkedIn URL of one person to get the whole known conversation with them instead of the whole inbox (e.g., 'https://www.linkedin.com/in/john-doe'). A hashed URL (personHashedUrl from a message) always matches; a public URL matches only once Linked API knows that person's public URL, so prefer personHashedUrl when messages from this person show personPublicUrl: null.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond readOnlyHint/openWorldHint: calls are queued into a cloud-browser workflow, may take minutes, return an immediate {status, workflowId, operationName} snapshot rather than data, and duplicate retries create duplicate queued work. It also discloses the 'outsideWorkingHours' parking behavior and that get_workflow_result returns immediately in that case, plus the nullability of threadId and threadId-dependent history.

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-loads the core purpose and return shape, then moves to the async workflow caveat. It is long and contains workflow boilerplate likely shared with every sibling tool, but each block is separated by a blank line and no sentence is strictly redundant for an agent that must poll correctly.

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 {messages, threads} return shape, inboxMessageId semantics (id in the unfiltered result or null), threadId/historyFrom/historyComplete, and the personUrn/personHashedUrl/personPublicUrl fields including when each is null. Combined with the async polling instructions, an agent has everything needed to call and interpret the result.

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; the description still adds value on personUrl by explaining it switches the tool into whole-conversation mode including history loaded by sync_conversation, and on matching semantics for hashed vs. public URLs. It does not add meaning for type or since beyond the schema, keeping it short of a 5.

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 verb, resource, and scope: 'Default way to read LinkedIn messages (standard and Sales Navigator), newest first.' It then splits the two modes of operation (all-inbox vs. single-person conversation) so an agent can tell which behavior a given call will trigger.

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 preconditions ('requires sync_inbox once per account'), a remediation path ('if historyComplete is false ... call sync_conversation once, then call get_inbox again'), and a hard negative ('Do not retry the original tool while a workflow is still running'). It also names the follow-up tool (get_workflow_result) and how to interpret pendingReason, including when to stop polling.

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

All Linked API tools Inspect

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.