de en ja ko ru zh

linkedin-mcp

Name: linkedin-mcp
Author: Sundeepg98

by Sundeepg98

Overview Schema Source Related Servers Discussions Admin

Python

Local

Ein MCP-Server, der dir die Daten deines eigenen LinkedIn-Kontos als strukturierte Tool‑Ergebnisse zeigt, statt als Seiten, durch die du klicken musst.

Vierzehn seiner siebzehn Tools lesen und ändern nichts. Drei schreiben.

Bis zum 2026-08-23 sagte dieser Absatz: „Es liest. Das ist alles, was es tut. Es gibt keinen Schreibpfad in diesem Repository – nicht deaktiviert, nicht gestubbt, nicht hinter einem Flag." Das stimmte. Es war erzwungen, nicht nur behauptet – und es hörte an dem Tag auf zu stimmen, an dem linkedin_save_job ausgeliefert wurde. Ein README, das den bequemen Satz weiterführt, ist das Erste, dem ein Leser vertraut, und das Erste, das ihn in die Irre führt.

Was jetzt wahr ist:

Das Paket enthält genau einen Aufruf, der auf LinkedIn etwas ändern kann: einen einzelnen verankerten Klick in writes.perform. Der Quellscanner meldet ihn weiterhin – ihm wurde nicht beigebracht, nicht mehr hinzusehen – und er ist nach Pfad, Funktion und Art in einer einzeiligen Allowlist zugelassen, bei der die Tests fehlschlagen, wenn sie breiter wird.
Schreibvorgänge sind aus, außer du schaltest sie ein. LINKEDIN_ENABLE_WRITES=1, pro Prozess. Ein frisch geklontes Repository kann überhaupt nicht auf LinkedIn schreiben.
Jeder Schreibvorgang ist zwei Aufrufe. Der erste bewirkt nichts und gibt dir einen Block zum Lesen; der zweite löst aus diesem Block einen Einmal-Token ein. Der Token ist an eine Aktion an einem Ziel gebunden und erlischt nach 120 Sekunden. Das macht einen geplanten oder unbeaufsichtigten Schreibvorgang strukturell unmöglich statt bloß ungeraten.
linkedin_unsave_job ist gebaut, gesichert und zu Tut nichts – siehe Das, das verweigert.
Es reicht keine Bewerbungen ein, und das ist kein Achselzucken. linkedin_job_detail meldet apply_path – ob eine Stelle auf LinkedIn zu bewerten ist oder dich an ein externes Bewerber-System übergibt – und benennt dieses System. Die identifizierende Hälfte ist als Lesevorgang ausgeliefert. Die einreichende Hälfte ist aus einem gemessenen Grund verweigert – siehe Bewerbung: die Hälfte, die ausgeliefert wird, und die Hälfte, die es nicht wird.

Lies diesen Teil, bevor du etwas anderes tust

LinkedIns Nutzungsvereinbarung schränkt den automatisierten Zugriff auf die Website ein. Das gilt unabhängig davon, wie dieser Server gebaut ist, und nichts weiter unten ändert daran etwas.

Was dieses Design bewitktel, ist nicht die Gefährdung zu leugnen, sondern sie zu minimieren:

Entscheidung	Warum das das Risiko senkt
Nur menschensgeführt	Jeder Aufruf ist einte, die du gerade bewusst gemacht hast. Nichts läuft nach Zeitplan, nichts läuft, während du schläfst.
Eine Aktion auf einmal	Ein Seitenabruf pro Tool-Aufruf. Keine Scrollschleifen, kein autoretisches Weiterblättern, kein Fan-out.
Deine eigene Session, dein eigener Rechner, deine eigene IP	Kein Cookie geht an Dritte. Kein Proxy, keine Verbreitungs-IP, keine Headless-Farm.
Ein gewöhnlicher Browser, ein Flag	Kein Stealth-Plugin, kein User-Agent- oder Plattform-Spoofing, kein Fingerabdruck-Patching, kein Proxy, keine sich gezeigt getimten Abläufe. Es wird genau ein einzige Flag übergeben – `--disable-blink-features=AutomationControlled`, das verhindert, dass Blink `navigator.webdriver` setzt – weil LinkedIn es bei der Anmeldung prüft und ohne es ablehnt. Das ist alles, es wird beim Start von `readonly.assert_launch_flags_permitted` erzwungen, und `tests/test_launch_boundary.py` lässt den Build fehlschlagen, wenn ein drittes Flag auftaucht.
Nur deine Daten	Deine Profilansichten, deine Bewerbungen, deine gespeicherten Jobs, dein Profil, deine Benachrichtigungen. Kein Auflisten oder Abgreifen anderer Mitglieddaten.
Lesen – ausser drei benannte Schreibvorgänge	Nichts wird eingereicht, gesendet, gepostet, bestätigt, eingehend oder editiert. Das Speichern, das Entfernen und das Nicht-Mehr-Folgen sind die Ausnahmen: standardmäßig aus, eine pro Vorgang, jede von dir gegen einen Monitor bestätigt, der aus einer Live-Anfrage gebaut wurde, mit einem Token, das nur einmal gilt und in zwei Minuten verfällt. Diese App sagte bis 2026-08-23 „Nur lesen", und die Bahn wurde korrigiert, nicht still verbreitert.

*Das senkt das Risiko, beseitigt es aber nicht. Automatisierter Zugriff kann trotzdem eine Ratengrenze, eine Verifikation oder eine Maßnahme mit dem Konto auslösen – und dieses Risiko musst du übernehmen. Entschprich dafür, bevor du den Server registrierst.

Das ist kein Anti-Erkennungs-Tool, und hier ist der Beweis – nicht die Zusicherung

Das eine Chromium-Flag oben ist die Art Ding, die ein Repository aussehen lässt wie ein Umgehungs-Projekt. Es ist wert, klar zu sagen, was tatsächlich gemessen wurde, denn diese Behauptung ist nachprüfbar ist, und der Leser muss sie nicht auf Vertrauen nehmen.

Geprüft am 2026-08-24 über alle 105 erfassten Dateien:

No fingerprint modification: zero. Kein User-Agent-, Plattform-, Locale-, Zeitzonen-, Geolocation- oder Viewport-Spoofing; kein Device-Scale-, WebGL- oder Canvas-Patching; keine page.route-Abfanggung, keein injiziertes Init-Skript, keine extra Header, keine proxy. Jeder davon wurde namentlich im gesamten Paket durchsucht und ergab null Aufrufstellen. Eine Einschränkung zu der: add_init_script steht zweimal in readonly.py, beide Male als das eigene Muster des Scanner, um einen solchen Aufruf zu erkennen. Der Scanner benennt die Dinge, die er verbietet – deshalb enthält seine Quelle sie enthält, der Rest des Pakets nicht. partition_mutation_hits bestätigt das eigenständig: Durch eine erlaubte verändernde Aufrufstelle and zero unauthorized.
Keine Stealth-Abhängigkeit. Vier Abhängigkeiten, keine davon eine Verachtungs-Erkennuungs-Bibliothek, und readonly.scan_source_for_evasion liefert überall im Paket null Treffer – die einzigen Treffer sind eine absichtlich eingepflanzte Kontrollgruppe in einem Test.
Zeitsteuerung ist fest, nicht vermenschlicht. Jede Verzögerung ist eine Konstante. import zufall kommt 0-Mal vor. Der 3‑Sekunden-Abstand zwischen Seitenläden ist MIN_INTERVAL - elapsed, genau schläft – immer maschinisch regulär. Zufälliges Jitter macht, was ein menschliches Nachahmt; ein flache Intervall ist, das zu begrenzen.
Das Flag selbst ist durch ein Gate durchgesetzt, nicht durch gute Absichten: readonly.assert_launch_flags_permitted wird bei jedem Start ausgeführt, und tests/test_launch_boundary` bricht den Build.

**Das Flag verhindert, dass Blink navigator.webdriver anmeldet – was LinkdIn bei der Anmeldung prüft und was einen automatisierten Browser für den eigentlichen Kontoinhaber unbrauchbar macht. Das ist alles. Einen automatisierten Browser betreibbar machen und das Umgehen der Erkennung sind zwei getrennte Dinge, und hier gibt es das.

Die Lizenz ergibt sich daraus, und sie ist bewusst nicht freigebig

Das ist kein Versehen und kein Platz halter. Dieser Server fährt eine authentifizierte LinkedIn-Sitzung unter einer Nutzungsvereinbarung, die automatisierte Zugriff. Eine durchlässige Lizenz würde Fremde einladen, sie auf ihre eigenen Konten zu richten – oder auf andere –, und mit dem Namen des Autors auf dem Repository, das die richtung angibt.

Es ist ein Portfolio-Artefakt. Es ist zum Lesen da, nicht zum Einsatz. Parsing das Design, die Grenze, die Gates und den Prüfpfad; dafür ist es da.

Related MCP server: LinkedIn MCP Server

Was es kann

Tool	Liest
`linkedin_who_viewed_me`	Wer Ihr Profil angesehen hat. Wo das Konto über Premium Career verfügt, reicht der Blick 365 Tage zurück – das höchste Absichtssignal einer Stellensuche.
`linkedin_my_applications`	Stellen, auf die Sie sich beworben haben: mit dem Status, den LinkedIn anzeigt.
`linkedin_saved_jobs`	Stellen, die Sie gespeichert haben.
`linkedin_search_jobs`	Stellensuche mit Schlüsselwörtern, Ort, Remote, Veröffentlichungsdatum und Erfahrungsgrad.
`linkedin_job_detail`	Eine Stellenausschreibung vollständig: die Gehaltsspanne, LinkedIns Bewerberanzahl, Arbeits- und Beschäftigungsart, Einstellungsstatus und die Ausschreibung. Keiner dieser Punkte steht auf einer Such- oder Gespeicherte-Stellen-Karte. Außerdem zeigt `apply_path`: welchen der beiden Bewerbungswege diese Auss Bir verwendet – und beim externen Weg, zu wessen Applicant-Tracking-System es Sie weiterleitet.
`linkedin_followed_companies`	Die Unternehmensseiten, denen Sie folgen, jeweils mit der numerischen ID – an diese richtet sich `linkedin_unfollow_company`. LinkedIn rendert nur ungefähr Zwanzig Zeilen von beliebig vielen Seiten, zeigt keine Methode zum Durchblättern der übrigen: an– dieses Werkzeug meldet also, was it in der Liste abgedeckt hat, ohne zu suggerieren, dass it it abgedeckt in decking the entire list.
`linkedin_my_profile`	Ihr eigenes Profil: Headline, About "About/Skills", Kenntnisse und welche Abschnitte gerendert wurden. Experience/Education/Skills aus load from LinkedIn werden erst nachgeladen, wenn the page scrollen, so support these Ausgaben als "UNKNOWN" (es handelt) not z erwartende "null" an.
`linkedin_notifications`	Ihre Benachrichtigungen.
`linkedin_auth_status`	Ob es eine aktive Sitzung gibt, was anhand einer authentifizierten Anfrage ermittelt wird.
`linkedin_login_browser`	Öffnet ein Fenster, in dem Sie sich selbst anmelden.
`linkedin_session_info`	Ob die Sitzung live ist und wann sie abläuft, aus dem eigenen Cookie-Speicher des Browsers (gelesen). Gibt die Zugangsdaten aus ndevice, the csrf seits Australian CSRFthat trägt, die Dauerhaftigkeit und warum es hier keine stille Reauthentifizierung für period die Sitzung gibt. `renewal.session_lapses_at` ist das Datum, nach the removal die Verlängerung nicht mehr hilft, and Sie sich von Anmeldung per man durchführen von Hand durchführen –THIS THE field compare between prior servers; in der Vergleich between servers is receivable, on LinkedIn it matches the "expiry" date of the cookie itself, because nothing in a environment like this can carry over the session listed beyond this dat.
`linkedin_logout`	Beenden lokalen Anmeldung, indem der Cookie-Speicher dieser Maschine geleert wird. Das einzige destruktive Werkzeug hier an: `confirm=False` (der Standard) führt für nothing through, only preliminary and shows as a preview of what would be done. Issues no request, LinkedIn never knows it.
`linkedin_cdp_status`	Wiederherstellungs-Diagnose: Gibt es einer Chrome-Instanz, an die sich dieser Server and could attach? Nichts auf LinkedIn wird angetrankt.
`linkedin_server_info`	Die Boundaries, the Rate-Einstellungen and the Start-Flags. No need to search the source code for it.

The right to truth – translation "The three tools".

Tool	Was funktion tut
`linkedin_save_job`	Setzt ein Lesezeichen für eine Ausschreibung. Aufruf without `confirm_token` and it doesn't perform anything: it reads the current posting alive, reads live your saved list a and shows returns a block in which the job is identified by its title and industry, in which direction toggle would-switch, where each factivative came from and how to undo the whole thing. Call them again with the token from that block, then it 's executed.
`linkedin_unsave_job`	Gleiche Form, dieselben gates and it verweigert – with: "siehe unten.
`linkedin_unfollow_company`	Die follow of a company-Page ends. As same Formique and the same five Gates. It is designed via the numerische Firmen-ID, not the name. Never by name -- names collide, change and are test – and the click is anchored in the row that itself carries the ID. it is thread you name and the thing that is clicked, giving as exact same Zeile on A construction principle. the row row to be independent by construction – design –

Nach dem klick wird das Ergebnis von einer anderen Oberfläche aus bestitigt – Ihrer gespeicherte Liste, unter Verwendung der eigenen Zählung von LinkedIn auf, itself from the other side of the table no longer its tab, not in the live Button by Klicks. performed gibt zurück true, false oder "unknown". Bei "unknown" nicht erneutholt: Ein erneuter Versuch bei einem Umschalter, der tatsächlich gesinktr hatte, bewirken the precise opposite action.

Das eine, das sich weigert

LinkedIn identifies das Speichern-Steuerelement using semantically not zugänglicher beachten ("accessible name") gehört. Bei jeder Aufnahme that City repo is in its its list resh – four postings, both hydration states, two different days – and all of them see that the label aria-label="Save the job" plus theUnzustand noted unsaved is. The name from "is saved" here the state is saved has never been observed. And can also not be determined through reads: there is nothing on account that is saved, what could serve to seeing this.

Thus:

So linkedin_unsave_job vomits anchor, but this server can't guess one. "Saved" and "Unsave the job" are both plausible, and it has seen was none of them. The refusal dazu includes dem auf which was reasonbetter about the saying "not implemented", because "not implemented" invites someone to implement it by picking string.

The fix is only one dimension line. The first directed save action creates it: The first batch, worth: perform reads nanti, the label to folder it became that changed ctrl immediately, and reports it. You write value in shape.SAVE_LABELS could, and then unsave_job receives its anchor. It is a row of the table, a single Tile of data – not a missing code path.

apply "Bewerben" - one half which with (ships) - and half that does not.

linkedin_job_detail tells tells you how about a posting allows to apply. LinkedIn shows rests that "Bewerben" not button but as a link, you really useful destination can therefore be recognized in passing without its touching at all. apply_path shows for it from three answers:

linkedin_apply – the Bwendung is that filled values in an submitted on LinkedIn.
offsite – LinkedIn Hands you are to the employer's own applicant tracking system. From there Ziel is decode that Comes out of this birthplace the Linkedin's outbound wrapper(The destination is decoded) solely from string materials: no redirect is being followed, no remote host address get contacted. You get Host, so you will know an correctly whose form you are just lying in front of you.
unknown – "Keine but reminder." it didn't say. A isis is a real answer, and a considerable – important, they can be no two the apparas see below.

The one that is andthe leg is valuable half, costs no other potentially an extra "page and one".load in lim and it is pure mais read.

It submits nothing. the true one you have "Bing" one goes the result. Nevertheless – it will not be both, because the Real application is under the remit of this server, but as caused a base based and measured* Reasoner,:

Der Apply-Flow wurde nie aufgezeichnet. In dreizehn Job-Aufzeichnungen gibt es null Formulare, null Datei-Eingabefelder, null Dialoge, null Screening-Fragen und null Steuerelemente, die irgendetwas absenden. Nichts davon hat gesehen, was ausgefüllt oder gedrückt würde. Das ist derselbe Maßstab, an dem unsave_job gemessen wird, angewendet auf die Aktion, die ihn am meisten verdient.
Eine Bewerbung kann von hier aus nicht wieder rückgängig gemacht werden, auf keiner Bestätigungsstufe, unter keinen Umständen. Ein Zurückziehen ist dauerhaft unmöglich.
Der Off-Site-Teil ist nicht die Aufgabe dieses Servers, egal wie gut eine Aufnahme geworden wäre. Ein Formular zu bedienen, das jemand anderem gehört, auf einer Domain, die jemand anderem gehört, unter deren Bedingungen, ist eine anderes Software.

apply_job ist daher vollständig spezifiziert und abgesichert in writes.py, registriert kein Tool und hält keine URL, damit eine Berechtigung dafür bei der Ausgabe verweigert wird, nicht erst bei der Verwendung.

Und die Lücke hat eine Adresse, was sie zu etwas Ungemessenem statt zu etwas Dauerhaftem macht. scripts/_probe_apply_flow.py zeichnet den von LinkedIn gehosteten Flow auf und inventarisiert genau die Steuerelemente, die jeder bestehenden Aufzeichnung fehlen – Formulare, Datei-Eingabefelder, Dialoge, Screening-Fragen, das Steuerelement, das etwas Die abschickt. Es erreicht den Flow per Navigation, nicht per Klick (LinkedIn zeichnet das Apply-Steuerelement als Link), der eigene Mutations-Scanner des Pakets findet darin null mutierende Aufrufe, und wie die Job-ID als Pflichtargument entgegennimmt, sodass kein Standard für dich eine Stellenanzeige auswählt. Es liest außerdem LinkedIn genemerk den eigenen Zähler des „Applied“-Reiters vorher und nachher, weil das Öffnen eines Easy-Apply-Flows einen Draft erzeugen könnte – eine Hypothese, die niemand verifiziert hat, genau als solche gekennzeichnet und gemessen statt vermutet.

Es wurde nicht ausgeführt. Führe es mit jemandem alsAufpasser aus, an einer Stellen, deren apply_path den Wert linkedin_apply hat.

Warum der Classifier darauf besteht, dass mehrere Felder übereinstimmen, wenn ein einziges offensichtliches Feld nach nicht zu genügen habet? JederKandidat wurde gemessen, und jeder scheitert allein: data-view-views="job-apply-button" ist in einer von dreizehn Aufnahmen vorhanden und fehlt bei einem vollständig hydrierten externen Inserat vollständig – sein Fehlen trägt also gebildet gar keine Information. Der ausgehende Wrapper ist generisch – eine Aufsammlung enthält zwei davon, und nur eine ist das Apply-Steuerelementestelement. Der zugänglichbar Name ist das stärkste einzelne Feld, und er ist genau das, which LinkedIn schon geändert hat: Die Zeichenfolge „Easy Apply" kommt in keinem zugänglicher Namenaten vor, immerhin in Fließtext auf derselben Saite, so dass ein Parser, der aus der name, under dem everyone das Feature kennt, nichts findet. Und das Pre-Hydration-Payload ist makey worse als nutzlos – für ein externes Inserat wurde gemessen, dass es den eigenen Marker des alleswegs On-site-Flows trägt, für dieselbe Job-ID – denn LinkedIn versendet die gesamte Apply-State-Machine als musterte per Inserat.

Was es bewusst nicht kann

Messaging, InMail, Verbindungsanfragen. Profiländerungen. Open To Work. Einem Unternehmen folgen. Bewerstellen, liken, kommentieren, Endorsements me. Benachrichtigungen als gelesen markieren. Daten über andere Mitglieder sammeln. Bewerbungen absenden, wie im obigen Abschnitt beschrieben.

Das sind keine fehlenden Features, und es ist nicht alles die gleiche Sorte „Nein“. linkedin_server_info label deteachone as POLICY, MEASURED oder UNMEASURED, because „wir lehnen das aus prinzip ab“, „Wir haben es uns angesehen und es funktioniert nicht“ und „niemand hat es sich angesehen“ statement else, ... drei verschiedene Aussagen. Eine Liste, die eingeeinet, ist so, wie eine ungeprüfte Lücke sich wie eine Design- Ententscheidung liest.

Folgen ist das interessante, und die Begründung hat sich am 2026-08-24 geändert, ohne dass sich die Antwort ändert. Es war block, weil es keinen Die gab – dieser Server konnte den einen Zustand erzeugen, den es nicht zurücknehmen konnte. Eines existiert nun doch. Es is still not tun, because das Rückgängigmachen kann nicht gezielt werden: Eine Aufgabe nannte seinen employer nach Slug, Unfollow-Oberfläche Zeilenadressen nach numerische company id, an no no capturen in this repo carries both for "one company" on an "interm suggest user" aced. Diese Oberfläche gerenderen auch about zwanzig Zeilen von 58 front ohne Paginationssteuerung, damit der größte Teil der Liste in einem Seitenlade nicht erreichbar ist. Die Ablehnung nennt beide und nennt war pay them to lift.

Das Lesen des eigenen Posteingangs ist ungemessen, nicht verweigert. Die Lese-Grenze blockt /messaging, und jede schriftliche Rationale dafür ist gegen Senden formulier that. Whether reading is a chance was never tested. scripts/_probe_messaging.py exists of the test and testing what one usually skips: the hypothesis -- unconfirmed, and that's the point – is, that LinkedIn's Desktop-Messaging-View would open on an arrival conversation, so that a "read" of the Posteingangs would mark a Thread as read, which would be the Notifications-Objection, arriving to a tool that itself calls itself. The prose measures all contributions by reading the Nav-Badge from /feed/ went, runway and after, a surface that load does not touch. It was not run, and the forbidden list is unchanged until the is: a boundary doesn't move on an unmeasured claim.

Anything else that would change on LinkedIn's server, is out of scope, and the tests/test_readonly.py does break the build, if a second mutation call is any way inside in Packet.

One tool changes something on this machine: linkedin_logout(confirm=True) erases local Cookie-Jar. The result no request, so LinkedIn never hears it, and it is linkedin_server_info under the local_state_writes get called to the user, instead of it being folded into the read_only field.

The two side effects, stated instead of hidden

A read that changes something must be med——

Opening the notifications page clears the LinkedIn's unread badge – as if it would be opened by you yourself. Measurable, not theoretical: one call on 2026-08-21 has brought it from 1 to 0, and it is doesn't come back. It can't be avoided: LinkedIn mark the list on the server as seen as soon as the page is surrendered, so there is no read of that surface with the badge sticky without safe the vacation. No click, no scroll, no appointment per single item, and no Mark-as-read call anyplace in the package. Let’s handle the badge not to empty is to not call linkedin_notifications. Since the badge disappears in the right Way anyway, each row gives unread so "LinkedIn as they had at the moment " – remaining the one fact that the page load defeats.
Die Ausführung einer Suche trägt etwas hinzu deinen eigenen Verlauf der letzten Suchen – das Gleiche wie die Frage auf site erstellen.

Beide sind schon in den Doc-Strings der Protokolle – und in linkedin_server_info.

Setup

cd D:\Sundeep\projects\job-hunting\mcp-servers\linkedin
pip install -r requirements.txt
playwright install chromium
python -m pytest            # 986 passed

Dann garniere, sobald der Server bei einem client registriert ist, zuerst linkedin_login_browser auf. **Ein Fenster öffnet sich unter linkedin.com/login. Log dich dort selbst ein — dieser Server sieht, types, produces, stores and transmit passt keines ein ein Passwort. Das persistente Chrome-Profil behält Session danach, so ist es einen einmal pro—bis LinkedIn it with time.

Bestätige er mit linkedin_auth_status, before you trust verlässlichen buildup Draft.

Registrieren

stdio-Transportieren from the entry point linkedin.py:

{
  "mcpServers": {
    "linkedin": {
      "command": "python",
      "args": ["D:\\Sundeep\\projects\\job-hunting\\mcp-servers\\linkedin\\linkedin.py"]
    }
  }
}

How "read-only" is enforced – instead of asserted

linkedin_server/readonly.py four mechanisms are in, and the tests show each of them at a planted violation to fail, before they enter the real package. Check, can't fail voll; it certifies nothing.

Eine Navigations-Allowlist. assert_read_url shut a single door to page.gRUEN general. Every supported URL is a patterned anchor; a typed in keyword cannot navigate to a URL-action that executes something. Blocked targets include /jobs/application/, /messaging/, invitation requests, /edit/, open-to-work, anythingwith „any kind ofaction=“ and every host expected to www.linkedin.com. The job include Post – pattern is the "tightest" on the list: it accepts a numeric ID and **impossible** Query-String um, since the url is made from an integer and thus never lived, which it must preserve. A slug from LinkedIn is (including /jobs/view/senior-node-engineer-at-acme-4600000042`) has got refused for the same cause – because a tag is a job title, and a title is a string.
source-scan. The package is 3pages on calls, to begins the state -- click, fill, type, press, select-option etc, set_input_files a form submit. It searches any other GET in exactly one: the click in writes.perform.

