LinkDrop

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

Annotations give only the coarse safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description adds the real behavioral detail: existing addresses gain a source rather than erroring, lastSeenAt/lastSource move, created returns false, existing names are never overwritten and nameKept signals it, and filled names are attributed to the team (nameSetBy). It also warns that titles, summaries and viewer text in results are untrusted author/reader content, which annotations cannot convey.

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

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

The purpose is front-loaded in the first clause and each sentence carries concrete behavior, but the prose is clause-heavy and the 'for a person the workspace already knows and the product has not seen' sentence is dense and slightly cryptic. Efficient overall, marginally over-written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full return-value burden and does so: created, replayed, nameKept and contact.name are all explained, including the duplicate and name-preservation outcomes. For a 3-parameter mutation tool with no output schema, nothing an agent needs is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds genuinely new semantics beyond the schema: the email is the identity, is required and is folded to lowercase, and a supplied name only fills a blank rather than overwriting. The interaction between the idempotencyKey and duplicate suppression is explained in the schema and reinforced in the description.

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

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

States a specific verb+resource+key ('Adds somebody to the workspace's contacts by email address') and immediately distinguishes itself from a sibling by declaring that renaming is lnkdrp_update_contact's job. An agent can tell this apart from update_contact, get_contact and list_contacts without opening their schemas.

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

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

Gives a clear usage scenario (contacts are added as people read a share link) and an explicit alternative plus the condition selecting it ('renaming a contact on purpose is lnkdrp_update_contact's job'). It also clarifies that re-adding an existing address is not an error, which is decision-relevant. It stops short of a full when-to-use/when-not framework, so a 4 rather than 5.

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

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

Annotations only declare the safety profile (not read-only, idempotent, not destructive); the description adds everything else an agent needs: batch and list capacity (100 per call, 500 per list), the exact error signals (validation with details.code list_members_limit, plan_limit with details.upgradeUrl), and the dry-run list restriction. It also flags that titles/summaries/viewer text in results are untrusted author-written content, which is a genuine injection-risk disclosure.

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

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

Purpose and limits are front-loaded and every sentence carries non-obvious information (return fields, error codes, plan gating, untrusted content). It is dense and run-on, packing five separate concerns into one paragraph, so scanning cost is higher than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description enumerates the return fields (added, alreadyMembers, notFound) and explains each. Capacity limits, plan gating, dry-run restrictions, and failure codes are all covered for a 3-parameter mutation tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by framing the two input paths as alternatives ('by contact id or address') and by explaining what notFound means for those inputs. Minor friction: it references 'dryRun true' as a condition although no dryRun parameter exists in the schema, which could briefly confuse an agent about the call's inputs.

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

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

States a specific verb (adds), resource (contacts to a list), and the two addressing modes (contact id or address). It explicitly distinguishes itself from lnkdrp_add_contact ('nothing is created for them, lnkdrp_add_contact adds a contact') and from lnkdrp_remove_contact_list_members, so an agent can select it without opening any schema.

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

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

Names the alternative for the adjacent task (lnkdrp_add_contact when the person is not yet a contact) and the sibling for the inverse operation (lnkdrp_remove_contact_list_members, which 'works on every plan'). It also states the conditions under which the call is forbidden (dry-run lists, Free plan), which is real when/when-not guidance rather than implied context.

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

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

Despite annotations already declaring idempotentHint=true and destructiveHint=false, the description adds substantial context: other projects are left untouched, the full result vocabulary (added, alreadyInProject, notFound, failed, contained, receivedCopies), the archived/visibility exception paths, and the public-page propagation side effect. It also flags untrusted author/reader text in results, which is a genuine injection-risk disclosure.

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

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

The action and scope are front-loaded in the first sentence, and each following sentence covers a distinct result category or edge case rather than padding. The result-semantics block is dense and the parentheticals make some sentences hard to parse, which keeps it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of explaining return values, and it does so exhaustively by enumerating every result bucket and its trigger conditions. Combined with idempotency, membership semantics, and the untrusted-content warning, an agent has everything needed to call and interpret this correctly.

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

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

Schema description coverage is 100%, and the schema already documents docIds, projectId and projectSlug including their formats and the either/or requirement. The description's '1-50 documents' adds nothing beyond the schema's minItems/maxItems, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb ('Put'), resource ('documents'), target ('into a project') and bounds ('1-50'). It is unambiguously distinct from lnkdrp_remove_doc_from_project and the other project siblings without needing either schema.

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

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

It clearly frames the operation and its idempotent repeat behavior ('a repeat call adds nothing new') and explains the alreadyInProject case, so the agent knows what happens on repeat. However, it never explicitly names an alternative tool (e.g. remove_doc_from_project) or states when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so safety and repeatability are covered structurally. The description adds only the 'same answers' equivalence claim and never explains the effect of archiving (hidden from listings? revocable? does it affect a send in progress), so it contributes almost nothing behavioral.

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

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

Two sentences: the first carries the actual identity information and is front-loaded, but the second is a lengthy domain gloss on what a drop is rather than on what archiving does, so it does not fully earn its space in an archive-tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter toggle with full schema coverage, a strong safety annotation set, and no output schema, the definition supplies the one thing structured fields cannot: that this is an alias of lnkdrp_archive_drop. The only real gap is that the alias/legacy-vs-canonical routing advice is left implicit.

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

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

Schema description coverage is 100% and both parameters (campaignId with the 24-hex pattern and its source tool, archived boolean with its default and true/false meaning) are fully documented in the schema. The description adds no meaning beyond that, which is the expected baseline when the schema does all the work.

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

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

The description never states the action directly; it identifies the tool only by equivalence to lnkdrp_archive_drop ("same arguments and the same answers"), so the verb 'archive' is inferred from the name and sibling rather than asserted. It does clarify the domain object (a drop = one email template sent from the member's Gmail), which is useful, but an agent must consult another tool to learn what the operation actually does.

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

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

No guidance on when to call this versus lnkdrp_archive_drop, its own twin, or restore_drop for reversal. The alias relationship implies the two are interchangeable but never says which is canonical or why an agent would pick one; nothing excludes misuse or states prerequisites.

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

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

Goes well beyond the annotations (destructive/idempotent/openWorld) by spelling out consequences: all share links stop resolving, the document leaves the shared-document cap, analytics are retained, unarchive can fail with plan_limit, and the confirmation-token flow differs by recipient activity. It even flags untrusted content in results.

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

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

Front-loaded with the action and reversible nature, then layered behavioral detail. Every sentence carries useful information for a destructive tool, though the confirmation-flow and untrusted-content sentences add length that could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full burden and does so: side effects, reversibility, failure modes, the two-step confirmation path, and a content-safety warning. Nothing an agent needs to call this destructive tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the confirm/confirmationToken flow (a preview returned for this same action, the person's yes) and the archived flag's dual role, though alwaysAllow is not elaborated on.

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

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

States a specific verb (archive/unarchive) and resource (document), and immediately disambiguates the two directions via the archived flag. An agent can distinguish it from lnkdrp_delete_doc or lnkdrp_restore_doc 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.

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

Explains the operational context clearly: archiving can be undone, unarchiving re-checks the Free cap and may fail with plan_limit, and confirmation is only required when recipients have already engaged with the document. It does not explicitly name sibling alternatives (e.g. delete_doc vs archive), but the when/when-not conditions are otherwise well covered.

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

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

Goes well beyond the annotations: nothing a recipient sees changes and already-sent emails stay sent, the record is retained and readable, it stops counting toward the workspace cap, it returns changed: false when already in that state (nothing written), and it enumerates the exact failure codes (campaign_sending, campaigns_limit, not_found). It even flags that titles and viewer-supplied text in results are untrusted content.

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

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

One dense paragraph in which nearly every sentence carries operational information, front-loaded with the verb and the toggle. The opening gloss of what a 'drop' is runs long for an archive tool and could be compressed, but it is not padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with no output schema, the description covers everything an agent needs: state effects, side effects on recipients, quota interaction, the changed:false no-op, and the full error surface. Nothing material is left to inference.

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

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

Schema coverage is 100%, so archived and campaignId are already documented, but the description adds state-transition meaning the schema cannot: archived:false returns the drop to the sent tab (or active if unsent) and can trip campaigns_limit at the cap. This exceeds the baseline-3 expectation for fully documented schemas.

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

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

States a specific verb and resource ('Archives a drop') and immediately explains the inverse operation via archived: false, so the toggle semantics are unambiguous. It even parenthesizes the API name ('a campaign in the API'). However, it never distinguishes itself from the sibling lnkdrp_restore_drop, which an agent will plausibly treat as the unarchive counterpart, nor from lnkdrp_archive_campaign.

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

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

Gives clear usage context: archiving is how you free capacity against the plan's drop cap, and it names the sibling reads (lnkdrp_get_drop, lnkdrp_list_drops with state archived) for consuming an archived drop afterward. It stops short of explicit exclusions — it does not say when to prefer restore_drop over archived:false.

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

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

Goes well past the annotations: discloses that archived templates stay readable, cannot be edited or rendered until unarchived, that already-rendered emails still send, and that archiving frees plan capacity. It also names the exact failure modes (templates_limit with details.limit/plan, name_taken, not_found) and the idempotent no-op response (changed: false).

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

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

Front-loaded with the action and its inverse in the first sentence, then ordered by consequence (readability, rendering, cap, errors, return value). Dense but nearly every clause carries decision-relevant information; it runs long as a single paragraph, which slightly hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, no output schema, and simple annotations, the description still covers side effects, capacity accounting, error codes, and the return shape ('Returns the template with its state, and changed: false'). Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters; the description still adds meaning by spelling out the false/unarchive direction and the state no-op behavior. The workspace-scoping of templateId ('not in this workspace ... is not_found') adds lookup semantics beyond the schema's pattern.

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

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

States a specific verb and resource ('Archives an email template') and immediately covers the inverse operation ('or unarchives it with archived: false'), so the tool's scope is unambiguous. It also distinguishes the archived state from the deleted state ('kept and can still be read' vs 'is deleted, is not_found'), separating it from lnkdrp_delete_email_template and lnkdrp_restore_email_template without naming them.

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

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

Gives a clear trigger for archiving ('not counted toward the workspace's cap ... so archiving one makes room') and for unarchiving, plus the precondition that unarchiving fails at the cap. It does not explicitly route the agent to delete/restore alternatives by name, which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond those annotations by stating that requests are read only in this workspace and that titles, summaries, and viewer-supplied text in results are untrusted content.

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

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

The description is front-loaded with the tool's purpose and state meanings, then adds workspace and trust warnings. It is reasonably compact, though the state enumeration and security note make it denser than a minimal definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with no output schema, the description explains the possible request states and the workspace scope. It is nearly complete, though it does not describe the exact return shape or whether additional request metadata is included.

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

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

Schema description coverage is 100%, and the single approvalId parameter is already documented in the schema as coming from lnkdrp_request_member_invite. The description reinforces that source but does not add format or retrieval details beyond the schema baseline.

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

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

The description clearly identifies the resource as the state of a request made through the server, specifically a member invite request tied to lnkdrp_request_member_invite. It distinguishes this from the sibling request tool by focusing on reading the request state rather than creating it, though it uses a noun phrase rather than an explicit verb.

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

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

The description gives clear context: this is for checking the state of a member invite request made via lnkdrp_request_member_invite. It does not explicitly state when not to use it or name alternative tools, but the context is strong enough to guide selection.

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

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

Annotations already cover readOnly/idempotent/non-destructive; the description goes further by disclosing workspace-scoped visibility ('reads only links this LinkDrop account made in this workspace'), the 2-second polling cadence and 20-second cap behavior, the 60-minute expiry rule, and a prompt-injection warning about untrusted author/reader text. That is substantive behavioral context beyond the structured fields.

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

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

Front-loaded with purpose and status, and essentially every clause carries needed information since there is no output schema. It is, however, a single dense paragraph with stacked parentheticals that is harder to scan than a short status list would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full burden of describing returns and does so: the doc {docId, title, status, shareUrl, version} payload, the email-image asset payload with imgTag, the null-asset deletion case, and that doc appears only once a document is created or changed.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description still adds real semantics the schema lacks: waitSeconds only has effect while status is started/uploaded/processing, polls every 2 seconds, and is bypassed entirely for pending links.

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

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

States a specific verb+resource (check the state of an upload link) and immediately scopes it to links made by lnkdrp_create_upload_link or lnkdrp_create_email_asset_upload_link, distinguishing it from the whole create_* / get_* sibling set. The status vocabulary makes the returned concept unambiguous.

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

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

Clear about the calling context: use it on a link returned by the two create tools, and use waitSeconds only for started/uploaded/processing while a pending link is answered at once. It does not explicitly compare against alternatives (e.g. get_share or list_share_links) or state what not to use it for, so it stops short of full routing guidance.

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

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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile, and the description adds substantial behavioral detail beyond them: truncation limits, readTextTruncated/readTextLinesLeftOut, appUrl, changeKind semantics, and specific not_found cases. This is exactly the kind of context an agent needs to interpret results and handle errors correctly.

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

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

The purpose is front-loaded, but the description is a single dense run-on paragraph with semicolon-separated return-field explanations. Most details are relevant given the absence of an output schema, but the structure is hard to scan and could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full burden of explaining return values, and it does so thoroughly: fieldChanges, readText, changeKind variants, word/body/html change flags, sourceLines, summary, deletedImages, appUrl, and error behavior. An agent has enough information to invoke and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful directionality: 'from 6 to 3 is the older text against the newer' and 'to defaults to the current version.' That interpretation goes beyond the parameter descriptions, though templateId is only referenced via its source list and not further clarified.

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

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

The description opens with a specific verb and resource: 'What changed between two versions of an email template.' It immediately explains the directional comparison semantics, so an agent can distinguish this from siblings like list_email_template_versions or get_email_template.

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

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

The context for use is clear: compare a `from` version against a `to` version, with `to` defaulting to the current version. It also documents not_found behavior for missing templates/versions. It stops short of explicitly naming alternatives such as list_email_template_versions for discovering version numbers, so it is not a full when/when-not/alternatives statement.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by explaining the token lifecycle: a token that is expired, used, or from another connection 'changes nothing', which substantiates the idempotency and one-shot semantics.

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

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

Two sentences, front-loaded with the tool's role followed by the token caveat; no filler. The opening clause is slightly convoluted but earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety and the schema documenting the decision enum, the description supplies the remaining needed context (mechanism plus token-failure behavior). No output schema exists, and the return values are not critical here, so the coverage is adequate.

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

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

Schema coverage is 100% and the enum values for 'decision' are fully documented in-schema. The description only adds that the cardToken is held solely by the card and that invalid tokens are no-ops, which is marginal beyond what the schema already provides.

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

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

States the resource precisely — the handler for the buttons on a confirmation card — and what it does (carries out or cancels the card's action). An agent can distinguish it from siblings like lnkdrp_check_approval or the mutation tools themselves, though the verb phrasing is abstract rather than a clean 'confirm X'.

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

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

The context ('the action behind the buttons on LinkDrop's confirmation card') implies you call it when responding to a confirmation card, but there is no explicit when-to-use/when-not statement or named alternative. Usage must be inferred from the card framing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so safety is covered. The description adds genuinely non-structured domain context — that each recipient gets their own tracked link to each template document and mail is sent from the member's own Gmail — but it says nothing about side effects of creation itself, such as whether auto-created contacts are persisted or whether duplicate drops are allowed (idempotentHint=false implies not).

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

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

Two sentences, front-loaded with the alias relationship, followed by compact domain context for 'drop'. Nothing is redundant, though the second sentence is dense and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation with no output schema, the definition defers almost everything to the sibling's contract ('same args, same answers'), which is a reasonable shortcut but leaves the return value vague and gives no deprecation policy. The parameter space is fully covered by the schema, so the gap is mainly around which tool to call and what comes back.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in detail, including constraints and semantics. The description only says 'the same arguments', adding no meaning beyond the schema. Baseline 3 applies.

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

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

The first clause anchors the tool to lnkdrp_create_drop ('same arguments, same answers'), so an agent can infer the create-a-drop verb plus resource without opening the schema. The second sentence defines what a drop actually is, which further secures the purpose. It stops short of a direct verb+resource statement of its own, relying on the sibling name to carry that weight.

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

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

'Under its earlier name' hints that this is a legacy alias, but the description never states the selection rule — nothing tells the agent to prefer lnkdrp_create_drop or when this name should still be used. With two behaviorally identical siblings in the list, an agent has no basis to choose between them.

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

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

Goes far beyond the annotations with error taxonomy (name_taken, lists_limit with details.limit, plan_limit with upgradeUrl), the plan gating (Pro and up; Free reads/renames still work), the 100-per-call and 500-per-list bounds, and the dryRun privilege model ('dryRun true from an agent's connection is forbidden'). It also discloses that new lists default to private-within-workspace unless visibility=team, and warns that titles/summaries are untrusted content.

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

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

The content is almost all load-bearing, but it is delivered as one long run-on paragraph mixing limits, error codes, plan gating, dry-run authorization, visibility and an untrusted-content warning. Front-loading is good (purpose first), but the lack of segmentation makes the privilege rules around dryRun easy to miss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return shape ('Returns the list, added and notFound'), covers the failure modes an agent must handle, and explains the plan and role preconditions. Nothing an agent needs to call this correctly and interpret the result is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: only existing contacts are accepted so unknown ids/addresses surface in notFound rather than being created, and dryRun/dryRunBandText are owner/admin-only with agent connections forbidden. Visibility privacy defaults and cross-scope name uniqueness are also explained in prose rather than left to the enum.

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

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

States a specific verb and resource ('Creates a named list of the workspace's contacts') and immediately gives a concrete example of what that means (an investor distribution list). It distinguishes itself from lnkdrp_add_contact, lnkdrp_add_contact_list_members, lnkdrp_update_contact_list and lnkdrp_delete_contact_list by scoping to list creation only.

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

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

The description explicitly routes to a sibling ('lnkdrp_add_contact adds a contact') and explains that renaming/removing/deleting are separate operations that work on all plans, which implicitly frames when not to call this tool. It stops short of naming the alternative for adding members to an existing list (lnkdrp_add_contact_list_members) by name, so the routing is slightly incomplete.

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

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

Annotations only declare non-readonly/non-idempotent/non-destructive; the description goes far beyond by disclosing ownership and sender identity, that visibility defaults to private with private list/template inheritance, that each call creates a new drop, and a full refusal taxonomy with details.code values (campaign_empty, invalid_email, contacts_limit_reached, campaigns_limit, not_found). It also carries a prompt-injection caveat about untrusted titles/summaries in results.

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

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

The core definition and the 'nothing is sent' routing are front-loaded, but the prose is a dense ~270-word block with redundancy: the per-person tracked link concept is stated in sentence one and restated as 'Each person gets their own link to each of the template's links.' Limits and refusal codes are packed into the same paragraph rather than separated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and no annotations carrying semantics, the description supplies an unusually complete picture: required pairings, limits, plan gating, privacy model, and error codes. The one gap is that it never says what a successful call returns (created drop id/shape), which matters when there is no output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns above that by adding cross-parameter logic the schema does not express: docId/projectId are only needed when the template has no links, and projectIds files the drop under projects while projectId is the link target. It also explains list/person de-duplication and the 100-person ceiling.

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

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

States the specific verb and resource ('Creates a drop') and immediately defines what a drop is in domain terms: one email template sent from the member's own Gmail with per-person tracked links. It also distinguishes this from the send/dry-run siblings by name, so an agent can separate creation from dispatch without opening any schema.

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

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

Explicitly says 'Nothing is sent; lnkdrp_send_drop sends it and lnkdrp_dry_run_drop sends one person's email to the member's own Gmail first,' naming both alternatives and the condition that selects them. It adds concrete gating conditions (Pro-and-up, plan caps, archiving frees room), which is more than a bare 'when to use' statement.

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

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

Beyond the annotations, the description discloses the one-time 60-minute validity, account/workspace scoping, revocation behavior, file validation rules, 10 MB resize behavior, 200-image workspace cap, rate limit of 10 waiting links per person, and what happens after a refused file. This is unusually complete behavioral context for a write-capable tool whose annotations only say it is non-readonly, non-destructive, idempotent, and closed-world.

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

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

The description is front-loaded with the core action and the condition that selects it. It is long and dense, but most clauses carry necessary behavioral constraints, validation rules, or return/next-step information that would otherwise be missing because there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex upload-link creation tool with no output schema, the description includes the returned fields and explicitly names lnkdrp_check_upload_link with uploadLinkId as the follow-up. It also covers constraints, permissions, expiration, and failure behavior, leaving little an agent needs to infer before calling it.

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

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

Schema description coverage is 100%, so both parameters are already well documented. The description repeats the 'name becomes image name and alt text' behavior, which is useful reinforcement but adds little beyond the schema, and it does not explain idempotencyKey behavior beyond what the schema already states. Baseline 3 is appropriate when the schema carries parameter semantics.

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

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

The description states a specific verb and resource: creates a one-time upload-link page for adding an image to HTML email templates. It clearly distinguishes this route from lnkdrp_upload_email_asset and from dataBase64/sourceUrl approaches, so an agent can identify it 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.

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

It explicitly says when to use this tool: an image attached in chat lacks a public sourceUrl and is too long for dataBase64. It also explains the operational context that the agent has no network access and the signed-in person must open the link, which is decisive for correct tool selection.

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

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

Annotations only supply safety hints (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description goes far beyond them, disclosing image size/count caps with the exact downgrade behaviour and reason codes, template and daily-creation caps with retryAt, default private visibility, name-uniqueness, and a full enumeration of validation/rate-limit detail codes with the conditions that trigger them. It also describes the return payload, which no output schema covers.

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

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

The definition is a single semicolon-chained wall of roughly a thousand words, with tag enumeration, error-code taxonomy and resize rules all crammed into one block. Much of the content is genuinely useful, but it is not front-loaded or segmented, and large portions (every built-in tag with an example, every failure code) would be better placed in a reference or in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation with no output schema, the description is complete: it covers the required fields, the optional links/tags structures, the caps that can block a save, and the exact shape of the response (tags used, unusedTags, warnings, imagesResized). An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by explaining the tag grammar ({{entity.field}} and {{entity.field|fallback}}), cataloguing every built-in tag with its value semantics and example, and defining what custom tags are and which are rejected as custom_tag_is_link. It does not touch `align` or `visibility` in prose beyond the private/team sentence, 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.

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

The opening sentence gives a specific verb and resource with the four required fields named: 'Creates an email template in the workspace: a name, a format (text or html), a subject and a body with replaceable tags.' It is clearly a creation tool, distinguishable from lnkdrp_update_email_template and lnkdrp_duplicate_email_template by the verb, though it never explicitly contrasts itself with those siblings.

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

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

It routes the agent to specific siblings in specific situations: images must be uploaded via lnkdrp_upload_email_asset and discovered via lnkdrp_list_email_assets, caps come from lnkdrp_whoami, custom tag values come from lnkdrp_render_email. It also explains what is refused and why. What is missing is the negative case — it never says when to use update/duplicate/preview instead of create.

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

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

Adds substantial behavior beyond the annotations: the public page is enabled by default and controlled by publicPageEnabled, names must be unique per workspace (duplicate = validation error), Free-plan caps fail with plan_limit and details, and idempotencyKey replay semantics. These are non-obvious operational traits the annotations (readOnly=false, idempotent=true) cannot convey.

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

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

Front-loaded with purpose and return values, then constraints and failure modes. It is dense and somewhat long, but each sentence carries distinct information (default public page, uniqueness, plan limit, idempotency, untrusted content), with little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description names the return fields (projectId, slug, name, appUrl, publicUrl) and explains key error conditions (duplicate name, plan_limit). Combined with the 100%-covered schema, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so all three parameters are already documented. The description restates the idempotency replay behavior and name uniqueness rather than adding syntax or new meaning, so the baseline 3 for a fully-covered 3-param schema is appropriate.

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

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

States a specific verb (create) and resource (empty project) with its purpose (group documents, e.g. a data room). It is trivially distinguishable from siblings like lnkdrp_list_projects, lnkdrp_update_project, and lnkdrp_delete_project.

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

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

Gives clear context for when this tool applies ('create an empty project to group documents, e.g. a data room for one deal') and notes the project starts empty, implying documents are added later via add_docs_to_project. There is no explicit comparison against an alternative creation path, but none of the sibling names suggest one.

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

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

Annotations declare idempotentHint=true, and the description earns its lower bar by disclosing rich side effects beyond them: creating an enabled link revives the project's public page (surfaced in warnings), allowDownload overrides every document's own link, contacts on a link credit no views, and a repeat call returns replayed:true. It also flags that result text is untrusted author/reader content.

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

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

Front-loads the core purpose and the sibling distinction, and every sentence carries real information for a 14-parameter tool. However, it is an undifferentiated block of dense clauses with some duplication of the schema, which slightly impairs scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, it covers what an agent needs: side effects on the public page, error codes and retry behavior, idempotency semantics, and result shape hints (warnings, replayed:true). Nothing material is left unstated.

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

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

Schema coverage is 100%, so the schema already documents all 14 parameters; per the rubric the baseline is 3. The description mostly restates schema content (sentAt/sentVia pairing, allowDownload scope) rather than adding syntax or semantics the schema lacks.

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

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

States a specific verb and resource ('Create a share link for a whole project') and explicitly distinguishes itself from the sibling document-link tool: 'A project link sends every document in a project... a document link sends one document.' An agent can route correctly without opening either schema.

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

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

Gives explicit when-to-use versus the alternative (project-wide vs single document), plus prerequisites and failure conditions: at most 50 links, too_many_links on the 51st, non-retryable until a link is deleted, and not_found for a non-contact email.

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

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

The description goes far beyond the annotations, disclosing the 50-link cap, the Free-plan behavior where a link is created but switched off (active false, planWarning.blocked true), the too_many_links and received_copy validation errors, archived-document behavior, contact crediting rules, and untrusted-content warnings. It also confirms and elaborates the idempotentHint annotation (replayed: true, 10-minute/24-hour windows). This is unusually rich operational disclosure.

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

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

The purpose is correctly front-loaded in the first sentence, and most clauses (caps, plan warnings, idempotency) earn their place. However the body is a single dense paragraph of run-on sentences covering many independent edge cases without segmentation, making it hard to scan and longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter creation tool with no output schema and many failure modes, the description covers caps, plan gating, error codes, archiving, idempotency and contact rules, which is everything an agent needs to invoke it correctly. No material gap remains.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 14 parameters. The description nonetheless adds interpretation the schema lacks, such as a link carrying only one contact, direct-vs-share semantics, and that a contact on a link credits no views, which sharpens contactRole/contactId usage beyond the field text.

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

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

The opening sentence gives a specific verb and resource ('Create an extra share link for a document') and enumerates what the link carries (label, audience, password, download, expiry). It also distinguishes the resource from its closest sibling by noting that 'a project link carries several documents on one URL', letting an agent separate this from lnkdrp_create_project_link and lnkdrp_create_upload_link without opening a schema.

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

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

Usage is implied through statements like 'One link per recipient' and the description of when links are created versus capped, but there is no explicit when-to-use / when-not guidance nor any routing to alternatives such as update_share_link or share_pdf. An agent can infer the context but must reason about which of the several share-link siblings to pick.

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

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

Goes far beyond the annotations: one upload of one PDF up to 50MB, 15-minute expiry, 5-minute file retention, uploadId scoped to this connection and requiring write access, and the fact that uploadUrl is a bearer secret until used. It also documents the proxy-403 failure mode precisely - nothing is created, retries from the same sandbox fail identically - which is exactly the kind of context annotations cannot carry.

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

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

Front-loaded correctly - the first clause states the purpose and precondition - but the body is a dense wall of text that repeats the 'a Drive file or public link needs no upload' point twice in near-identical form. The trailing note about untrusted titles and viewer-supplied text is a global disclaimer appended to this tool rather than something that earns its place here.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema, it covers everything: the full return shape ({ uploadId, uploadUrl, method, expiresAt, maxBytes, curlExample, nextStep }), the downstream consumers of uploadId (share_pdf, replace_pdf, stage_pdf), TTLs, the secret-handling requirement, and the network-policy failure path. Nothing needed to call it correctly or interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value by tying sizeBytes to the 50MB refusal point and contrasting the mechanism with fileBase64 (carries larger files, no base64 in the call), plus the curlExample path for the actual PUT. It stops short of explaining fileName/contentType beyond what the schema already says.

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

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

Stated as a specific verb+resource (get a one-time URL to upload a PDF to) with the exact precondition that selects it: a file in the client's own environment that has neither a readable path nor a public https URL. It explicitly names the sibling routes (driveFileId, sourceUrl, filePath, lnkdrp_create_upload_link) it is not, so an agent can distinguish it without opening any schema.

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

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

Gives explicit when-to-use and when-not-to-use: a Drive file, a public link, or a locally readable path needs no upload, and an upload link is the alternative when the person should add the file from their own browser. It even names the environment condition (ChatGPT's code sandbox) under which the tool will refuse and points to the routes that work.

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

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

Goes far beyond the annotations: one-use link, 60-minute expiry, scoped to the connection's account and workspace, revoked with the key or sign-in, carries no password or personal details in the URL, validation refusal of title/projectId/projectSlug/allowDownload/password when docId is set, 'forbidden' with details.code publisher_required, and a 10-link-per-person rate limit. It also flags untrusted author/viewer text in results.

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

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

Front-loads purpose and constraints, and nearly every clause adds a distinct fact (expiry, scope, refusal rules, return shape, rate limit). It is a dense wall of text with some repetition of the docId/new-version condition, which keeps it from a top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the return object ({ uploadLinkId, url, expiresAt, mode, ... }) and ties uploadLinkId to lnkdrp_check_upload_link, the natural follow-up. Combined with the failure modes and rate limit, an agent has everything needed to call it and handle the outcome.

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

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

Schema coverage is 100%, so the schema carries the field-level detail; the description adds the cross-parameter rule that matters most — with docId the five new-document fields are refused by validation, and password is stored and never returned (only passwordSet). It does not elaborate on idempotencyKey's 10-minute replay beyond what the schema already says.

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

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

States a specific verb and resource ('Creates a one-time page on the LinkDrop site where the signed-in person adds a PDF') and immediately clarifies the scope difference from a direct upload: the agent has no network/file access, the person supplies the PDF through their browser. That framing alone separates it from lnkdrp_create_upload and lnkdrp_stage_pdf.

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

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

Gives strong when-to-use context ('works in every client, with no network access from the agent's environment; needs the person to open the link') and names one alternative for the publisher failure path (lnkdrp_stage_pdf adds a draft instead). It never explicitly names lnkdrp_create_upload as the contrasting direct-upload path, so the sibling routing is implied rather than stated.

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

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

Goes well beyond the annotations (destructive=true, idempotent=true): it discloses the permission model (only the document owner or link creator can decide), rate and reversal limits matching the app, the side effects of each branch (approve emails a download link or offers the latest version; deny notifies the requester), and repeated untrusted-content warnings about the requester's note and result text. This is exactly the added context annotations cannot carry.

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

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

The core action and addressing are front-loaded, and each subsequent sentence carries distinct value (permissions, limits, branch effects, untrusted content). It is dense and long, but there is little that could be cut without losing behavioral disclosure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must carry the full burden; it does. It covers who may decide, what each decision causes, the confirmation prerequisite, refusal behavior, rate limits, reversibility, and untrusted-content handling — everything an agent needs to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning by framing notificationId and request.requestId as alternative addressing handles both sourced from lnkdrp_get_notifications, clarifying their relationship rather than restating types.

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

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

States a specific verb pair (approves or denies) on a specific resource (one download request waiting for the person), and distinguishes itself from siblings like lnkdrp_confirm_action and lnkdrp_check_approval by its subject matter. The addressing keys (notificationId / request.requestId) are named up front.

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

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

Gives clear context: IDs come from lnkdrp_get_notifications, the person must confirm in lnkdrp's own prompt, and there is no confirm flag. It even states the negative condition — a client that cannot show the prompt cannot decide and the call refuses. It does not name an explicit alternative tool beyond the notification source, so it stops short of a full 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered, and the description does not contradict them. However, it adds nothing behavioral beyond the alias and a glossary gloss: it never says deletion is permanent or that lnkdrp_restore_drop can undo it, nor that the confirm/confirmationToken preview flow is expected before the call.

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

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

Two sentences, front-loaded with the equivalence claim that an agent needs first. The glossary sentence is long-ish but earns its place by resolving a non-obvious domain term that appears in many sibling names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations carry the destructive/idempotent profile and the schema fully documents the confirmation workflow, so the coverage gap is narrow. Still, for a destructive tool with no output schema, the description should at minimum state that the drop is deleted and point to lnkdrp_restore_drop as the recovery path; neither is present.

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

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

Schema description coverage is 100% — campaignId, confirm, confirmationToken and alwaysAllow are all documented inline, including where campaignId comes from. The description adds nothing about parameters, deferring instead to the sibling ("the same arguments"), which is a baseline-3 outcome rather than added meaning.

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

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

The description never states directly that this deletes anything; it defines the tool only by equivalence ("Same as lnkdrp_delete_drop, under its earlier name") and then defines the domain term "drop". An agent must open the sibling definition to learn the effect. The aliasing relationship is conveyed clearly, which is real value, but the verb+resource statement is absent.

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

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

"Same arguments and the same answers" implies the two delete tools are interchangeable, but the description gives no explicit when-to-use guidance and no exclusion (e.g. "prefer lnkdrp_delete_drop; this name is kept for older clients"). No mention of the sibling restore path or of prerequisites.

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

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

Annotations already mark it destructive, non-read-only and idempotent, but the description adds substantial context the annotations cannot: exactly what is removed (sources, history, note, tags, reader summary/profile), what is kept (document analytics and share stats), irreversibility, the fact that old activity does not rebuild the contact, that share links keep working, and the confirmation prompt behavior.

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

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

It opens with the action and identifier, then front-loads removed-vs-kept before the softer details. It runs about nine sentences, which is long, but nearly each one carries a distinct behavioral fact rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description covers the full decision surface an agent needs: scope, irreversible consequences, preserved side effects, error semantics (not_found), re-creation path, and the untrusted-content caveat. Nothing material is left unstated.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and the baseline is 3. The description adds value by explaining the confirmation workflow ('asks the person to confirm before it acts') that motivates confirm/confirmationToken, and by reaffirming contactId's origin, pushing it above baseline.

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

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

States a specific verb and resource ('Deletes one contact ... from the workspace's contacts') and pins down the identifier source ('by contactId, from lnkdrp_list_contacts'). It is clearly distinguishable from siblings like lnkdrp_update_contact or lnkdrp_list_contacts without opening a schema.

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

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

Gives clear context: it is for removing one contact, notes the not_found case (already deleted or not in the workspace), and points to lnkdrp_add_contact as the path to re-introduce someone. It stops short of explicitly contrasting with sibling mutations (e.g. why not update_contact), so it falls just short of the when/when-not bar.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description still adds real value: permanence, that contacts/links/history are preserved, that a preview confirmation showing list name and contact count is required, and the not_found behavior for out-of-workspace ids. It omits the response shape and any permission requirements, keeping it below a 5.

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

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

Four short sentences, front-loaded with the action and its permanence, then the non-obvious side effects and the confirmation/error behavior. Nothing is repeated and every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, no-output-schema tool with fully documented parameters and rich annotations, the description covers consequences, confirmation requirements, and a known error case. It could still say what the success response contains, but an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes slightly beyond by explaining that the confirmation is a preview the person sees with the list's name and contact count, which gives meaning to the confirm/confirmationToken/alwaysAllow trio. It adds no format or fallback guidance for listId beyond what the schema's pattern already says.

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

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

States a specific verb and resource ("Deletes a contact list permanently") and clarifies that member contacts and their links/history survive, which separates it from destructive contact operations. It never names a sibling tool (e.g. lnkdrp_remove_contact_list_members or lnkdrp_delete_contact), so differentiation is inferred rather than explicit.

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

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

The use case (permanently removing a list) is implied by the verb and the confirmation flow described, but there is no explicit when-to-use/when-not guidance or pointer to alternatives such as unarchiving, editing, or removing members only. An agent must infer which tool to pick from the name alone.

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

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

Annotations only give destructiveHint/idempotentHint/openWorldHint; the description goes well beyond by disclosing the immediate link-breakage, the exact 30-day purge window, precisely what is destroyed (file, versions, links, analytics), and the confirmation/undo model. It stays fully consistent with the destructive annotation.

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

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

Front-loads the action, then consequences, then alternatives, then the confirmation and trust note. Every sentence carries distinct information with no hedging or repetition, despite covering a lot of ground.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, the description supplies the full picture: reversibility window, sibling alternatives, the human confirmation flow that gates the call, and an untrusted-content caveat for returned text. Nothing material an agent needs to invoke this safely is missing.

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

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

Schema coverage is 100%, so the schema already documents all four parameters (baseline 3). The description adds the workflow context behind confirm/confirmationToken/alwaysAllow by describing the preview that shows 'the document, its links and their traffic,' which is more than the schema alone conveys.

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

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

Opens with a specific verb+resource ('Deletes a document') and immediately scopes the effect ('disappears from the workspace and every share link on it stops resolving'). It also names the two most confusable siblings (lnkdrp_restore_doc, lnkdrp_archive_doc) and their distinct behaviors, so an agent can differentiate without opening schemas.

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

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

It lays out the alternative paths clearly: restore brings it back within 30 days, archive takes links offline while keeping analytics and is reversible. That gives strong context for choosing delete vs archive, though it never states the selection rule outright ('use archive when you want to keep analytics') or any hard prerequisite.

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

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

Adds substantial context beyond the annotations: soft-delete with a 30-day retention window and purgeAt, restoration path, that sent emails and share links are unaffected, and that a confirmation preview with name/state/send-count is shown first. Also discloses the exact error discriminators (campaign_sending, not_found for cross-tenant ids).

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

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

Dense but every sentence carries information; the only inefficiency is that the resource definition precedes the action so the verb 'Deletes' is not front-loaded. Errors are grouped at the end in a logical order.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, the definition covers lifecycle, recovery, side effects, confirmation flow and failure modes. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100% and the schema documents all four parameters, so the baseline is 3. The description's mention of the confirmation preview and its token loosely contextualizes confirm/confirmationToken, but adds no new constraints or formats beyond the schema.

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

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

States a specific verb and resource ('Deletes a drop (a campaign in the API)') and defines what a drop is, so an agent can map the term to the resource. It does not differentiate itself from the sibling lnkdrp_archive_drop, which presumably is the softer alternative, so the sibling discrimination is incomplete.

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

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

Gives clear conditions and consequences ('kept 30 days in Recently deleted, where lnkdrp_restore_drop brings it back') and names the state in which the call is rejected (campaign_sending), which lets the agent judge applicability. It never states when to prefer archive_drop over delete, which is the main remaining gap.

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

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

The description goes well beyond the destructiveHint annotation by explaining that templates and already-sent emails will show broken images, that cached copies may persist up to a day, and that affected template saves fail with image_not_an_asset. It also discloses the confirmation preview behavior and the not_found condition for images outside the workspace.

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

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

The description is front-loaded with the action and its main consequence, then adds useful operational details. It is somewhat long, but each sentence carries relevant destructive-impact or confirmation context, with little obvious waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, idempotent delete operation with no output schema, the description covers the consequences, confirmation flow, and error behavior thoroughly. An agent has enough information to invoke it correctly and understand the impact.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds only marginal meaning, such as the not_found behavior for assetId and the confirmation preview context, but does not need to compensate for schema gaps.

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

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

The description states a specific verb and resource: deletes one uploaded email image and its file. It distinguishes the tool from sibling operations like deleting templates or renders by scoping it to email image assets, and the title reinforces this.

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

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

The usage context is clear: use this when removing an email image asset, with warnings that templates referencing it cannot render or send until it is removed. It does not explicitly name alternatives or exclusions, but no direct sibling alternative exists for this specific asset deletion.

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

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

Annotations already flag destructiveHint and idempotentHint, yet the description adds substantial non-obvious behavior: the preview page is removed, the share link and already-sent mail survive, and a confirmation prompt shows recipient/subject/sent status. It also discloses error semantics (not_found for expired/foreign renders, forbidden with details.code needs_person and a resolveUrl for locked emails), which no annotation conveys.

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

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

Front-loads the destructive effect in the first sentence, then layers side effects, confirmation, and error codes in descending priority. The parenthetical explanation of a locked email is slightly convoluted but earns its place by making an otherwise cryptic error actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, it covers side effects, the confirmation flow, and failure modes well. It does not describe the shape of a successful response beyond the act of deletion, leaving that inferred.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the confirmation preview that the confirm and confirmationToken parameters correspond to. It does not restate constraints on alwaysAllow or renderId format (left to the schema), which is appropriate.

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

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

States a specific verb and resource ("Deletes one rendered email permanently, with its preview page") and immediately disambiguates scope by saying the recipient's share link is untouched, which separates it from the delete_share_link sibling. An agent can tell exactly what is being removed versus preserved.

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

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

Clearly frames the deletion context and the confirmation precondition ("LinkDrop asks the person to confirm before it acts"). It does not name sibling alternatives such as delete_email_asset or delete_email_template and when to prefer them, so it stops short of full when/when-not guidance.

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

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

Goes well beyond the destructiveHint/idempotentHint annotations: it discloses the 30-day retention window, the purgeAt permanent removal point, and that rendered emails and share links are unaffected. It also documents the confirmation preview flow and the not_found cross-workspace case, which is exactly the side-effect and error context an agent needs before a destructive call.

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

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

Front-loaded with the core action and lifecycle, then side effects, then the confirmation behavior. Five dense sentences with little filler, though the rendered-emails/share-link sentence could be tightened slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a destructive mutation, the description covers retention, revert path, collateral effects, confirmation preconditions, and the error case. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by explaining the two-step confirmation model ('asks the person to confirm before it acts') that gives meaning to the confirm/confirmationToken pair beyond their field descriptions. It also states what the preview shows, which the schema does not.

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

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

States a specific verb and resource ('Deletes an email template') and immediately clarifies the soft-delete lifecycle, so the agent can distinguish it from a hard purge. It does not explicitly contrast with lnkdrp_archive_email_template or lnkdrp_discard_email_template_draft, which are the nearest ambiguous siblings, so it falls short of full sibling differentiation.

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

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

It names lnkdrp_list_deleted and lnkdrp_restore_email_template, but as descriptions of the aftermath rather than as alternatives for the agent to choose between. There is no explicit 'use this instead of X when Y' guidance, so the agent must infer when deletion is preferred over archiving.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them: exactly what is destroyed (public page, project links) versus preserved (documents, their links and analytics), the 30-day reversibility window, permanent purge after, and the confirmation preview flow. This is the level of disclosure a destructive, open-world mutation needs.

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

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

The delete action and its scope are front-loaded, then restore window, alternative, tier effect, and confirmation flow follow in a tight sequence with no filler. It is dense but every sentence carries actionable information; only the trailing untrusted-content note reads as boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, no-required-param tool with no output schema, the definition covers effect on related resources, reversibility and its time limit, downstream purge, tier impact, the confirmation mechanism, and the sibling alternative. An agent has everything needed to invoke it correctly and warn a user.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning the schema does not: it explains that LinkDrop shows a preview (project, document count, public-page status) before acting, which is what confirm and confirmationToken refer to, tying the parameters to a concrete human-in-the-loop flow.

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

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

The description opens with a specific verb+resource ("Delete a project") and immediately delineates scope: documents survive, the project and its links stop resolving. It is easily distinguished from lnkdrp_remove_doc_from_project and lnkdrp_restore_project without opening any schema.

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

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

It names two alternatives and the conditions that select them: lnkdrp_restore_project for undo within 30 days, and lnkdrp_remove_doc_from_project when only single documents should leave while the project stays. It also states the Free-tier consequence, giving an agent enough to decide whether deletion is the right call.

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

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

Annotations already declare destructive/idempotent/openWorld, and the description still adds substantial non-redundant behavior: the link dies immediately, the recipient's view shows nothing about the project, past analytics are preserved, the recipient loses access to all documents, and the default-link deletion fails with a validation error. It also discloses the human confirmation preview before the action runs.

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

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

Six sentences, front-loaded with the core action and its immediate effect before moving to alternatives and constraints. Dense and mostly earning its place, though the closing untrusted-content caveat is generic boilerplate that slightly pads the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a destructive 6-parameter tool with no output schema: irreversible-effect semantics, undo path, revoke-without-delete alternative, the default-link exception, and the confirmation requirement are all covered. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds context for the confirm/confirmationToken/alwaysAllow flow by explaining that LinkDrop shows a preview of the link and its traffic before acting. It does not explain the projectId/projectSlug alternation beyond what the schema already says, so it stays short of a 5.

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

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

States a specific verb and resource ('Delete one project link') and immediately clarifies scope by naming what survives (analytics kept in totals) versus what is lost (recipient access to every document). This is clearly distinguishable from sibling link tools such as lnkdrp_update_project_link and lnkdrp_delete_project.

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

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

Explicitly names the two alternatives and the conditions that select them: lnkdrp_restore_share_link for a reversible restore, and lnkdrp_update_project_link with enabled:false to revoke access while keeping the link listed. It also states the when-not case (default links cannot be deleted, only disabled) with the reason.

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

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

Annotations already declare destructive/idempotent/openWorld, yet the description adds substantial context beyond them: the link stops resolving immediately, past analytics are preserved in document totals, the shareId becomes unaddressable, the default-link validation error, the confirmation preview showing link and traffic, and the untrusted-content warning for author/viewer text. This is exactly the extra disclosure the destructive hint cannot carry.

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

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

The destructive action and its immediate effect are front-loaded in the first sentence, and the remaining clauses each carry distinct information (analytics retention, restore path, default-link exception, confirmation, trust warning). The later sentences are dense and slightly run-on, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter destructive tool with no output schema, the definition covers effect, post-deletion state, retention of analytics, reversibility, the only hard failure case, and the human-confirmation interlock. An agent has everything needed to call it correctly and warn the user appropriately.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains that analytics remain readable by docId after deletion, and it describes the confirm-before-acting flow that gives purpose to the confirm/confirmationToken/alwaysAllow parameters (which the schema only names). linkId's provenance is left to the schema description.

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

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

Opens with a specific verb+resource: 'Delete one share link.' It then immediately bounds the scope ('one share link', 'a document's default link cannot be deleted'), which lets an agent distinguish it from lnkdrp_delete_doc, lnkdrp_delete_project_link, and lnkdrp_restore_share_link without opening any schema.

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

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

Provides an explicit when-not case ('A document's default link cannot be deleted (validation error); it can be disabled') and names the inverse operation (lnkdrp_restore_share_link), so the agent knows both the exclusion and the recovery path. It lacks an explicit positive 'use this when...' statement, but the effect description plus the named alternative covers the routing decision well.

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

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

Adds far more than the destructive/idempotent annotations: storage stops counting immediately while files are removed later by the drafts purge (with lnkdrp_get_pending_purges / purgeEnabled named), the authorization model with the specific forbidden/not_your_draft error code, the notification side effect to the draft owner by app and email, and the confirm-before-acting preview flow. Return shape is also disclosed.

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

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

Front-loaded with the action and its immediate consequences, and nearly every sentence carries non-obvious information. It is a dense, slightly run-on single paragraph with nested parentheticals ('lnkdrp_get_pending_purges, the drafts bucket's purgeEnabled') that interrupt scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, permission-gated mutation with no output schema, the description covers consequences, delayed cleanup, reversibility, who may call it, the failure mode, side effects on third parties, the confirmation flow, and the returned object. Nothing an agent needs before invoking it is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by documenting the uploadId fallback chain, which the schema's own text does not describe, and by tying reason to where it surfaces ('Discarded row', owner notification, 500-char cap). The confirm/confirmationToken/alwaysAllow params are left entirely to the schema.

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

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

States a specific verb and resource ('Discards a draft (lnkdrp_stage_pdf)') and immediately scopes it against the obvious confusion points: 'The live version and every link are untouched', which separates it from delete_doc/remove_latest_version. An agent can distinguish it from publish_draft, get_draft and delete_doc 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.

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

Gives concrete selection logic for the key ambiguity ('uploadId names the draft; without it, this connection's own open draft, else the only open one') and states irreversibility with the alternative ('staging the file again makes a new draft'). It never names a sibling tool as the alternative action (e.g. publish_draft), so routing is strong but not explicit.

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

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

The description adds substantial behavioral detail beyond the annotations: immediate deletion of the draft text, unchanged live template, 90-day audit record, author notification in-app and by email, optional note shown to the author, irreversibility, and a confirmation preview. These details are exactly what an agent needs to understand the destructive and social consequences of invoking the tool.

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

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

The description is dense but front-loaded with the core action and its consequences. Most details earn their place for a destructive tool, though the single long paragraph could be structured more clearly for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-output-schema tool, the description covers the essential context: effects on draft and live template, retention, authorization rules, notification behavior, confirmation flow, draftId fallback, and return value. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description reinforces the optional note's 500-character limit and visibility to the author, and explains the draftId fallback behavior, but this largely repeats schema-provided information rather than adding new parameter meaning.

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

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

The description states a specific verb and resource: discarding an email template draft, and clarifies that only the draft text is deleted while the live template is unchanged. It is clear enough to distinguish from neighboring template tools, though it does not explicitly name alternatives such as publish_email_template_draft or the generic discard_draft.

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

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

It explains who may discard a draft (its author or anyone who may publish the template) and how draftId is defaulted, which is useful context. However, it does not explicitly compare this operation with alternatives like publishing, deleting, or archiving a template, so guidance is implied rather than complete.

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

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

Consistent with the read-only/idempotent annotations ('It changes nothing in Drive or LinkDrop') and adds substantial context the annotations cannot convey: result cap (10), ordering (newest first), duplicate-name caveat, the exact failure modes drive_not_connected and drive_not_granted with their remediation URLs, and an untrusted-content warning about document-authored titles and text.

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

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

Front-loads the purpose, consumption targets, and scope in the first sentences, then the return shape, then error modes. Dense and largely waste-free, though the two failure-mode sentences are lengthy relative to the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully specifies the return object (file fields, kind enum, googleEmail) and enumerates the error modes with remediation, so an agent has everything needed to invoke and interpret results.

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

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

Schema description coverage is 100%, so the query parameter's syntax and empty-string behavior are already documented; the description reinforces the search semantics and adds the non-obvious alternative that a pasted link is accepted as driveFileId, which is meaning beyond the schema.

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

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

States a specific verb (find/search) and resource (files in the person's own Google Drive) with explicit scope ('the person's own Google Drive, through the Drive connection they made on LinkDrop's Integrations page') and clarifies 'This tool only lists files.' It also distinguishes itself from downstream siblings by naming lnkdrp_share_pdf and lnkdrp_replace_pdf as consumers of the returned driveFileId.

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

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

Clearly states when to use it (finding a file to import into LinkDrop) and notes the alternative path where a pasted Drive/Docs/Slides/Sheets link is accepted as driveFileId with no search. It does not explicitly exclude other scenarios beyond 'only lists files', so it stops just short of full when/when-not routing.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, which is surprising for something called a 'dry run', yet the description never clarifies whether anything is actually sent or mutated. It does add useful domain context about what a drop is, but leaves the central behavioral question (side effects, idempotency) unaddressed.

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

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

The alias relationship is front-loaded in the first clause, which is the most important info. The second sentence defining 'drop' is long and somewhat tangential to the dry-run operation, but still earns its place as domain context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-read-only, open-world tool with no output schema, the description omits the essential details: what a dry run produces and whether it has side effects. The drop definition does not compensate for the missing operational description.

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

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

Schema description coverage is 100% and both parameters are fully documented with sources and formats, so the schema carries the burden. The description adds no parameter meaning beyond 'same arguments', which is the expected baseline.

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

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

The description states that this is the alias of lnkdrp_dry_run_drop with identical arguments and answers, which helps distinguish it from the many siblings. However it never says what a dry run actually does – it only defines the domain term 'drop'. The operation's purpose is left to be inferred from the name.

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

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

By declaring 'same as lnkdrp_dry_run_drop, same arguments and same answers', it implies the two are interchangeable and routes the agent to the canonical tool. It gives no explicit when-to-use/when-not or preference ordering between the alias and the canonical name.

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

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

Discloses behavior far beyond the annotations: nobody on the drop is marked and no count or state changes, which reconciles why destructiveHint is false while readOnlyHint is also false (an email is still emitted). It enumerates skip outcomes (missing_tags, a link switched off), refusal codes with their details payloads (plan_limit/upgradeUrl, gmail_not_connected/connectUrl, rate_limited with dry_run_daily_limit or gmail_daily_limit, not_found), the no-Cc rule, and the fact that titles and viewer-supplied text are untrusted author-written content. No annotation contradiction.

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

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

It is a single dense block, but it is front-loaded: the what (dry run to the owner's Gmail) and the identifying detail (contactId default) arrive in the first two sentences. Nearly every later sentence carries distinct decision-relevant information (quota, skip paths, refusal codes), though the lead-in explanation of what a drop is could be trimmed for callers who already know the domain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a side-effecting send with no output schema, the description supplies everything an agent needs: permissions, quota cost, template version selection, default parameter behavior, skip semantics, and a full refusal taxonomy. Nothing material about calling it correctly is left undocumented.

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

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

Schema coverage is 100%, so both parameters are already documented; the description still adds operational meaning by stating contactId selects the person and defaults to the first in send order, and that campaignId is the drop's id. It adds little on the 24-hex format beyond the schema, but the default-selection semantics are worth having in prose.

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

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

Opens with a concrete verb+resource: sends one person's email of a drop, rendered as the drop renders it, to the owner's own Gmail as a dry run. It even disambiguates the domain vocabulary ('a drop (a campaign in the API)'), which helps separate it from campaign tooling. It stops short of naming the sibling dry-run tools (lnkdrp_dry_run_campaign, lnkdrp_dry_run_email) or lnkdrp_send_drop, so the agent must infer the choice from context rather than being routed explicitly.

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

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

Gives clear conditions for correct invocation: the drop's owner must call it (forbidden otherwise), contactId defaults to the first person in send order, and pre-Send uses the published template while post-Send uses the frozen version. It also sets expectations that dry runs consume quota (25 per 24h, 50 Gmail sends). What it lacks is an explicit 'use X instead when...' clause pointing at the real send or the other dry-run variants.

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

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

Adds substantial behavior beyond the annotations: the band and subject prefix, that no Cc is carried, that batches of 2–100 are queued one at a time with a batchId returned, the 25-per-24h and 50-Gmail-send caps, and an enumerated list of refusal codes with their detail fields. This is unusually rich disclosure for a mutation tool.

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

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

The purpose is front-loaded, but the middle is a dense run-on with multiple clauses compressed into single sentences and a stray 'One email is sent at once' fragment. Every fact is relevant, but the packaging makes it 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still covers what the agent needs on return — status queued plus batchId for batches — and enumerates every documented refusal path with its detail fields. Nothing material for correct invocation is missing.

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

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

Schema coverage is 100%, so 3 is the baseline, but the description adds real meaning: bandText's default is spelled out and its override chain described, and 'to: me' vs 'to: recipients' gets concrete destination semantics. renderIds sourcing is also implied via lnkdrp_render_email.

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

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

States a specific verb and resource — sends dry-run copies of rendered emails from the connected Gmail account — and immediately distinguishes itself from a real send by noting 'Nothing is marked sent and the emails stay sendable.' That is enough for an agent to separate it from lnkdrp_send_email or lnkdrp_render_email.

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

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

Explains the two modes precisely, including the prerequisite that 'to: recipients' only works when every recipient is on a dry-run list set by an owner or admin, and points to lnkdrp_get_contact_list's dryRun for that check. It does not explicitly name the sibling it replaces (lnkdrp_send_email), so it's clear context without full alternative routing.

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

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

Annotations already declare non-read-only, non-idempotent, non-destructive behavior, so the bar is lower. The description does contribute real domain context — a drop sends a template from the member's own Gmail to recipients and their contact lists with per-person tracked links — which tells the agent a duplicate spawns a sendable object with tracking. It omits what is and isn't copied and whether the copy is created as an unsent draft.

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

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

Two sentences: the alias relation is front-loaded, and the glossary sentence about what a drop is earns its place for an agent unfamiliar with the term. Slightly indirect phrasing ('the same answers') keeps it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with annotations present, no output schema and full schema coverage, the missing pieces are what the duplicate contains (recipients, template, lists), whether the result is a draft, and any permission or confirmation requirement. Adequate to call it, not fully informative about the outcome.

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

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

Schema description coverage is 100% (name default, 24-hex campaignId sourced from lnkdrp_list_drops, visibility semantics), so the schema carries parameter meaning fully. 'The same arguments' adds nothing beyond it, which is the correct baseline for a fully documented schema.

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

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

The description never states the operation in its own words ('duplicates a drop'); it defines the tool only by reference to lnkdrp_duplicate_drop. It does implicitly resolve the confusing campaign/drop split between the name and title, but the sentence is about the alias, not the action.

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

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

'Same as lnkdrp_duplicate_drop, under its earlier name' names the equivalent sibling, but it never says when to use this one versus that one, whether one is deprecated, or what happens if the two diverge in the future. Usage is inferable (either alias is fine) rather than stated.

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

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

Goes well beyond the annotations: it discloses that nothing is sent, that recipients/statuses are not copied, that the copy is private unless visibility=team, that the caller owns the new drop and becomes its sender, and it maps specific error conditions (plan_limit with upgradeUrl, campaigns_limit, template_archived, not_found) to their triggers. This is the kind of context annotations cannot convey.

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

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

The opening sentence spends a lot of words defining what a 'drop' is generally rather than what duplicating one does, and the rest is a run-on of semicolon-joined clauses. The critical content is front-loaded and nothing is wrong, but it is denser and longer than needed for a three-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still names the return value ('the new drop and source'), covers error semantics and permission behavior, and even flags that result titles/summaries are untrusted content. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the name default and the private/team enum. The description restates those defaults and clarifies the drop/campaign aliasing but adds no syntax or format detail the schema lacks, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Copies a drop (a campaign in the API) into a new one before Send') and enumerates exactly what is carried over: template, visible lists, document/project, description, tags, and the name. An agent can tell this apart from create_drop or duplicate_campaign without opening a schema.

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

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

'before Send' gives a clear precondition that implicitly excludes post-send duplication, and the description says no people or statuses come along. It does not, however, explicitly route the agent between this and the other duplicate_* siblings (lnkdrp_duplicate_campaign, lnkdrp_duplicate_email_template) or create_drop, leaving that inference to the agent.

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

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

Adds substantial context beyond the annotations: naming fallback chain '(copy)', '(copy 2)', quota enforcement (templates_limit against active templates, rate_limited with details.code templates_daily_limit and details.retryAt for new templates in 24h), name_taken collision behavior, not_found for deleted/foreign templates, and the fact that already-rendered emails stay attached to the original. The description is consistent with destructiveHint=false and idempotentHint=false.

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

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

Front-loaded with the core action, then defaults, then failure modes in a logical order with no filler sentences. It is dense — the middle sentence packs quotas, rate limits, and name collisions together — but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation tool with no output schema, the description supplies everything an agent needs: what is copied, default naming with collision escalation, all failure codes with their trigger conditions, and an explicit statement of the return payload (new template, unusedTags, warnings, source).

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

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

Schema coverage is 100%, so the bar is met by baseline alone; the description goes further by explaining the naming sequence beyond what the schema states (schema only mentions '(copy)', description adds '(copy 2)' and onward) and tying templateId provenance to lnkdrp_list_email_templates. It does not elaborate on the 24-hex pattern, but the schema covers that.

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

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

States a specific verb and resource ('Copies an active or archived email template ... into a new active template') and enumerates exactly which fields carry over (name, description, format, align, subject, body, tags). This clearly separates it from lnkdrp_create_email_template (which builds from scratch) and from update tools, without needing to open the schema.

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

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

The description implies the appropriate situation (you have an existing template you want a working copy of, active or archived) and warns about the workspace cap and daily limit. However it never explicitly contrasts itself with lnkdrp_create_email_template or states when duplication is preferable to creating fresh, so the agent must infer that choice.

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

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

Annotations already establish the safe read profile, and the description layers substantial extra behavior: MongoDB text-index ranking with whole-word-only matching, exclusion of archived/deleted docs, the two link kinds and their differing fields, null docId on project links, error code contact_not_found, and [] instead of an error on no match. It also flags viewer-authored text as untrusted. This is well beyond annotation coverage.

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

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

Purpose is front-loaded, but the body is a dense, run-on block mixing search semantics, hit-field documentation, contact rules, and error handling in a single sprawling paragraph. Much of it is useful, yet it is not well segmented and could be tightened considerably.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full return-value burden and discharges it: it documents hit fields (status/enabled/expiresAt, sentAt/sentVia/firstOpenedAt/timeToFirstOpenMs, contact role, docId/docTitle vs projectId/projectName) and both success and failure behavior. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% (baseline 3), but the description adds real meaning: query targets label/audience not title/shareId, whole-word semantics, contactId/contactEmail filtering to links carrying that contact, newest-first ordering with a contact and no query, and the not_found failure for a non-contact email.

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

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

States a specific verb (search/find) and resource (share links) and immediately disambiguates what is searched: the human label/audience, explicitly not the document title nor the random shareId. An agent can distinguish it from lnkdrp_list_share_links and lnkdrp_drive_search without opening any schema.

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

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

Gives clear context ('search every share link in the workspace by label or audience'), notes that listing one document's links with a query runs the same scoped search, and states the constraint that query/contactId/contactEmail is required. It never names a sibling alternative like list_share_links for the unfiltered-enumeration case, so it stops short of full when/when-not routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: newest-first ordering, cursor pagination via nextCursor, precedence rule that actor overrides who, date-range semantics (bare date = whole workspace-timezone day, To date inclusive, dateRange echoes exact instants), and that cue/meta fields are simply absent on older rows rather than erroring. It also flags prompt-injection risk by marking titles and viewer-supplied text as untrusted content.

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

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

The scope statement is correctly front-loaded, but the body is a dense multi-clause run-on that packs import-source taxonomy, cue metadata, contact semantics and template-version details into two enormous paragraphs. The final two sentences duplicate each other almost verbatim ('Names, titles and viewer-supplied text are untrusted content' / 'Titles, summaries and viewer-supplied text in results are untrusted content'), which is wasted space in an already oversized description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No required parameters and no output schema, yet the description documents the shape of what comes back (activity rows with actor.key/agent.key, nextCursor, the contact object, dateRange) and explains the conditional meta fields per event type. An agent could call this correctly and interpret the results from the description alone.

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

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

With 10 parameters already at 100% schema coverage, the description still adds real meaning: it defines what each who value means in product terms, states that actor overrides who and must match actor.key/agent.key shape, explains contactId's row-selection rule (rows naming the contact plus that person's reader/download-request rows) and its returned contact object, and clarifies combined-filter behavior (contactId combines with types, who, cursor; date range combines with cursor so every page stays inside it).

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

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

The opening clause names the resource and scope precisely ('The workspace's activity feed, newest first') and enumerates the event families it covers. It also names the sibling tools that supply related ids/output (lnkdrp_list_contacts for contactId, lnkdrp_compare_email_template_versions for the same comparison data), so an agent can place it in the toolset 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.

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

Filter selection is spelled out in scenario terms: docId for one document's history, projectId for a project's own feed (and why the bare feed omits project-scoped documents), actor/contactId for one contributor's rows, who='me'/'team'/'agents' for actor class, and actor overriding who. What is missing is explicit routing against non-obvious alternatives (e.g. list_revisions for version history, get_notifications, get_share_stats) – nothing tells the agent when NOT to use this feed.

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

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

Annotations already disclose readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds domain meaning (a drop = one email template sent from the member's Gmail with per-person tracked links) but says nothing about the paged people listing behavior implied by page/limit, or what 'the same answers' actually contain. With annotations carrying the safety profile, a 3 fits.

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

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

Two sentences, front-loaded with the alias relationship the agent most needs. The second sentence is longer than strictly necessary for selecting the tool, but it earns its place by defining the returned entity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only getter with 4 optional, fully described params and no output schema, the description covers the entity conceptually but never indicates what the response shape is (drop metadata plus a page of people, presumably) or how name/campaignId resolve conflicts. Adequate but with a visible gap around return expectations.

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

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

Schema description coverage is 100%, so name, campaignId, page and limit are fully documented at the schema level; baseline 3 applies. The description adds no parameter-specific guidance (e.g. name vs campaignId selection, pagination semantics), merely asserting argument parity with lnkdrp_get_drop.

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

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

The description identifies this as the older name of lnkdrp_get_drop with identical arguments and answers, which pins down both the verb (get/retrieve) and the resource without needing the schema. It then defines what a drop is entity-wise. It loses a point only because the action verb itself is inherited by reference to a sibling rather than stated directly.

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

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

Explicitly tells the agent this tool is interchangeable with lnkdrp_get_drop ('the same arguments and the same answers'), which effectively resolves the alias/duplicate ambiguity among the ~120 sibling tools. It does not state when to prefer one name over the other, but for a pure alias those exclusions are moot.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantially beyond that: deleted documents persist in sources and docs with deleted:true for 30 days so reads and visits keep accumulating, then drop at purge; live documents carry no deleted field; links are capped at 100 with linksTotal giving the real count and viewCount is per-link not per-contact; profile is a stored research result that contacts no outside source; pending is true only while research is queued or running. It also flags untrusted content boundaries, which is operationally important.

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

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

The first clause is front-loaded and correct, but the body is one dense run-on block of nested field explanations with no breaks, mixing return-shape documentation, business rules, and safety notes. Almost every sentence carries real information (justified by the absence of an output schema), so the length is defensible, but the structure makes it hard to scan and re-read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description is the only specification of the response, and it covers the significant structures: identity, sources with attribution semantics, lastEmail with status and failure reasons, links with role/viewCount/limit, profile lifecycle statuses, and the 30-day deleted-document behavior. An agent can reason about the result without guessing.

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

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

A single parameter with 100% schema coverage, so the baseline is 3. The description only adds provenance ('from lnkdrp_list_contacts'), not format or constraint information beyond the schema's 24-hex-char pattern. Adequate, not additive.

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

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

Opens with a specific verb+resource+scope: 'One contact by id (from lnkdrp_list_contacts)', immediately separating it from the bulk lnkdrp_list_contacts sibling and pointing at where the id comes from. It then enumerates exactly what the single record contains (identity, sources, docs, tags, note, links, profile). It stops short of explicitly contrasting with lnkdrp_update_contact or lnkdrp_get_activity, but the read-one-record purpose is unambiguous.

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

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

Usage is implied by the parenthetical id source and by the explicit exclusion 'This tool does not start or refresh research', which routes research initiation elsewhere. It also names lnkdrp_restore_doc as the path for restoring purged documents. But there is no direct 'use this rather than X when Y' statement versus siblings like lnkdrp_list_contacts or lnkdrp_get_activity, leaving the agent to infer the choice.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantive behavior on top: deleted contacts excluded, page-based totals where list.memberCount equals total, canChangeVisibility meaning, createdBy 'Former member' handling, dropCount nullability, and untrusted-content wrapping. It stops short of auth requirements or ordering, and repeats the untrusted-content warning in two places.

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

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

The core purpose is front-loaded, but the body is one dense paragraph that mixes return-field semantics, sibling routing, error states and a security caveat with no structure. The untrusted-content warning is stated twice, and several clauses could be trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the return shape: member fields, visibility, owner, createdBy, labels, projects and dropCount with its null case. An agent could call this correctly from the description alone; only ordering of members and empty-page behavior are left unstated.

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

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

Schema coverage is 100%, so page, limit and listId are already documented in the schema, making 3 the baseline. The description adds only modest value beyond that, clarifying that pagination is page-based and that list.memberCount equals total, rather than explaining limit/page interaction or defaults.

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

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

Opens with a specific verb+resource: one contact list plus a page of its members, with the four returned member fields named. It implicitly distinguishes itself from the plural lnkdrp_list_contact_lists by 'One contact list' and routes to lnkdrp_list_drops/lnkdrp_tag. An explicit statement of the sibling alternative would push this to a 5.

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

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

Gives real chaining guidance: a member's contactId is what lnkdrp_render_email takes (one render per member), tags come from lnkdrp_tag with listId, drops from lnkdrp_list_drops with listId. It also states the exclusion case that another person's private list returns not_found, but never says when to prefer lnkdrp_list_contact_lists instead.

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

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

Annotations already cover read-only/idempotent safety, but the description adds substantial behavioral context: discarded/expired retention for 90 days, purge behavior, publishing permissions including paid-plan pause behavior, stale/unchangedFromLive flags, outcome shapes, and untrusted-content warnings. It does not contradict the annotations and adds a great deal beyond them.

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

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

The purpose is front-loaded, but the description is a very long, dense paragraph with nested parentheticals and field-by-field return details. Much of the detail is useful because there is no output schema, but its structure makes it harder to scan than a well-sectioned definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the full return-shape burden, and it does so extensively: draft statuses, compare fields, publishing rules, outcome objects, counts, pagination, and untrusted-content caveats are all covered. For a read-only tool with six optional parameters, this leaves little essential context missing.

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

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

Schema coverage is 100%, so the schema already defines each parameter, but the description adds inter-parameter meaning: uploadId returns a specific draft in any state, mine selects only this connection's own open draft, status switches between open/published/discarded lists, and offset pairs with nextOffset. That is meaningful context beyond the schema, though it does not explain every parameter in depth.

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

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

States a specific verb and resource (reads a document's drafts) and immediately distinguishes drafts from staged files and versions by naming lnkdrp_stage_pdf and noting drafts are not listed by lnkdrp_list_revisions. The with/without uploadId behavior is also described clearly enough that an agent can tell what the tool will return.

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

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

Explains the alternative paths well: with uploadId for one draft in any state, without uploadId for own/only/all open drafts, and status published/discarded for historical lists. It also points to lnkdrp_recompare_draft and lnkdrp_get_pending_purges for follow-up actions, though it does not explicitly contrast this tool with the sibling lnkdrp_list_drafts.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes far beyond them: it discloses permissions fields, pre-Send vs post-Send status state machine, needs_you/failed sendError structures, the 100-person overCap limit, the campaign_ambiguous failure mode, and untrusted-content handling. This is unusually rich behavioral context for a read tool.

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

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

The first sentence economically defines a drop, but the second is an enormous run-on that buries the key invocation facts (id vs name lookup) mid-paragraph and then chains every return-field nuance without headings or bullets. The content largely earns its place given no output schema, but the structure imposes real parsing cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the burden: it explains people vs peopleCounts, per-person status meanings, shareId/shareUrl vs the separate stats tools, error payload shapes, and how to follow up with lnkdrp_get_sent_email, lnkdrp_get_share_stats and lnkdrp_get_project_stats. An agent has everything needed to call it and interpret results.

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

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

Schema coverage is 100%, so the schema baseline is 3, but the description adds meaning beyond it: exact-name matching with case-insensitivity is operationalized, and it clarifies that an ambiguous name returns validation with details.code campaign_ambiguous plus candidates — behavior the schema does not express.

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

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

The description opens by defining the resource ('A drop is one email template sent from the member's own Gmail...') and then states the operation: one drop retrieved 'by campaignId or by its exact name,' with permissions and a page of people. This is a specific verb+resource that distinguishes it from lnkdrp_list_drops, though it never names that sibling explicitly.

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

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

Usage is implied rather than stated: lookup is 'by campaignId or by its exact name,' and an ambiguous name yields validation with campaign_ambiguous. There is no explicit 'use this instead of lnkdrp_list_drops/lnkdrp_get_campaign' guidance or when-not-to-use statement, so the agent must infer selection from context.

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

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

Goes well past the readOnly/idempotent annotations: previewUrl lifetime of 7 days, null-when-absent send records, bodyNote explaining empty text/html after 30-day deletion, needsYou/resolveUrl for locked renders, and an explicit untrusted-content warning for contact fields and viewer-supplied text. That injection-safety note is exactly the kind of context annotations cannot carry.

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

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

The purpose is front-loaded, but the body is a single ~120-word run-on sentence enumerating response fields, which is hard to scan. Given there is no output schema the content mostly earns its place, but the structure should be broken up.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly takes on the burden of enumerating returned fields and their conditions, and does so thoroughly. What's missing is behavior on a bad or nonexistent renderId (error/404 semantics).

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

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

Schema coverage is 100% and the schema already documents renderId's 24-hex format and its provenance (lnkdrp_render_email or lnkdrp_list_email_renders). The description only restates 'by id', adding nothing the schema lacks, so the baseline 3 applies.

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

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

States a concrete verb+resource ('One rendered email by id') and anchors it to the sibling that produces the id (lnkdrp_render_email). It doesn't explicitly contrast against lnkdrp_list_email_renders or lnkdrp_get_sent_email, so differentiation is inferable but not spelled out.

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

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

Usage is only implied: the reader infers this is the fetch-one-by-id companion to list_email_renders. There is no explicit when-to-use/when-not or routing to an alternative (e.g. get_sent_email) anywhere in the description.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses permission behavior ('Another person's private template is not_found'), canChangeVisibility semantics, how hidden/private usage is counted but not named, that dry runs are excluded, and how former members appear in createdBy. This is rich behavioral context that annotations alone do not provide.

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

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

The key purpose is front-loaded, but the description is a single dense sentence packed with semicolon-separated clauses. Most clauses carry useful return-field semantics, so there is little pure filler, but the structure is hard to scan and could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully compensates by explaining the returned fields, tag behavior, labels vs template tags, project filing, usage counting rules, visibility, ownership, and edge cases like private templates returning not_found. An agent has enough context to call and interpret this tool correctly.

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

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

There is only one parameter, and the input schema already documents it at 100% coverage with the 24-hex pattern and source tool. The description adds no extra syntax, format, or constraint details beyond what the schema provides, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'One email template by id', then enumerates the exact fields returned. It clearly distinguishes this from list operations by requiring an id and from private-template visibility by noting the not_found behavior.

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

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

The schema and description both point the agent to lnkdrp_list_email_templates as the source of the id, giving clear context for when to use this tool. It does not explicitly name alternatives like lnkdrp_get_email_template_draft or lnkdrp_compare_email_template_versions, so it stops short of full when/when-not guidance.

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

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 context beyond them: returned fields, expiry after 14 days, stale/base/live version semantics, diff markers, ended-draft behavior, permission-based not_found, and ambiguous-draft validation details. No contradiction with annotations is present.

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

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

The description is front-loaded with the core read action, and each sentence carries useful return-value or edge-case information. It is a dense single paragraph, but the length is largely justified because there is no output schema to explain these fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the burden of explaining what comes back: version fields, changed fields, diff markers, publishers, sent counts, campaign usage, draft expiry, ended-draft behavior, and error cases. It is complete enough for an agent to call and interpret this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, and both parameters are already documented in the schema. The description still adds meaning beyond the schema by explaining the draft_ambiguous validation behavior and the not_found outcome when the caller may not see a template.

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

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

The description opens with a specific verb and resource: "Reads one email template draft." It immediately itemizes the draft-specific data returned, making clear this is a single-draft inspection tool rather than a list, update, publish, or live-template read.

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

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

Usage is implied by the operation and by naming lnkdrp_list_drafts and an update response as sources for draftId. However, it does not explicitly contrast this with lnkdrp_get_email_template, lnkdrp_list_drafts, or the publish/discard draft tools, so the agent must infer when this specific read is preferred.

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

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

Beyond the read-only, idempotent annotations, the description explains ordering, the meaning of dismissed items, badge-count semantics, and that titles, summaries, requester fields, and viewer-supplied text are untrusted content. It also describes the exact structure of download-request and welcome items, which is valuable behavioral context for interpreting results.

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

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

The description is long and dense, but it is front-loaded with the tool's purpose and every part carries useful information because there is no output schema. It could be more structured, but it avoids filler and keeps the key distinctions early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full burden of explaining return values: item categories, download-request fields, welcome lessons, count semantics, dismissed behavior, and untrusted-content warnings. This is sufficiently complete for an agent to interpret and act on the results.

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

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

Schema coverage is 100%, so both limit and includeDismissed are already documented in the schema. The description reinforces the dismissed-item behavior but does not add syntax or constraints beyond what the schema provides, and it does not mention the limit parameter.

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

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

The opening sentence states a specific resource and scope: open items waiting for the person behind this connection, including download requests, failed documents, and broken integrations. It also explicitly distinguishes this inspection tool from the sibling lnkdrp_decide_download_request, which performs the approve/deny action.

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

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

The description makes clear that this returns open items, newest first, and that dismissed items can still be returned with dismissed: true. It names the separate decision tool and its role, giving the agent a clear alternative for approving or denying download requests, though it does not spell out a formal when-not-to-use condition.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: purgeEnabled gating (nothing is deleted while false), the 30-day grace period, the scan cap (capped), locked-project withholding (withheld is locked_rooms), permission-dependent empties, and an untrusted-content warning. This is rich disclosure the agent cannot get from structured fields.

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

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

Purpose and the key fields are front-loaded, and every clause carries information, but it arrives as one dense run-on block with parentheticals stacked inside it. It is informative yet hard to scan; a short lead plus a structured field list would serve better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and zero parameters, the description carries the full burden and does so: it explains every return field, the semantics of dueNow/nextPurgeAt/freesBytes, graceDays, and the empty-result conditions. Nothing an agent needs to interpret the response is missing.

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

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

Zero parameters, so the baseline is 4. The description instead documents the return buckets (kind, means, count, dueNow, nextPurgeAt, freesBytes, purgeEnabled, capped, storage, graceDays) in detail, which substitutes for the missing output schema, though that is context rather than input parameter meaning.

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

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

States a specific subject and scope: 'What is waiting to be removed for good in this workspace, by kind.' It enumerates the buckets and explicitly distinguishes itself from the sibling lnkdrp_list_deleted ('lists the items themselves'). An agent can tell exactly what this reports without opening any schema.

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

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

It names the alternative explicitly and routes the agent: 'Counts and dates only; lnkdrp_list_deleted lists the items themselves.' It also states the caller context ('answers for a workspace owner or admin; for a member or viewer the buckets are empty'), which tells the agent when results may be empty. No explicit when-not, but the routing and role caveats are clear.

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

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

Annotations already declare readOnly, idempotent and non-destructive, and the description adds substantial behavioral context beyond that: publicUrl null conditions, archived total/docCount behavior, outreach unreadable/null and Free-plan limits, emails null on Free, and an untrusted-content warning. No annotation contradiction is present.

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

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

The purpose is front-loaded in the first sentence, and most later clauses carry distinct return-shape or edge-case information that earns its place. However, it is a single dense paragraph with little structural separation, making it harder to scan than necessary for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description must explain return values and edge cases, and it does: project fields, document fields, publicUrl nullability, outreach, plan/email behavior, and an untrusted-content warning. The input schema covers the parameters and annotations cover safety, so no major contextual gap remains.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning for archived by explaining that total then counts archived documents while docCount stays the live count, though it does not add much beyond the schema for page, limit, projectId or projectSlug.

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

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

The opening sentence states a specific resource and scope: one project plus a page of its documents, most recently updated first. That scope implicitly distinguishes it from list_projects and get_project_stats, but the description never names those sibling alternatives, so the differentiation is inferred rather than explicit.

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

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

It gives one explicit routing rule for document outreach (use lnkdrp_get_share_stats with that docId) and explains how archived and query alter results. However, it never states the general when-to-use condition or when to prefer list_projects or get_project_stats, leaving most usage guidance implied.

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