Skip to main content
Glama

Mark Reply Handled

li_mark_reply_handled

Record that a person DEALT WITH this conversation. Call it after you answer a reply, or to close one you are not going to answer.

It is no longer what empties li_replies_to_answer — that queue is derived from the thread, so an answer sent with li_send_reply drops the row once the send lands. What this still does, and nothing else does: it writes the conversation down as handled, which is what makes the contact stop reading "needs reply" on their dossier and in the campaign, takes them out of the reply-rate numerator, and puts a dated line with your note on their timeline. It is also the only way out for a thread the queue cannot read — an answer typed by hand in LinkedIn (nothing re-reads that thread), a reply sent from a different account than the one that campaign uses, or a send that reported a failure after the message had in fact gone out.

It says NOTHING about how the conversation went — that is li_mark_outcome (won / meeting_booked / interested / not_interested / no_outcome), and marking an outcome does this as well, so use that one instead whenever you already know the verdict.

If they write AGAIN after you mark this, the conversation REOPENS on its own: the inbox sweep (about hourly) still watches a handled thread for new messages from them, puts it back in li_replies_to_answer with reopened, and li_list_conversations(onlyNeedsReply) lists it again. ⚠️ Still NOT for "not right now" — nothing brings a handled conversation back on a DATE. Use li_snooze_reply for that.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note for the contact timeline, e.g. what you answered
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, e.g. what you answered"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say non-read-only, non-destructive, closed-world; the description goes far beyond by disclosing the automatic REOPENING on a new inbound message (hourly sweep, `reopened` flag), the timeline write, the reply-rate numerator effect, and the failure/re-send edge cases. This is substantive behavioral context no annotation conveys.

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?

Four dense paragraphs, front-loaded with the core action and then the queue/side-effect mechanics, with bolded warnings. Slightly verbose and warning-heavy, but nearly every sentence carries non-redundant information rather than 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?

For a 10-param, no-output-schema mutation tool, the description covers the action, side effects, reopening lifecycle, alternatives, and edge cases a caller would otherwise get wrong. Nothing material for correct invocation 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 prose adds real meaning: it frames why campaignId scoping matters (multiple memberships), why conversationUrn alone may not find the person, and when sessionId is needed. It stops short of walking every one of the 10 params, but it enriches the semantically tricky ones.

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 (record/mark) and resource (a reply/conversation as handled) and immediately contrasts it with li_mark_outcome, li_snooze_reply, li_send_reply, and li_replies_to_answer. An agent can distinguish it from every sibling without opening another 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?

Explicit when-to-use ('after you answer a reply, or to close one you are not going to answer'), explicit when-not ('NOT for not right now... Use li_snooze_reply'), and names the preferred alternative when a verdict is known (li_mark_outcome). It even enumerates the queue-unreadable edge cases it uniquely handles.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources