Skip to content

feat(mcp): v0.1.10 — auto-downsample get_temperature_history to fit under 1 MB cap#9

Merged
hculap merged 1 commit into
mainfrom
feat/v0.1.10-mcp-response-cap
May 21, 2026
Merged

feat(mcp): v0.1.10 — auto-downsample get_temperature_history to fit under 1 MB cap#9
hculap merged 1 commit into
mainfrom
feat/v0.1.10-mcp-response-cap

Conversation

@hculap
Copy link
Copy Markdown
Owner

@hculap hculap commented May 21, 2026

Summary

  • Fix the 7-day temperature history blocker in Claude Desktop: tool-result payload was ~2.6 MB (per-minute samples × 8 zones × 7 days), exceeding the client's ~1 MB / 25k-token cap.
  • get_temperature_history now bucket-averages each zone's series to at most 600 samples before returning. Empirical 7-day × 8 zones: 2,733,887 → 161,612 bytes (17x reduction).
  • Response gains a downsample envelope ({downsampled, max_points_per_zone, per_zone: {<key>: {original, returned}}}) so the agent can surface the pre-bucket sample count. The {x, y} shape and series keys are unchanged.
  • Bumps to 0.1.10.

Background — why downsampling, not a FastMCP setting

I checked the MCP Python SDK (mcp.server.fastmcp) — neither Settings nor the FastMCP(...) constructor exposes any response-size knob (max_response_size, max_message_size, nothing). The 1 MB cap lives client-side in Claude Desktop / Claude Code — controlled there by MAX_MCP_OUTPUT_TOKENS (default 25k tokens, docs). The official server-side mitigations Anthropic suggests are: (a) declare an anthropic/maxResultSizeChars annotation, or (b) paginate/downsample. We can't change the client cap from the server, so downsampling is the correct lever.

Test plan

  • ruff check emodul/ --select=E,F,I,B --ignore=E501 — clean
  • CI MCP smoke test (stdio client): exposes 17 tools, get_temperature_history advertises downsampling in its description
  • Pure-transform tests on _downsample_series (empty, small-passthrough, at-threshold, over-threshold, mixed None-y, max_points=0 safety)
  • Empirical size check on simulated 7d × 8-zone payload: 154 KB post-downsample (was 2.61 MB)
  • CLI emodul stats linear untouched — separate code path
  • No tool-signature changes, no new tools (tool count stays at 17)
  • Real-controller verification — please test against your live --module Parter once merged

Claude Desktop's ~1 MB / 25k-token tool-result cap was blocking 7-day
history fetches across all zones (~2.6 MB raw). FastMCP / the Python
MCP SDK has no server-side response-size knob — the cap is enforced
client-side — so the only fix is to shrink the payload on the server.

`get_temperature_history` now bucket-averages each zone's series down
to at most 600 samples (10-min resolution over a week, 30-min over a
month). Empirically: 7-day × 8 zones drops from 2,733,887 → 161,612
bytes — 17x reduction, well under every known client cap. Samples
keep the `{x, y}` wire shape so existing agent code keeps working;
the response gains a `downsample` envelope reporting pre/post counts
per zone.

CLI `emodul stats linear` is unaffected.
@hculap hculap merged commit e8d7845 into main May 21, 2026
9 checks passed
@hculap hculap deleted the feat/v0.1.10-mcp-response-cap branch May 21, 2026 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant