charter 0.2.4

Notes

• No code changes, for the same reason as 0.2.3, under conditions where it can
  work. 0.2.3 was cut to force PyPI to republish its cached project page, which
  had been serving a render from 0.1.0. That attempt could not have succeeded: an
  upload fires a cache purge, but the purge needs PyPI's web backend alive to
  regenerate the page, and the backend was down — unannounced — from before 0.2.2
  went out until roughly 12:50Z. Both purges were lost. Downloads were never
  affected, since files.pythonhosted.org stayed healthy throughout. The backend
  has since recovered, so this upload's purge is the first one able to land. The
  package is identical to 0.2.2 apart from __version__.

charter 0.2.3

Notes

• No code changes: this release exists to make 0.2.2 visible. The 0.2.2
  artifacts uploaded and served correctly — both files answer 200 from
  files.pythonhosted.org — but PyPI's cached read surfaces disagreed with each
  other and with the upload: the project page served a render from 0.1.0, three
  days old, while /pypi/charter-ai/json answered 0.2.1 and the JSON /simple/
  index answered 0.2.2. Peer packages were consistent over the same window, so the
  stale object was this project's, not a PyPI-wide lag. An upload re-emits the
  project's purge keys, which is the only lever a publisher has. The package is
  identical to 0.2.2 apart from __version__.

v0.2.2

Fixed

• A progressive MCP server comes up in a third of the time on every pack.
  Building a ToolSession sized every tool's schema to decide what to defer, and
  sizing one builds it: about 1.5s for Linear's 128 tools and 8s for the fifteen
  packs together. At
  the default threshold of zero that work has one possible outcome. Nothing can be
  resident — schema_tokens cannot reach zero, since pydantic writes type and
  properties for every model and the smallest parameter schema a tool can carry
  is {"properties": {}, "type": "object"}, 9 tokens before a field is declared
  and 16 across the shipped packs — so every schema was derived to answer a
  question that was already answered.

  python -m charter.mcp paid it between the client's initialize and the reply,
  which made the progressive server — the one that sends no schemas at all — the
  slower of the two to come up, behind --no-progressive, which sends every one.
  Over the same handshake, median of seven: --pack linear answered initialize
  in 4.8s and now answers in 3.3s; all fifteen packs took 14.7s and now take 6.8s.
  What is left is the pack import itself, which is pydantic building the
  declarations — 2.7s of Linear's is its recursive filter graph. A positive
  threshold still has to weigh every schema to place it, and still costs what it
  did.

  The partition was also, incidentally, prepare() for every tool it walked — and
  for the wrong tools, since a progressive server publishes ToolSearch and
  nothing else. ToolSearch now prepares each tool as it loads it, which is the
  same work in the same amount at the one point in the exchange where a schema was
  always going to be built. Preparing is the optimisation and loading is the
  contract, so it happens after the load and a tool whose view cannot be built no
  longer takes the rest of the query down with it.

  This finishes what 0.2.0 started under Performance. Deriving a view at
  construction was dropped there because it "holds for one tool and not for 128
  that a session will never all expose" — and then the partition touched all 128
  anyway, one layer up, on the first session built over them.

• tools/list no longer rebuilds every loaded tool's schema. The MCP adapter
  called llm_json_schema(tool.llm_schema()) per entry, which is the same value as
  to_json_schema()["parameters"] without the cache behind it. A client re-lists
  after every ToolSearch, so the 40ms-per-tool generation was paid again on each
  load for every tool already loaded. Serving Linear with --no-progressive, a
  repeated tools/list drops from 707ms to 29ms.

charter 0.2.1

Fixed

• pip install 'charter-ai[mcp]' now installs from wheels on every supported
  platform. The extra reaches cryptography three levels down — mcp →
  pyjwt[crypto] → cryptography — and upstream has retired that wheel platform
  by platform: macOS Intel after 48.0.1 (49.0.0 is arm64-only), Windows ARM64 after
  46.0.3, Windows 32-bit after 48.0.1. With no wheel, pip and uv fall through to a
  source build and the install ends in cargo metadata, naming maturin and
  Cargo.lock — an error that does not read as anything to do with an MCP server.

  The extra now caps cryptography on exactly those three platforms, at the newest
  release each can still install, and leaves Apple Silicon, Linux and Windows x64
  on the current version. Nothing on the served path imports cryptography — it
  reaches mcp only for OAuth verification on HTTP transports, and Charter serves
  stdio — so the cap costs those platforms no behaviour.

charter 0.2.0

Added

• format_path_costs renders paths(by_cost=True) as a column, so the branch that dominates a schema is visible without reading every label.
• pass_through, and response_handler on Tool.derived. A pack's handler was previously take-it-or-leave-it: the only way to change what a tool handed back was to rebuild it, restating the URL, credentials, casing and envelope the pack carries.

Fixed

• Reference pages for format_path_costs and pass_through, and the derived signature, which omitted the new argument.
• Live provider tests no longer assert a third party's page content, and a provider that will not serve us — expired key, exhausted quota, rate limit — skips instead of failing. CI excludes them outright.

Full notes in CHANGELOG.md.

charter 0.1.0

Full Changelog: https://github.com/r28ai/charter/commits/v0.1.0