LinkedIn MCP

linkedin_exchange_code

Exchanges an OAuth authorization code for an access token after validating the session-generated state, completing the authorization flow.

Instructions

Exchange an OAuth authorization code for a token after checking the state generated in this session.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>",
      "state": "<state>"
    },
    "name": "linkedin_exchange_code"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes
`state`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does add real value by disclosing that state is validated against the session, but it omits what happens to the resulting token (stored? returned only?), the single-use nature of authorization codes, and failure modes on invalid state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb-action first and the prerequisite second. No filler and nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and both parameters get semantic coverage. The remaining gap is the missing link to linkedin_start_oauth and the token-handling behavior after exchange, which matters for a flow-terminal call.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate and it partly does: 'authorization code' and 'state generated in this session' map meaningfully to both required parameters. It still lacks format hints (where the code comes from, what the state string looks like) that an agent would need to supply correct values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: exchange an OAuth authorization code for a token. This clearly differentiates it from the sibling linkedin_start_oauth, which initiates the flow rather than completing it, though the description never names that sibling explicitly.

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

Usage Guidelines3/5

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

The phrase 'after checking the state generated in this session' implies a prerequisite ordering in the OAuth flow, so usage is inferable. However, it never names linkedin_start_oauth as the source of the code/state, nor does it state what to do on state mismatch or whether the call can be retried.

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

Deploy Server