ToolGate manual development e5edc4acd596

Manual development build for commit e5edc4acd596c85dfebd33b436a1c1d16a4fdabf.

No CI verification, tests, scans or smoke tests were run. Maven signing runs in its separate publication job.

Library version: 1.0.0-dev.38776668404.1.ge5edc4acd596. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  `TOOLGATE_AU...

ToolGate development e5edc4acd596

Development artifacts for commit e5edc4acd596c85dfebd33b436a1c1d16a4fdabf.

Maven: io.github.olo-labs:toolgate-contracts:1.0.0-dev.38776542656.ge5edc4acd596.

Six native client packages retain the tested source version 0.10.0-dev; their commit identity is recorded in development-release.json.

Container digests and checksums are included.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer ...

ToolGate manual development c8d2a6ab0e8a

Manual development build for commit c8d2a6ab0e8a78cb9a371006b99c6d3ccefac732.

No CI verification, tests, scans or smoke tests were run. Maven signing runs in its separate publication job.

Library version: 1.0.0-dev.38613766319.1.gc8d2a6ab0e8a. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  `TOOLGATE_AU...

ToolGate manual development 9db9b812218c

Manual development build for commit 9db9b812218c81d4331c715464a052a3db84813c.

No CI verification, tests, scans or smoke tests were run. Maven signing runs in its separate publication job.

