---
summary: "Constrain four per-page cap inputs to integers, rejecting fractional values that were previously silently floored or forwarded upstream."
breaking: true
security: false
---

# 0.6.0 — 2026-07-28

## Changed

- **`pubchem_get_compound_xrefs`**'s `maxPerType`, **`pubchem_search_assays`**'s `maxResults`, **`pubchem_get_bioactivity`**'s `maxResults`, and **`pubchem_search_compounds`**'s `maxResults` now advertise `integer` instead of an unconstrained `number`. All nine cap inputs across the server (these four plus the already-integer `maxSynonyms`, `maxDescriptions`, `maxAtoms`, `maxBonds`, `maxEntries`) now advertise `integer` consistently. ([#44](https://github.com/cyanheads/pubchem-mcp-server/issues/44))

**Migration:** a call passing a fractional value to any of the four inputs above now fails input validation instead of succeeding. Previously, `pubchem_get_compound_xrefs.maxPerType`, `pubchem_search_assays.maxResults`, and `pubchem_get_bioactivity.maxResults` silently floored a fractional cap via `Array.prototype.slice`, returning fewer results than the schema implied without any error. `pubchem_search_compounds.maxResults` is a narrower case: for formula, substructure, superstructure, and similarity searches the handler derives the upstream record window directly from this input, so a fractional value previously reached PubChem verbatim and the call already failed — with an upstream HTTP 400 rather than a local validation error. For that one input the change moves an existing failure earlier and makes it legible; for the other three it is a new rejection where a call previously succeeded. Round every value passed to these four inputs to a whole number before calling.

Completes [#44](https://github.com/cyanheads/pubchem-mcp-server/issues/44).