The scanner is not relaxed, ur to allow it. It still always always awaits every mutation call, and one time the new first-line allowlist allows readonly.SANCTIONED_MUTATIONS keyed by (path, function, kind). All three parts blocking something: click the form in dom.py click in write another function write, come true fill into perform he each rejected. And a click hidden in closure one scope, because the attribution goes to the innermost enclosing function; those five near misses (catch), are shown as fail. The package where it is uses a proven method, so contains exactly so many mutation calls as number of entry list – which is what picks up a „second“ click in perform not a triple can distinguish itself of first.

evaluate has the marker: the three read-only DOM tenants with # readonly-ok tail; each new call evaluate has fails in build, until someone allows it in a reviewable diff.

**A tool–surface?. **No tool has a write verb in the name, and no "Docstring" – nothing in code says it definitely does. Docstrings can be to say what a tool cannot do – „has no way to add or remove anything“ is a sentence that a read-only tool must indeed contain, so test the question using negation and not the words.
The launch limit. assert_launch_flags_permitted rejects any Chromium flag outside the two allowed flag; rejects --disable-blink-features unless it carries the exact AutomationControlled – as flag toggles Blinkbehavior. You can't allow sloppy names. browser.py executes it before the good launch, so it's binding at runtime, not only in the CI. A companion Hexe rejects every "anti-detection" library, that appears as dependency (playwright_stealth, undetected_chromedrivers, captcha solvers, TLS-spoof clients), only logs on import – so this document can can can explains the boundary in prose.

