LinkedIn API for AI agents

Why these endpoints suit tool calling

They are plain GET requests with flat query parameters and no request body, which maps cleanly onto a tool schema. There is no session to maintain, no pagination cursor you must hold across turns unless you want one, and no authentication dance beyond a single header.

The response envelope is stable and shallow: element for single-record endpoints, elements plus pagination for lists, always with status, error and the echoed query. A model can be told that shape once and rely on it, which matters more for reliability than any individual field.

Cost control for something you do not fully control

An agent in a loop is a spend risk in a way a cron job is not. Three things here help:

• Every response reports its cost. X-Request-Cost and X-Balance-Remaining let a wrapper keep a running total per task and abort when it crosses a budget, without a second API call to check.
• Balance is prepaid and hard-capped. There is no overdraft. When the balance is gone, calls return 402 and stop. An agent cannot run up a bill you have not already funded.
• Separate keys, separate blast radius. Give the agent its own key. If it misbehaves, revoke that key from the dashboard and nothing else you run is affected.

Concurrency limits also work in your favour here: a runaway loop hits 429 with a Retry-After rather than quietly costing you money at full speed.

Exposing it as MCP tools

There is no official MCP server for this API yet, and writing one is a small job: each endpoint becomes a tool whose input schema is its query parameters and whose output is the JSON envelope. The parameter names and descriptions in the documentation come from the same source the API validates against, so a generated schema will match behaviour.

Two things are worth adding in the wrapper rather than leaving to the model. First, collapse the identifier variants — a tool that takes one person argument and works out whether it is a URL, a handle or an ID is far more reliable than three optional parameters the model must choose between. Second, default short=1 on profile lookups and expose the full profile as a separate, more expensive tool, so the cheap call is the default path.

What agents get wrong on this API

The most common failure is paging forever. A model asked to "find everyone who…" will happily page a search to exhaustion and spend real money doing it. Cap pages in the wrapper, not in the prompt.

The second is treating an empty result as a failure and retrying. A private or non-existent profile returns a successful response with an empty element, and retrying it costs again every time. Handle that case explicitly.

The third is hallucinating fields. Models will confidently report an email address that is not in the response, because their training says profile data usually includes one. It never does here — validate the output against the schema rather than trusting the summary.