Bevel's Own Users Filed an MCP Connector Request. 1.0k Votes Later, It Is Still Under Review.
You can learn more about a health app from its feedback board than from its feature page. The feature page tells you what the team built. The board tells you what the people paying for it cannot do.
AI-assisted, human reviewed. How we use AI
Quick answer
Bevel's public feedback board carries a feature request titled Claude connector / MCP, opened on 22 February 2026, showing 1.0k votes and marked under review when we read it on 21 October 2026 (source: feedback.bevel.health, thread "Claude connector / MCP"). That is the strongest demand proof in this category this year, and it is aimed at a bridge the most feature-complete cloud coach has not shipped. The users are asking for the thing a local MCP server already does: let their own agent read their health data without copying numbers between two apps.
What the board actually shows
The thread is not a vague wish. It is a queue of people describing the same missing interface from slightly different angles, and four separate threads have been merged into it (Export API, AI, Official ChatGPT Integration / MCP Connector, and a request to spend your own OpenAI tokens). The opening post is the shortest and the clearest:
"Connect so I don't need to copy paste across both to speak with each other"
Max Starkman, opening post, 22 February 2026
Nine months later the comments are still arriving, and the most useful one is about architecture rather than features:
"MCP is the number 1 feature I'm now looking forward to. Bevel is actually becoming the main agent about health and fitness, but I need my other agents, which are built around me, to talk to Bevel and plan accordingly. Otherwise it's just a broken stack, if I have to tell one story twice."
Misha Belyaev, 10 October 2026
And a shorter one from 9 October that draws the line between using an app and owning your own analysis:
"I would like to connect data to my own AI but I can't get access."
oliver, 9 October 2026
One verifiable number for the record. On 21 October 2026 the request showed 1.0k votes, status under review, with the original post dated 22 February 2026. Vote counts move, so read the thread yourself before quoting it.
A vote is demand, not a delivery date
"Under review" is honest product language. It means the team has read the request and has not committed to building it. A connector is real work, and a vendor with a cloud coach has a data path to redesign before it can hand a third-party agent read access.
But if you are choosing an app this month because you want your own agent on your health data, a highly voted request is not a feature. It is a queue position. The gap between asking and shipping is where most buyers get stuck, and the board is unusually good at showing you the queue.
Why this specific ask keeps showing up
Look at what the three quotes have in common. Nobody is asking for another in-app report. They are asking to stop maintaining two versions of their own story: one inside the health app's coach, one inside the agent they already use for everything else.
That problem is structural, not a missing toggle. A cloud coach is built so the vendor's model reads your data and answers inside the vendor's product. An agent bridge is built so your model reads your data and answers wherever you already are. Both are legitimate products. Only one of them makes the health app replaceable.
| Vendor connector (what the board asks for) | Local bridge (what you can run today) | |
|---|---|---|
| Who ships it | The health app vendor | You, from an export you already own |
| Data path | Account to vendor to your agent | Phone to local file to your agent |
| Availability | Roadmap dependent | Now |
| Works across apps | One vendor at a time | Any app that exports |
| Read access to raw metrics | Whatever the vendor exposes | Read-only tools over your file |
| Vendor can revoke it | Yes | No |
What the ask tells you to check before you buy
If an agent bridge matters to you, four questions settle it faster than any feature list:
- Is there a documented tool list, such as an MCP server, or only an in-app assistant?
- Can you point at the data path, ideally a local file you can open yourself?
- Is the server open source, so you can read what it does with your data?
- Does it still work if the vendor's roadmap slips, or does access depend on them shipping something?
The path that does not wait
Export your Apple Health data to JSON on your phone, keep the file local, and run an MCP server against it. Your agent calls read-only tools and gets real numbers instead of a summary someone else wrote. No account in the middle, no queue, no vendor decision.
{
"mcpServers": {
"health-export": {
"command": "node",
"args": ["/Users/you/.health-export-mcp/server.mjs"],
"env": {
"HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
}
}
}
}Then ask your agent to call get_mcp_status to confirm it can see the export, and follow with something like "which nights did my sleep stages shift this month". You get an answer built on your own baseline, from your own model. Nothing in it is a diagnosis, just a deviation from your personal baseline.
Good product, different layer
This is not an argument that Bevel is bad. A long, well-documented capability list and a public feedback board where the team merges duplicates are both signs of a company that listens. If you want a coach inside the app, that is a real product and it is probably excellent.
The argument is narrower and more useful: the most complete cloud coach in the category has a 1.0k-vote open request for exactly the interface a local bridge gives you on day one. When your own users write "otherwise it's just a broken stack" about a missing connector, the demand is not speculative, and the waiting is optional.
FAQ
Does Bevel have an MCP server?
No public MCP server is documented. Bevel runs a public feedback board where a Claude connector / MCP request has been open since 22 February 2026 and shows 1.0k votes. The board marks it under review, which means it is a request the team has acknowledged, not a shipped interface.
What does a highly voted feature request actually prove?
It proves demand, not delivery. A vote count tells you that a lot of people want the same interface, and that the vendor has not shipped it yet. Treat it as evidence about the category gap, and plan around what exists today rather than a roadmap item.
Why do health app users want MCP instead of an in-app AI coach?
Because their analysis already lives somewhere else. People running their own agent want their sleep, HRV and training history in the same context as their calendar, notes and work, without copying numbers between two apps. The board posts say this in almost exactly those words.
Can I get my Apple Health data into my own agent today without waiting for an app to ship a connector?
Yes. Export Apple Health from your phone to a local JSON file, then point a local MCP server at that file. Your agent reads the file directly, on your machine, and the vendor of the health app is not in the path at all.
Doing this yourself? MetricBridge handles the export step: all 190 metrics as local JSON, with the open-source MCP server (GitHub).
Skip the queue
A $24.99 one-time unlock: 190 metrics as local JSON, the open-source MCP server with 16 read-only tools, plus the on-device Ask and Weekly Brief.