Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Record Triage Decisions On Inbound Invitations

li_mark_invitations

Record what you decided about people who invited this account, in OUR database only — it never clicks Accept, Ignore or Withdraw on LinkedIn and sends nothing. li_received_invitations(onlyUnreviewed) then leaves them out (counted under alreadyDecided) until their headline or company changes. Up to 200 per call; each is resolved to the inviter's member id (a renamed vanity URL stays the same person) and keyed per account — the same person inviting two of your accounts gets two independent decisions.

Decisions: rejected and wrong_lane need a reason (wrong_lane takes routeTo, the account that should reach them cold instead), deferred is 'look again later', failed is for a failed accept. accepted is REFUSED unless li_accept_invitations confirmed the accept or they are already in a campaign on this account — accept them with li_accept_invitations, which records accepted itself. Re-marking overwrites and keeps the old decision in the history. A rejection is NOT a do-not-contact: nobody is suppressed.

confirmMark=false is a dry run: every row says marked / updated / unchanged / refused (with why) and nothing is written. One refusal never blocks the rest.

Input Schema

NameRequiredDescriptionDefault
decisionsYes1-200 decisions, one per inviter; each is applied or refused on its own
sessionIdNoAccount id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed.
confirmMarkYestrue writes; false previews every row
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / decisions / description
      Added value: +"1-200 decisions, one per inviter; each is applied or refused on its own"
    • addedInput schema / properties / decisions / items / properties / campaignId / description
      Added value: +"The campaign they joined, for an accepted person"
    • addedInput schema / properties / decisions / items / properties / decision / description
      Added value: +"accepted (only after a confirmed accept), rejected, wrong_lane, failed or deferred"
    • addedInput schema / properties / decisions / items / properties / icp / description
      Added value: +"ICP label you judged them against"
    • addedInput schema / properties / decisions / items / properties / profileUrl / description
      Added value: +"The inviter, by profile URL (or memberId)"
    • addedInput schema / properties / decisions / items / properties / reason / description
      Added value: +"Why; required for rejected and wrong_lane"
    • addedInput schema / properties / decisions / items / properties / routeTo / description
      Added value: +"wrong_lane only: the account that should reach them cold instead"
    • 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses the 200/call cap, per-account keying, member-id resolution, overwrite-plus-history behavior, that re-marking preserves the old decision, that a rejection is NOT a suppression, and the dry-run row outcomes (marked/updated/unchanged/refused) with per-row independence.

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 core purpose and non-side-effect guarantee lead, with decision rules and dry-run semantics following. Some sentences are long and pack multiple clauses, but essentially no filler for a tool of this complexity.

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 complex mutation tool with no output schema, the description covers everything an agent needs: side-effect scope, decision semantics, refusal handling, history behavior, suppression caveat, and dry-run output shape. Nothing material 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 baseline is 3, but the description adds real semantics: the conditional requirement of `reason` for rejected/wrong_lane, the meaning of `routeTo` as the cold-reach account, the accepted-refusal rule keyed to a decision value, and the sessionId/sessionLabel multi-account requirement. It goes beyond restating the schema.

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 (records decisions) and resource (inbound invitations on this account), and immediately scopes it as 'in OUR database only' with no LinkedIn-side action. This cleanly distinguishes it from li_accept_invitations and other invitation tools without the agent needing to open 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 routes the agent: 'accepted' is refused unless li_accept_invitations confirmed the accept, so accept via that tool instead. It also names the li_received_invitations interplay (rows leave results, counted under alreadyDecided) and defines when each decision applies.

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