# Composio 0.16.0

- Product: Composio (https://whatsnew.fyi/product/composio)
- Vendor: Composio
- Date: 2026-08-11
- Version: 0.16.0
- Original notes: https://github.com/ComposioHQ/composio/releases/tag/%40composio/core%400.16.0
- Permalink: https://whatsnew.fyi/product/composio/releases/0.16.0

What's New is an index, not a publisher: every entry below links to the vendor's own release notes, which are the authoritative source. Entries are labelled where they are hand-curated sample data, pre-releases, or drawn from a secondary source such as a developer blog.

Reuse: the summaries, labels and curation here are © What's New. Quote freely with attribution and a link back; wholesale republication of the corpus is not permitted — terms: https://whatsnew.fyi/terms. The vendors' own release notes remain their publishers'.

---

- **changed** — Keep free-form object roots, patternProperties, and additionalProperties when parsing a tool schema, and make properties optional in the ToolSchema type to reflect valid property-less object schemas
- **fixed** — Add type: "object" to nested JSON Schema nodes that carry properties without an explicit type for compatibility with strict OpenAPI 3.0 consumers like Google Gemini
- **changed** — Reuse fetched tool schemas when provider-wrapped tools execute to avoid redundant retrieval requests

###### Minor Changes

- 5e57815: Keep free-form object roots, `patternProperties`, and `additionalProperties` when parsing a tool schema.

  `ToolSchema.parse` used to reject a bare `{ "type": "object" }` root, drop root `patternProperties` as an unknown key, and reject a root `additionalProperties` written as a schema instead of a boolean. Free-form roots now parse successfully, and both constraints survive parsing exactly as written. The public `ToolSchema` type now makes `properties` optional to reflect those valid property-less object schemas.

  This matters downstream. Every provider reads `inputParameters` after parsing, so a tool that declares dynamic keys had those rules stripped before the model ever saw them.

  An omitted `additionalProperties` still stays omitted. The parser does not invent a value, because each converter decides its own default.

  **What no longer works**

  Parsing no longer fails on a schema-valued root `additionalProperties`.

  ```ts
  const tool = ToolSchema.parse({
    slug: 'MY_TOOL',
    inputParameters: {
      type: 'object',
      properties: { name: { type: 'string' } },
      additionalProperties: { type: 'number' },
    },
    // ...
  });

  // before: parsing failed, because only a boolean was accepted
  // now:    tool.inputParameters.additionalProperties is { type: 'number' }
  ```

  **What to do instead**

  Nothing, if you only ever passed boolean values. That case is unchanged.

  If your code assumed `inputParameters` never carries `patternProperties`, or that `additionalProperties` is always a boolean, widen that assumption. Both keywords can now appear, and `additionalProperties` can be a boolean or a schema object.

###### Patch Changes

- a2f6b96: Add `type: "object"` to nested JSON Schema nodes that carry `properties` without an explicit type, so tool schemas work with strict OpenAPI 3.0 consumers like Google Gemini.
- c625edc: Reuse fetched tool schemas when provider-wrapped tools execute to avoid a redundant retrieval request.
- Updated dependencies [5e57815]
  - @composio/json-schema-to-zod@0.3.0