#feedback
Feature request — API / MCP connector: support setting a contact's status to…
# feedback
h
Hessan Haiderzada
06/09/2026, 10:59 AMFeature request — API / MCP connector: support setting a contact's status to "Meeting booked" Today we can mark a contact as Replied via the API and the MCP connector, but there's no way to set "Meeting booked" (or update contact status generally) programmatically — it can only be done by hand in the UI. Since we book meetings through outbound, we'd like to keep the "Meetings booked" metric and contact statuses accurate automatically rather than updating each contact manually. Could you add an endpoint / MCP tool — e.g. update_contact_status (or mark_contacts_as_meeting_booked) — that accepts prospect IDs or emails plus a target status? Ideally exposed on the v3 API and surfaced through the MCP connector so agent-driven workflows can flag contacts the moment a meeting is confirmed. That would close the gap with the existing "mark as replied" action and keep our reporting and CRM sync clean.
d
Daniil
06/09/2026, 11:03 AMHey Hessan!
Thank you for your feedback - I really appreciate it!
I'll make sure to forward this feature request to our Product team for review. If there's anything else you'd like to share or suggest, please don't hesitate to let me know.
Have a great rest of the day!
h
Hessan Haiderzada
06/09/2026, 11:03 AMMany Thanks Daniil
m
Max Foster
06/09/2026, 11:05 AMHey @Hessan Haiderzada ,
I see that the Update a contact endpoint allows you to pass the meetingStatus https://docs.reply.io/api-reference/contacts/update-a-contact#body-meeting-status
Will this be sufficient or do you require a more enhanced way of setting the "Meeting booked" for contacts?
h
Hessan Haiderzada
06/09/2026, 11:07 AMThanks — meetingStatus: "meetingBooked" on PATCH /v3/contacts/{id} is exactly the field we need, so the capability itself is sufficient.
For our agent/MCP-based workflow to use it, two asks:
1) Expose it through the Reply MCP connector as a tool (e.g. set_meeting_status or update_contact) — we drive Reply via the connector, not raw REST, and today only mark_contacts_as_replied is available there.
2) Make it work by email and in bulk — accept a list of emails or prospectIds and set the status in one call (same shape as mark_contacts_as_replied's prospectIds[]). We typically mark a batch of booked meetings at once and identify contacts by email, so an email→id lookup or email-keyed tool would save a round-trip.
Also noting the endpoint is currently Beta, and meetingStatus is binary (none/meetingBooked) — both fine for us, just confirming that's intended.
d
Daniil
06/09/2026, 11:24 AMThank you again for the clarification. I’ve already forwarded the details to the team.
"_Also noting the endpoint is currently Beta, and meetingStatus is binary (none/meetingBooked) — both fine for us, just confirming that's intended."_
Yes, I can confirm that the endpoint is currently in Beta. While there may be changes to the meetingStatus values (none / meetingBooked) in the future, they currently remain as they are and this behavior is expected.
h
Hessan Haiderzada
06/09/2026, 11:30 AM@Daniil Also, one more important request so that we can let client reporting run via agent:
Copy code
we run our weekly client reports through an AI agent (via the Reply MCP connector), and it can already pull stats and manage sequences fine. There's one gap stopping it from running the reports end-to-end, and it's the important one.
The problem — the agent can't read prospect replies:
Our reports are built almost entirely from the CONTENT of inbound replies — we read each prospect's reply and categorise it (interested / callback / wrong contact / not interested / opt-out / meeting booked) into the client report. The agent talks to Reply only through the MCP connector, and today that connector exposes sequences, sequence/contact stats (open/reply/click counts), our own sent content, and mark-as-replied — but NOT the inbound reply message bodies. So it can see THAT a contact replied and the reply rate, but not WHAT they wrote. As a result we still copy every reply out of Gmail/Outlook by hand and paste it into the agent — that manual step is the main thing keeping a human in the loop.
Important: the capability already exists in your v3 REST API — the Inbox endpoints, specifically "List inbox threads" / "Filter inbox threads" and "List messages in an inbox thread" (plus "Get inbox thread"), currently Beta. The gap is purely that these reads aren't surfaced through the MCP connector, and the agent only reaches Reply via the connector (it can't call raw REST).
Ask:
1) Expose the Inbox read endpoints in the Reply MCP connector — list/filter threads (by sequence, owner, date range, read/category status) and read the full message body (from, subject, body, timestamp, linked contact id/email). Read-only is enough for us.
2) Bonus: combined with the meetingStatus write we asked about earlier, the loop closes fully — the agent could read a reply, categorise it, and set the contact's status (replied / meeting booked) in a single pass, with no manual copy-paste.d
Daniil
06/09/2026, 11:48 AMThank you for the details, Hessan 👍
I’ve also forwarded this feature request to the team for their consideration. I’ll keep you posted if there are any updates from their side. If you have anything else to add, don't hesitate to let me know!