The injected scripts are scanned in a separate pass, for anything that can mutate page (.click(, .value =, dispatchEvent(, fetch(-., ...). They only query DOM and read text.

That scan is bound to what's truly runs, not to what is somehow called. The tests parse package, take first argument from every page.evaluate(...), resolve to module-level constant, and scan them -- so a script cannot be inserted without also being read, and a script that these check is unable hold (for because composed at runtime) causes the build to fail at once. The previous version scanned the hand-written list of 3 names from _JS; a calm review cant hold a constant named EVIL_INLINE, enclosing localStorage.setItemasfetch(, through the whole Call site` and moved with green tests, that hole is closed. And the attack is itself now test.

Sibling server shipped of this opposite, in the day before was normal: the moment sistema.

It reports "success" the moment when session cookie appears. LinkedIn gives cookies to logged-out list visitors as well – meaning that sentence success = nothing.

Hier entsteht the verdict from GET /voyager/api/me call – identity call on LinkedIn own web app at page load. An li_at appearing is a reason to request the exchange the `endpoint at best.

The result comes in three states, not two:

authenticated: true -- the endpoint returned identity
authenticated: false – endpoint refused – or returned feed to point to "please log in" page
authenticated: null – not either could make. "Unknown" not "logged out", the server would tell you login again while your session entirely in order.

Corroboration can only ever turn absolutely into "false". Never allowed to generate true from "weaker assumption".

Cookie-Werte sind Anmeldedaten: Sie werden niemals protokolliert, niemals von diesem Server persistiert und erscheinen niemals in einem Tool-Ergebnis. Nur ihr Vorhandensein wird gemeldet, und zwei Tests bestätigen das.

Anmelden und wie lange es dauert

Rufen Sie linkedin_login_browser auf. Ein Chrome-Fenster öffnet sich auf der Anmeldeseite von LinkedIn, und Sie tippen hinein. Dieser Server sieht, tippt, speichert oder überträgt niemals ein Passwort – es gibt keinen Codepfad, der das könnte. Das Fenster bleibt geöffnet, bis der Identitäts-Endpunkt eine echte Sitzung bestätigt, Sie es schließen oder wait_seconds abläuft (Standard 300; übergeben Sie eine größere Zahl, wenn Sie länger brauchen).

Es ist ein einmaliger Schritt, keiner pro Sitzung. Die Sitzung lebt in einem Chrome-Profil auf der Festplatte unter _state/chrome-profile/ und übersteht daher:

Ereignis	Übersteht die Sitzung?	Warum
Dieser Server wird neu gestartet	Ja	Die Sitzung liegt auf der Festplatte, nicht im Prozess.
Die Maschine wird neu gestartet	Ja	Ebenfalls.
Das Profilverzeichnis wird gelöscht	Nein	Dieses Verzeichnis ist die Sitzung.
Abmelden innerhalb des Fensters	Nein	LinkedIn widerruft sie.
LinkedIn lässt das Cookie ablaufen	Nein	Siehe unten.

Wie viel Zeit LinkedIn Ihnen gibt. linkedin_session_info meldet das Ablaufdatum des li_at-Cookies und die verbleibenden Tage, live aus dem Cookie-Speicher des Browsers gelesen – Sie müssen also nie raten, und es ist eine Messung, kein eine Behauptung in einer README. Zur Kalibrierung: Die eigenen langlebigen Cookies von LinkedIn in diesem Profil (bcookie, bscookie) wurden mit einer 365-Tage-Gültigkeit ausgestellt. Der li_at-Wert ist derjenige, der für die Anmeldung maßgeblich ist, und nur eine echte Anmeldung kann ihn erzeugen.

Cookie-Werte sind Anmeldedaten: niemals protokolliert, niemals von diesem Server persistiert, niemals in einem Tool-Ergebnis. Nur der Name, das Vorhandensein und das Ablaufdatum.

Wenn sie abläuft, meldet jedes Lesetool genau das – {"error": "not_authenticated", "message": "..."} – und nennt linkedin_login_browser als den Weg zurück. Es gibt niemals stattdessen eine Liste zurück; eine leere Liste aus einer abgelaufenen Sitzung ist nicht von einer leeren Liste zu unterscheiden, die daher stammt, dass Sie wirklich keine haben.

Der Kaltstart und die Falle darin

li_at ist ein persistentes Cookie. JSESSIONID – das LinkedIn eigene Web-App in den csrf-token-Header kopiert und ohne das der Identitäts-Endpunkt eine authentifizierte Anfrage nicht beantwortet – ist ein Sitzungs-Cookie (is_persistent=0 im Cookie-Store dieses Profils). Bei jedem Browserstart enthält der Store also eine einwandfreie Anmeldung und kein csrf-Token.

Ein Server, der den Identitäts-Endpunkt direkt fragen würde, schickte eine Anfrage ohne Token, würde abgelehnt und man bekäme die Aufforderung, sich neu anzumelden, obwohl die Sitzung in Ordnung war. Bei einem kalten Store lädt check_auth also zuerst eine LinkedIn-Seite, wodurch LinkedIn das Cookie ausstellt, und fragt erst dann. Dieses Laden ist zugleich der bestätigende Lesevortrag und kostet so keine zusätzliche Anfrage.

Der Wiederherstellungspfad: das eigene Chrome verwenden

Nicht der Alltagspfad. Das persibstente Profil oben ist die Antwort; hier ist der Notfallplan für den Tag, an dem die Sitzung dieses Profils stirbt und eine erneute Anmeldung abgelehnt wird. Aktivieren Sie es mit LINKEDIN_CDP_ATTACH=1, und dieser Server startet nichts – er bindet sich über CDP an ein Chrome, das Sie gestartet haben.

Zwei Dinge bringen das still zum Scheitern, beide auf dieser Maschine gemessen:

Ein über die Taskleiste geöffnetes Chrome hat keinen DevTools-Port. „Mein Browser ist geöffnet“ ist nicht genug; es muss mit --remote-debugging-port gestartet worden sein.
Chromes Singleton-Eigenschaft frisst das Flag. Läuft bereits ein Chrome, reicht das Starten eines zweiten mit dem Flag die Argument an das erste weiter und beendet sich – kein Port, kein Fehler, Exit-Status null.

Beenden Sie also zuerst Chrome vollständig (Fenster und die Hintergrundinstanz), damit Ihr echtes Profil und damit Ihre echte LinkedIn-Sitzung erhalten bleibt:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9224

oder geben Sie ihm ein eigenes Profil, das neben Ihrem laufenden Chrome funktioniert, aber an nichts angemeldet ist; in diesem Fenster melden Sie sich dann einmal bei LinkedIn an:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9224 --user-data-dir="%LOCALAPPDATA%\linkedin-cdp"

Das Gelingen bestätigen Sie durch das Öffnen von http://127.0.0.1:9224/json/version – JSON bedeutet, der Port ist aktiv. Oder Sie rufen linkedin_cdp_status auf, das für Sie testet und das Verbindungskommando meldet, wenn nichts antwortet. Die Adresse ist 127.0.0.1 und nicht localhost: Chrome bindet den Port nur auf IPv4 an; der Name löst daher zuerst zu [::1] auf und ein Timeout vergeht (gemessen 2085 ms gegenüber 35 ms).

Port 9224, bewusst nicht den Port 9223 des benachbarten Naukri-Servers.

Im Anbindungsmodus übernimmt dieser Server keine Profilsperre (er hat kein Profil), arbeitet in einem eigenen Tab und beim Herunterfahren trennt er die Verbindung, ohne Ihren Browser zu schließen – Playwrights close() auf einer CDP-Verbindung verwirft nur den Client; das wurde an einem echten Chrome gemessen, bevor derart vorgenommen wurde. Die Nur-Lese-Allowlist ist in beiden Modis identisch.

Raten-Disziplin

Ein pauschales Mindestintervall der 3 Sekunden zwischen jedes Seiten laden, global erzwungen. Throttling, keine Tarnung: es wird bewusst nicht gejit't, um irgendetwas zu ähneln.
Wer eine Seite pro Tool-Aufruf lädt. Die einzige Ausnahme ist linkedin_my_profile(include_skills=True), die eine zweite Seite lädt und pages_loaded: 2 meldet.
Kein automatisches Umblättern. Fragen Sie die nächste Seite einer Suche ganz bewusst mit start=25 an. Jedes Listenergebnis trägt capped, page_had und limit, damit „25 Ergebnisse“ nie mit „25 Ergebnisse gibt es“ verwechselt wird.
Ein Aufruf nach dem anderen, serial im Prozess; ein Prozess nach, serialisiert durch eine prozessübergreifende Sperre auf das Chrome-Profil. Wenn zwei Prozesse auf einem Chromium-Benutzerdatenverzeichnis liegen, beschädigen sie es und die Sitzung ist weg – das hat einen benachbarten Server betroffen.
Das Fenster bleibt nicht dauerhaft geöffnet. Der Browser schließt nach 5 Minuten Inaktivität und gibt die Sperre frei.

Wenn etwas nicht gelesen werden kann

Der Server wirft eine Exception, statt eine leere Liste zu liefern. Eine leere Liste einer Seite, die nicht gerendert werden konnte, ist nicht von einer leeren Liste zu unterscheiden, die daher kommt, dass Sie wirklich nichts vorhanden sind, und diese beiden müssen niemals verwechselbar sein. Ein fehlgeschlagener Lesungsversuch kommt als {"error": "extraction_failed", "url": ..., "hint": ...} zurück, damit Sie selbst dieselbe Seite öffnen und sehen können, was sie gesehen hat.

Die einzige Ausnahme ist linkedin_search_jobs, dort ist null Ergebnisse eine echte Antwort; es liefert results: [] mit einem note-Feld.

Wie die Seiten gelesen werden

LinkedIn-Klassennamen werden generiert, und die GraphQL-Query-IDs rotieren mit jedem Deployment, beides sind daher brüchige Anker. Was sich nicht ändert, ist die Form eines Links: eine Person liegt hinter /in/<slug>, ein Job dahin /jobs/view/. Jede Listenfläche wird geerntet, indem diese Links gefunden und der Text der Karte um sie herum gelesen wird, dann mit puren Funktionen in shape.py geparst wird – genau aus diesem Grund ist das Parsing ohne Browser, Netzwerk und Konto testgetrieben.

Benachrichtigungen sind die einzige Fläche ohne zuverlässigen Link im Element selbst, daher ist der Anker die Struktur. Diese Seite ist am ehelichsten Pflege erforderlich und wirft bei den Fehlen eine Exception statt einer leeren Liste.

Layout

linkedin.py              entry point (stdio)
linkedin_server/
  config.py                  paths, timeouts, caps, the rate floor,
                             the two launch flags
  readonly.py                the allowlist, the scanners, the verb list,
                             the launch boundary
  profile_lock.py            cross-process lock on the Chrome profile
  browser.py                 persistent context, single-flight, idle close
  auth.py                    the login gate, session lifetime, cold start
  cdp_bridge.py              the recovery path: attach to a running Chrome
  dom.py                     the read-only harvesters and the control readers
  shape.py                   pure parsers and the result envelope
  server.py                  the seventeen tools
  errors.py
tests/                       1393 tests, no network, no account
  fixtures/                  frozen LinkedIn markup, scrubbed

Workstate

Gebaut und getestet: 1393 Tests, ohne Netzwerk und ohne Konto. Die meisten laufen ohne Browser; die fixture-basierten Module starten einen lokal headless Chromium, um die echten Read-Bibliotheken über eingefrorenes Rendering laufen zu lassen, das nichts außerhalb der Maschine erreicht.

Diese Zahlen sind die, die in dieser Datei am häufigsten falsch waren. Sie zeigte 986 über drei Releases, nachdem die Suite tausend überschritten waren, was für sich unschädlich ist und dieselbe attitude, vier Dokumente erklärten, der Server könne nicht schreiben. Sie werden nun bei jedem Release neu gemessen und nicht einfach fortgeschoben.

Erster Live-Lauf: 2026-08-21. Die Anmeldung war erfolgreich und die Sitzung blieb im Profil bestehen; daher ist das Merkmal jetzt auf dieser Maschine als ausreichend verifiziert, außerdem sind /voyager/api/me und die Lebensdauer von li_at (365 Tage) bestätigt. Danach wurde jedes Lotool genau einmal gegen das echte Konto ausgeführt. Vier der elf funktierten; der Untersuchungsansatz ist beschrieben in ../_audit/2026-08-21-linkedin-parse-fix.md, und zwar was festgestellt wurde.

linkedin_who_viewed_me lieferte Namen, die keine Namen waren. Jede Zeile trug die Seitenüberschrift, „Wer hat Ihr Profil angeschaut", verknüpft mit einem echten Personen-Profil-Link: vier Zeilen, ein wiederholter Name, und alle vier Links waren wirklich echt. Es wurde am selben Tag behoben: Die Zeilengrenze hängt nicht länger von einem Attribut ab, das LinkedIn erst nach Hydration einhängt; durch Datenschutz eingeschränkte Personen werden nicht mehr stumm verworfen (es waren sechs von zehn), und die Zeitstempel werden gelesen. Ein live verifiziert: 10 Zeilen, 10 verschandelte Namen, keinsstaff fehlt.

Zweiter Durchlauf, 2026-08-22. Die drei Surfacedaten, die der erste Durchlauf unfertig hinterließ, wurden repariert und live verifiziert. Alle vier Fehler hatten dieselbe Form: ein Parser, der an einem Markup hing, das LinkedIn nicht mehr ausgibt, oder an Markup, dessen Vorhandensein davon abhängt, wie weit die Seite gerendert wurde.

Tool	war	jetzt
`linkedin_my_profile`	Fehler: Kein Name lesbar	liest Name, Headline, Ort, „Über“ und Foto von einer Seite mit null `h1`. Ein Abschnitt ist jetzt der größte Vorfahre seiner Überschrift, die exakt EINE Überschrift enthält – dieselbe Regel, die auch der Zeilenlauf nutzt – daher identische Ausgabe vor und nach der Hydratisierung. Live verifiziert.
`linkedin_saved_jobs`, `linkedin_my_applications`	Fehler beim Weiterleitungs	last `/jobs-tracker/?stage=saved` und `?stage=applied`. Beide Listen sind wirklich leer; ein leeres Ergebnis sagt das jetzt explizit, mit Of LinkedIins Tab-Zähler und dem "Dder wurden bis ein`t" empty-state Text. Eine Null, die die Seite nicht bestätigt, bleibt Fehler. Live verifiziert.
`linkedin`notifications`	`Zeilen, Rauschen`	darlet Screen-Reader-Text wird nach Anzahl abgezogen, statt nach Position, und `when` kommt aus dem eigenen Zeit-Element der Karte. Jede Zeilstücke `unread` so wie beim Lesen. Verifiziert gegen einen eingefrorenen Schnappschuss der LiveSeite.
skills, innerhalb `my_profile`	lieiterte `All`, `Industry Knowledge`, `Tools & Technologies`	liefert die echte Liste – also 20 Fähigkeiten im Live-Konto –, übergelagert auf den einzigen Pro-Fähigkeit-Anker, den die Seite zu redet.

Eine Sache macht der Profil-Leser nicht: Erfahrung, Ausbildung und Skills stehen überhaupt nicht auf der Profilseite. Sie werden nachgeladen, LinkedIn lädt sie erst durch Scrollen, und dieser Server scrollt nicht. Sie stehen als UNKNOWN, nie als 0, und details_urls liefert Ihnen die Seite für jeden Eintrag.

Dritter Durchlauf, 2026-08-22. linkedin_search_jobs war das letzte defekte Werkzeug. Bei einer Zeile für ein verifiziertenes Arbeitgebers fügt LinkedIn eine Zeile für Screenreaders hinzu, die im Fragment „ mit der Vorverifikation“ liest; Positional gelesen wurde das zu company und drückte der echte Arbeitgeber in location – 5 von 14 Zeilen bei zwei Live-Suchen betroffen.

Die Korrektur ist keine Regel, die diese Zeichenfolge betrifft. Felder werden nicht mehr als „Zeile 1, Zeile 2, Zeile 3“ gelesen, denn jede Zeile, die LinkedIn einfügt, verschiebt alle danach liegenden Felder; dieselben zwei Seiten enthielten außerdem „Gesponsert“, „Jetzt bewerben“, „Angesehen“, „Prüft aktiv Bewerbungen“, einen Gehalts-Chip und eine Alumni-Zeile. Jedes Feld ist jetzt an dem verankert, was es IDENTIFIZIERT: der Titel an dem Text des Links, der die Zeile zur Job-Zeile macht, wobei die eigenen Screenreader-Kopien der Seite zahlenmäßig abgezogen werden; das Unternehmen an dem zugänglichen Namen, den LinkedIn dem Logo des Arbeitgebers gibt, dass ein Bild ist und sich durch eine eingefügte Zeile nicht verschieben lässt; der Standort an der Metadatenliste im Entity-Lockup, wobei das Lockup ohne jeder Klassennamen als die kleinste Vorfahre des Links gefunden wird, der ebenfalls dieses Logo enthält. Eine Oberfläche, die keines dieser Anker enthält – der Job-Tracker bietet keinen –, fällt wie zuvor darauf zurück, die Zeilen der Reihenfolge nach zu lesen. Live mit derselben Suchanfrage verifiziert: 7 von 7 Zeilen stimmen mit den LinkedIn-eigenen artdeco-entity-lockup-Elementen überein, die die Korrektur bewusst nicht verwendet, und 3 dieser 7 trugen die Verifizierungs-Dekoration. Die Tests injizieren an jeder Position in jeder eingefrorenen Zeile eine Dekoration, die LinkedIn nicht ausgeliefert hat, und verlangen, dass sich die Antwort nicht bewegt; die kontrolle zeigt, dass dieselbe Injektion die Feldernicht, sobald die Anker entfernt werden.

Available Tools

17 tools

linkedin_auth_statusA

Report whether there is a live LinkedIn session, measured not guessed.

The verdict comes from an authenticated request: GET /voyager/api/me, the same identity call LinkedIn's own web app makes on page load. A session cookie sitting in the profile proves nothing and is never treated as an answer -- LinkedIn hands cookies to signed-out visitors too.

Three outcomes, deliberately:

authenticated true -- the endpoint returned an identity.
authenticated false -- the endpoint refused, or the feed redirected to LinkedIn's signed-out wall.
authenticated null -- neither could be established. Unknown is reported as unknown rather than collapsed into "signed out".

Costs up to two requests: the identity call, plus one feed load used only to turn an inconclusive answer into a definite "false".

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses the internal behavior: makes up to two requests, uses the identity endpoint, treats cookies as unreliable, and explicitly defines the null case as 'unknown' rather than 'signed out'. This level of detail is transparent and goes well beyond basic expectations.

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 structured with a clear opening statement, followed by detail and bullet-point outcomes. Every sentence adds value: it explains the measurement method, the meaning of each outcome, and the cost. It is thorough without being verbose, and the front-loaded core statement makes it easy to grasp quickly.

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?

Given that the tool has no parameters, an output schema exists, and the description thoroughly explains the semantics of each outcome, nothing is missing. It also covers edge cases (e.g., cookies from signed-out users) and costs, making it complete for an agent to use correctly.

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?

The tool has zero parameters, so the description correctly does not discuss any. Per the calibration rules, a baseline of 4 is appropriate since there are no parameters to explain and the schema coverage is 100% (empty schema). The description doesn't need to add anything beyond that.

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 clearly states the tool's purpose: to report whether there is a live LinkedIn session, and it specifies the exact method (authenticated GET /voyager/api/me). It distinguishes itself from siblings like linkedin_session_info by emphasizing it measures actual authentication status, not guessed from cookies.

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?

The description effectively communicates when to use this tool—whenever an agent needs to determine authentication status. It explains the methodology and the three possible outcomes, making it obvious how to interpret results. However, it does not explicitly name alternative tools or state when not to use it, so it misses the highest bar for usage guidance.

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

linkedin_cdp_statusA

Is there a browser this server could attach to? A recovery diagnostic.

NOT the normal way to run this server, and not something to reach for first. The daily path is the persistent Chrome profile: sign in once and it holds for as long as LinkedIn honours it. This exists for the day that profile's session dies and an automated sign-in is being refused -- then the operator can run his own Chrome with a DevTools port open and let this server read through that instead.

It needs a Chrome that is ALREADY RUNNING and that was started with --remote-debugging-port. A browser opened from the taskbar has no such port, so "my browser is open" is not enough. Worse, when a Chrome is already running, a second one started with the flag silently hands its arguments to the first and no port opens at all -- so either quit Chrome completely first, or give the new one its own --user-data-dir.

This touches nothing on LinkedIn. It asks the local port what is there and reports the answer, or the exact command to run when nothing answered.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool touches nothing on LinkedIn, only queries the local port, and reports the answer or the exact command to run when nothing answers. This fully discloses side effects (none) and expected outcomes, making behavior transparent and safe to invoke.

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?

Although the description is relatively long, every sentence earns its place. It front-loads the purpose and the 'not the normal way' nuance, then details prerequisites and pitfalls, and finishes with the safety guarantee and output behavior. The structure is logical and efficient, with no filler.

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?

The description is complete for a no-parameter diagnostic tool with an output schema. It explains the tool's role, when to use it, prerequisites, common failure modes, side effects, and how the result is reported. Nothing an agent needs to decide whether and how to call it 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?

The tool has zero parameters, and the schema confirms an empty object. The description does not need to explain parameters, and the baseline for no parameters is 4. It adds nothing beyond that, but nothing is needed—the schema already fully covers the parameter surface.

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 clearly states the tool's purpose: checking for an attachable browser, explicitly framing it as a recovery diagnostic. It distinguishes this from the normal persistent-Chrome-profile path and names the alternative clearly, so an agent can tell this tool apart from its siblings like linkedin_auth_status or linkedin_server_info.

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?

The description explicitly explains when to use this tool (when the profile session dies and automated sign-in is refused) and when not to use it (not the first choice, not the daily path). It also provides operational prerequisites (Chrome already running with --remote-debugging-port) and warns about the second-instance pitfall, giving concrete guidance that leaves no ambiguity.

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

linkedin_followed_companiesA

The company Pages LinkedIn records you as following.

A read, and the exact counterpart of linkedin_saved_jobs: it answers "is this Page already on the list?". This server cannot follow or unfollow anything and ships no tool that could.

THE ONE THING TO READ BEFORE TRUSTING AN ANSWER. LinkedIn draws only the first rows of this list and fetches the rest on scroll; this server opens one page and reads whatever had drawn. So complete is normally false -- measured 2026-08-23, twenty rows under a heading saying 58 Pages -- and a Page missing from pages comes back as UNKNOWN, never as not-followed. Three-valued on purpose: "absent from the rows I was shown" and "you are not following them" are different facts, and reporting the first as the second is how a confirm gate ends up pointing the wrong way.

For a SINGLE employer whose posting you already have, linkedin_job_detail is the better read: it reports company_follow_state off the posting page itself, at no extra page load, and that answer is never partial.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	how many rows to return.
`company`	No	a Page name or numeric Page id to ask about. Leave it out to get the whole rendered list.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the burden and does so excellently. It discloses the incomplete list due to scrolling, that 'complete' is normally false, and explains the three-valued semantics (UNKNOWN vs not followed) to avoid misinterpretation. It also notes the server's read-only nature.

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?

Although long, every section earns its place. The critical caveat is front-loaded in a bolded warning, and the structure guides the reader from core purpose to alternatives. Nothing is redundant; it's dense but efficient.

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?

The description covers purpose, limitations, alternatives, and parameter usage thoroughly. Since an output schema exists to explain the return shape, nothing essential is missing. An agent can confidently decide when and how to use this tool.

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?

Both parameters are already well-documented in the schema (100% coverage). The description adds a slight extra: 'Leave it out to get the whole rendered list' for the company parameter, which provides context beyond the schema. Given the high schema coverage, this is adequate but not extensive.

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 clearly states the resource (company Pages you follow) and the action (list/read). It explicitly identifies itself as the counterpart of linkedin_saved_jobs and answers 'is this Page already on the list?', which precisely distinguishes it from mutation siblings like linkedin_unfollow_company.

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?

It explicitly names linkedin_job_detail as the better alternative for a single employer, explains why (reports company_follow_state directly from the posting page, never partial), and clarifies that this server cannot follow or unfollow anything. This gives clear when-to-use guidance and prevents misuse.

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

linkedin_job_detailA

Read one job posting in full, including the description and the pay.

Every list tool here returns CARDS -- title, company, location, link. This reads the posting behind one of them, which is where the facts that settle a decision actually live: the pay range, LinkedIn's own applicant count, the workplace and employment type, the hiring status, and the description itself. None of those is on any card.

One page load, one posting. There is no sweep and no paging.

A read in both directions: this does not apply to the job, does not save it, and has no way to change anything about the posting. Nobody else on the page is collected either -- LinkedIn draws a hiring team and a "people also viewed" rail beside a job, and neither is read here.

A field the page did not carry comes back null rather than blank. If the page did not render the posting at all the call FAILS instead of returning an empty one: LinkedIn serves the document title before the body, so a title with nothing behind it is never treated as an answer.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes	the numeric job id, or a job url to take it from -- linkedin_search_jobs and linkedin_saved_jobs both return each.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

There are no annotations provided (readOnlyHint, destructiveHint are absent), so the description carries the full burden of disclosing behavioral traits. It does this well: it states that this tool does not apply to the job, does not save it, and has no way to change anything about the posting; it also clarifies it does not collect other people on the page. It describes null vs. FAIL behavior for missing fields and unrenderable pages. The only small gap is that it doesn't explicitly mention auth requirements or rate limits, but for a read-only tool with one page load, the disclosure is thorough and covers the key side effects and failure modes.

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 description is well-structured and front-loaded: the first sentence states the core purpose, then it builds context about what cards lack, confirms the one-page behavior, clarifies non-effects, and explains null/fail semantics. It is a bit longer than strictly necessary (around 150 words) but every paragraph earns its place by addressing a distinct aspect: what this gives, what it does not give, and the specific edge case. The structure is clear and uses paragraphs to separate logical blocks. Slightly verbose in places (repeats 'this does not apply...' phrasing), but overall effective.

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?

Given the complexity is simple (one parameter, no nested objects) and there is an output schema (has_output_schema=true) that presumably describes the returned fields, the description covers the critical runtime behaviors an agent needs: what data is available, the distinction from sibling list tools, the null vs. FAIL semantics, and the explicit side-effect-free nature. The description fully equips an agent to decide when to call this tool and what to expect. The only potential missing detail is the exact output fields, but that is covered by the output schema, so the description is complete.

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?

The schema has a single parameter, job_id, with 100% description coverage (the schema already describes it as the numeric job id or a job URL from two sibling tools). The description reinforces this by mentioning that both linkedin_search_jobs and linkedin_saved_jobs return it, but does not add new meaning beyond what the schema gives. Since coverage is 100% and the description adds a small hint about which tools return the id, a score of 4 is appropriate—slightly above baseline because the description confirms the source of the parameter value, which is useful for an agent.

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 opens with a direct, specific statement of what the tool does: 'Read one job posting in full, including the description and the pay.' It clearly identifies the resource (one job posting) and the verb (read). It goes further to distinguish itself from sibling list tools, explaining that this tool retrieves the full posting behind a card, and explicitly lists the facts available only here (pay range, applicant count, etc.). This fully separates it from the list/collection siblings (linkedin_search_jobs, linkedin_saved_jobs) and from action tools (linkedin_save_job, linkedin_unsave_job).

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?

The description is explicit about when to use this tool vs. the sibling list tools: it explains that list tools return only cards with title, company, location, link, while this tool is where the decision-settling facts live. It states there is one page load, no pagination, and explicitly mentions it does not read the 'people also viewed' rail or hiring team. It also provides clear behavioral conditions: the call FAILS if the page did not render the posting, and it treats a title-only page as an error. This gives an agent unambiguous selection criteria.

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

linkedin_login_browserA

Open LinkedIn's sign-in page and wait for you to sign in yourself.

This server never sees, types, stores or transmits a password. It opens a browser window at linkedin.com/login; you type into that window; the persistent Chrome profile keeps the session afterwards, so this is a one-time step until LinkedIn expires it.

The window stays open until the identity endpoint confirms a real session, the window is closed, or wait_seconds runs out. A cookie appearing does not end the wait -- it only causes the endpoint to be asked again. On timeout the result is authenticated false with a reason, never an optimistic success.

ParametersJSON Schema

Name	Required	Description	Default
`wait_seconds`	No	how long to leave the window open for you. Default 300.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden — and it excels. It discloses that the server 'never sees, types, stores or transmits a password,' that the persistent Chrome profile retains the session, and crucially the non-obvious cookie nuance: 'A cookie appearing does not end the wait — it only causes the endpoint to be asked again.' It also states the no-optimistic-success guarantee on timeout. This prevents a common agent failure mode of assuming cookie presence means logged in.

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 purpose in the first sentence, and every subsequent sentence earns its place: the password privacy guarantee, the persistent-profile behavior, the termination conditions, and the cookie/timeout nuance. Nothing is filler; the multi-paragraph length is justified by the density of non-obvious behavioral information.

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?

Given the tool's interactive-browser complexity and the presence of an output schema, the description covers everything an agent needs: how the interactive flow works, the three termination conditions, the meaning of wait_seconds on timeout, and the return semantics. The one-time-step framing sets expectations correctly. Nothing essential 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% and the schema already documents wait_seconds with a default. The description adds value beyond the schema by tying the parameter to observable behavior: 'On timeout the result is authenticated false with a reason, never an optimistic success.' This connects the parameter to the wait-termination and result semantics, which is genuine value added over 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?

The description opens with a specific verb+resource+behavior: 'Open LinkedIn's sign-in page and wait for you to sign in yourself.' This clearly distinguishes it from siblings like linkedin_auth_status (checking status) and linkedin_session_info (session info). An agent immediately knows this tool initiates interactive login rather than inspecting or acting on the session.

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?

The description conveys the key usage fact that this is 'a one-time step until LinkedIn expires it,' which tells the agent not to expect repeated calls. However, it does not explicitly route to alternatives such as checking linkedin_auth_status first to determine whether login is even needed. The context is clear but lacks explicit when-not/alternative guidance.

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

linkedin_logoutA

End the local LinkedIn session by erasing this profile's cookie jar.

THE ONE DESTRUCTIVE TOOL IN THIS SERVER, and the most expensive thing it can do to you. The sign-in it throws away took a full day to establish, and there is no automated way to put it back: linkedin_login_browser opens a window and you type into it yourself, exactly as you did the first time.

So confirm is False by default and an unconfirmed call performs NOTHING AT ALL -- no file is opened, no file is even stat-ed, no browser starts, the profile is not read. It hands back a preview naming the exact files a confirmed call would erase, what the sign-in cost, and how you get back in. Read that first; nothing about this is reversible afterwards.

Nothing here reaches LinkedIn. This server stays read-only towards the platform: no request goes out, no session is ended on LinkedIn's side, your account is untouched, and any other browser signed in to it stays signed in. What lapses is purely local -- the cookie jar on this machine.

A profile another process is using is never touched. If the cross-process lock is held, the answer is cleared false naming the holder's PID, because erasing a jar out from under a live Chromium is how a profile gets corrupted -- which costs the same day this tool is asking about.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	No	False -- the default -- previews and performs nothing. True erases the jar.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It thoroughly discloses the destructive nature, the confirm-gated behavior (including that unconfirmed calls do nothing), the local-only scope (no remote impact), and the cross-process lock protection. It is transparent about irreversibility and side effects.

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 description is lengthy but every paragraph serves a safety-critical purpose: purpose, consequences, confirm behavior, local-only scope, and lock protection. It is front-loaded with the core action, and structure is logical. While it could be trimmed, the verbosity is justified for a destructive tool.

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?

Given the tool's destructive complexity and absence of annotations, the description covers all essential aspects: the action, the confirm gate, preview behavior, irreversibility, recovery path, remote non-effect, and cross-process lock. The output schema exists separately, so return value details are not required here.

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?

The input schema already provides a description for 'confirm' that exactly matches the text in the tool description ('False -- the default -- previews and performs nothing. True erases the jar.'). Since schema coverage is 100%, the description adds no additional semantic value beyond reiteration; the baseline of 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?

The description opens with a specific verb and resource: 'End the local LinkedIn session by erasing this profile's cookie jar.' It clearly distinguishes itself as the sole destructive tool among siblings, making selection unambiguous.

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?

It explicitly warns that this is the one destructive tool and explains the cost of recovery, pointing to linkedin_login_browser as the alternative for re-establishing a session. The description implies when to use it (when you intend to end session) and strongly cautions against casual use, providing clear usage context.

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

linkedin_my_applicationsA

List the jobs you have applied to on LinkedIn, with their status.

Reads the Applied tab of your own job tracker (the page My Items > Applied became). Each row carries title, company, location, the status LinkedIn shows (applied, application viewed, resume downloaded, no longer accepting applications) and how long ago, plus the job id and link.

Status is whatever LinkedIn displays; this server does not infer, score or chase anything, and it cannot see applications you made anywhere else.

An empty result says so explicitly and carries LinkedIn's own count for the tab, so "you have applied to nothing" and "this could not be read" are never the same answer. If the two disagree -- no rows, but a non-zero count -- you get an error rather than an empty list.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	maximum rows to return (default 25, max 100).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses that status is whatever LinkedIn displays, that the server does not infer or chase, and explicitly explains edge cases: empty results carry LinkedIn's count, and a mismatch between rows and count yields an error. This is exceptionally transparent about behavior.

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 description is multi-sentence and a bit longer than strictly needed, but every sentence adds value: scope, row contents, status behavior, and edge cases. It could be tightened slightly, but it is well-structured and front-loads the primary action.

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?

The description explains row contents (title, company, location, status, how long ago, job id, link), clarifies that statuses mirror LinkedIn's display, and covers empty-result and error disambiguation. Given the simple schema and the presence of an output schema, this is complete enough for an agent to call correctly.

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 description coverage is 100% for the only parameter (limit), and the schema already documents its behavior fully. The description adds no further parameter details, so the baseline score of 3 is appropriate per the scoring rules.

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 exactly what the tool does: 'List the jobs you have applied to on LinkedIn, with their status.' It names a specific resource (own job tracker's Applied tab) and the action (list), and clarifies it reads only your own applications. This clearly distinguishes it from siblings like saved_jobs or search_jobs.

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?

While it doesn't explicitly name alternative tools or say when not to use it, the description makes the scope obvious: it reads only the Applied tab and cannot see applications made elsewhere. This is sufficient guidance for an agent to know when to invoke it versus other job-related tools.

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

linkedin_my_profileA

Read your own LinkedIn profile as LinkedIn currently stores it.

Returns name, headline, location, the About text, and which sections were on the page when it was read.

On completeness: LinkedIn's own profile-strength meter is not exposed here, so this server does not report one. What it reports is derived and labelled as such.

One honest limitation, stated because its absence would otherwise read as data: LinkedIn now defers Experience, Education and Skills until the page is SCROLLED, and this server does not scroll. Those sections are therefore usually absent from the render, and absent means UNKNOWN here, never zero. sections_not_rendered names them, and details_urls gives you the page for each one if you want to look yourself.

ParametersJSON Schema

Name	Required	Description	Default
`include_skills`	No	also load the full skills page, which is where a real skills list can be read. That is a second page load, reported as pages_loaded: 2. Pass false to stay at one.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It is exceptionally transparent: it explains that LinkedIn defers certain sections until scrolling and that this server does not scroll, so those sections are usually absent and reported as UNKNOWN, not zero. It also admits the profile-strength meter is not exposed and that derived data is labelled as such.

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 longer than average but every sentence adds information: it states the purpose, enumerates outputs, discloses limitations, and clarifies how to interpret absence. It is well-paragraphed and front-loads the core purpose before diving into nuance. No filler exists.

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 read-only profile tool with an output schema, the description covers all necessary aspects: what is returned, the caveat about missing sections, how to interpret missing data, and a hint about the details_urls for further investigation. The 'include_skills' parameter behavior is also disclosed through the schema. Nothing an agent needs to call and interpret the tool correctly is omitted.

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?

There is a single parameter, include_skills, and its schema description is already very informative, explaining the effect (additional page load, pages_loaded: 2) and the trade-off. The description itself does not elaborate on the parameter, but because the schema coverage is 100% and the schema text is detailed, the parameter semantics are clear. A score of 4 reflects the extra value of the schema description beyond a bare type.

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 uses a specific verb and resource ('Read your own LinkedIn profile') and immediately lists the concrete output fields (name, headline, location, About text, sections). It clearly distinguishes itself from siblings by focusing on the user's own profile and explicitly notes what is not included (profile-strength meter).

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?

The description explains when the tool is appropriate (reading your own profile) and provides guidance on handling missing sections by pointing to details_urls. It does not explicitly contrast with sibling tools, but the tool name and the content give enough context for correct selection. The explanation of the 'include_skills' parameter also adds usage context.

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

linkedin_notificationsA

List your LinkedIn notifications as they appear on the notifications page.

====================== SIDE EFFECT -- READ FIRST ====================== THIS TOOL CHANGES SOMETHING ON LINKEDIN. Loading the notifications page CLEARS YOUR UNREAD BADGE -- every notification LinkedIn was still counting as unread stops being counted, exactly as if you had opened the page yourself. MEASURED, not theorised: one call on 2026-08-21 took the badge from 1 to 0, and it does not come back.

It cannot be avoided. LinkedIn marks the list seen on the server when the page is served, so there is no read of this surface that leaves the badge alone: no click, no scroll and no per-item open is involved, and there is no mark-as-read call anywhere in this package. The only way not to clear the badge is not to call this tool.

It is the ONE server-side change any tool here causes. Everything else in this package leaves LinkedIn exactly as it found it.

Partial compensation, since the badge is going either way: each row carries "unread": true/false as LinkedIn had it AT THE MOMENT OF READING -- which is the fact the page load is about to destroy. Read it here or lose it.

Rows carry the notification text, how long ago it arrived, whether it was unread, and the link LinkedIn attaches. Screen-reader-only text ("Unread notification.", "Status is reachable") is stripped, so the body is what you would read on screen.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	maximum notifications to return (default 20, max 50).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

Annotations are absent, so the description carries the full burden — and it delivers exceptionally. It discloses the badge-clearing side effect with a dated measured example (badge 1→0), states it is unavoidable, confirms this is the only server-side change in the package, and describes the partial compensation (unread flags captured at read time) plus input stripping behavior. This is model behavioral 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 description is long (~300 words), but the length is earned: the side-effect disclosure requires specific, verifiable detail. The purpose is front-loaded before the warning block, and the block formatting makes the critical information visually distinct. Minor deduction for verbosity in the compensation paragraph, which could be tightened.

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 single-parameter list tool with full schema coverage, an output schema, and a thoroughly disclosed side-effect profile, nothing an agent needs to call it correctly is missing. Return format is described in prose (notification text, time, unread flag, link), complementing the output schema.

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 description coverage is 100% — the single 'limit' parameter (default 20, max 50) is fully documented in the schema. The description adds no parameter-specific meaning beyond the schema, which the rubric sets as the baseline 3. Nothing beyond the baseline, but nothing missing either.

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 first sentence states a specific verb (List) and resource (your LinkedIn notifications) with a clear frame of reference ('as they appear on the notifications page'). It is unmistakably distinct from the sibling tools, all of which cover auth, sessions, jobs, or profile surfaces — no other tool claims the notifications surface.

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?

The description does not explicitly name an alternative, but none of the siblings overlap with notifications, so exclusion guidance is unnecessary. It instead provides strong context on when NOT to call: the side-effect block makes the cost explicit ('The only way not to clear the badge is not to call this tool'), which functions as clear usage guidance. Slight deduction for not naming an alternative, though no natural one exists.

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

linkedin_saved_jobsA

List the jobs you have bookmarked on LinkedIn.

Reads the Saved tab of your own job tracker: title, company, location, when it was posted where LinkedIn shows it, and the job link.

Read-only in both directions -- this lists what you saved and has no way to add to or remove from the list.

An empty result says so explicitly and carries LinkedIn's own count for the tab, so an empty list can never be mistaken for a read that failed.

The tracker also holds In Progress, Interview and Archived tabs. They are not exposed as tools: this reads the two lists it names and nothing else.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	maximum rows to return (default 25, max 100).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations at all, the description carries the full disclosure burden and handles it well. It explicitly declares read-only behavior in both directions (covering what destructiveHint would normally signal) and gives a strong edge-case guarantee: an empty result is stated explicitly and carries LinkedIn's own count, so an empty list can never be misread as a failed call. This is the kind of behavioral detail agents genuinely need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening line is profitably front-loaded, but the body is somewhat verbose for a single-parameter list tool and contains an internal inconsistency: the last sentence says 'this reads the two lists it names' when only one list (the Saved tab) is actually named. Phrases like 'when it was posted where LinkedIn shows it' are clunky. The redundancy around read-only scope could be tightened.

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?

Given the tool's simplicity (one optional parameter, no required inputs, an output schema present), the description is more than sufficient. It covers the safety profile, the exact scope, and the empty-result edge case, leaving no gap an agent needs to fill before calling it. The 'two lists' wording is a minor editorial slip, not a completeness failure.

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?

The schema covers 100% of the single parameter (limit) with a complete description ('maximum rows to return (default 25, max 100)'). The tool description adds no parameter-level detail, which is acceptable since the schema already documents the limit fully and there are no other parameters to explain. Baseline 3 is appropriate.

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 first line uses a specific verb and resource ('List the jobs you have bookmarked on LinkedIn') that clearly identifies this as the read counterpart to the save/unsave siblings. It names exactly what is returned (title, company, location, post date, link) and scopes itself to the Saved tab, distinguishing it from search and job-detail tools.

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?

The description states the tool reads only the Saved tab and explicitly notes that In Progress, Interview and Archived tabs are 'not exposed as tools.' The read-only framing ('no way to add to or remove from the list') implicitly routes agents away from linkedin_save_job/linkedin_unsave_job, though it does not name those alternatives directly or give an explicit when-to-use statement.

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

linkedin_save_jobA

Bookmark one job posting on LinkedIn. Two steps, and the first is free.

THIS TOOL CHANGES SOMETHING ON LINKEDIN, which no other tool in this server does. It is the reason linkedin_server_info no longer reports read_only: true.

CALL IT WITHOUT confirm_token FIRST. Nothing is done: the posting and your own saved list are read live, and you get back a block naming the job by title and employer, saying which way the toggle would move, where each fact was read from, and how the action can be undone. Read it, then call again with the confirm_token it hands you.

The token works ONCE, only for this posting, only for this verb, and it expires in two minutes -- so a scheduled or unattended caller can never hold a live one. That is the intended consequence and not a side effect.

After the click the result is confirmed from a DIFFERENT surface: your saved list, with LinkedIn's own per-tab count, rather than from the button that was just pressed. performed comes back true, false, or "unknown"; on "unknown" do not retry, because a retry on a toggle that did land performs the opposite action -- look at your saved jobs instead.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes	the numeric LinkedIn job id, as it appears in /jobs/view/<id>.
`confirm_token`	No	leave empty to preview. Pass the token from that preview to actually save.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels: it states the tool mutates LinkedIn state, explains the preview/confirm two-step mechanism, describes the token's single-use, per-post, per-verb, two-minute expiry, and discloses that confirmation is read from a different surface (the saved list) rather than the button. It also explains the 'performed' result values and the risk of opposite actions on retry. This is exhaustive and transparent.

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 description is longer than typical, but it is well-structured and front-loaded: the opening sentence captures the core action and two-step nature. Subsequent paragraphs each add necessary detail (token lifecycle, confirmation source, retry warning) without redundancy. Every sentence serves a purpose; while verbose, it respects the complexity of the operation.

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?

Given the tool's state-changing complexity and two-step flow, the description is exceptionally complete. It covers the preview, confirmation, token expiry, result semantics, retry avoidance, and even a fallback suggestion ('look at your saved jobs instead'). An output schema exists, but the description still clarifies the meaning of 'performed' and the confirmation pathway, leaving no critical operational detail 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 the schema already documents both parameters. The description adds meaningful context for confirm_token—its lifecycle, the preview/confirm pattern, and that an empty value means preview—which goes beyond the schema. For job_id, it mostly repeats the schema's description but confirms it as a numeric ID. The added semantic depth for confirm_token raises the score above the baseline of 3.

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 explicitly states the verb 'Bookmark' and the resource 'job posting on LinkedIn', and immediately distinguishes this tool from all read-only siblings by noting it is the only one that changes something on LinkedIn. It also implicitly contrasts with the sibling 'linkedin_unsave_job' by describing the save action. No ambiguity about what the tool does.

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?

The description gives a precise two-step procedure: call without confirm_token to preview, then call again with the token to save. It clearly states when to use the tool (when you want to save a job) and provides explicit warnings about token expiration, single-use, and when not to retry ('on "unknown" do not retry'). It also mentions the intended consequence of preventing unattended callers, further clarifying appropriate usage.

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

linkedin_search_jobsA

Search LinkedIn jobs with filters, returning one page of results.

Runs the search LinkedIn's own jobs page runs and reads the rendered results: title, company, location, job id and link.

One page load per call, no scrolling and no auto-paging -- LinkedIn puts roughly 25 results on a page, so ask for the next page deliberately with start=25, start=50 and so on. capped in the result tells you the limit trimmed the rows, and page_had tells you how many the page actually held.

Note that LinkedIn records searches in your own recent-search history, exactly as it would if you typed the query on the site. That is the only trace a search leaves, and it is on your account, not anyone else's.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	maximum rows to return (default 25, max 50).
`start`	No	result offset for manual paging (0, 25, 50 ...).
`remote`	No	any \| on_site \| remote \| hybrid.	any
`sort_by`	No	relevance \| date.	relevance
`keywords`	Yes	what to search for, e.g. "senior node.js engineer".
`location`	No	city, region or country. Empty means LinkedIn's default.
`date_posted`	No	any \| past_24h \| past_week \| past_month.	any
`experience_level`	No	comma-separated from internship, entry, associate, mid_senior, director, executive. Empty means no filter.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden. It exceeds expectations by detailing that each call is a single page load with no scrolling or auto-paging, that results are roughly 25 per page, and that capped/page_had indicate row trimming. Most notably, it discloses a non-obvious side effect: searches are recorded in the user's own LinkedIn recent-search history, leaving a trace on the account. This level of transparency about side effects and pagination mechanics is exemplary.

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 description is structured into three focused paragraphs: purpose, pagination mechanics, and privacy note. It is front-loaded with the core purpose in the first sentence. Every sentence contributes either operational details (single page, start offsets) or behavioral transparency (capped, page_had, search history). It is concise relative to the amount of critical information it conveys, though slightly longer than the bare minimum. The structure makes the key usage guidance easy to find.

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 search tool with 8 parameters and an output schema, the description covers all necessary aspects: what the tool does, how it works, how to page for more results, what the returned fields include (title, company, location, job id, link), and the side effect on search history. The presence of an output schema means the return format needn't be detailed, and the description still names the key fields. Nothing essential is missing for an agent to call this correctly.

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 description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema: it mentions start for paging and limit indirectly through the pagination discussion, but the schema already documents defaults, enums, and descriptions for every parameter (keywords, start, limit, remote, etc.). The description's pagination explanation adds marginal value over the schema's 'result offset for manual paging' line, but not enough to raise the score above baseline.

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 opens with a crisp statement of function: 'Search LinkedIn jobs with filters, returning one page of results.' It then specifics the returned fields (title, company, location, job id, link) and indicates the search runs on LinkedIn's own jobs page. This clearly distinguishes it from sibling tools like linkedin_job_detail (which likely retrieves a single job) and linkedin_saved_jobs (which lists saved jobs). The purpose is unambiguous and specific.

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?

The description provides explicit operational guidance: it explains the single-page behavior and instructs the agent to page deliberately using start=25, start=50, etc. It also explains the meaning of capped and page_had fields for interpreting results. However, it does not explicitly say 'use this instead of X' for any sibling tool, though the distinct search function is implied. The guidance is clear on how to use the tool for repeated paginated searches, which is the core usage pattern.

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

linkedin_server_infoA

Describe this server: what it can do, what it deliberately cannot.

Useful for confirming the read-only boundary and the rate settings without reading the source.

version and build.code.commit are two different facts and both are reported. version is a HAND-MAINTAINED label: it says what this server calls itself, and it keeps saying it whether or not anybody remembered to bump it. build.code.commit is MEASURED -- it is the commit this process was imported from, read once at import and frozen.

WHAT TO DO WITH IT. A fix committed to disk changes nothing for a server that is already running. To tell "the fix is not loaded" from "the fix is wrong", compare build.code.commit against git rev-parse HEAD in the checkout::

git -C <this checkout> rev-parse --short=12 HEAD

They MATCH -> the running process holds that commit, so a bug you can still reproduce is a real bug. They DIFFER -> the process is STALE and no further committing will change its behaviour until the MCP client restarts it. build.code.dirty says whether the working tree had uncommitted changes when this process started, so a matching commit with dirty: true means the commit is necessary but not sufficient to describe what is loaded. build.process.started_at dates the answer.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully carries the burden. It discloses that version is a hand-maintained label while build.code.commit is measured and frozen at import, distinguishes between stale and current processes, explains how to compare against git rev-parse HEAD, and covers the dirty flag and started_at field. This goes well beyond what annotations would provide and gives the agent complete behavioral expectations.

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 description is front-loaded with the main purpose and then dives into detailed interpretation of version/build fields. It is well-structured with a clear flow, but it is somewhat verbose, especially the code block and extended explanation of staleness. Every sentence adds value, so it is not padded, but it could be tightened without losing essential meaning.

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?

The description is extraordinarily complete for a no-parameter tool. It explains the meaning of each output field (version, build.code.commit, dirty, started_at), how to interpret them together, and even provides a practical procedure (git rev-parse HEAD) for diagnosing stale servers. Nothing an agent needs to call or interpret this tool 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?

The tool has zero parameters, so the schema is trivially complete (100% coverage). Per the rubric, a baseline of 4 applies, and the description adds no parameter detail (none is needed). No deduction is warranted.

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 opens with "Describe this server: what it can do, what it deliberately cannot," a specific verb/resource pair that clearly distinguishes this tool from siblings like linkedin_auth_status or linkedin_session_info. It states the exact scope (server capabilities, read-only boundary, rate settings) and the primary output (version and build information). No ambiguity about what this tool does.

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 explicitly states when to use it ("Useful for confirming the read-only boundary and the rate settings without reading the source"). It stops short of naming alternatives or explicit when-not-to-use conditions, but the context of the sibling list makes the intended use clear. A 5 would require an explicit comparison to alternatives, which is missing.

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

linkedin_session_infoA

Report whether the session is live and how long it has left.

This is the question that comes up after a week away: is the sign-in still good, and when does it lapse? The verdict is the same measured one linkedin_auth_status gives -- an authenticated call to the identity endpoint, never a cookie's presence -- and alongside it comes the expiry date read from the browser profile's own cookie jar.

The sign-in lives in an on-disk Chrome profile rather than in this process, so it survives this server restarting and the machine rebooting. What ends it is LinkedIn expiring it, a sign-out, or the profile directory going away.

When no browser can be started at all -- Chromium missing, another process holding the profile -- this tool does not die with it. It falls back to reading the expiry dates out of that profile's cookie jar on disk, which is precisely the moment you most want to know whether the login survived. Then 'authenticated' is null and the live_check block says why in plain words: a cookie in the jar is not a session, and reporting one as the other is a lie this server refuses to tell. Two labelled fields, never one blurred one.

What comes back, block by block, so a caller is never guessing:

credential -- li_at, the one cookie that authenticates here. Its name, whether it is there, its expiry, and expiry_source naming which route produced that date: the live browser's jar, or the on-disk jar read with no browser.
supporting -- JSESSIONID, role csrf. Not a second credential: it cannot sign anything in, it only governs whether the identity call can be made at all. It dies with the browser and a fresh one arrives on the next page load, so it having lapsed means nothing on its own.
renewal -- silent_renew_available is false here, and why says what the four servers in this family were ruled on: there is one credential layer, so a linkedin_reauth would be linkedin_login_browser wearing a different name and it is deliberately not shipped. It also carries session_lapses_at / _in_days: the date past which no silent renew can help and you sign in by hand. THAT is the number to compare against a sibling server, not credential.expires_at -- a server that re-mints its own credential shows hours there while its session holds for months. On LinkedIn the two coincide, because nothing here can carry the session past the cookie, and session_lapses_source says so. uses_browser is null rather than false -- there is no renewal here to characterise, and a false would claim one exists and happens to need no browser -- while mechanism spells out what recovery actually costs: a real window and your own hands, never a background refresh.
durability -- where the sign-in is kept and what it survives.

Cookie values are never returned. Only the name, whether it is there, and when it lapses. When it has lapsed every read tool says so with a reason rather than handing back nothing, and linkedin_login_browser is the way back.

(Everything below this point is dropped from the description a caller sees: FastMCP cuts a docstring at Args: and renders the rest into the argument schema. Prose that has to reach a caller goes ABOVE it.)

ParametersJSON Schema

Name	Required	Description	Default
`verify_live`	No	put the question to the identity endpoint for a real verdict, which requires a working browser. Pass False for the free, browserless answer -- jar facts only, 'authenticated' null. Default True.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers heavily: it discloses the measurement method (identity endpoint, never cookie presence), the persistence of the session in an on-disk Chrome profile, the fallback to reading the jar without a browser and the resulting null 'authenticated', the fact that cookie values are never returned, and the semantic of renewal (silent_renew_available false, costs manual sign-in). This is extensive behavioral disclosure beyond the basics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely verbose. It includes narrative prose ('This is the question that comes up after a week away...'), extensive block-by-block explanations, and a meta-note about FastMCP cutting the docstring. While structured with headings, the length is excessive for an AI caller; many sentences could be trimmed without losing essential information. The front-loaded purpose is clear, but the overall bulk detracts from usability.

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 tool with no annotations and a fairly complex behavior (fallback, multiple output fields, nuanced semantics), the description is extremely thorough. It explains each output block, the meaning of null, the reasons behind renewal limitations, and the durability of the session. An agent would have all necessary context to call it correctly, even without seeing the output schema (which exists but is not needed to understand the tool).

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?

The schema already covers the only parameter (verify_live) with a clear description, so the baseline is 3. The description adds value by explaining the trade-offs in context: it details what True vs False means for the live_check block, the fallback when no browser is available, and the null semantics. This enriches the parameter's meaning beyond the schema's concise 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?

The opening sentence clearly states the tool's purpose: 'Report whether the session is live and how long it has left.' It goes further to differentiate from linkedin_auth_status by specifying that it uses the same identity-endpoint verdict but also includes the expiry date from the cookie jar, and it names linkedin_login_browser as the recovery path. This makes the resource and scope unambiguous.

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?

The description explicitly references alternatives and when to choose them: it says the verdict is the same as linkedin_auth_status, points out that linkedin_login_browser is the way back after lapse, and explains the fallback behavior when no browser can be started. It also tells when to set verify_live True vs False. This gives clear decision rules for an agent.

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

linkedin_unfollow_companyA

Stop following one company Page. Two steps, and the first is free.

Same two-step shape and the same five gates as linkedin_save_job. What differs is worth reading before you use it, because two of the differences change what an answer from this tool means.

IT IS ADDRESSED BY THE NUMERIC COMPANY ID, NOT BY NAME. Call linkedin_followed_companies first: it prints the id beside each Page. A name is refused outright -- names collide, they change, and they belong to somebody else -- and the click is anchored to the row carrying the id, so the thing you name and the thing that gets pressed are the same row by construction. The preview still prints the NAME, because an id is not something a person can check.

THE LIST IS NEVER COMPLETE, AND THAT IS THE IMPORTANT ONE. LinkedIn renders about twenty rows of however many you follow, and offers no way to page through the rest. So a Page that is not in the rendered rows comes back "unknown" rather than "not followed", and the preview refuses rather than guessing. If the company you want is not reachable, this tool will say so instead of doing nothing quietly.

Confirmation after the click is read by RELOADING the same list -- there is no second surface that lists followed Pages -- and the verdict rests on LinkedIn's own stated total dropping by one, not on the row having vanished. On a partial list an absent row is not evidence.

THE PAIR IS ASYMMETRIC ON PURPOSE: this server can stop a follow and cannot start one. linkedin_follow_company is specced and is not performed.

ParametersJSON Schema

Name	Required	Description	Default
`company_id`	Yes	the numeric LinkedIn company id, as printed by ``linkedin_followed_companies``.
`confirm_token`	No	leave empty to preview. Pass the token from that preview to actually unfollow.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and excels at it. It discloses the two-step confirmation flow, the lack of pagination in the followed-companies list and its consequences, the confirmation method (reloading the list and checking the total count drop), and the 'unknown' vs 'not followed' distinction. It even explains why a partial list makes absent rows unreliable evidence. This is exemplary behavioral disclosure.

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?

Though long, the description is tightly structured and every sentence earns its place. The key warnings are front-loaded and emphasized with caps, and the paragraphs each address a distinct behavioral aspect. It is verbose only where necessary; the complexity of the tool justifies the length, and the structure makes it scannable.

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 tool with an output schema and non-trivial behavioral caveats, this description is complete. It covers prerequisites (get the ID), limitations (list is partial), verification (count drop), and side-effect asymmetry. Nothing an agent needs to call it correctly or interpret results 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 the parameters are already documented. The description adds contextual meaning: company_id is clarified as the numeric id printed by the followed list (not the name), and confirm_token is explained as the preview vs final confirmation flow, with an empty value meaning preview. This goes beyond the schema's basic 'leave empty to preview' by tying it into the overall two-step process, justifying a 4 over the baseline 3.

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 opens with a precise verb+resource ('Stop following one company Page') and immediately differentiates from siblings by referencing the shared two-step shape and five gates, and by naming the asymmetry with linkedin_follow_company. It leaves no ambiguity about what the tool does and how it differs from related tools.

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?

The description gives explicit when-to-use guidance: call linkedin_followed_companies first to obtain the numeric ID, explains that names are refused, and details the list incompleteness that makes a 'unknown' verdict possible. It also states the asymmetry (can unfollow but not follow) and directs to the unimplemented follow tool for the inverse, leaving no room for misuse.

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

linkedin_unsave_jobA

Remove one job posting from your saved list. Built, gated, and refusing.

Same two-step shape as linkedin_save_job and the same gates, with ONE honest difference that this docstring will not bury: THIS TOOL CANNOT PERFORM ANYTHING TODAY, and it is not because the code is missing.

LinkedIn labels the save control by its accessible name, and the name it wears when a posting IS saved has never been observed on this account -- there has been nothing saved on it to observe. Every capture this repo holds shows the unsaved state. So the selector an unsave would click is unknown, and this server will not guess one: "Saved" and "Unsave the job" are both plausible spellings and it has seen neither.

THE FIX IS ONE MEASURED LINE, and the first supervised save produces it -- linkedin_save_job reads back the label the control changes into and reports it. Until that label is written down, this refuses with that explanation rather than clicking something it hopes is the right button.

A preview may also be unrenderable for a second and unrelated reason: an unsave is only valid on a posting that is currently saved, so with an empty saved list there is nothing to preview it against. The preview says so.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes	the numeric LinkedIn job id, as it appears in /jobs/view/<id>.
`confirm_token`	No	leave empty to preview. A token is accepted but the action behind it will refuse until its anchor has been measured.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden of behavioral disclosure. It is exceptionally transparent: it confesses 'THIS TOOL CANNOT PERFORM ANYTHING TODAY,' explains the technical reason (unknown accessible name), details the preview failure condition, and states it will refuse rather than guess. This level of honest disclosure is exemplary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a multi-paragraph essay covering the tool's broken state, future fix, and preview behavior. While informative, it is verbose and could be condensed into a few sentences. An MCP description should be concise; this one isn't.

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?

Given the tool has an output schema and no annotations, the description must convey behavioral context. It thoroughly covers why the tool refuses, how preview behaves, and the condition for it to work, leaving no ambiguity about what will happen when called. It is complete for an agent to handle correctly.

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% – both parameters (job_id and confirm_token) are fully described in the input schema, including the preview vs. token behavior. The description adds no additional parameter-level information, which is acceptable given the schema already covers semantics. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Remove one job posting from your saved list,' which is a clear verb+resource statement. It implicitly differentiates from linkedin_save_job by being the inverse operation, though it doesn't explicitly compare with siblings. The core purpose is unambiguous despite the lengthy caveats about the tool being non-functional.

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

Usage Guidelines3/5

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

The description implies usage when a user wants to unsave a job and explicitly states the tool cannot currently perform the action and will refuse until a label is measured. It also mentions the preview limitation based on having a saved job. However, it doesn't explicitly state when not to use it or mention alternatives, though the refusal condition is clear.

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

linkedin_who_viewed_meA

List the people who viewed your profile, most recent first.

The highest-intent signal in a job search: someone who opened your profile has already spent attention on you. Where the account has Premium Career, this list reaches back 365 days rather than the free tier's five viewers.

Rows carry name, headline, when the view happened, and a profile link.

Viewers browsing with limited visibility appear exactly as LinkedIn shows them to you and no more: "Someone at Acme", "Recruiter at Acme", with a date and no link, flagged "anonymous": true. They are the majority of a typical list and often the most useful part of it -- a recruiter's view is a recruiter's view whether or not it comes with a name. This server makes no attempt to work out who they are, and there is no code here that could: nothing is fetched about any viewer, and no viewer's profile is ever opened. What you get is the row LinkedIn already put on your screen.

Reads the Premium analytics page. The older /me/profile-views/ address now redirects to that same page, so the second attempt is a re-load for a page that had not finished rendering rather than a different surface; it still reports pages_loaded: 2 when it happens.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	maximum rows to return (default 25, max 100).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description takes full responsibility for behavior. It discloses that some viewers appear as anonymous with limited info, states the server makes no attempt to identify them and fetches nothing about viewers, mentions the data source (Premium analytics page), and explains the redirect behavior and resulting pages_loaded count. This is exceptionally transparent.

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 description is longer than average, but it is front-loaded with the core purpose and organized into informative paragraphs. Each segment adds value: the high-intent context, anonymous viewer behavior, technical data source, and the redirect edge case. It is structured logically and avoids redundancy, though it could be tightened without losing clarity.

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?

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description still covers all essential behavioral context: the kind of rows returned (name, headline, when, link), anonymous flagging, the data source, and the redirect quirk. It even explains what the server does not do. This is complete for an agent to use correctly.

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 description coverage is 100%, so the baseline is 3. The sole parameter 'limit' is already fully described in the schema with default and max values; the tool description adds no additional semantic meaning or usage nuance beyond that. Thus it meets the baseline without needing extra explanation.

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 opens with 'List the people who viewed your profile, most recent first' — a precise verb and resource. It clearly distinguishes from sibling tools like linkedin_search_jobs or linkedin_my_applications by specifying the unique action of listing profile viewers, and provides additional context about the 'highest-intent signal in a job search.'

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?

The description provides strong contextual guidance on when this tool is valuable ('the highest-intent signal in a job search' and notes that anonymous viewers are often the most useful part), implying usage in recruiter outreach scenarios. However, it does not explicitly exclude or compare against sibling tools, so it falls short of a 5 but is above a 3 due to the clear situational context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

17 tool updatesv0.1.0Aug 25, 2026
- First observedlinkedin_auth_status
- First observedlinkedin_cdp_status
- First observedlinkedin_followed_companies
- First observedlinkedin_job_detail
- First observedlinkedin_login_browser
- First observedlinkedin_logout
- First observedlinkedin_my_applications
- First observedlinkedin_my_profile
- First observedlinkedin_notifications
- First observedlinkedin_save_job
- First observedlinkedin_saved_jobs
- First observedlinkedin_search_jobs
- First observedlinkedin_server_info
- First observedlinkedin_session_info
- First observedlinkedin_unfollow_company
- First observedlinkedin_unsave_job
- First observedlinkedin_who_viewed_me

Deploy Server

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A4.2/5.0

Scored 2026-08-25 02:02 across 17 tools

Disambiguation5/5

Each tool targets a distinct action or query: auth status, session details, login, logout, CDP diagnostics, profile viewers, applications, saved jobs, job search, job detail, followed companies, own profile, notifications, save job, unsave job, unfollow company, server info. Even related tools like auth_status and session_info are clearly differentiated by scope.

Naming Consistency4/5

All tools begin with 'linkedin_' and use snake_case, but the pattern mixes noun phrases (linkedin_my_profile, linkedin_notifications) with verb-noun (linkedin_search_jobs, linkedin_save_job) and state queries (linkedin_auth_status). While consistent in prefix, the verb usage is not uniform, though still readable.

Tool Count4/5

17 tools is slightly above the ideal 3-15 range but each serves a distinct purpose, from session management to job and company interactions. The count is justified by the breadth of LinkedIn functionality covered, though a few are diagnostic or advisory.

Completeness3/5

The server covers the main job-search workflow (search, detail, saved, applications) and profile viewing, but has notable gaps: no way to follow a company (only unfollow), and the unsave_job tool is explicitly non-functional. Additionally, there is no tool for applying to jobs or editing profile, leaving some expected actions absent.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

LinkFetch: LinkedIn MCP
io.linkfetch
LinkedIn jobs, companies and people for AI agents, plus messages and invites via your own account.
Social Media Search Communication
1
TopClozer LinkedIn MCP
com.topclozer
LinkedIn for AI agents: search people, read profiles, posts and connections via a connected account
1
mcpOAuth
com.curviate
LinkedIn actions for AI agents: search, messaging, posts and invites, as hosted MCP tools.
Social Media Communication
1
Reach MCP — LinkedIn for AI agents AOAuth
com.reachmcp
LinkedIn for AI agents: inbox, invitations, Sales Navigator search, posts, jobs, quotas, webhooks.
Social Media CRM
611

Related MCP Servers

LinkedIn MCP Server
Web Scraping Browser Automation Social Media
stickerdaniel
A
license
A
quality
A
maintenance
Enables AI assistants to interact with LinkedIn by scraping profiles, companies, job postings, and getting personalized job recommendations using authenticated browser automation.
Updated a day ago (2026-10-15 06:43 UTC)
17
12,621 PyPI
3,876
Apache 2.0
LinkedIn MCP Server
Social Media Communication
quinnjr
A
license
B
quality
C
maintenance
Enables AI agents to manage LinkedIn profiles, posts, connections, skills, education, and certifications through the LinkedIn API.
Updated 2 months ago (2026-08-03 15:06 UTC)
18
176 npm
64
MIT
LinkedIn Agent MCP
Social Media Web Scraping
iushv
A
license
Not graded
quality
D
maintenance
Enables AI assistants to connect to LinkedIn, accessing profiles and companies, searching for jobs and people, managing saved jobs, updating job-search profile settings, and inspecting analytics.
Updated 2 months ago (2026-08-03 18:44 UTC)
1
Apache 2.0
LinkedIn MCP Server
Social Media Communication
pauling-ai
A
license
Not graded
quality
B
maintenance
Enables natural language interaction with LinkedIn, including profile retrieval, job searching, messaging, and post engagement.
Updated 3 months ago (2026-07-16 21:15 UTC)
3
Apache 2.0

linkedin

Lies diesen Teil, bevor du etwas anderes tust

Das ist kein Anti-Erkennungs-Tool, und hier ist der Beweis – nicht die Zusicherung

Die Lizenz ergibt sich daraus, und sie ist bewusst nicht freigebig

Was es kann

The right to truth – translation "The three tools".

Das eine, das sich weigert

apply "Bewerben" - one half which with (ships) - and half that does not.

Was es bewusst nicht kann

The two side effects, stated instead of hidden

Setup

Registrieren

How "read-only" is enforced – instead of asserted

Login gate: cookie not a login

Anmelden und wie lange es dauert

Der Kaltstart und die Falle darin

Der Wiederherstellungspfad: das eigene Chrome verwenden

Raten-Disziplin

Wenn etwas nicht gelesen werden kann

Wie die Seiten gelesen werden

Layout

Workstate

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Partial compensation, since the badge is going either way: each row carries "unread": true/false as LinkedIn had it AT THE MOMENT OF READING -- which is the fact the page load is about to destroy. Read it here or lose it.

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers