LinkDrop

List email images

lnkdrp_list_email_assets

Read-onlyIdempotent

The images uploaded for this workspace's HTML email templates, newest first: assetId, name (also its alt text), fileName (the uploaded file's name; null on images from before it was kept), url, contentType, size in bytes, width, height, createdAt and imgTag, the ready element for a template body. usedBy { count, templates } is how many live templates this person can see load it, at most three named. 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. mine keeps only this person's own uploads. An HTML template's sources are these urls. Each image has labels (the workspace's tags on it, lnkdrp_tag with assetId) and projects (the projects it is filed under). projectId keeps the images filed under that project; labels keeps those carrying any of the named tags. lnkdrp_update_email_asset renames an image or files it under projects. query searches the name, the file name, the type (png, gif, jpg or jpeg, webp), workspace tags, projects, and the name or subject of the templates that load it. With a word of three or more letters, rows come best match first and each carries match { in, snippet, name }: in is name, file name, type, label, project or template; name is the tag, project or template that matched. totalCapped true means more than 500 matched and total is a lower bound. searchIn: name searches the name only. More filters: format (gif, png, jpeg or webp), madeBy (person or agent), templateId (the images that template loads), used (true: loaded by a live template; false: by none), and the created and updated ranges. order: relevance (the default with a query), newest (the default otherwise), name or updated. 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. With page, limit, query or a filter the answer is one page (limit 25 by default) and total says how many match; without them, every image (up to 200).

Input Schema

Name	Required	Description
`mine`	No	true: only the images this person uploaded.
`page`	No	1-based page number; asks for one page.
`used`	No	true: images a live template loads. false: images no live template loads.
`limit`	No	Images per page (1-100, default 25); asks for one page.
`order`	No	relevance: best match (the default with a query). newest: uploaded most recently (the default otherwise). name: A-Z. updated: changed most recently.
`query`	No	Searches name, file name, type, workspace tags, projects and the names and subjects of templates that use the image, case-insensitively.
`format`	No	Only images of this type.
`labels`	No	Only images carrying any of these workspace tags (lnkdrp_tag), by name or slug (1-20).
`madeBy`	No	person: uploaded in the app. agent: uploaded through the API or an agent.
`searchIn`	No	all (default): everything query searches. name: the image's name only.
`createdTo`	No	Only images created on or before this date (that whole day) or time.
`projectId`	No	Only images filed under this project (24 hex chars).
`updatedTo`	No	Only images last changed on or before this date (that whole day) or time.
`templateId`	No	Only the images this email template loads (24 hex chars); a template this person cannot see gives an empty page.
`createdFrom`	No	Only images created on or after this date (2026-10-28) or time.
`updatedFrom`	No	Only images last changed on or after this date (2026-10-28) or time.

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 29, 2026

addedInput schema / properties / createdFrom

Added value: +{
+  "description": "Only images 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 images 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 / format

Added value: +{
+  "description": "Only images of this type.",
+  "enum": [
+    "gif",
+    "png",
+    "jpeg",
+    "webp"
+  ],
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Images per page (1-100, default 25); asks for one page.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / madeBy

Added value: +{
+  "description": "person: uploaded in the app. agent: uploaded through the API or an agent.",
+  "enum": [
+    "person",
+    "agent"
+  ],
+  "type": "string"
+}

addedInput schema / properties / order

Added value: +{
+  "description": "relevance: best match (the default with a query). newest: uploaded most recently (the default otherwise). name: A-Z. updated: changed most recently.",
+  "enum": [
+    "relevance",
+    "newest",
+    "name",
+    "updated"
+  ],
+  "type": "string"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "1-based page number; asks for one page.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "Searches name, file name, type, workspace tags, projects and the names and subjects of templates that use the image, case-insensitively.",
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / searchIn

Added value: +{
+  "description": "all (default): everything query searches. name: the image's name only.",
+  "enum": [
+    "all",
+    "name"
+  ],
+  "type": "string"
+}

addedInput schema / properties / templateId

Added value: +{
+  "description": "Only the images this email template loads (24 hex chars); a template this person cannot see gives an empty page.",
+  "pattern": "^[a-fA-F0-9]{24}$",
+  "type": "string"
+}

addedInput schema / properties / updatedFrom

Added value: +{
+  "description": "Only images last changed on or after this date (2026-10-28) or time.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}

addedInput schema / properties / updatedTo

Added value: +{
+  "description": "Only images last changed on or before this date (that whole day) or time.",
+  "maxLength": 40,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}",
+  "type": "string"
+}

addedInput schema / properties / used

Added value: +{
+  "description": "true: images a live template loads. false: images no live template loads.",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 28, 2026

addedInput schema / properties / labels

Added value: +{
+  "description": "Only images carrying any of these workspace tags (lnkdrp_tag), by name or slug (1-20).",
+  "items": {
+    "maxLength": 60,
+    "minLength": 1,
+    "pattern": "^[^,]*$",
+    "type": "string"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / mine

Added value: +{
+  "description": "true: only the images this person uploaded.",
+  "type": "boolean"
+}

addedInput schema / properties / projectId

Added value: +{
+  "description": "Only images filed under this project (24 hex chars).",
+  "pattern": "^[a-fA-F0-9]{24}$",
+  "type": "string"
+}

AddedOct 23, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description still adds substantial behavioral context: the 500-match cap with totalCapped and a lower-bound total, the paged-vs-unpaged branch (25 default vs all up to 200), visibility scoping via usedBy and 'a template this person cannot see gives an empty page', and 'Former member' for departed creators. This is exactly the kind of limit and permission detail annotations cannot express.

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?

It is a single dense wall of text with no list structure, and it front-loads the full return-field inventory before the filters an agent actually selects on. Every sentence carries information, but the lack of grouping across a 16-parameter tool makes the content harder to scan than it needs to be.

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?

No output schema exists, and the description compensates fully by documenting every returned field (assetId, imgTag, usedBy, createdBy, labels, projects, match) alongside all 16 filters. Nothing an agent needs to call this correctly or interpret the response is missing.

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 baseline is 3; the description nonetheless adds real meaning beyond it — date semantics (a bare date is the whole day in the workspace time zone, a To date includes that day, offset times are exact instants, dateRange reports the instants used) and the pagination trigger condition are not in the schema. The remaining filter prose largely restates schema descriptions.

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 opening clause names the resource precisely — the images uploaded for this workspace's HTML email templates — and enumerates the returned fields, so an agent knows exactly what it gets back. It stops short of a clean verb-and-scope statement and never contrasts itself with the sibling listing tools (e.g. lnkdrp_list_email_templates), so differentiation is inferred rather than stated.

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?

Usage is implied rather than prescribed: 'An HTML template's <img> sources are these urls' and the lnkdrp_update_email_asset cross-reference signal where this tool fits, but there is no explicit when-to-use / when-not phrasing and no named alternative for overlapping lookups. An agent must infer from the filter list what scenarios this covers.

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

All LinkDrop tools Inspect

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

Need Help?