Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Accept Inbound Connection Requests

li_accept_invitations
Destructive

Accept connection requests sent TO this account. Provide profileUrls to accept only specific people; omit to accept all pending up to maxAccept. State-changing — requires confirmAccept=true.

RETURNS A JOB ID AND DOES NOT WAIT. Reading a long invitations backlog takes minutes, and holding the call open used to exceed the client's own idle limit while the run carried on regardless. Read the outcome with li_job_result(jobId) — it carries the per-person outcomes and the pageState. Pass wait=true only for a handful of people.

CONNECTION REQUESTS ONLY. A newsletter-subscription or page-follow invitation is listed against the INVITER's profile, so naming that person used to subscribe the account to their newsletter — which nothing in this system can undo. Those are now refused per person and reported as not_a_connection_invite; acceptNonConnection=true overrides it deliberately.

Every named person comes back in outcomes with a reason: accepted, not_on_page (we read the WHOLE list and their invitation is not on it), page_not_fully_read (we ran out of budget — this says nothing about them), not_a_connection_invite, click_not_trusted or click_failed. pageState says how much was actually read, so a zero-accept run is diagnosable instead of a guess. ok:false means the run went wrong or did not finish reading, NOT that somebody simply had no invitation pending.

AUTO-MARKS THE TRIAGE MEMORY. Every confirmed acceptance is recorded as decision accepted, and click_failed / click_not_trusted / page_not_fully_read as failed with that reason (so they come back under li_received_invitations onlyUnreviewed for a retry). not_on_page writes nothing. triageMemory in the result says how many were written. Do not mark accepted people yourself.

Input Schema

NameRequiredDescriptionDefault
waitNoBlock until the run finishes. Default false — reading a long invitations list takes minutes.
maxAcceptNoCap how many to accept this run. Defaults to the number of profileUrls given, or 20 when accepting whatever is pending.
sessionIdNoAccount id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed.
profileUrlsNoAccept only these profile URLs; omit to accept all pending.
sessionLabelNoAccount by label, LinkedIn name, profile slug or member id (li_list_accounts). Needed (or sessionId) when you have more than one account; never guessed.
confirmAcceptYesMust be true to accept; false reads the page and previews what would happen
acceptNonConnectionNoAlso accept newsletter subscriptions and page follows. Default false. There is no way to undo one from here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / sessionId / description
      Added value: +"Account id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed."
    • addedInput schema / properties / sessionLabel / description
      Added value: +"Account by label, LinkedIn name, profile slug or member id (li_list_accounts). Needed (or sessionId) when you have more than one account; never guessed."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the destructive/openWorld annotations: it discloses that the tool returns a job id without waiting and why, that non-connection invitations (newsletter/page-follow) are irreversible if wrongly accepted and are now refused by default, that confirmAccept=true is required for mutation, and that the run auto-writes triage memory decisions including failed-retry reasons.

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

Conciseness4/5

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

Front-loads the core action, scoping, and the confirmAccept requirement in the first sentence. It is long (five paragraphs), but with no output schema the outcome/triage detail is load-bearing rather than filler; only minor tightening is possible.

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?

Because there is no output schema, the description carries the full return contract: job-id async pattern, per-person outcome reasons, pageState diagnosability, the meaning of ok:false, and the triageMemory side effect. An agent can call and interpret this tool without further documentation.

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 baseline is 3, but the description adds real meaning: why wait defaults false, how maxAccept defaults differ (profileUrls count vs 20 pending), what confirmAccept=false produces ('reads the page and previews'), and the irreversible consequence guarded by acceptNonConnection.

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

Purpose5/5

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

States a specific verb and resource with explicit scope: 'Accept connection requests sent TO this account.' The 'TO this account' / inbound framing distinguishes it from outbound siblings like li_send_connection_now, and the CONNECTION REQUESTS ONLY constraint sharpens the boundary further.

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

Usage Guidelines4/5

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

Gives clear conditional guidance: pass profileUrls to target specific people, omit to accept all pending up to maxAccept, and 'Pass wait=true only for a handful of people.' It also routes retries to li_received_invitations onlyUnreviewed and reading to li_job_result. It does not explicitly name a near-alternative tool for the accept action itself, but the operational conditions are well specified.

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

All PoliteReach toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources