Add MCP tools for safe schema updates (schema_update_collection, schema_update_field) - #1681

[Vallhalen]

Problem

The MCP surface has schema tools for list_collections, get_collection, create_collection, delete_collection, create_field, and delete_field, but no update counterpart for either collections or fields. An agent that wants to rename a collection's label, change hasSeo on an existing collection, mark a field searchable, adjust a field's sortOrder, or promote a string field to a slug field has to delete-and-recreate, which is destructive (loses field values in the affected column) and racy against concurrent writes.

This maps to roadmap issue #1681. Filing this Discussion first per CONTRIBUTING for a maintainer green light before opening a PR.

Why this is a thin PR, not a new feature

The heavy lifting is already done. The REST layer already exposes safe update paths:

• handleSchemaCollectionUpdate at packages/core/src/api/handlers/schema.ts:161, backed by SchemaRegistry.updateCollection at packages/core/src/schema/registry.ts:270.
• handleSchemaFieldUpdate in the same handlers file, backed by SchemaRegistry.updateField at packages/core/src/schema/registry.ts:552.

Both are used by the admin UI, both return typed errors via SchemaError, and updateField already refuses type changes that would alter column affinity (see the UpdateFieldInput.type docstring in schema/types.ts around line 266: "Only type changes that keep the same underlying column type per FIELD_TYPE_TO_COLUMN are allowed"). So Tools enforce RBAC and MCP scopes consistently and Error responses make unsafe schema changes clear to agents fall out of reusing those handlers, exactly like content_update reuses handleContentUpdate.

Proposed shape

Two new tools registered in packages/core/src/mcp/server.ts, both requiring scope schema:manage and Role.ADMIN (parity with schema_create_collection / schema_create_field).

schema_update_collection

{
  collection: string,          // slug
  label?: string,
  labelSingular?: string,
  description?: string,
  icon?: string,
  supports?: CollectionSupport[],
  urlPattern?: string,
  hasSeo?: boolean,
  commentsEnabled?: boolean,
  commentsModeration?: 'all' | 'first_time' | 'none',
  commentsClosedAfterDays?: number,
  commentsAutoApproveUsers?: boolean,
}

Fields mirror UpdateCollectionInput exactly. Returns the updated collection.

schema_update_field

{
  collection: string,
  field: string,               // field slug
  label?: string,
  type?: FieldType,            // only affinity-preserving; validated by updateField
  required?: boolean,
  unique?: boolean,
  defaultValue?: unknown,
  validation?: FieldValidation | null,
  widget?: string,
  options?: FieldWidgetOptions,
  sortOrder?: number,
  searchable?: boolean,
  translatable?: boolean,
}

Fields mirror UpdateFieldInput. Returns the updated field.

Error surface: propagate SchemaError.code verbatim so agents can pattern-match (FIELD_TYPE_CHANGE_UNSAFE, COLLECTION_NOT_FOUND, etc.).

Acceptance criteria mapping (from #1681)

• MCP exposes update collection and update field operations. Direct: the two tools above.
• Updates do not require destructive delete-and-recreate workflows. Direct: that's the point.
• Tools enforce RBAC and MCP scopes consistently. Reuse existing requireScope('schema:manage') + requireRole(Role.ADMIN) from the other schema tools.
• Error responses make unsafe schema changes clear to agents. SchemaError.code + .details are already structured; MCP unwrap surfaces them.
• Tests cover successful updates and rejected unsafe updates. Add:
  • schema_update_collection happy path per dialect (via describeEachDialect).
  • schema_update_field happy path.
  • schema_update_field rejects an affinity-breaking type change (e.g. text to portableText) with the specific error code.
  • Role/scope enforcement: schema:read scope or non-admin role gets a permission error.

Non-goals (for this PR)

• Bulk / atomic multi-field updates. Keep parity with existing per-field REST semantics; batching can come later.
• Schema migrations that DO change column affinity (would need real data migration, out of scope for a safe-update tool).
• Field reordering as a separate tool (already covered by sortOrder on update).

Estimate

~150 lines of tool wiring + type-mirror + ~100 lines of tests. Similar shape to #1874.

Questions for maintainers before I open the PR

1. Are you fine with mirroring the REST input types verbatim, or do you want a slimmer MCP-specific surface?
2. Do you want the "unsafe type change" error code exposed as a distinct MCP error, or is the existing SCHEMA_UPDATE_ERROR code + message enough for agents?
3. Should schema_update_collection accept slug renames? REST doesn't currently; keeping parity means no.

Happy to iterate on any of this before writing code.