[anton_salcher]

Good distinction, but the 90-day trend queries actually don't touch JSONB at all, because trends hit scalar columns (avg_hrv, duration_seconds, start_time) where a regular B-tree index is sufficient. The JSONB arrays are only used for sample-level queries like "show me my HR during last night's sleep" which are inherently single-session lookups, not range aggregations.

On streaming: currently returning complete payloads. For this use case it hasn't been a problem, because the trend queries aggregate 90 rows of scalar data which is fast, and the response is compact text. Streaming would make sense if I were piping large sample arrays directly, but those get aggregated server-side before returning. Worth revisiting if I add something like full workout trace exports.

[silbercue]

> Streaming would make sense if I were piping large sample arrays directly, but those get aggregated server-side before returning

thitami's point on perceived latency is the thing I'd still watch. had the same "its fine, its fast enough" moment in a different MCP context (iOS simulator automation)... turned out the 300ms per-tool-call was what made the whole loop feel sluggish even though each individual query was "fast". got it down to ~20ms and Claude felt noticeably less hesitant between calls after that. cant fully explain why but the behavior shift was real.

probably not your problem at 90 rows of scalar data =) just a thing I wish I had clocked earlier.

[anton_salcher]

Thanks for the tip though. I will definitely keep an eye on the latency thing. If you have any other tips on how to build a MCP Server, I would really appreciate your experience. Moreover, I would really respect it if you could test my product and give me some honest, clear feedback - if you want, obviously. Thanks ;)