Skip to main content
Glama

Check LinkedIn DOM Drift (operator only)

li_selector_canary
Read-only

OPERATOR ONLY — refused for anyone but whoever runs this install: it opens a live browser on the account for a few minutes and reports on our own selectors, which nobody but the operator can act on. If sends or reads on your account look broken, call li_account_activity (what is running, queued or held) or li_session_status with verifyLive (whether the LinkedIn sign-in still works). Read-only check that the controls this system depends on still exist AND are still clickable: the feed, the messaging composer and send button, a real contact profile's Message control and its href, a post's reaction control, and the post composer (opened and closed again, nothing typed or posted). Also checks the Voyager conversation read, because selectors are only half the exposure — LinkedIn rotates the messaging queryId and a failed read reports as an EMPTY INBOX rather than an error, which would leave the reply routine answering nobody while the account still looked healthy. It sends nothing. Runs daily on its own; use this to check immediately after a suspected change, or when sends start failing for no clear reason. "found but not hittable" is the important failure — a control covered by the sticky nav accepts no real click, which presents as the action silently doing nothing.

Input Schema

NameRequiredDescriptionDefault
sessionIdNoAccount id from li_list_accounts. Omit (with sessionLabel) to use your default account.
profileUrlNoA real contact to check the profile controls on. Defaults to a recent accepted connection; without one those checks are SKIPPED and the run reports itself incomplete.
sessionLabelNoAccount by label, LinkedIn name, profile slug or member id (li_list_accounts). Omit (with sessionId) to use your default account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / sessionId / description
      Added value: +"Account id from li_list_accounts. Omit (with sessionLabel) to use your default account."
    • addedInput schema / properties / sessionLabel / description
      Added value: +"Account by label, LinkedIn name, profile slug or member id (li_list_accounts). Omit (with sessionId) to use your default account."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare readOnly/destructive=false, and the description is consistent while adding substantial beyond-annotations context: it opens a live browser for minutes, sends nothing, creates and closes a post composer, and explains the two silent-failure modes (sticky-nav 'found but not hittable', and a rotated messaging queryId surfacing as an EMPTY INBOX). This is unusually rich disclosure.

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 operator-only restriction and the read-only nature are front-loaded, and the failure-mode explanation is placed before the when-to-use guidance. It is dense but occasionally repetitive (read-only/sends-nothing stated more than once), pushing it below 5.

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?

With no output schema, the description carries the reporting burden and does explain what is checked and that an incomplete run self-reports. It stops short of describing the actual report shape or pagination, but is otherwise complete for an operator diagnostic.

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%, and the schema already documents the default-account and default-connection behavior for sessionId/sessionLabel/profileUrl. The description does not add syntax or format meaning beyond that, so the baseline 3 applies.

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?

Names a specific verb and resource (checks that LinkedIn DOM selectors still exist and are clickable) and enumerates exactly which controls are probed. It also distinguishes itself from li_account_activity and li_session_status by pointing to them as the alternatives for account/session health.

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 when-to-use ('immediately after a suspected change, or when sends start failing for no clear reason'), when-not (operator only, refused for anyone else), and named alternatives with their conditions. Nothing is left to inference.

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