1.0.7 — Package metadata refresh and version bump

Summary

Version 1.0.7 is a small, packaging-focused release. It updates package.json only, primarily to finalize the 1.0.7 version and refresh package metadata/dependency declarations.

Changes

Packaging / metadata

• Bumped package version to 1.0.7.
• Refreshed package.json metadata and dependency declarations (no source code changes).

Dependencies

• No functional/runtime code changes were made in this release; only dependency declarations/metadata were adjusted in package.json.

Impact

• Users: No behavior changes are expected at runtime; this release should be a drop-in update.
• Developers / maintainers: Packaging metadata is aligned for the 1.0.7 release; scripts and dependency declarations were refreshed.

Breaking changes

• No breaking changes detected in the diff (and no API/source files changed).

1.0.6: Publish workflow and repo hygiene updates (lockfile + KodrDriv config)

Summary

This release is a maintenance/update release focused on making publishing more reliable and keeping the repo clean, primarily by formalizing lockfile handling and tracking only the necessary KodrDriv publish configuration.

Changes

Publishing / release process

• Added KodrDriv publish configuration via .kodrdriv/config.yaml to enforce a consistent rule during publish:
  • publish.lockfilePolicy: ignore (publishing should not require a committed package-lock.json).
• Updated .gitignore to:
  • Ignore KodrDriv working files (.kodrdriv*, .kodrdriv/*) while explicitly keeping !.kodrdriv/config.yaml tracked.
  • Ignore package-lock.json.

Why it matters: KodrDriv publish workflows can fail prechecks if the working tree becomes dirty due to lockfile rewrites. These changes make publishes less brittle by aligning repo tracking with the publish policy.

Package metadata / tooling

• Updated package.json (small maintenance changes):
  • Version set to 1.0.6
  • Minor dependency/tooling and script refinements (no functional runtime changes indicated by the diff scope).

Impact

For library consumers

• No user-facing API changes are indicated in this release; it is primarily build/publish hygiene.

For contributors / maintainers

• package-lock.json is now intentionally not tracked and is gitignored.
  • Local installs may still generate a lockfile; it should not be committed.
  • CI/publish will rely on npm install behavior without a committed lockfile, so dependency resolution may vary over time within semver ranges.

Breaking changes

• No breaking changes detected in the changes from main to HEAD.
• Note: while not an API break, the repository policy change (not committing package-lock.json) may require workflow adjustments for contributors who previously relied on a committed lockfile for reproducible installs.

Release 1.0.5 — publish workflow hardening, dependency/tooling updates, and tracked lockfile

Main story

1.0.5 is primarily a packaging and release-process update. It tightens up publish-time checks, updates tooling/dependency versions, and ensures the repository consistently tracks the npm lockfile so installs and CI behave deterministically.

Changes in this release

Publishing & release hygiene

• Hardened prerelease/publish prechecks so publish validation and lockfile policy checks behave consistently.
• Lockfile is now tracked (and no longer ignored), making dependency resolution reproducible across machines and CI.
• publishConfig.tag is set to dev in package.json, steering publishes toward the dev dist-tag by default.

Scripts and metadata

• Updated package.json scripts to standardize the build/test/lint flow:
  • build: vite build
  • test / test:coverage: vitest run --coverage
  • precommit: build && lint && test
  • prepublishOnly: clean && build
• Package metadata and dependency declarations were refreshed (including updated dev tooling versions).

Dependency/lockfile updates

• Updated package-lock.json to reflect the current dependency tree.
• Notable: while package.json depends on @modelcontextprotocol/sdk as ^1.0.4, the lockfile resolves it to a newer compatible version (as expected with a caret range).

Impact

For users

• More predictable installs due to the committed lockfile.
• No runtime behavior changes are indicated by this diff; changes are concentrated in packaging/tooling.

For maintainers/contributors

• More consistent publish behavior due to tightened prechecks and explicit publish configuration.
• CI/local parity improves because installs will match the committed lockfile.

Breaking changes / important notes

• Potentially breaking (publishing behavior): publishConfig.tag is now dev. If you publish from this repo without overriding tags, npm publish will default to the dev dist-tag rather than latest.
  • If you intend a stable release to land on latest, publish with an explicit tag (for example, npm publish --tag latest) or adjust publishConfig for the release process.
• No API- or code-level breaking changes were detected in this release range (changes are limited to repo config, scripts, and dependencies).

1.0.4 — Dependency/tooling updates, Node.js >=24 requirement, and refreshed Apache 2.0 license header

Summary

Version 1.0.4 is a maintenance release focused on project metadata and build/test tooling. It updates dependencies, tightens the supported Node.js runtime, and refreshes the LICENSE file to reflect current copyright/Apache 2.0 compliance.

Changes

Runtime requirement

• Node.js engine requirement is now >=24.0.0 (package.json#engines).
  • Impact: installs may fail (or warn, depending on your package manager settings) on Node 23 and earlier.

Dependency and tooling updates

• Updated runtime dependency:
  • @modelcontextprotocol/sdk to ^1.0.4
• Updated dev tooling versions (not exhaustive, see package.json):
  • eslint ^9.28.0
  • typescript ^5.8.3
  • vite ^7.0.4
  • vitest / @vitest/coverage-v8 ^3.2.4
  • @types/node ^25.0.6
  • vite-plugin-dts ^4.5.4
  • @typescript-eslint/* ^8.33.1

Licensing

• Updated LICENSE to an Apache License 2.0 text with current copyright holder.

Breaking changes

• Potentially breaking: the Node.js engine constraint is now >=24.0.0. Consumers running older Node versions will need to upgrade Node to install/use this package.

No other breaking changes were detected in this release range (no API/code changes beyond metadata and dependency/tooling updates).

Release 1.0.3 — package metadata and dependency declaration updates

Summary

1.0.3 is a packaging-only release. There are no source code changes; updates are limited to package.json (versioning/metadata and dependency declarations).

Changes

Packaging / metadata

• Bumped the published package version to 1.0.3.
• Updated package.json metadata and dependency declarations (no functional/runtime code changes included in this release).

Impact

• Users: No behavior changes expected at runtime. This release primarily affects how the package is described and resolved via npm (version and dependency metadata).
• Developers/Maintainers: Cleaner/more accurate package metadata and dependency declarations for publishing and consumption.

Breaking changes

• None detected in the diff between main and HEAD for this release range (only package.json changed).

1.0.2 — Ensure MCP sampling requests always include `maxTokens`

Main change: MCP sampling spec compliance (maxTokens)

SamplingProvider now always sends a maxTokens value in sampling/createMessage requests.

• What changed

  • In convertToSamplingRequest(), maxTokens is now set to a default of 8192 when not provided via ExecutionOptions:
    • maxTokens: options?.maxTokens ?? 8192

• Why it matters

  • maxTokens is required by the MCP sampling specification. Previously, if callers did not provide options.maxTokens, the request could be sent without maxTokens, which can cause MCP clients to reject the request as invalid (often surfaced as invalid-params errors).

• Impact

  • Users: fewer “invalid sampling request parameters” failures when using clients that strictly validate MCP sampling requests.
  • Developers: no required code changes. You can still override the limit by passing maxTokens in execute(request, { maxTokens }).

Packaging

• Package version updated to 1.0.2 in package.json.

Breaking changes

• No breaking changes detected in this release. The maxTokens default may change behavior for consumers who previously relied on the MCP client’s implicit defaults when maxTokens was omitted (the request now explicitly caps at 8192 unless overridden).