DocSend

View saved version →

---
name: docsend-build-data-room
description: Create and organize a DocSend data room for fundraising, M&A, due diligence, or another document-sharing workflow. Use for setting up Spaces, organizing materials into meaningful folders, improving file names, and identifying potential content gaps.
---

# Build a DocSend Data Room

Example: “Build a fundraising data room using these documents.”

Use the DocSend MCP. Discover current schemas before acting; use supported workflows and obey tool approval requirements. This skill builds and reviews rooms; creating the skill itself does not authorize live DocSend mutations.

## Establish purpose and sources

Identify the deal purpose, desired Space name, source materials, and requested structure from context. Ask only for information needed for the requested actions. A request to build a room authorizes its Space and folders, but does not authorize external access.

Use `list_spaces` when needed to identify an existing Space the user refers to or reconcile an uncertain creation result. Inspect existing links/groups before adding materials to an existing room, since visitors may already have access.

Use supplied materials or locate documents with `search_documents` and `list_content_library`. The Content Library is separate from Space content. Inspect rooms with `list_space_content`, starting with the returned `home_folder_id`; inspect relevant subfolders and pagination.

Inspect accessible contents when names alone are insufficient. Call `read_document` once without `page`, prefer downloading its `file_url` exactly once, and analyze the full file locally. Use page requests only for a specific-page question or when the file URL is unavailable. Keep inaccessible materials distinct from missing documents.

## Build and organize

Follow the user's requested structure when provided. Otherwise develop meaningful, shallow folders based on the deal purpose and available materials.

Create the Space and folders with `create_space` and `create_space_folder` within the authorized scope. Preserve user-provided Space names and descriptions exactly; ask for a shorter value if rejected by length limits. Leave questions and unrelated settings unchanged unless requested. Inspect state before retrying an uncertain creation result.

If an appropriate company logo or banner image is available, upload it to supported Space logo/banner fields. The current MCP has no branding-image update fields: leave them unchanged and report the limitation unless new tools support them. Do not add branding images as substitute room documents.

Add available materials to the data room using the DocSend MCP upload workflow below and verify that documents appear in their destination folders. Currently there is no direct Content Library-to-Space add/copy operation. `move_space_content` only moves content within one Space. When exact source bytes are accessible, use the upload workflow below; otherwise report the materials that require manual addition. Finding or reading a Library document does not add it to a room.

Organize by subject and purpose. Avoid a generic catch-all folder and unnecessary depth. Do not guess a document's purpose: clarify unresolved placements and report them. Use `move_space_content` for existing content, batching only items with the same source parent. Verify destinations after moves and additions.

### Upload preparation and completion

1. Obtain exact file bytes and metadata. Before `request_space_upload`, show the exact Space/folder destination and each file's `original_name` and `size_bytes`, explain that uploaded content is visible to Space visitors, and ask the user to approve those uploads, as required by the upload tools. This approval covers finalization for the unchanged file and destination; changes require updated details, confirmation, and a fresh target.
2. Call `request_space_upload`. This prepares a presigned target; it does not transfer bytes or add a document.
3. Keep each respons

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: docsend-deal-activity-briefing
description: Summarize visitor engagement and internal activity across DocSend Spaces or shared documents for a requested reporting period. Use when someone asks for a one-time deal activity briefing, Space engagement summary, or summary of document visits and changes.
---

# DocSend Deal Activity Briefing

Produce a concise briefing for the current request using the DocSend MCP. Cover visitor engagement and internal changes separately, with clear reporting dates and data limits.

## Set scope and reporting period

Identify requested Spaces or shared documents from the request and conversation. Use the user's timezone and state the exact dates covered.

