Skip to main content
Glama
Sign In

LinkDrop

by com.lnkdrp
OverviewDiscussionsAdmin

List rendered emails

lnkdrp_list_email_renders
Read-onlyIdempotent

Rendered emails in the workspace (kept 30 days), newest first, without their text and html: recipient, target, link, subject, missingTags, ready, previewUrl, appUrl (the email's page in LinkDrop, Outreach › Sends › Single emails), and sentAt, sentVia (agent_gmail, gmail or manual) and heldIn once sent or held. locked is true for an email Gmail was handed with no answer recorded, which only the person resolves in LinkDrop (needsYou.resolveUrl); null when the app does not say. sort review with sent false puts the locked ones first, then newest. templateId, contactId, sent, locked and mine (only the emails this person made) narrow the list; batchId (from lnkdrp_send_email or lnkdrp_dry_run_email) lists one batch, each with queue (queued or sending, expectedAt) while it waits, and queueResult once its queued send or dry run ended (status done, skipped or failed, outcome, reason, dryRun). createdBy says who made it: name, via (web, api or mcp) and the agent when known; "Former member" for someone no longer in the workspace. query matches the recipient's name or address. createdFrom and createdTo narrow by when the email was made, sentFrom and sentTo by when it was sent (an unsent email is outside any sent range). Dates: a bare date (2026-10-28) is that whole day in the workspace's time zone (UTC when it has none) and a To date includes that day; a time with Z or an offset is that exact instant; the answer's dateRange gives the time zone and the exact instants used. Page-based: total says how many match. The contact's name and address and the document title are wrapped as untrusted content. Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
mineNotrue: only the emails this person made.
pageNo1-based page number.
sentNotrue: only sent emails; false: only unsent ones.
sortNoreview (with sent false): the locked emails first, then newest.
limitNoRenders per page (1-100).
queryNoOnly emails to a recipient whose name or address matches, case-insensitively.
lockedNotrue: only locked emails, waiting for the person; false: none of them.
sentToNoOnly emails sent on or before this date (that whole day) or time; one not sent is left out.
batchIdNoOnly the emails of one batch, as lnkdrp_send_email or lnkdrp_dry_run_email answered it.
sentFromNoOnly emails sent on or after this date (2026-10-28) or time; one not sent is left out.
contactIdNoOnly emails rendered for this contact.
createdToNoOnly emails created on or before this date (that whole day) or time.
templateIdNoOnly emails rendered from this template.
createdFromNoOnly emails created on or after this date (2026-10-28) or time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / createdFrom
      Added value: +{
+  "description": "Only emails created on or after this date (2026-10-28) or time.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}
    • addedInput schema / properties / createdTo
      Added value: +{
+  "description": "Only emails created on or before this date (that whole day) or time.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Only emails to a recipient whose name or address matches, case-insensitively.",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / sentFrom
      Added value: +{
+  "description": "Only emails sent on or after this date (2026-10-28) or time; one not sent is left out.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}
    • addedInput schema / properties / sentTo
      Added value: +{
+  "description": "Only emails sent on or before this date (that whole day) or time; one not sent is left out.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}
  2. Changed4 schema fields changed
    • addedInput schema / properties / batchId
      Added value: +{
+  "description": "Only the emails of one batch, as lnkdrp_send_email or lnkdrp_dry_run_email answered it.",
+  "pattern": "^[a-fA-F0-9]{24}$",
+  "type": "string"
+}
    • addedInput schema / properties / locked
      Added value: +{
+  "description": "true: only locked emails, waiting for the person; false: none of them.",
+  "type": "boolean"
+}
    • addedInput schema / properties / mine
      Added value: +{
+  "description": "true: only the emails this person made.",
+  "type": "boolean"
+}
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "review (with sent false): the locked emails first, then newest.",
+  "enum": [
+    "review"
+  ],
+  "type": "string"
+}
  3. Added

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: 30-day retention window, default newest-first ordering, review-sort tie-breaking on locked, inclusive date-range semantics with workspace time zone, and an explicit untrusted-content warning on titles and viewer-supplied text. These are behaviors an agent cannot derive from the annotations or schema.

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

Conciseness3/5

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

One dense ~200-word paragraph that mixes returned fields, filter semantics, and date rules without sub-structure, making it hard to scan. It is front-loaded with the resource and ordering, and most sentences carry information, but the returned-field enumeration crowds out the operational rules.

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 no output schema, the description carries the return-value burden and does so by enumerating the render fields, queue/queueResult lifecycle for batches, createdBy shape, and the total for pagination. Minor gaps remain on page/limit interaction with total, but an agent has enough to call and interpret it.

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% (baseline 3), and the description still adds real meaning: bare dates mean the whole day in the workspace's time zone while Z/offset means an exact instant, To dates are inclusive, unsent emails fall outside any sent range, and the response's dateRange echoes the resolved instants. A few parameters (page, limit, templateId, contactId) are only restated from the schema.

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?

Opens with a specific verb and resource plus scope: rendered emails in the workspace, retained 30 days, newest first, without text/html. That distinguishes it from get_email_render implicitly, but no sibling is named explicitly, so the differentiation is only inferable.

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?

Filter behavior is spelled out well (sort review requires sent false; batchId comes from lnkdrp_send_email or lnkdrp_dry_run_email), which implies usage. However, it never states when to choose this tool over lnkdrp_get_email_render or lnkdrp_get_sent_email, leaving the routing decision to inference.

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

All LinkDrop toolsInspect
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.

Resources