Skip to main content
Glama

Reach MCP — LinkedIn for AI agents

list_notifications

Read-onlyIdempotent

List the account's LinkedIn notifications, as on its Notifications page, newest first: mentions, comments and reactions on its posts, birthdays, work anniversaries, job changes, invitations, profile views. filter picks the tab: all (default), mentions, my_posts or jobs. Each item has card_type (LinkedIn's own name), kind (mention, comment, reaction, birthday, work_anniversary, job_change, invitation, reshare, job, profile_view or other), the line LinkedIn shows, published_at, read, url, actor_name and actor_linkedin_id (or actor_company_id for a page), and when it is about a post post_urn and post_text; when it is about a comment (a mention in a comment, a comment on the account's post) comment_urn and comment_text: pass comment_urn to reply_comment to answer in that thread. Reading does not mark them seen. One LinkedIn call per page; paged with start/next_start. Do not poll it: subscribe a webhook or check once a day. Use for the daily check: what happened to the account (mentions, comments, birthdays, work anniversaries, job changes); for every liker and commenter of its own posts use scrape_my_posts. Read-only.

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": {
      "account_id": "<account_id>"
    },
    "name": "list_notifications"
  }
}

Input Schema

NameRequiredDescriptionDefault
countNoPage size.
kindsNoOnly these kinds (e.g. ['birthday', 'work_anniversary']); filters the page LinkedIn returns.
sinceNoOnly notifications since this ISO date or datetime (UTC unless an offset is given); next_start is dropped once older ones are reached.
startNoPagination offset, 0-based.
filterNoThe Notifications page tab.all
account_idYesReach id of the LinkedIn account to act on, from list_accounts.

Output Schema

NameRequiredDescriptionDefault
itemsNo
next_startNoPass as start for the next page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description goes further with non-obvious behavior: 'Reading does not mark them seen', 'One LinkedIn call per page' (quota cost), 'paged with start/next_start', 'next_start is dropped once older ones are reached', and the polling prohibition. These are exactly the traits an agent cannot infer from structured fields.

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?

Front-loaded with purpose, then filtering, then item shape, then operational constraints — a sensible order with no filler sentences. It is dense and runs long, with a sizeable enumeration of item fields that is partly redundant against the existing output schema, which keeps it from a 5.

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 paged, filtered, read-only list tool, an agent has everything needed: tab semantics, page-size and offset behavior, the since/next_start interaction, what a returned item contains, the downstream reply_comment handoff, and quota/polling guidance. Nothing required to call it correctly 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%, so baseline is 3; the description earns above that by explaining filter as 'the tab' with the default, and clarifying that kinds 'filters the page LinkedIn returns' rather than doing server-side retrieval — a meaningful semantic distinction. It adds the reply_comment chaining for comment_urn but does not otherwise deepen count/start/since beyond the schema text.

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 the account's LinkedIn notifications, as on its Notifications page, newest first') and enumerates exactly what appears (mentions, comments, reactions, birthdays, work anniversaries, job changes, invitations, profile views). It also explicitly separates itself from the sibling it could be confused with: 'for every liker and commenter of its own posts use scrape_my_posts.'

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?

Gives explicit when-to-use ('Use for the daily check: what happened to the account'), explicit alternative for the adjacent need (scrape_my_posts for likers/commenters), and an explicit anti-pattern with remedy ('Do not poll it: subscribe a webhook or check once a day'). Both the positive and negative conditions are named.

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