Skip to main content
Glama

update_schema_incremental

Evolve a schema in place by adding/removing fields or re-keying identity, then activate the new version immediately; optionally backfill historical data.

Instructions

Incrementally update a schema by adding fields (fields_to_add — minor version bump), removing fields (fields_to_remove — major version bump; observation data preserved, snapshot-excluded until re-added), or changing the identity rule (canonical_name_fields — major version bump). Creates a new schema version and activates it immediately, so all new data stored after this call uses the updated schema. Optionally migrates existing raw_fragments to observations for historical data backfill.

canonical_name_fields re-keys how the type derives canonical_name / identity. Rules are ordered precedence with fallback — the first rule whose fields are all present wins, e.g. [{composite:["linkedin_url"]},"email","name"] keys on linkedin_url, else email, else name. Reach for it when same-name-different-entity collisions appear (e.g. a bulk import collapses distinct people who share a name because identity resolves on name alone). The existing reducer_config is preserved automatically, so this is the safe way to re-key without a full register_schema re-supply. Applies to NEW writes only — it does not retroactively re-key existing entities, so it will not by itself merge existing duplicates. Omit to keep the current rule; pass [] to clear it (succeeds only if the schema also declares identity_opt_out). The response echoes the resolved canonical_name_fields; call describe_entity_type first to see the current rule before replacing it.

On ERR_SCHEMA_SCOPE_MISMATCH an active schema exists in a different scope than the call checked (details.guard_scope vs details.found_scope). Retry with user_specific matching details.found_scope (user→true, global→false/omit). Never call register_schema for that code — a second active row for the same entity_type risks dual-active corruption (#2374/#2378).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idNoUser ID for user-specific schema (required if user_specific=true)
activateNoActivate schema immediately so it applies to new data (default: true). If false, schema is registered but not active.
entity_typeYesEntity type to update
fields_to_addNoFields to add to schema
user_specificNoCreate user-specific schema variant (default: false)
schema_versionNoNew schema version (auto-increments if not provided)
fields_to_removeNoField names to remove from schema (triggers major version bump). Observation data is preserved; fields can be restored by re-adding them later.
migrate_existingNoMigrate existing raw_fragments to observations for historical data backfill (default: false). Note: New data automatically uses updated schema after activation, migration is only for old data.
canonical_name_fieldsNoReplace the entity type's identity rule (how canonical_name / entity identity is derived). Triggers a major version bump. Each item is a single field name (string) or an all-required composite ({composite:[...]}). Rules are ORDERED PRECEDENCE WITH FALLBACK: the resolver uses the first rule whose fields are all present, not an unordered set. Example: [{"composite":["linkedin_url"]},"email","name"] keys on linkedin_url when present, else email, else name. Omit to keep the current rule. Passing [] clears the rule, but only succeeds when the schema also declares identity_opt_out; otherwise it is rejected (a schema must declare canonical_name_fields OR identity_opt_out). The existing reducer_config is preserved automatically — this is the safe way to re-key a type without reconstructing it. Applies to NEW writes only; it does NOT retroactively re-key existing entities (they keep their stored canonical_name until re-derived), so re-keying will not by itself merge existing duplicates. To see the current rule before replacing it, call describe_entity_type first; the update response also echoes the resolved canonical_name_fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.21.0
    • addedInput schema / properties / canonical_name_fields
      Added value: +{
      +  "description": "Replace the entity type's identity rule (how canonical_name / entity identity is derived). Triggers a major version bump. Each item is a single field name (string) or an all-required composite ({composite:[...]}). Rules are ORDERED PRECEDENCE WITH FALLBACK: the resolver uses the first rule whose fields are all present, not an unordered set. Example: [{\"composite\":[\"linkedin_url\"]},\"email\",\"name\"] keys on linkedin_url when present, else email, else name. Omit to keep the current rule. Passing [] clears the rule, but only succeeds when the schema also declares identity_opt_out; otherwise it is rejected (a schema must declare canonical_name_fields OR identity_opt_out). The existing reducer_config is preserved automatically — this is the safe way to re-key a type without reconstructing it. Applies to NEW writes only; it does NOT retroactively re-key existing entities (they keep their stored canonical_name until re-derived), so re-keying will not by itself merge existing duplicates. To see the current rule before replacing it, call describe_entity_type first; the update response also echoes the resolved canonical_name_fields.",
      +  "items": {
      +    "oneOf": [
      +      {
      +        "type": "string"
      +      },
      +      {
      +        "properties": {
      +          "composite": {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        },
      +        "required": [
      +          "composite"
      +        ],
      +        "type": "object"
      +      }
      +    ]
      +  },
      +  "type": "array"
      +}
  2. Addedv0.15.0
  3. Removedv0.14.0
  4. Addedv0.12.1
  5. Removedv0.11.0
  6. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden — and it delivers. It discloses minor vs major version bumps, that observation data is preserved and only snapshot-excluded on removal, that the schema activates immediately, that migration is optional, that re-keying does NOT retroactively merge existing duplicates, that reducer_config is auto-preserved, and the ERR_SCHEMA_SCOPE_MISMATCH handling. For an unannotated mutation tool this is unusually complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but for a 9-parameter schema-mutation tool the density is warranted — nearly every sentence carries distinct semantic weight (version bumps, preservation, fallback precedence, error handling, safety warnings). It is front-loaded with the core purpose before entering details, and organized into clear sections. Slightly verbose but well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutating tool with no annotations and no output schema, the description covers when to use it, what changes take effect, data-preservation caveats, error-handling recovery steps, and the dual-active corruption risk. It even addresses return-value behavior ('The response echoes the resolved canonical_name_fields'). Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema: it maps each operation to its version-bump consequence (minor for adds, major for removes and identity changes), clarifies data preservation on removal, and explains the PRECEDENCE-ordered canonical_name_fields fallback behavior with a concrete example. This exceeds what the property descriptions alone convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Incrementally update a schema', then enumerates the three exact operations (fields_to_add, fields_to_remove, canonical_name_fields) with their version-bump semantics. It distinguishes itself from the sibling register_schema by framing this as the incremental/safe re-key path, so an agent can tell them apart immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is given: 'Reach for it when same-name-different-entity collisions appear' and 'the safe way to re-key without a full register_schema re-supply'. It also states a hard when-not: 'Never call register_schema for that code — a second active row for the same entity_type risks dual-active corruption'. This routes the agent clearly against alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.