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

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

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 28, 2026
- removedInput schema / properties / integration_attribute / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / integration_attribute / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / integration_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / integration_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / integration_attribute / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / integration_attribute / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / integration_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / integration_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / slug / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / slug / type
```
Added value: +[
+  "string",
+  "null"
+]
```

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?

Goes well past annotations (destructive/idempotent/openWorld) by disclosing concrete consequences: templates and campaign conditions keep pointing at the field because id is preserved, binding an integration queues a re-sync, unlinking stops it, integrations never fill url fields, and the previous definition is overwritten. Also lists required scope and the 422/404 failure modes (read-only defaults, non-addressable Email field, taken label, invalid kind, unknown integration).

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-loaded with the core action and scope, then alternatives, then side effects, then errors – a sensible order with no filler sentences. It is dense and long for a single paragraph, so findability of the error codes suffers slightly.

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 destructive, integration-touching mutation with an output schema present, the description covers what is overwritten, what is preserved, who is affected by syncs, permissions, and error semantics. An agent has everything needed to call it correctly and to anticipate failure responses.

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 baseline is 3; the description adds genuine semantic value beyond it with the partial-update contract ('Only the fields you pass change') and the re-sync side effect of changing a binding. It does not restate enum values or per-parameter formats, which the schema already handles well.

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?

Specific verb+resource ('Change an existing custom smart field's definition') plus an enumeration of what is mutable (label, kind, required flag, integration binding). It also distinguishes itself from create_smart_field, delete_smart_field and update_teammate by name.

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: create_smart_field for new fields, delete_smart_field to remove, update_teammate to set a teammate's value, and states the negative boundary 'this tool never writes values directly'. No inference required.

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.