- “Yesterday” means the previous calendar day.
- “Last week” means the previous calendar week, Monday through Sunday.
- If the period is missing or ambiguous, default to the previous calendar week and explicitly state that assumption. Preserve any unambiguous dates supplied by the user.
- If resource scope is unspecified or ambiguous, use clear context where possible; otherwise default to accessible, enabled Spaces the user owns or collaborates on for that period, stating the assumed scope. Do not silently expand to all company Spaces or all Library documents. If the resource cannot be resolved without a material risk of reporting the wrong deal, ask for clarification while proceeding with unambiguous resources.

Compute calendar boundaries in the user's timezone, accounting for daylight-saving changes, then convert timestamps for tool calls. Filter the interval from the start of its first day up to, but excluding, the next day after its last day. For a period still in progress, disclose the retrieval cutoff.

## Resolve resources

Use `list_spaces` to resolve Space names and `search_documents` / `list_content_library` to find requested Library documents. Use `list_space_content`, starting with a Space's returned `home_folder_id`, for its documents and folders. Follow pagination and inspect relevant folders. The Content Library and Space content are separate surfaces.

Exclude Spaces explicitly marked disabled. Zero activity is not evidence that a Space is disabled. State exclusions concisely when relevant. Use `all_company` only when the user asks for all company Spaces and their access supports it.

## Retrieve activity and assess coverage

Use `list_visits` scoped by `space_id` for a room or `document_id` for a shared document. Omit `contact_id` for general engagement summaries; use it only for a specifically requested visitor after resolving them with `search_contacts`.

The current visits tool has no date-range parameter. Follow pagination and filter visit timestamps locally to the reporting period. Do not assume pagination order or stop at an old record unless documented ordering guarantees full coverage. For Space changes, use `list_space_events` with `from` and `to`, following pagination and applying the same reporting boundaries locally. Its end filter is inclusive, so exclude events at the next-day boundary locally.

For audit events, use `display_name` in all user-facing communication. Never expose raw event type values; use them only in tool filters. Attribute changes to the returned actor when identifiable, using their name or email. Do not infer the actor from Space ownership or assume every audit event is internal: visitor views, downloads, and signatures belong with visitor engagement. Inspect returned event details before describing what changed. If details identify only an update, do not invent the changed fields or claim a new document version without evidence.

For standalone documents, retrieve available visits. Space audit events are scoped to a Space: do not treat Library timestamps as a complete change log or claim standalone internal history is available when no supported source exposes it. If a requested document belongs to a known relevant Space, use that Space's accessible events and clearly scope the findings

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: docsend-prepare-meeting
description: Create a concise, sourced meeting brief using accessible DocSend documents and engagement activity. The user can identify a meeting by person, email, company, or calendar event.
---

# Prepare for a Deal Meeting

Use the DocSend MCP to connect meeting context with observed engagement and relevant document contents. Produce the supported portions of the brief even when some sources are unavailable.

Example requests:

- “Prepare me for a meeting with Bob Smith.”
- “Prepare me for a meeting with bsmith@xyz.com.”
- “Prepare me for tomorrow’s meeting with Acme based on what they’ve viewed.”
- “Set up a brief one hour before each meeting on my calendar.”

## Identify the meeting and purpose

Use the person, email, company, date, or meeting details provided; the user may or may not supply a meeting purpose. If an upcoming meeting is unidentified, discover an available, authorized calendar connection and use its event title, start time, attendees, description, and linked materials. Resolve relative dates in the user's timezone. Distinguish similarly named or recurring event instances.

If calendar access is unavailable or the relevant event remains unclear, proceed with what is known. Do not require a meeting date or purpose before preparing the supported brief. A name or email alone can support a counterparty brief; do not invent a meeting date or purpose. Label any inferred purpose as an assumption. Ask for clarification when identity ambiguity could materially change attribution, as described below.

## Match people to DocSend activity

Use `search_contacts` to match the provided or calendar-attendee email to DocSend visitors. These contacts represent visitors, not a complete recipient or delivery list. Search by name when appropriate; if only email addresses are present, use authorized calendar/contact evidence, an established name-to-email pattern, and company-domain context to assess likely matches.

