Skip to main content
Glama

Preview email template

lnkdrp_preview_email_template
Read-onlyIdempotent

Shows how a template reads, with no recipient made: a saved template (templateId) or unsaved template fields (format, subject, body and tags). Built-in tags: contact.firstName: The first word of the contact's name. (e.g. Ken); contact.name: The contact's name: the name the team gave them, else the name they gave. (e.g. Ken Lee); contact.lastName: Everything after the first word of the contact's name. (e.g. Lee); contact.email: The contact's email address. (e.g. ken@example.com); contact.company: The domain of the contact's address; empty for a webmail address such as gmail.com. (e.g. acme.com); contact.note: The team's note on the contact, as written; it goes into the email exactly as it is. (e.g. Met at the October demo day.); contact.tags: The contact's tags, comma-separated. (e.g. Investor, Seed); contact.firstSeen: When LinkDrop first saw the contact, e.g. October 22, 2026. (e.g. October 22, 2026); contact.lastSeen: When the contact was last seen, e.g. October 22, 2026. (e.g. October 22, 2026); contact.visits: How many times the contact has viewed, as a number. (e.g. 3); link.url: The recipient's own LinkDrop link to the document or project; one link per person, reused on every render. (e.g. https://lnkdrp.com/s/example); link.password: The password of the recipient's own link; empty when the link has none. Filled when the email is sent and for a member signed in to the app; a connected agent sees [password]. (e.g. chris58); document.title: The document's title (document emails only). (e.g. Q3 investor update); project.name: The project's name (project emails only). (e.g. Series A data room); sender.name: The name of the member the email is from. (e.g. Chris); sender.firstName: The first word of the sender's name. (e.g. Chris); sender.email: The sender's LinkDrop account email (not necessarily the Gmail address the email goes out from). (e.g. chris@example.com); workspace.name: The workspace's name. (e.g. LinkDrop). mode tags (the default) shows each tag as written ({{contact.firstName}}) unless values gives it one; mode examples shows each tag's example (the template's own for a custom tag, else the built-in one, else the tag as written). contactId (with templateId) shows the saved template as that contact's email: their details, the sender's and the workspace's, {{link.url}} as a placeholder (their own link is made when the email is rendered) and {{link.password}} as [password]; a contact this person cannot see is contact_not_found. dryRun true adds the dry-run band and the [Dry run] subject marker; dry runs are on Pro and up, and on Free it answers plan_limit with details.upgradeUrl. Nothing is stored, no link is made and nothing is charged. Returns subject, text, html, missingTags (required tags with no value), usedTags, errors: what saving this template would refuse, as { code, message } (unsaved fields' link-like custom tag is custom_tag_is_link), warnings: what saving it would note without refusing (body_self_centred), missing (for a contact: the tags that come out empty or as their fallback, { key, reason }), contact (the contact previewed as; name and email wrapped as untrusted content) and dryRun. html carries the template's align. A preview page with an address of its own comes from lnkdrp_render_email, which renders for a real contact and may create that contact's link.

Input Schema

NameRequiredDescriptionDefault
bodyNoUnsaved template fields: the body, with tags.
modeNotags (the default): each tag as written; examples: each tag's example.
tagsNoTag declarations: every {{custom.x}} used, with its description; a built-in may be listed to override its description or required.
alignNoWhere an html email sits in the reader's window. left (the default): nothing is added around the body, so it shows flush left. center: the body is placed in a centred column at most 600px wide. The text version is unaffected.
linksNoUnsaved template fields: the documents the body places with {{link.<key>}}, each drawn by its title.
dryRunNotrue: with the dry-run band and the [Dry run] subject marker (Pro and up).
formatNotext: a plain-text body (an HTML version is derived from it). html: an HTML body (a text version is derived from it).
valuesNoValues to show for tags, by key: { "custom.round": "Series A", "contact.firstName": "Ken" }. Up to 30 keys; custom tags only with contactId.
draftIdNoA draft of the saved template (templateId) to preview.
subjectNoUnsaved template fields: the subject line, with tags.
contactIdNoPreview a saved template (templateId) as this contact's email, from lnkdrp_list_contacts.
templateIdNoA saved template to preview; or give format, subject and body instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / body / description
      Previous value: -"A draft's body, with tags."New value: +"Unsaved template fields: the body, with tags."
    • addedInput schema / properties / contactId
      Added value: +{
      +  "description": "Preview a saved template (templateId) as this contact's email, from lnkdrp_list_contacts.",
      +  "pattern": "^[a-fA-F0-9]{24}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / draftId
      Added value: +{
      +  "description": "A draft of the saved template (templateId) to preview.",
      +  "pattern": "^[a-fA-F0-9]{24}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / dryRun
      Added value: +{
      +  "description": "true: with the dry-run band and the [Dry run] subject marker (Pro and up).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / links
      Added value: +{
      +  "description": "Unsaved template fields: the documents the body places with {{link.<key>}}, each drawn by its title.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "docId": {
      +        "pattern": "^[a-fA-F0-9]{24}$",
      +        "type": "string"
      +      },
      +      "key": {
      +        "maxLength": 40,
      +        "type": "string"
      +      },
      +      "projectId": {
      +        "pattern": "^[a-fA-F0-9]{24}$",
      +        "type": "string"
      +      },
      +      "title": {
      +        "anyOf": [
      +          {
      +            "maxLength": 300,
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "key"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "tags (the default): each tag as written; examples: each tag's example.",
      +  "enum": [
      +    "tags",
      +    "examples"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / subject / description
      Previous value: -"A draft's subject line, with tags."New value: +"Unsaved template fields: the subject line, with tags."
    • changedInput schema / properties / values / description
      Previous value: -"Values to show for tags, by key: { \"custom.round\": \"Series A\", \"contact.firstName\": \"Ken\" }. Up to 30 keys."New value: +"Values to show for tags, by key: { \"custom.round\": \"Series A\", \"contact.firstName\": \"Ken\" }. Up to 30 keys; custom tags only with contactId."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish a safe read-only operation, but the description adds valuable behavior beyond them: nothing is stored, no link is made, nothing is charged, contact visibility failures return contact_not_found, dry-run plan limits surface plan_limit, and link passwords are redacted for connected agents. It does not contradict the annotations.

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

Conciseness2/5

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

The opening sentence is well front-loaded, but the description becomes extremely long and is dominated by an exhaustive built-in tag reference with examples. That tag list buries the key usage and behavioral details, making the definition harder to scan despite its logical internal ordering.

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?

With 12 parameters, nested objects, no required fields, and no output schema, the description does the necessary work of explaining return values (subject, text, html, missingTags, usedTags, errors, warnings, missing, contact, dryRun) and key failure modes. It is complete enough for an agent to call this tool correctly.

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% with 12 complex parameters, so the schema already carries most parameter meaning and a baseline 3 would apply. The description adds useful context for contactId preview behavior, dryRun plan-limit behavior, mode semantics, and return fields, though some of this repeats existing schema descriptions.

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 first sentence states a specific verb and resource: it shows how a template reads, covering both saved templates and unsaved fields. It also distinguishes itself from lnkdrp_render_email at the end, so an agent can route correctly without opening sibling schemas.

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 explicitly covers saved vs unsaved template paths, how contactId alters the preview, how dryRun behaves, and names lnkdrp_render_email as the alternative for a self-addressed preview rendered for a real contact. These are concrete when-to-use and when-not-to-use cues.

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.

Resources