Library version: 1.0.0-dev.38656272087.1.g9db9b812218c. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  `TOOLGATE_AU...

ToolGate development 9db9b812218c

Development artifacts for commit 9db9b812218c81d4331c715464a052a3db84813c.

Maven: io.github.olo-labs:toolgate-contracts:1.0.0-dev.38654795984.g9db9b812218c.

Six native client packages retain the tested source version 0.10.0-dev; their commit identity is recorded in development-release.json.

Container digests and checksums are included.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer ...

ToolGate manual development 7a6ea7e0edcb

Manual development build for commit 7a6ea7e0edcbaaa7a6327d4b39b89f37bb56ebb6.

No CI verification, tests, scans, smoke tests, or signing were run.

Library version: 1.0.0-dev.38545259803.1.g7a6ea7e0edcb. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  TOOLGATE_AUTH_* it checks JWTs against a JWKS URL or...

ToolGate manual development a97c383a6998

Manual development build for commit a97c383a69986c8ec86153b87f87708229adb8fa.

No CI verification, tests, scans, smoke tests, or signing were run.

Library version: 1.0.0-dev.38367764127.1.ga97c383a6998. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  TOOLGATE_AUTH_* it checks JWTs against a JWKS URL or...

ToolGate development a706a3db0056

Development artifacts for commit a706a3db0056d34107929bd5102b2a8121a34e28.

Maven: io.ololabs.toolgate:toolgate-contracts:1.0.0-dev.38375150142.ga706a3db0056.

Six native client packages retain the tested source version 0.10.0-dev; their commit identity is recorded in development-release.json.

Container digests and checksums are included.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer...

ToolGate manual development 0ded652e7c61

Manual development build for commit 0ded652e7c6152c1bbe9195196bc352f6138f7fd.

No CI verification, tests, scans, smoke tests, or signing were run.

Library version: 1.0.0-dev.38424763727.1.g0ded652e7c61. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  TOOLGATE_AUTH_* it checks JWTs against a JWKS URL or...

ToolGate manual development a827cb102db1

Manual development build for commit a827cb102db1e21d83f696d011096524e9206663.

No CI verification, tests, scans, smoke tests, or signing were run.

Library version: 1.0.0-dev.38318337891.1.ga827cb102db1. Container digests and checksums are attached.

OLO ToolGate 0.10.0-dev release notes

Contracts version: 1.0.0.

License: Apache-2.0. See LICENSE and bundled third-party notices/SBOMs.

Changelog

All notable project changes should be documented here.

The project follows semantic versioning once stable versioning begins.

0.10.0-dev

• Java tools ship as one self-contained executable. toolgatePackage and the Maven package
  goal stage artifacts/tool.jar, a deterministic fat jar of the tool jar and its whole runtime
  class path with Main-Class: io.ololabs.toolgate.runtime.Main, in place of app.jar and
  libs.zip; a device needs only a JRE, and java -jar tool.jar serves the tools over stdio.
  Resources go to the first jar that has them, META-INF/services files are merged, signatures
  and module-info are dropped, and two different copies of one class fail the build. The
  packager, Control and the Tool Host refuse a Java tool that names anything but one jar, so the
  permit's pinned artifact digest now covers everything the tool runs.

• Server tools run on any Tool Host, local or remote, and move by switching the device (M0
  part 15). A deployment may name its Tool Hosts (hostIds on PackageDeploymentRequest and
  PackageDeployment; none means every host); Control's placement sends a call only to a host
  the deployment names, so deploying the same version to another host moves its tools. An
  enrolled Tool Host also fetches its calls from Control (pull mode) over its device
  certificate: POST /api/control/v1/tool-hosts/dispatches/next, then .../{id}/admission
  and .../{id}/result, so a laptop behind NAT runs tools without an inbound route. When the
  Gateway has no route to the placed host it queues the signed Dispatch at
  POST /api/control/v1/access/dispatches and reads ToolHostDispatchStatus from
  GET .../access/dispatches/{id} until the result arrives; the permit is still verified and
  consumed once, on the host. New contract models ToolHostDispatchState and
  ToolHostDispatchStatus; Postgres migration V21 and SQLite V14 add the dispatch queue. The
  console's deploy form takes the Tool Hosts and the versions table shows where each runs. The
  quickstart image runs a second, pull-only Tool Host, and tools/quickstart/check.py calls the
  starter tool on the first host, redeploys it to the second and calls it again there.

• A community guide to building MCP tools with the Tool SDK, TOOL-SDK-GUIDE.md at the
  repository root. It covers authoring, values, routes, errors, effects, testing, standalone use,
  packaging and running under ToolGate. The same file ships in the toolgate-sdk-api jar as
  META-INF/toolgate/TOOL-SDK-GUIDE.md and prints with toolgate guide.

• Java server tools run end to end through /mcp (M0 part 14). Control takes a .tgpkg at
  POST /api/control/v1/packages/uploads (Super Admin), applies the packager's archive rules,
  CHECKSUMS and descriptor digests, and stores the exact bytes; POST .../packages/deployments
  makes a version the one Tool Hosts run, with values for its globals and destination host
  settings, writing the service profile, the globals document, a disabled directory entry per
  new tool and its resource extractor. The Tool Host enrolls as a device (CSR, administrator
  approval, renewal on check-in), registers, fetches its assignments and their content by
  digest, and checks in with the tools it can run, so Control's placement sends it calls like
  any device. The Gateway gains toolHosts: a call placed on one gets a permit from Control's
  v2 reserve and is dispatched to the host; Control takes the host's v2 consume and result
  report. The console gains a Server packages page, the quickstart image runs a Tool Host, and
  tools/quickstart/check.py uploads and deploys the toolgate init starter and calls its
  Java tool through the Gateway, then revokes its grants and checks it disappears. Deploying
  adds new tools to the default Tool Group, a bare runtimes.javaPath is resolved on the host's
  PATH at startup, and the quickstart proxy accepts configuration snapshots up to 2 MiB.

• The Tool Host runs server tools from verified packages (M0 part 13). apps/tool-host
  admits a Gateway dispatch only with an RS256 invocation permit Control signed for that host
  (issuer, audience, admission window, single-use jti, arguments digest), finds the package,
  service profile and globals in its content store by the digests the permit pins, claims the
  permit at Control's permits/consume, and answers ADMITTED with the fencing token or a
  definitive REFUSED reason. It then runs the tool's runtime with a clean environment over
  tool protocol v2 and reports the outcome to effects/report; a crash or timeout is
  OUTCOME_UNKNOWN for ledger tools. Route calls go through a per-invocation broker on a Unix
  socket with a capability: only the permit's routes as the service profile approves them,
  checked path variables, allowlisted query names and headers, connect-time address checks,
  TLS by system roots, CA bundle or SPKI pin, and API_KEY or BASIC credentials added by
  the broker from Control. The Java runtime gains governed mode (TOOLGATE_PROTOCOL=2), and
  apps/tool-host/e2e/run.sh runs the toolgate init starter's package through the host.
  Control's Tool Host endpoints and Gateway dispatch follow.

• The toolgate CLI creates and drives tool projects (M0 part 12). toolgate init <name>
  writes the Java starter for Gradle (the default) or Maven (--build maven): a tool reading a
  global through its typed accessor, a tool calling a declared route with a recorded exchange,
  examples, a ToolHarness test and a git-ignored toolgate.dev.json. In a project,
  toolgate dev serves the tools over stdio (or --http on loopback), toolgate dev --digests prints the descriptor digests, toolgate check (and toolgate validate <dir>)
  runs the tests and examples, and toolgate pack builds and validates the .tgpkg. The CLI
  drives each build through one adapter per language and build tool, and starters are layered
  templates embedded in the binary, so a new language adds a starter and an adapter.
  ./gradlew publishJavaSdkToMavenLocal publishes the SDK where starters find it. The Java
  end-to-end run now builds the starter instead of a separate sample.

• The Java Tool SDK is complete for standalone use (M0 part 11). context.tcp() connects only
  to the TCP destinations a tool lists, directly or through a socket factory. The processor
  proves URL-style convenience calls at build time (literal arguments, exactly one route the
  tool lists), refuses reflective access to the network API, checks literal get*Value names
  and types, and generates <Class>Vars typed accessors; it now analyses after javac's own
  attribution. toolgate-sdk-testing adds ToolHarness, which runs tools in test mode with
  fixtures and recorded route exchanges in a shared format (spec/authoring/testing.md);
  @Example gains exchanges, and examples travel in the package index. The Gradle plugin
  io.ololabs.toolgate.sdk and toolgate-maven-plugin add dev, check and package
  over the shared toolgate-sdk-build, which stages app.jar plus a deterministic
  libs.zip and packs with the toolgate CLI. ./gradlew publishJavaSdkLocally publishes
  the SDK to build/sdk-repo, and tool-sdk/java-sdk/e2e/run.sh builds a sample with both
  plugins end to end.

• The Java standalone runtime can keep tasks in SQLite (M0 part 10). With
  TOOLGATE_TASK_STORE=sqlite tasks and their results live in the state file at
  TOOLGATE_STATE_DB and survive a restart; a task the stopped process had not finished ends
  failed with OUTCOME_UNKNOWN. memory stays the default. A call whose task cannot be
  stored gets the retryable TASK_STORE_UNAVAILABLE and nothing runs. The TaskStore port
  lists active() tasks instead of all().

• The Java standalone runtime reserves business keys (M0 part 9). Tools that require a key, or
  declare businessKeyArgument, run only after the key (from that argument or the
  Idempotency-Key header) is reserved in a local SQLite store at TOOLGATE_STATE_DB. Repeats
  return the first result or task; other arguments get IDEMPOTENCY_CONFLICT, another caller
  of a TENANT key gets IDEMPOTENCY_KEY_IN_USE, a running repeat gets IN_PROGRESS, and a
  key past TOOLGATE_BUSINESS_KEY_RETENTION gets EXPIRED_KEY. @Idempotency forwards the key
  upstream per namespace (a.<hash>.<key>, u.<hash>.<key> or the raw TENANT key). Such
  tools no longer refuse startup.

• The Java standalone runtime has the routes HTTP client (M0 part 8). context.http() calls
  only the routes a tool lists, with path variables matched against their patterns (never
  /), allowlisted query names and headers, the route's size limits and a timeout a call
  can only shorten. Destination hosts come from TOOLGATE_DESTINATION_<HOSTSETTING> or
  toolgate.dev.json, SPKI pins are enforced, and API_KEY, BASIC and OAuth 2.0 client
  credentials come from local secrets. Failures map to UPSTREAM_4XX, UPSTREAM_5XX,
  UPSTREAM_TIMEOUT and UPSTREAM_CONNECTION with effectUncertain, and a ledger tool whose
  request was sent without a complete answer ends OUTCOME_UNKNOWN. The processor now
  refuses a route path variable without a pattern, and descriptor vector tool-03 declares
  /orders/{orderId:[0-9]{6,12}}/refunds, so its digest changed.

• The Java standalone runtime verifies bearer tokens (M0 part 7, adapter A4). With
  TOOLGATE_AUTH_* it checks JWTs against a JWKS URL or...