Skip to main content
Glama
Sign In

Bridgly

by app.bridgly.mcp
OverviewDiscussionsAdmin

List the work experience of a LinkedIn profile

linkedin_get_profile_experience
Read-onlyIdempotent

List every position on a LinkedIn member's profile, including roles the full profile leaves out. Each position includes the title, company with its link and logo, employment type, location, dates and description. count sets how many companies come back, each with every position held there; page on with the nextStart from the previous response. Read-only: returns public data and changes nothing. Costs 1 credit per request.

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": {
      "publicId": "<publicId>",
      "count": "<count>"
    },
    "name": "linkedin_get_profile_experience"
  }
}

Input Schema

NameRequiredDescriptionDefault
countYesNumber of companies to return (1–100), each with every position held there. Defaults to 100.
startNoNumber of results to skip. Defaults to 0.
publicIdYesThe member public identity, or the profile link itself, e.g. "williamhgates" or "https://www.linkedin.com/in/williamhgates".
cacheOnlyNoReturn only a cached result and never scrape live. With `cacheMaxAgeHours`, only a result that recent is returned; without it, the latest cached result of any age. Responds 404, at no cost, when there is none, e.g. true.
cacheMaxAgeHoursNoAccept a cached result scraped up to this many hours ago. A cached result costs no credits, and its `cachedAt` says when it was scraped. When no cached result is that recent, the data is scraped live at the normal price. Leave it out to always scrape live, e.g. 24.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / count / default
      Previous value: -10New value: +100
    • changedInput schema / properties / count / description
      Previous value: -"Number of companies to return (1–100), each with every position held there. Defaults to 10."New value: +"Number of companies to return (1–100), each with every position held there. Defaults to 100."
  2. Changed2 schema fields changed
    • addedInput schema / properties / cacheMaxAgeHours
      Added value: +{
+  "description": "Accept a cached result scraped up to this many hours ago. A cached result costs no credits, and its `cachedAt` says when it was scraped. When no cached result is that recent, the data is scraped live at the normal price. Leave it out to always scrape live, e.g. 24.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / cacheOnly
      Added value: +{
+  "description": "Return only a cached result and never scrape live. With `cacheMaxAgeHours`, only a result that recent is returned; without it, the latest cached result of any age. Responds 404, at no cost, when there is none, e.g. true.",
+  "type": "boolean"
+}
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the bar is lower; the description still adds value by disclosing the 1-credit cost per request, which no annotation carries. The "Read-only: returns public data and changes nothing" sentence largely restates the annotations, and caching cost behavior is left entirely to the schema.

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?

Three sentences, no filler, with the scope statement front-loaded before the return-shape, pagination and cost details. Every clause carries operational information an agent needs.

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?

With no output schema, the description compensates by enumerating the returned fields (title, company with link and logo, employment type, location, dates, description) and explaining pagination via `nextStart`. For a five-parameter read-only list tool with full schema coverage and rich annotations, nothing material is missing.

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%, setting a baseline of 3, but the description adds meaning the schema lacks: it explains that `count` counts companies rather than positions, each carrying all positions held there, and it names `nextStart` from the prior response as the pagination cursor even though no output schema documents that field. It does not address `cacheOnly`/`cacheMaxAgeHours`, but those are fully 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?

States a specific verb and resource ("List every position on a LinkedIn member's profile") and sharpens scope with "including roles the full profile leaves out." That resource is inherently separable from the sibling tools that return education, certifications, skills or honors, so an agent can pick it without opening the schema.

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

Usage Guidelines4/5

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

Gives clear operating context: paginate using `nextStart` from the previous response, and each request costs 1 credit. It stops short of naming when to prefer a different tool (e.g. the profile-from-URL sibling or the full-profile tool) or any when-not conditions, so it is clear context rather than explicit routing.

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

All Bridgly toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources