feat(agent-toolkit): state prerequisite tool ordering for board, view, and column tools

[RomKadria]

Split out of #463 — this PR covers the board / view / column tools only. The remaining domains (object schemas, forms, automations, sprints, dynamic GraphQL API, board activity) are in the sibling PR.

Why

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.

Description-only changes. No input schemas, GraphQL operations, or runtime behavior changed.

The create_column settings bug

This also addresses a widely-reported create_column schema validation failure (103 sessions / 59 users / 58 orgs on the internal issue tracker, 8.8% of create_column executions).

Agents were sending:

{"settings": {"labels": [{"label": "Cat"}]}}

instead of:

{"labels": [{"label": "Cat"}]}

Root cause: get_board_info — which most write tools declare as their required precondition — returns each column with its raw API config under a settings key:

{ "id": "project_status", "title": "Status", "type": "status",
  "settings": { "labels": [{ "label": "Working on it", "index": 1, ... }] } }

Verified against a live board. The value of settings is already almost exactly the correct columnSettings shape — so the only mistake is grabbing the enclosing object instead of reaching one level in. Nothing in the tool descriptions showed a correct flat example to contradict the copy-paste instinct.

get_board_info's description now states that a column's settings value is the raw read-only shape, must not be copied verbatim into columnSettings, and points at get_column_type_info with fetchMode: "schema" for the authoritative structure.

Changes

• get_column_type_info — 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)
• 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; delete_column now requires resolving the id first and notes the deletion is irreversible
• get_board_info — states the precondition role already declared by its downstream tools, that its views are the source of view ids, and the settings warning above
• 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", matching the precondition already stated on get_board_items_page and board_insights

Testing

• tsc --noEmit clean
• tool-description-safety.test.ts — 210/210 pass (this suite's UNSAFE_CHARS_PATTERN previously caught a stray semicolon in this work; verified clean here)

🤖 Generated with Claude Code