Skip to main content
Glama

Scribe Mail

Install the signatures of one email

install_signature_for_email
Destructive

Install one email's signatures now, in its mailbox alone, without reinstalling the signature for everyone else (install_signature): a send-as alias that needs its signature, one person whose details changed (a new title). Installs the installed (activated) and published signatures assigned to the email, or only signature_id, through the workspace's signature integrations (Google Workspace, Zoho Mail, Front, …). Runs in the background: the result lists what was queued, and list_signature_installations with the email_id shows each one as it ends. 409 installed_by_client when the Outlook add-in or the desktop app installs the workspace's signatures: the client picks up the latest published signature by itself, there is nothing to push, say so. 409 no_signature_to_install when no installed signature is assigned to the email; 422 not_a_recipient when signature_id is not assigned to it. Returns 403 if the plan lacks signature installation, or 409 installation_unavailable if no signature integration is connected; relay the dashboard link.

Input Schema

NameRequiredDescriptionDefault
contextYesExplain 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."
email_idYesThe email's UUID: the `id` from list_emails, or the `email_id` from list_signature_recipients or list_signature_installations.
signature_idNoInstall only this signature (its UUID from list_signatures), one assigned to the email. Without it, every installed signature assigned to the email.

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / properties / data / properties / signatures / items / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / data / properties / signatures / items / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by disclosing asynchronous execution ('runs in the background', result lists what was queued), the polling path via list_signature_installations, and the full error contract: 403 plan limitation, 409 installed_by_client, 409 no_signature_to_install, 409 installation_unavailable, 422 not_a_recipient. It also tells the agent what to say to the user in the installed_by_client case, which is behavior no structured field conveys.

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?

Dense and front-loaded, with the scope constraint and the sibling contrast in the first clause. The parenthetical example list and the long error-code enumeration make it a single run-on sentence that is heavier than it needs to be, though almost every clause carries actionable content.

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, an agent has everything it needs: scope, async model, follow-up polling tool, tier/setup prerequisites, and every documented failure mode with the required user-facing response. Nothing material is left unspecified.

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

Parameters3/5

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

Schema coverage is 100%, so email_id and signature_id are already fully documented in the schema, including the 'without it, every installed signature' default. The description restates 'or only signature_id' without adding format, validation, or sourcing detail beyond what the schema provides, so the baseline 3 applies.

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 and resource ('install one email's signatures') plus the crucial scope constraint: 'in its mailbox alone, without reinstalling the signature for everyone else'. It explicitly names the sibling install_signature as the contrasting tool, so an agent can route between them without opening either schema.

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?

Gives concrete triggering scenarios ('a send-as alias that needs its signature, one person whose details changed') and explicitly distinguishes this from install_signature (workspace-wide). The alternative and the condition that selects it are both stated, not inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.