A domain alone establishes possible company affiliation, not a specific person's identity. Do not generate an address and treat it as a verified match. When evidence strongly supports one reasonable match, state the assumption and its basis. If multiple plausible matches could materially change the brief, ask the user to choose, identifying candidates by email and relevant dates. Do not attribute activity on weak or ambiguous evidence; continue with unambiguous materials while clarification is pending.

When a company-specific domain is established, search for relevant visitors from that company and include useful activity from other people. Check actual email-domain boundaries rather than loose substring matches; do not group people by public email-provider domains. Keep each person's activity separate and identify any uncertain affiliation.

## Gather activity and materials

Retrieve visits with `list_visits`. For a specific visitor, resolve the contact first and use `contact_id`. For room-wide activity, use `space_id` from `list_spaces` and omit `contact_id`. Follow pagination to cover the relevant scope; disclose incomplete retrieval. Contact `total_visits` is a lifetime total, not a count for the meeting window.

By default, use the 30 days immediately before the meeting start, in the user's timezone, and state the exact start/end dates and timezone. Exclude activity after the meeting. For a future meeting, distinguish the requested window from coverage available as of preparation time. If the meeting date is unknown, cover the 30 calendar days prior to the day the user invokes the skill, in the user's timezone. State that fallback and its exact date range; do not ask for the meeting date merely to establish the activity window. Include older activity only when it adds useful context and label it separately.

The current `list_visits` schema has no date-range parameter: filter returned timestamps locally, and do not assume pagination order unless documented. Only stop early on a d

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: docsend-prioritize-follow-ups
description: Use DocSend engagement activity to recommend which investors, buyers, or prospects to follow up with. Use for prioritizing outreach, reviewing engagement changes, and drafting personalized follow-ups.
---

# Prioritize Deal Follow-Ups

Example: “Which investors should I follow up with this week, and what should I say?”

Use the DocSend MCP to recommend a short outreach priority list grounded in observed engagement. Draft messages when requested; sending is a separate action requiring explicit authorization and an available messaging capability.

## Resolve scope and period

Identify relevant Spaces or shared documents from the request and context. Use `list_spaces` for Spaces, `list_space_content` for room documents and folders, and `search_documents` / `list_content_library` for Library documents. Follow relevant pagination. Keep Space content distinct from the Content Library. If resource scope is missing, use the relevant context or accessible Spaces the user owns or collaborates on and state the assumed scope; ask only when a materially ambiguous deal cannot be resolved. Do not silently expand to all company resources.

If no reporting period is specified, use the last 30 days up to preparation time and state that assumption, exact start/end dates, cutoff, and the user's timezone. Distinguish a requested outreach timeframe, such as “this week,” from the historical engagement window. Preserve explicitly requested reporting dates.

## Retrieve contact and viewing evidence

Retrieve `list_visits` scoped by Space or document. Use `search_contacts` to resolve a specific person before using `contact_id`; omit it for general resource-wide queries. Contacts represent observed visitors, not a complete recipient or delivery list. Resolve ambiguous same-named people using email and context, asking when the ambiguity could change attribution. Do not guess a recipient address.

The current visits schema has no date filter. Follow pagination and filter returned timestamps locally. Do not assume pagination order or stop at an older record unless documented ordering guarantees coverage. Keep relevant resource and reporting-window filters when gathering contact-specific history. Do not use a contact's lifetime visit total as their activity for this deal or period.

Gather supported evidence such as:

- Most recent visit and its date.
- Repeat visits and whether they occurred on distinct days.
- Documents or pages viewed, viewing percentage, and coverage of relevant materials.
- Viewing duration, with total visit milliseconds converted correctly and per-page seconds treated separately.
- Downloads only when explicitly recorded by available audit events or another supported source. Views alone do not establish downloads.

