Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Assign an Account’s Proxy (operator only)

li_set_account_proxy
Destructive

OPERATOR ONLY. Points ONE account at a proxy from li_proxies, or back at the install default with proxyId: null. ⚠️ This changes the IP LinkedIn sees the account on — a fingerprint jump that can trigger a security check or a logout — so a change that moves the IP is REFUSED unless confirmEgressChange: true; the refusal names the old and new address. Confirm only when the person has agreed to the move. Check the proxy with li_check_proxy first. The account's next browser job launches through the new proxy; a warm browser on the old one is closed, not reused. Name the account explicitly — it never falls back to a default.

Input Schema

NameRequiredDescriptionDefault
proxyIdYesA proxy id from li_proxies, or null for the install default
sessionIdNoAccount id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed.
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.
confirmEgressChangeNoRequired when the account's egress IP changes

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.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, and the description goes well beyond that: it discloses the egress-IP refusal gate (confirmEgressChange), the security-check/logout risk of a fingerprint jump, that the refusal names old and new addresses, and that the warm browser on the old proxy is closed rather than reused.

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?

Dense but front-loaded: the OPERATOR ONLY gate, then the egress-change rule, then the follow-up behavior. Every sentence carries operational weight, though the length borders on long for a 4-parameter call.

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?

No output schema exists, yet the description covers the outcome (refusal message contents), side effects (browser closed, next job uses new proxy), and the confirmation requirement, leaving nothing an agent needs to call it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains proxyId null resolves to the install default, that confirmEgressChange is a hard gate tied to IP movement, and that the account must be named explicitly with no default fallback.

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+resource (set an account's proxy) and disambiguates from siblings by scoping it to ONE account and pointing at li_proxies / the install default, while the sibling li_set_user_default_proxy handles the user-level default. An agent can tell them apart without opening a schema.

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?

Explicitly instructs to check the proxy with li_check_proxy first, says to confirm only when the person agreed to the move, and states the operator-only precondition. This is when-to-use plus prerequisites plus a named companion tool.

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