Skip to main content
Glama
Sign In
dev.socialscrape/socialscrape

dev.socialscrape/socialscrape

Official
by SocialScraper
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

LinkedIn

linkedin
Read-onlyIdempotent

Fetches company pages, profiles, posts, video transcripts, and public post search results via resource-based calls, supporting pagination and cached responses.

Instructions

Data from LinkedIn: profiles, posts and videos, transcripts.

Pick a resource, then pass its parameters as top-level arguments (extras in params). Each call costs the credits shown below and the result says what was charged and what is left; failures are free. List resources return a cursor: pass it back unchanged for the next page. Pass max_age_days to accept a cached copy for free.

Resources:

  • company(url): LinkedIn company page. 1 credit.

  • company.posts(url): LinkedIn company posts. 1 credit. Paged.

  • post(url): LinkedIn public post. 1 credit.

  • post.transcript(url): LinkedIn post video transcript. 1 credit (captions); AI transcription 1 credit up to 2 minutes, then 5 per started minute of the whole video. Optional: allow_long_transcription.

  • profile(url): LinkedIn public person profile. 1 credit.

  • search.posts(query): LinkedIn post search. 1 credit. Paged. Optional: date_posted, enrich.

Input Schema

NameRequiredDescriptionDefault
urlNoURL of the item the resource is about (profile, post, video, event...). Used by: company, company.posts, post, post.transcript, profile
queryNoKeyword or phrase to look for in public LinkedIn posts. Used by: search.posts
cursorNoOpaque cursor from the previous page; pass it back unchanged
paramsNoAny other parameter for the chosen resource, by name, e.g. {"start_date": "2026-01-01"}. Optional parameters of each resource are in the tool description; call describe for types and allowed values.
resourceYesWhich LinkedIn data to fetch. The tool description lists what each needs.
max_age_daysNoAccept a cached copy fetched within this many days, for 0 credits (0 to 30).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the read-only annotations: per-resource credit costs, free failures, cached copies via `max_age_days`, pagination via returned cursors, and transcription pricing details. These are exactly the operational traits an agent needs before invoking a paid data-fetching tool.

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?

The description is front-loaded with the calling pattern and then structured as a compact resource list. Despite covering six resources, costs, caching, and pagination, every section serves a clear operational purpose.

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?

For a complex multi-resource dispatcher, it covers resource selection, required arguments, costs, pagination, caching, and transcription exceptions. The main remaining gap is that it does not describe the shape of returned LinkedIn data beyond cursor and credit metadata, which is a minor limitation given there is no output schema.

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 already 100%, so the baseline is 3. The description adds useful meaning by mapping resources to required arguments and noting optional resource-specific parameters such as `allow_long_transcription`, `date_posted`, and `enrich`; it stops short of fully documenting every nested `params` option, instead directing the agent to `describe`.

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 description states a specific platform and data domain: LinkedIn profiles, posts, videos, and transcripts. It then enumerates the exact resource variants available, so an agent can distinguish this from other platform tools such as youtube, tiktok, or twitter.

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?

It gives clear operational guidance: choose a `resource`, pass its parameters as top-level arguments, use `cursor` for pagination, and use `max_age_days` for cached results. It does not explicitly compare this tool with generic siblings like `get_profile` or `get_post`, so it falls short of full when-to-use/when-not guidance.

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

Deploy Server

Other Tools