Skip to main content
Glama

Record How A Conversation Went

li_mark_outcome
Destructive

Record the human verdict on a conversation: won, meeting_booked (a call is on the calendar — NOT won), interested (they want to talk, nothing booked yet), not_interested, or no_outcome (it ran its course and nothing came of it). A demo request or a booked call is never won. This is orthogonal to the message status, which only ever says where the AUTOMATION stopped — a deal and a dead end are both handed_off, and nothing in the pipeline can tell them apart, so a person marks it.

Mark up to the batch limit at once with profileUrls — after working a queue the verdict is usually the same for several people, and it was the one mark that still cost a call each.

Marking an outcome CLOSES the conversation: every SCHEDULED step is cancelled and an open sequence moves to handed_off, so no further automated message goes out. A newer message from them REOPENS it (verdict kept), so an interested person who writes back is owed a reply again and leaves li_marked_conversations(dueOnly) until marked again.

For someone who AGREED to a call, use li_track_booking instead of marking interested by hand: it marks interested AND schedules the booking check that li_booking_due works from. A booked call is li_mark_booked (outcome meeting_booked plus the calendar event). Marking not_interested/no_outcome closes an open booking; meeting_booked marks it booked.

⚠️ It does NOT reach a message already handed to the queue. A reply you queued with li_send_reply moments ago is a job on its way to a browser, and nothing consults the outcome before it types — so marking somebody not_interested does not stop the answer you just sent them. Check li_job_result before marking if that matters. Pass outcome=null to clear a mis-mark — that only unsets the verdict and revives nothing; use li_reset_contact to put a contact back into the sequence.

Input Schema

NameRequiredDescriptionDefault
noteNoWhy — stored with the verdict and in the timeline
outcomeYeswon | meeting_booked | interested | not_interested | no_outcome, or null to clear a mis-mark. Applies to every contact in this call.
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. Changed1 schema field changed
    • addedInput schema / properties / contactId / description
      Added value: +"One contact by id (from li_contact_dossier or li_campaign_contacts), instead of profileUrl"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true; the description earns that by specifying exactly what gets destroyed — scheduled steps cancelled, open sequence moved to handed_off. It goes further with non-obvious traits: a newer message REOPENS the conversation with the verdict kept, and marking does NOT reach a message already handed to the queue. This is behavioral context well beyond the annotations.

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 verdict definitions, then layers orthogonality, batching, closing semantics, and routing. Dense but each paragraph carries information; the length is justified by the eleven parameters and the destructive/reopen semantics, though it is heavier than strictly necessary.

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 fully covers what the tool does to state (closes conversation, cancels scheduled steps, hands off, reopens on new message), the queue caveat, and every sibling handoff. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3. The description adds rationale beyond the schema: why profileUrls batching exists (same verdict across a queue, one call saved) and confirms outcome=null only unsets the verdict and revives nothing. Adds genuine meaning over the structured fields.

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 the human verdict) plus the exact resource and enumerates all five verdicts with discriminating definitions (`meeting_booked` = call on the calendar, NOT won). An agent can distinguish this from siblings like li_mark_booked or li_track_booking without opening any 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 to alternatives: use li_track_booking for someone who agreed to a call, li_mark_booked for a booked call, li_reset_contact to revive a sequence, li_job_result to check a queued reply first. It also states when-not (a demo request or booked call is never `won`) and how to undo (outcome=null).

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