Skip to main content
Glama

Render email

lnkdrp_render_email
Idempotent

Renders one email from a template for one contact and one document or project. LinkDrop finds or creates that contact's own share link (labelled with their name), fills the built-in tags and the custom values, and stores the result for 30 days. Returns subject, text, html, missingTags (required tags with no value; they stay in the text as {{key}}), warnings with warningNotes, ready (no missing tags and the link is on), link (created: true when this render made it), howToSend (the recipient address, a mail tool's arguments, the follow-up calls, and whether lnkdrp_send_email is available here), hasImages (true when the html shows an image, which a mail tool that sends only text drops), previewUrl: a signed page, valid 7 days, that shows the email without sign-in, and appUrl: the email's page in LinkDrop (Outreach › Sends › Single emails), for a signed-in member. Rendering the same template for the same contact and target again, before it is sent, replaces that render, its Cc included. cc puts up to 5 addresses on Cc of this one email (a real Cc header): they get the email as it is, with the recipient's own link, so their opens count as the recipient's, and they see the link's password when the email shows it (ccSeesPassword); the answer's ccNote says so. Refusals for cc are validation with details.code cc_invalid (details.address), cc_too_many (details.max), cc_is_recipient or cc_is_sender. The contact is an existing contact (contactId, or contactEmail; a contact list's members[].contactId fits contactId); an unknown one is not_found. A contact with no link to the target gets one made by this call. A contact link that is switched off or expired is validation with details.code link_inactive (no new link is made around it). The contact's name and address and the document title are wrapped as untrusted content; subject, text and html are the rendered email as plain strings and include names the contact gave. Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
ccNoAddresses on Cc of this email (up to 5), as a real Cc on the one email. Not the recipient's own address and not the sender's. Everyone on Cc gets the email as it is, with the recipient's own link, so their opens count as the recipient's. Rendering again replaces it: give cc again to keep it.
docIdNoThe document the email links to; one of docId or projectId, for a template with no links (its own documents) only.
valuesNoValues for custom tags, by key: { "custom.round": "Series A" } (the custom. prefix is optional). Up to 30 keys, 2,000 characters each.
contactIdNoThe recipient, by contact id (from lnkdrp_list_contacts or a contact list).
projectIdNoThe project the email links to; one of docId or projectId, for a template with no links only.
templateIdYesEmail template id (24 hex chars), from lnkdrp_list_email_templates.
contactEmailNoThe recipient, by the address of an existing contact.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / cc
      Added value: +{
      +  "description": "Addresses on Cc of this email (up to 5), as a real Cc on the one email. Not the recipient's own address and not the sender's. Everyone on Cc gets the email as it is, with the recipient's own link, so their opens count as the recipient's. Rendering again replaces it: give cc again to keep it.",
      +  "items": {
      +    "maxLength": 254,
      +    "pattern": "^[a-z0-9.!#$%&'*+\\/=?^_`{|}~-]+@[a-z0-9-]+(\\.[a-z0-9-]+)+$",
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
    • changedInput schema / properties / docId / description
      Previous value: -"The document the email links to; one of docId or projectId."New value: +"The document the email links to; one of docId or projectId, for a template with no links (its own documents) only."
    • changedInput schema / properties / projectId / description
      Previous value: -"The project the email links to; one of docId or projectId."New value: +"The project the email links to; one of docId or projectId, for a template with no links only."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

The description goes well beyond the annotations: it discloses the 30-day storage, replacement semantics for re-rendering, automatic link creation, link-inactive refusal behavior, cc side effects and refusal codes, return fields, and untrusted-content handling. These details are materially useful for an agent invoking a non-read-only, idempotent mutation.

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?

The core action and return structure are front-loaded, and most details earn their place because there is no output schema. The single dense paragraph is still heavy and contains mild repetition around cc replacement and untrusted content, so it is not maximally concise or structured.

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 complex 7-parameter tool with no output schema, the description is unusually complete: it covers inputs, side effects, return fields, error codes, cc behavior, link creation, and security caveats. An agent has enough information to call it correctly and interpret the result.

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

Parameters5/5

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

Although schema description coverage is already 100%, the description adds important meaning beyond the schema: contact resolution via contactId or contactEmail, target-link behavior, cc consequences including that Cc recipients see the recipient's link and password, and specific cc refusal codes. These are semantic consequences an agent would not infer from parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: renders one email from a template for one contact and one document or project. It also clarifies that the result is stored for 30 days and a share link is found or created, which distinguishes it from a simple preview. It does not explicitly name or contrast nearby siblings such as lnkdrp_preview_email_template or lnkdrp_dry_run_email, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful operational context: the contact must exist, unknown contacts return not_found, inactive links are refused, and re-rendering before send replaces the prior render. However, it never explicitly says when to use this tool instead of previewing, dry-running, or sending an email, nor does it name alternatives. Usage is implied by the behavior rather than clearly routed.

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