Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Mark Contact Replied

li_mark_replied
Destructive

Flag a contact as REPLIED — stops the auto follow-up sequence and surfaces them in li_replies_to_answer. Rarely needed: the inbox sweep detects replies by itself (force one with li_sweep_inbox); use this when you saw a reply it cannot, e.g. one sent by email. Writes our database only and sends nothing. Identify by profileUrl (vanity URL, the /in/ACoAA… URL li_list_conversations returns, or a bare member id — all resolve to the same person) or contactId. A person in NO campaign (an inbound or manual thread) gets a light conversation record on the account you name with sessionLabel, instead of a refusal — pass the participantProfileId URL (and conversationUrn + participantName) from li_list_conversations. After answering, close it with li_mark_reply_handled; record a verdict with li_mark_outcome.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note for the contact timeline
contactIdNoOne contact by id (from li_contact_dossier or li_campaign_contacts), instead of profileUrl
messageIdNoThe exact message row, when you already have it from a dossier or a queue read.
sessionIdNoThe account this conversation is on. Only used when the person is in NO campaign: then a light record is created on this account so the mark has something to act on. Needed only when you have more than one account.
campaignIdNoWhich campaign membership to act on. A contact can be in more than one campaign, and without this the row is whichever was touched last — so stopping them in one campaign while leaving the other running was not possible. Pass it whenever the contact might be in two.
profileUrlNoOne contact, by profile URL
profileUrlsNoSeveral contacts in ONE call, max 200. Each is resolved and marked independently: one refusal does not stop the rest, and the reply reports every one by URL.
sessionLabelNoSame, by account label
conversationUrnNoThe thread, straight from li_list_conversations (single-person form). Recorded on the conversation so the live inbox recognises it as decided. On its own it finds the person only when their thread is already stored — pass profileUrl (the participantProfileId / ACoAA… URL) too.
participantNameNoTheir name from li_list_conversations — kept on a newly recorded contact.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / contactId / description
      Added value: +"One contact by id (from li_contact_dossier or li_campaign_contacts), instead of profileUrl"
    • addedInput schema / properties / note / description
      Added value: +"Optional note for the contact timeline"
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=false, but the description adds crucial scope: 'Writes our database only and sends nothing,' which tells the agent the destructive hint is a local record mutation, not an outbound message. It also discloses partial-failure semantics ('one refusal does not stop the rest') and the light-record branch for no-campaign people.

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-loaded with purpose, then when-to-use, then side effects, then identity mechanics — a sensible order. It is dense and long, but nearly every clause carries a distinct constraint rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, no-required, no-output-schema tool, the description covers identity resolution, the no-campaign branch, bulk partial-failure behaviour, and the follow-up sequence. It does not mention the note or messageId parameters, but those are documented in the schema and are minor.

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% (baseline 3), but the description adds real meaning on top: profileUrl accepts vanity URLs, /in/ACoAA… URLs, or bare member ids; campaignId is needed whenever a contact may sit in two campaigns; conversationUrn alone only finds an already-stored thread. Cross-parameter guidance like pairing profileUrl with conversationUrn/participantName exceeds 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?

Opens with a specific verb+resource+effect: 'Flag a contact as REPLIED — stops the auto follow-up sequence and surfaces them in li_replies_to_answer.' This distinguishes it from li_mark_reply_handled and li_mark_outcome, which are named as the follow-on steps.

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 states when NOT to use it ('Rarely needed: the inbox sweep detects replies by itself (force one with li_sweep_inbox)') and the narrow condition that selects it ('use this when you saw a reply it cannot, e.g. one sent by email'). It also routes to the two follow-up siblings, so the agent knows the full sequence.

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