Skip to main content
Glama

Enrich LinkedIn profiles

enrich_linkedin_profiles
Read-only

This is the tool for questions about a list of people: filtering a list by connection count or seniority, labelling who works where, or filling in headlines before drafting. experience carries every role with its dates, so it also answers career-history questions — how long someone has been in seat, where they worked before, whether they were promoted internally, who is an alum of a given company — without a separate lookup. It does not touch the user's LinkedIn account, so it neither consumes their daily profile-lookup budget nor carries any account-safety risk — prefer it over per-person lookups whenever you have more than a couple of people to enrich.

Costs 0.1 Sliq credits per profile returned; misses are free. A profile this user enriched in the last 24h is served from cache, so re-calling does not look up or charge again.

Enriching a profile also links it to its primary employer's canonical company, which may need a one-time web-domain lookup: 0.05 credits the first time a given company is looked up (cached after, so it never charges twice for the same company). A batch spanning many unfamiliar employers costs a little beyond the per-profile total; fold that into any estimate you give the user.

How many to run is a spend question: run a list of up to 500 straight away. Past 500, tell the user how many profiles it is and what that costs — the count times 0.1 credits — and wait for a go-ahead before running it; a batch that size also takes several minutes, so say so in the same breath. In a background run there is nobody to ask, so run it and report the spend in your summary.

How to call it is a separate question, and the answer is almost always run_code. A direct return is truncated at 50KB, and one senior profile's career history can be a third of that on its own — so a direct call on a dozen executives shows you two of them, after charging for all twelve, since credits are spent inside the tool before anything is truncated. Only a handful of profiles fit. From run_code nothing is truncated: the rows stay in the sandbox and you print only the filter, count, or summary you need. Call it directly only for a few people whose full profiles you intend to read.

What it cannot tell you: whether the user is already connected to someone, their network distance, or shared connections. Those describe the user's own relationship to the profile and only a LinkedIn-account lookup can answer them — use queue_linkedin_outreach(action_type='resolve') when the decision genuinely depends on connection status. One entry per input, in input order — either a profile dict, or an {'error': ...} entry for a profile that could not be resolved — followed by any warnings. The error says which case it is: no profile exists for the identifier, or the lookup did not finish and the identifier should be retried.

experience and education cover the person's whole history and are long for senior people — a 25-year career can run 20+ roles. They arrive in LinkedIn's display order, which is NOT sorted by date: roles at the same employer sit next to each other, so the first entry is not reliably the current one. Sort on start_date.get('year') when you need chronology. Consecutive entries at one employer are usually one tenure with internal promotions, but check the dates before saying so — a gap between them means they left and came back, which is a different story to tell. Dates are {'year': 2014, 'month': 'Feb', 'text': 'Feb 2014'}; month is missing when LinkedIn shows only a year, and a date can be empty entirely, so reach for .get() rather than indexing. An end_date of {'text': 'Present'} means the role is current, and someone can hold several at once.

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": {
      "linkedin_urls": "<linkedin_urls>"
    },
    "name": "enrich_linkedin_profiles"
  }
}

Input Schema

NameRequiredDescriptionDefault
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
linkedin_urlsYesLinkedIn identifiers to enrich — full profile URLs, bare slugs, or encoded provider ids, in any mix. Capped at 1000 per call; split a longer list across calls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the readOnlyHint=true annotation: it discloses cost per returned profile (0.1 credits, misses free), a 24h result cache that prevents re-charging, an extra 0.05 credit one-time company domain lookup per unfamiliar employer, batching behavior, and the 50KB truncation ceiling with the crucial warning that credits are spent before truncation. It confirms the read-only annotation by stating it never touches the user's LinkedIn account and carries no account-safety risk or daily-budget consumption. No contradiction with annotations.

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 structure is strong — a front-loaded summary followed by cost, batching, invocation-mode, and limitation paragraphs, all separated by intent. It is nonetheless long and somewhat repetitive about credits (per-profile cost restated alongside the 500-item gate and again under company lookup), which could be tightened without losing substance.

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 two-parameter tool with no output schema, the definition carries the return-value burden thoroughly: one entry per input in input order, `{'error': ...}` entries distinguishing unresolvable vs. retryable, `experience`/`education` arriving in LinkedIn display (not date) order, `start_date.get('year')` sorting advice, and the ambiguity of consecutive same-employer entries. It also flags the multiple-concurrent-roles case and the sparse date fields, which are exactly the traps an agent would otherwise hit.

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 coverage is 100%, so both parameters are already documented, and the description's note about mixing URLs, slugs, and provider ids largely restates the schema. It does add list-level semantics (everything is passed in one call and fetched in batches) and a 500-item spend threshold, but it never mentions the 1000-per-call cap the schema declares, and it says nothing about the `on_behalf_of` parameter at all.

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 summary names a specific verb and resource (bulk lookup of LinkedIn profiles) and enumerates exactly what comes back: headline, title, company, location, connection/follower counts, employment and education history. It also bounds the domain by stating what it cannot return (connection status, network distance, shared connections) and names the sibling that can, `queue_linkedin_outreach(action_type='resolve')` — so the agent can separate it from `search_linkedin_people`, `find_linkedin_url`, and per-person lookups without opening a 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?

Explicit selection rules are given: use this for questions about a list of people (filtering by connection count/seniority, labelling employers, filling headlines, career-history questions), prefer it over per-person lookups whenever there is more than a couple of people, and use a different tool when the decision hinges on connection status. It also routes on invocation mode — `run_code` by default, direct call only for a few profiles you intend to read in full — and states a spend gate (run up to 500 immediately, ask for approval past 500) plus the background-run exception.

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