Scribe Mail

Update a smart field

update_smart_field

DestructiveIdempotent

Change an existing custom smart field's definition: its label, kind, required flag or integration binding. Only the fields you pass change, and the field keeps its id, so templates and campaign conditions that reference it still point to it. Use create_smart_field for a new field, delete_smart_field to remove one, and update_teammate to set a teammate's value (this tool never writes values directly). Binding a new integration or attribute queues a re-sync of the teammates' values from it (integrations never fill url fields); unlinking stops the sync. Overwrites the previous definition and returns the field. Needs the smart_fields:write scope; default fields are read-only (422), the computed Email field is not addressable (404), and a taken label, an invalid kind or an unknown integration returns 422.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The smart field's UUID (the `id` returned by list_smart_fields).
`kind`	No	New field type.
`label`	No	New display name. Must be unique in the workspace (422 `taken` otherwise).
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`required`	No	Whether teammates must fill this field.
`integration_id`	No	UUID of a workspace integration to sync values from (a directory or HR/enrichment integration from list_integrations). Pass null to unlink, which also clears integration_attribute. Omit to leave unchanged.
`integration_attribute`	No	The integration's attribute key (required when the field is bound to an integration; 422 without it). Changing it re-syncs the field's values.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 16, 2026

changedInput schema / properties / integration_attribute / description

Previous value: -"The integration's attribute key (required when integration_id is set)."New value: +"The integration's attribute key (required when the field is bound to an integration; 422 without it). Changing it re-syncs the field's values."

changedInput schema / properties / integration_id / description

Previous value: -"UUID of a workspace integration to sync values from; pass null to unlink. Omit to leave unchanged."New value: +"UUID of a workspace integration to sync values from (a directory or HR/enrichment integration from list_integrations). Pass null to unlink, which also clears integration_attribute. Omit to leave unchanged."

changedInput schema / properties / label / description

Previous value: -"New display name."New value: +"New display name. Must be unique in the workspace (422 `taken` otherwise)."

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations give the safety profile (destructive/overwrite, idempotent, openWorld), and the description adds real context beyond them: it preserves `id` so references survive, only passed fields change, integration binding queues a re-sync, unlinking stops it, integrations never fill url fields, plus required scope and specific 422/404 failure conditions.

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?

Front-loads purpose then layers siblings, mutation semantics, and error codes with no filler sentences. It is dense and the final sentence packs several error cases together, but each sentence carries distinct, useful information.

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 mutation tool with an output schema, the description covers everything else needed: permissions scope, id preservation, partial-update behavior, integration sync consequences, and the specific error codes. 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 genuine meaning: omission leaves a field unchanged, binding a new integration/attribute triggers a re-sync, and integrations cannot fill url fields (a kind/integration constraint not stated in the schema).

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?

States a specific verb (Change) and resource (an existing custom smart field's definition) and enumerates the editable facets (label, kind, required flag, integration binding). It is immediately distinguishable from create_smart_field, delete_smart_field, and update_teammate, which it names explicitly.

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?

Explicitly routes the agent: use create_smart_field for new fields, delete_smart_field to remove, and update_teammate to set a teammate's value, noting this tool 'never writes values directly.' This is a clear when-to-use/when-not with named alternatives.

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

All Scribe Mail tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.