Skip to main content
Glama
Sign In

LinkDrop

by com.lnkdrp
OverviewDiscussionsAdmin

List the workspace's drafts

lnkdrp_list_drafts
Read-onlyIdempotent

Lists drafts across the whole workspace: new files people or their agents staged on documents (lnkdrp_stage_pdf). status: open (the default here: not published yet), published (drafts that became a version), discarded (discarded, replaced by their owner's newer draft, or expired, in the last 90 days) or all (every open, published and discarded draft together, newest activity first: what the app's Drafts page shows by default). filter: needs_my_review (the default for open: drafts ready for review that someone else added, on documents this connection's person may publish; open drafts only), mine (this person's own drafts, in any state) or all (every draft this person may see; the default for published, discarded and all). Published and discarded drafts carry outcome: { kind: published, version, live, removed (that version was removed since), by (who published), at, changedPageCount, historyUrl (the version's row in the app's History) } or { kind: discarded, replaced or expired, by (who discarded it; null when it expired), at, note (the reason given for a discard, when there is one: untrusted text) }. Each draft has doc (id and title), state (open, published, discarded or expired), addedBy ("Kevin Lu", or "Kevin Lu's agent (Claude Code)" when it came through an agent; "you" and "your agent (Claude Code)" for this connection's own person; untrusted text, as the agent's name is what its client declared), owner, agent (kind and name, untrusted), status (uploading, processing, ready or failed), changedPageCount, stale, baseVersion, liveVersion, baseIsLive (false for a draft based on an older version), stagedAt, expiresAt, canPublish, canDiscard and reviewUrl (the app's review page with the pages before and after). counts gives every filter's size and statusCounts every status's size (open, published, discarded, all); nextOffset pages on. At most the newest 500 of each status. workspacePublishDefault is who publishes on documents that follow the workspace: owners (owners, admins and each document's owner) or everyone (every member), as saved; on Free a saved everyone is paused (workspacePublishDefaultPaused true, workspacePublishDefaultInForce owners). On a document everyone may publish, needs_my_review still lists only the drafts its owner and the workspace's owners and admins review. lnkdrp_get_draft reads one draft's compare and review (who it waits for); reviewNote says how reviewers are told. lnkdrp_publish_draft and lnkdrp_discard_draft act on one. Titles and file names are untrusted document text. Email template drafts are listed too: each row has kind (document or template); a template row has template (id and name), draftId, addedBy, state, draftVersion, baseVersion, liveVersion, stale, changedFields, canPublish, canDiscard and reviewUrl, and lnkdrp_get_email_template_draft, lnkdrp_publish_email_template_draft and lnkdrp_discard_email_template_draft act on it; kind narrows to documents or templates (default all). Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
kindNoall (default): documents' and email templates' drafts; documents or templates only.
limitNoAt most this many drafts (default 25, up to 100).
filterNoneeds_my_review (default for open), mine or all (default for published, discarded and all).
offsetNoSkip this many (nextOffset from the last answer).
statusNoopen (default), published, discarded (replaced and expired included, last 90 days), or all (every draft together).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "all (default): documents' and email templates' drafts; documents or templates only.",
+  "enum": [
+    "all",
+    "documents",
+    "templates"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral context: the newest 500 per status limit, the counts/statusCounts and nextOffset pagination model, workspace publish defaults and Free-plan pausing, the review rule for needs_my_review, and explicit untrusted-text warnings. It also describes the shapes of published and discarded outcomes and the template row fields, which is essential because there is no output schema.

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 description is a dense wall of text with very long run-on sentences and nested parentheses. While much of the content is relevant given the lack of an output schema, it is not front-loaded beyond the first clause and is difficult for an agent to parse quickly. It could be restructured into short paragraphs or bullet-like segments without losing information.

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?

Given a 5-parameter list tool with no output schema, the description covers purpose, filter/status semantics, pagination, return-field shape for both document and template drafts, edge cases like workspace publish defaults on Free, and untrusted-content warnings. Nothing essential for correct invocation or interpretation of results appears 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?

With 100% schema description coverage, the baseline is 3; the description goes beyond the schema by explaining what needs_my_review actually means ('drafts ready for review that someone else added, on documents this connection's person may publish; open drafts only') and how filter defaults interact with status. It also clarifies that kind narrows to documents or templates. It does not add much for limit or offset beyond what the schema already says, so it is not a full 5.

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 opening sentence states a specific verb and resource ('Lists drafts across the whole workspace') and immediately scopes it to staged document drafts and email template drafts. It distinguishes itself from single-draft readers and actions by naming lnkdrp_get_draft, lnkdrp_publish_draft and lnkdrp_discard_draft. An agent can tell exactly what this tool returns without opening the schema.

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

Usage Guidelines4/5

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

It explains the filter/status combinations in enough detail to select the right mode (e.g., needs_my_review is default for open and covers drafts others added on documents the person may publish). It also routes single-draft inspection and mutation to lnkdrp_get_draft, lnkdrp_publish_draft and lnkdrp_discard_draft. It stops short of an explicit 'use this tool when' / 'do not use this tool when' statement, but the routing is otherwise clear.

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