Skip to main content
Glama

Preview a signature

argorant_preview_signature
Read-onlyIdempotent

Show how a signature text reads with real values, without saving it. Use it to check a text before argorant_set_inbox_signature, argorant_set_inbox_signatures or argorant_set_default_signature. Pass email to fill the variables from that mailbox, or first_name, last_name, title and company to try other values. The answer has text and campaign_text, the plain text form an email uses, where a link reads as its label with the address after it. More in the docs at https://docs.argorant.com/docs/agents/tools#analytics-mailbox-settings-blocklist

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "template": "<template>"
    },
    "name": "argorant_preview_signature"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNoA mailbox whose name, title and company fill the variables.
titleNoA job title to use for {{sender_title}}.
formatNotext (default) or html (simple HTML with links and line breaks)text
companyNoA company name to use for {{sender_company}}.
templateYesThe signature, fixed text with the variables {{sender_first_name}}, {{sender_last_name}}, {{sender_full_name}}, {{sender_title}}, {{sender_company}} and {{sender_email}}, for example "Best,\n{{sender_first_name}} {{sender_last_name}}\n{{sender_title}}, {{sender_company}}". No {a|b} variations.
last_nameNoA last name to try in place of the mailbox's own.
first_nameNoA first name to try in place of the mailbox's own.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false; the description reinforces with "without saving it", confirming no state is written. It adds value beyond annotations by explaining how links render in campaign_text (label followed by the address), which is behavioral output context the annotations do not cover.

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?

Three sentences, front-loaded with the purpose, then the routing, then the parameter modes and return shape. The docs URL is somewhat extraneous but short; no sentence is filler.

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

Completeness4/5

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

With 7 parameters, full schema coverage and an output schema, the description supplies the missing decision context (which parameter mode, what the preview returns). It does not mention failure behavior for an unknown or malformed variable, which is the remaining gap for a preview tool.

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 the relationship the schema does not express: email is an alternative source of variables versus supplying first_name/last_name/title/company individually. It also notes the template supports no {a|b} variations, a constraint only partially implied by 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?

"Show how a signature text reads with real values, without saving it" names a specific verb (show/preview), resource (signature text) and scope (no persistence). It is immediately distinguishable from the sibling setters it explicitly names.

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?

The description states the use case (check a text before saving) and names the three concrete alternatives it precedes: argorant_set_inbox_signature, argorant_set_inbox_signatures, argorant_set_default_signature. It also gives the selection rule between the two parameter modes (pass email to fill from a mailbox, or the individual fields to try other values).

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.