@mondaydotcomorg/agent-toolkit 5.64.4 → 5.64.6

package/CHANGELOG.md

@@ -1,5 +1,33 @@
 # Changelog
 
+## 5.64.6
+
+### Spell out prerequisite tool ordering for board, view, and column tools
+
+Discovery tools (schema/id/revision lookups) and the write tools that depend on them often didn't state the ordering between them, so callers guessed column ids, revisions, and settings shapes instead of fetching them first. Prerequisites are now stated on both sides of each pair — the upstream tool says what it should be called before, the downstream tool says what to call first. No input schemas or behavior changed.
+
+- `get_column_type_info` — now names all three settings writers it precedes (`create_column`, `update_column`, `manage_object_schema_columns`) instead of only `create_column`
+- `create_column` / `update_column` — call `get_column_type_info` before populating `columnSettings` (previously only stated on the field description). `update_column` keeps the existing revision precondition
+- `get_board_schema` / `delete_column` — `get_board_schema` documents the column id + revision it supplies to `update_column`, `delete_column`, `configure_ai_column`, and `remove_ai_from_column`, and points to `get_board_info` for broader metadata. `delete_column` now requires resolving the id first and notes the deletion is irreversible
+- `get_board_info` — states it is the required precondition already declared by `get_board_items_page`, `board_insights`, `create_item`, `create_items`, `update_items`, and `change_item_column_values`, and that its views are the source of view ids
+- `get_board_info` — also warns that a column's returned `settings` value is the raw API shape for that existing column and must not be copied verbatim into the `columnSettings` parameter of `create_column` / `update_column`, which was producing doubly-nested `{"settings": {...}}` payloads and schema validation failures
+- `create_view` / `create_view_table` / `update_view` / `update_view_table` — call `get_board_info` first for column ids, status label indexes, and (for updates) the `viewId`
+- `create_view` — fetch filter guidelines via `get_column_type_info` with `fetchMode: "guidelines"` (`data.guidelines.filter`) before sending filter rules, matching the precondition already stated on `get_board_items_page` and `board_insights`
+
+## 5.64.5
+
+### Spell out prerequisite tool ordering for object schema, form, automation, sprint, and dynamic API tools
+
+Discovery tools (schema/id/revision lookups) and the write tools that depend on them often didn't state the ordering between them, so callers guessed schema ids, column ids, revisions, question ids, tag ids, automation ids, and sprint ids instead of fetching them first. Prerequisites are now stated on both sides of each pair — the upstream tool says what it should be called before, the downstream tool says what to call first. No input schemas or behavior changed.
+
+- `get_object_schemas` — listed as the resolver for schema ids, column ids, and revisions ahead of `update_object_schema`, `manage_object_schema_columns`, `set_object_schema_column_active_state`, `delete_object_schema_columns`, `delete_object_schema`, and `manage_object_schema_board_connection`. The matching precondition was added to `manage_object_schema_columns` (update), `set_object_schema_column_active_state`, and `delete_object_schema_columns`
+- `create_object_schema` — resolve `parentId` via `get_object_schemas`, and notes columns/boards are added afterwards
+- `get_form` / `update_form` / `form_questions_editor` — `get_form` states it precedes `create_form_submission`, `form_questions_editor`, and `update_form`, and the two writers now require it for question ids, tag ids, and current settings
+- `get_type_details` — documents that it returns fields, input fields, and enum values, and that it should be used to confirm a type's shape before referencing that type in an operation for `all_monday_api`, `all_api_read`, or `all_api_write`. It takes a known type name and is not gated on any other lookup. `get_graphql_schema` is unchanged
+- `list_automations` — stated as the only way to resolve an automation id before `manage_automations`
+- `get_board_activity` — call with `includeData=true` before `undo_action` to get the `action_record_uuid`
+- `get_sprints_metadata` / `get_sprint_summary` — `get_sprints_metadata` points back to `get_monday_dev_sprints_boards` for the board id and forward to `get_sprint_summary` for the sprint ids it supplies. `get_sprint_summary` now requires resolving `sprintId` there
+
 ## 5.64.4
 
 ### search — scope UPDATES and TIMELINE_ITEMS search by workspaceIds