Rookie

Question

API / MCP gap: no way to fetch a user's "Open" view (personal + assigned + subscribed)

Forum|Forum|1 month ago
June 28, 2026
5 replies
265 views

I run an AI agent on claude that sweeps my Front every morning and surfaces what actually needs my attention, especially activity on our biggest deals. Front is the source of truth for that, so the agent reads conversations through the API (and I looked at the new MCP server too).

The core problem: there's no way to programmatically get my "Open" view, the thing I look at in the UI every day. My Open is the union of my personal inbox + conversations assigned to me + conversations I'm subscribed/following. The first two are reachable. The subscribed bucket is not.

Specifically:

follower: search is unreliable. Searching follower:<me> returns only a handful of conversations (4 in my case) when my actual Subscribed bucket in the UI is 23. The conversation object itself correctly lists me under /conversations/{id}/followers, but I can't search or list by it. So there's no way to enumerate "everything I follow."
No "Open view" union endpoint. Your own MCP docs confirm this: "There's also no current way to fetch the union of a user's personal inbox plus conversations assigned or subscribed to them. The MCP server returns conversations from the queried inbox only," and "no tools exist to filter by followed/subscribed status in v1."

Here's why it matters in practice. Two of our largest active deals had real movement on a Friday. On both, I was a subscriber/participant, not an @mention, and the threads lived in a teammate's inbox. Because the agent could only reliably read my own inbox + @mentions, it reported "no movement" on both. They were sitting right there in my Open view the whole time. The only reason I caught it was by manually checking.

The workaround I'm stuck with is sweeping teammates' inboxes and content-searching for known client names. That's brittle, and it completely misses any new deal where I'm a silent subscriber.

What I need (any one of these would solve it):

An endpoint/MCP tool that returns a user's Open view directly: the union of their personal inbox + assigned + subscribed, filterable by status (open/archived).
A subscribed: / follower: search filter that actually returns all of a user's followed conversations, or an endpoint to list the conversations a teammate follows.
Per-user OAuth in the MCP is great (it authenticates as me), but it needs a tool that respects my personal Open/Subscribed view, not just per-inbox queries.

Is any of this on the roadmap for the full MCP release or the API? The "built from the ground up, not a wrapper" rebuild sounds like the right moment for it. Happy to be a beta tester. This single gap is the difference between an agent that reliably watches my pipeline and one I can't fully trust.

Thanks.

conversations

Javier - Developer Relations

Community Manager

Hey @romanpey, thanks for sharing this detailed report!

Yes, we have encountered this issue ourselves, and are working to improve the search tool. I can confirm that we have open tickets for searches to include all possible conversations that you have access to, not just the ones that you’re assigned to or are in your personal inbox. We’re also exploring how we can better serve the use case you mentioned around views (what is “open” for me, etc.). I can share more as we progress these improvements!

One thing to note is that these improvements are targeted for our MCP server, not the API.

Javier - Front Developer Relations

JimKeough

Conversationalist

Yes this is the problem I'm having to

JimKeough

Conversationalist

Thanks Javier — glad to hear the MCP search improvements are underway.

I want to add a related but distinct finding to romanpey's, in case it's useful for the same work. Mine isn't about the follower/subscribed bucket — it's about conversations with no inbox.

Reproducible test: I applied a single shared tag to 41 conversations (confirmed count in the UI). Then:

- REST `/tags/{id}/conversations` returned 23
- REST `/conversations/search/tag:{id}` returned 23
- Reading one of the "missing" conversations by ID confirmed the tag was genuinely applied — it just had no inbox (it was a discussion, `inbox_id` empty)
- The moment I moved that conversation into a shared inbox, it appeared in the results and the count went to 24

So the listing/search endpoints appear to silently exclude any conversation without an inbox (discussions, some channel items), even when the tag is definitely present. They're readable individually by ID, just not enumerable.

Interestingly, the MCP `search_conversations` tool did *not* have this problem — it returned a `totalCount` of 41, including the inbox-less discussion. So on this specific axis the MCP is already ahead of the REST API. The one gap I still hit on the MCP side is enumeration: the tool returns an accurate `totalCount` but only ~5 conversations per call with no pagination cursor, so I can count the full set but can't list it.

That's the crux for my use case (an agent maintaining a working queue): I need the full enumerated list, not just a count. So my question on the roadmap — will the improved MCP search support paginating through the complete result set, and will inbox-less conversations be included in it? If both, that fully solves my case.

Happy to share exact request/response details or beta test. Thanks!

marklaz81

Conversationalist

TThanks Javier — glad to hear the MCP search improvements are underway.

I want to add a related but distinct finding to romanpey's, in case it's useful for the same work. Mine isn't about the follower/subscribed bucket — it's about conversations with no inbox.

Reproducible test: I applied a single shared tag to 41 conversations (confirmed count in the UI). Then:

- REST `/tags/{id}/conversations` returned 23
- REST `/conversations/search/tag:{id}` returned 23
- Reading one of the "missing" conversations by ID confirmed the tag was genuinely applied — it just had no inbox (it was a discussion, `inbox_id` empty)
- The moment I moved that conversation into a shared inbox, it appeared in the results and the count went to 24

So the listing/search endpoints appear to silently exclude any conversation without an inbox (discussions, some channel items), even when the tag is definitely present. They're readable individually by ID, just not enumerable.

Interestingly, the MCP `search_conversations` tool did *not* have this problem — it returned a `totalCount` of 41, including the inbox-less discussion. So on this specific axis the MCP is already ahead of the REST API. The one gap I still hit on the MCP side is enumeration: the tool returns an accurate `totalCount` but only ~5 conversations per call with no pagination cursor, so I can count the full set but can't list it.

That's the crux for my use case (an agent maintaining a working queue): I need the full enumerated list, not just a count. So my question on the roadmap — will the improved MCP search support paginating through the complete result set, and will inbox-less conversations be included in it? If both, that fully solves my case.

Happy to share exact request/response details or beta test. Thanks!

This was raised over a month ago - It seems this maybe an ongoing problem without a solution. The agent use case is interesting, maybe they want to charge for such a tool directly?!

Javier - Developer Relations

Community Manager

For the original question in this post, this related post has a deeper ongoing discussion:

For the REST API question, I imagine this is working as expected and would mirror search in the UI + whatever access the API token has. I don’t think there is any gap with our API search, but let me know if I’m misunderstanding. You should be able to see all the conversation results unless the API token doesn’t have access to certain resources, such as specific shared inboxes or lacks access to personal resources.

For whether the MCP server can paginate through a full list of relevant conversation results, I want to tag @eric.neto and @martin_silva for a response.

Javier - Front Developer Relations

Sign up

Use your Front credentials

Login to the community

Use your Front credentials