Use `list_space_events` when needed for available Space download evidence. Use event `display_name` values in user-facing text, never raw event type values. Do not count audit views and visit records as separate visits when they describe the same activity. Keep bulk downloads separate from individual-document downloads unless contents are known.

Retrieve comparison history only when needed to support claims about engagement changes, and state the baseline dates and scope. Separate anonymous activity from identifiable contacts; do not assign an anonymous or shared-link visit to the intended recipient without evidence. Disclose retrieval failures, plan/permission limits, and incomplete coverage. Lack of records is different from unavailable data.

## Compare contacts and prioritize

Explain the factors used instead of inventing a DocSend engagement score. Weigh available signals in context: recency, repeat visits, breadth of relevant document coverage, supported changes over time, and explicit downloads may support different next actions. Do not let a long viewing duration alone dominate the ranking or imply that the document was actively read throughout.

Use known deal p

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: docsend-standardize-file-names
description: Identify unclear or inconsistent document names in a DocSend Space and rename them using a consistent convention. Use for file naming cleanup, ambiguous filenames, and data room organization.
---

# Standardize File Naming

Example: “Find unclear file names in this data room and make them consistent.”

Use the DocSend MCP to inspect the target Space, propose content-supported names, and apply renames within the user's authorization.

## Find the Space and inventory

Resolve the target from conversation context or `list_spaces`. Ask only if the target remains ambiguous. Use its returned `home_folder_id` with `list_space_content`, then traverse relevant subfolders and follow pagination within each folder. Record document identifiers, current names, extensions when available, and folder paths internally. The Content Library is separate from Space content; do not substitute Library search results for the room inventory.

List the room's documents and folders in a readable form. Use folder paths or verified document links to distinguish same-named items. Disclose inaccessible items and incomplete retrieval; do not imply that an incomplete inventory covers the whole room.

## Choose a convention and inspect names

Follow the user's naming convention. Otherwise preserve useful existing conventions and prefer descriptive names containing the document subject. Do not add dates or versions unless the user requests them. Preserve existing dates, version numbers, and status labels when needed to distinguish documents or revisions; this preservation does not authorize inventing new metadata. Ask only when an unresolved choice materially affects the result.

Look for:

- Generic names such as “Document 1,” “Scan,” or “Untitled.”
- Automatically generated names such as “IMG_4821,” “DSC_0093,” timestamps, or random character strings.
- Clutter such as “Copy of,” repeated extensions, or “final_final.”
- Inconsistent capitalization, separators, date formats, or version notation.
- Names that do not clearly describe the contents.

Suggest descriptive, consistent replacements. Remove redundant version labels only when they serve no meaningful purpose. Do not erase distinctions between revisions or change the meaning of status labels for cosmetic consistency.

Inspect accessible document contents when needed to determine a meaningful name. Call `read_document` once without `page`; prefer downloading its `file_url` exactly once and analyzing the full document locally. Use a page request only for a specific-page question or when full-file access is unavailable; do not loop over every page instead of downloading the full file. Do not infer dates, versions, approval status, signatures, or document type without supporting evidence. If contents remain unavailable or unclear, flag that limitation and leave unsupported subject renames unresolved; propose purely mechanical cleanup only when it preserves meaning, and obtain approval before applying it.

Preserve a real file extension where applicable, correcting repeated extensions without changing the underlying format. Distinguish an extension stored separately by DocSend from an extension present in the display name; do not append an extra suffix merely because extension metadata exists. Check proposed names against both unchanged and other proposed names, particularly in the same folder. Avoid confusing duplicates; use content-supported distinguishing terms or ask for a material unresolved choice rather than inventing revision labels.

## Present and apply

Present a table with **Current name**, **Proposed name**, and **Reason**. Include folder context or document links when needed to identify items; never display internal identifiers. Flag rows whose contents are unavailable or unclear and indicate when no supported replacement is available. The user must approve the proposed changes before any file is renamed, including purely mechanical cleanup.

Preview of the first 4,000 characters. Read full instructions →