Lack of personal conversation views through MCP

​@marklaz81 I promoted your previous reply to a new topic in this group for better visibility!

Hi ​@marklaz81, thanks for your patience here. The MCP server now has the ability to search for conversations that are open for you, so this use case should be satisfied. Would you mind letting us know whether it fits your needs? Thanks!

Yes this is the problem I'm having to 

It doesn't work. It returns the COUNT of what is personally open but not all of the conversation ids.

Does this give MCP or API access / view of personal Snooze status e.g. ability to see whether a given Conversation is snoozed in someone’s inbox, and to what date?  I’ve been using a VERY clunky workaround (Rule that tags conversation as Snoozed when snoozed) that isn’t reliable. 

Thanks Javier. I've tested the updated server fairly thoroughly and I'm afraid it doesn't fully satisfy the use case yet — JimKeough's experience matches mine.

The good news first: the response schema has improved. Conversations now return an `inboxes` array rather than a single inbox field, which correctly handles conversations that live in more than one inbox. That's a genuine step forward.

But three issues remain when trying to reconstruct what's actually in my personal sidebar (

1. Over-count / scope overreach. `search_conversations` with status:open and scope:my_conversations returns a totalCount of 60 — nearly double the 32 my sidebar shows. A lot of the excess is conversations in shared workspace inboxes (Enquiries, Report Admin) that I'm a participant in or assigned to, but which don't appear in my personal sidebar sections. There doesn't seem to be a way to scope the query to the sidebar's actual membership rules.

2. The status filter isn't reliably honoured. Even with status:open specified, the results include conversations whose ticketStatus.category is "resolved"/archived. So a client can't trust the server-side filter and has to re-check status on every record.

3. Orphaned/blank records inflate the count. A cluster of records comes back with an empty subject and an empty inboxes array (all timestamped within a couple of minutes of each other). These aren't real, actionable conversations but they're counted in the total. Interestingly they appear under scope:my_conversations but not under scope:all_inboxes, so the two scopes are applying different logic.

To Jim's point: I'd add that beyond the count mismatch, the results are paginated with a cap, so a single call doesn't return the full set of IDs either — you have to page through, and the total still doesn't reconcile.

Net: the ideal would be an option to query by the same view/membership logic Front uses to populate a teammate's sidebar sections (Open, Assigned to me, and custom inbox sections), rather than a raw conversation search that over-returns. 

Thanks for keeping at this.

​@front Please fix this issue. Its affecting us as well 

Hey ​@marklaz81 , ​@JimKeough , and ​@Santevia, this is Martín from the Product team, stepping in for Javier.

Thanks again for the thorough testing — it sent us digging properly, and I wanted to come back with what we found. The short version: after reproducing your steps, we believe search_conversations is behaving as intended. It's designed to mirror Front's own search, not the sidebar's "Open" counter — and that distinction explains all three of your points.

1. On the over-count / scope. Our MCP search replicates Front's search functionality directly. Could you try this in Front itself: go to your Open inbox and type is:open in the search bar (exactly like the screenshot below)? That's effectively the query the MCP is running, and it should line up with what the MCP returns. We weren't able to reproduce a mismatch on our side. The reason you're seeing more than your sidebar shows is most likely open Discussions and Drafts — the sidebar counter of “Open” doesn't include those, but search does (As front works as of today)
2. On "open" returning archived/resolved conversations. This one is actually expected behavior rather than a bug. In Front, each subscriber to a conversation has their own individual status. When another teammate who was the assignee resolved it, that updated the conversation's status globally — but it stayed open for the other subscribers in their own inboxes. So a search for "open" returns conversations that are open to you, even if they've been resolved globally, and the MCP mirrors that exact behavior. Drafts surface under the same logic.

3. On the extra records inflating the count. Same root cause: Drafts come back as "open" because they haven't been archived. So what you're getting is a mix of everything that's open to you as a person — conversations, discussions, and drafts — which won't line up one-to-one with the "Open" counter in your sidebar.

A couple of things that would help us close this out:

• Would you mind running the conversation status "open" search in Front's own search bar (as in the image) and comparing it against what the MCP returns? That's the true apples-to-apples check.
• If it still doesn't match after that, could you share the actual response from the LLM? That would let us see exactly what it's working with.

Hope this is helpful. Since search_conversations is built to mimic the search tool rather than the sidebar view, if what you're really after is validating specifically against the sidebar UI, I'd genuinely love to understand the "why" behind it — it may be a distinct need worth looking at separately. But as far as we can tell, the search itself is working as intended.

Thanks for keeping at this with us.

Hey ​@jay ! This is actually a current gap on our search conversations tool, that we are not getting the metadata or even snoozed conversations. Its coming up soon in the roadmap and already prioritized!

That’s good to hear!  I would love to be notified when this is ready (via this thread maybe).