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.
Bevel's public feedback board carries a feature request titled Claude connector / MCP, opened on 22 February 2026. When I read it on 21 October 2026 it showed 1.0k votes and was still marked under review. Four separate threads had been merged into it, including Export API, AI, and Official ChatGPT Integration / MCP Connector.
What the thread actually says
The opening post is the shortest and clearest:
Connect so I don't need to copy paste across both to speak with each other.
Nine months later the comments are still arriving. 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.
And a shorter one:
I would like to connect data to my own AI but I can't get access.
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.
Why this ask keeps showing up
Nobody in those threads 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. Only one of those makes the health app replaceable.
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.
{
"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 capability list and a public feedback board where the team merges duplicates are both signs of a company that listens. The argument is narrower: 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.
MetricBridge handles the export step: all 190 metrics as local JSON, plus the open-source MCP server with 16 read-only tools.
Read the full write-up with the source thread and the four buying questions: Bevel's Users Filed an MCP Request.
