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 response paired with its matching file. Build a multipart POST containing every returned `upload_body_params` property exactly once as text, preserving names, case, and values byte-for-byte. Do not decode/re-encode them. Let the HTTP library generate the multipart Content-Type header and boundary; the returned Content-Type is a signed form field. Append the matching file last as `file` and POST to `upload_url` before `expires_at`.
4. Only HTTP 201 permits finalization. For expiry, non-201, or unknown transfer outcome, do not finalize; request a fresh target if continuing. If byte transfer is unavailable, report that preparation is incomplete work.
5. After HTTP 201, call `upload_file_to_space` using the unchanged `upload_key`, destination, and identical original name, MIME type, and size. Finalization is not idempotent: inspect the destination before retrying an uncertain result to avoid duplicates.
6. Immediately check the destination with `list_space_content`. For PENDING, wait about 10 seconds and check again; if still PENDING, wait about 20 seconds and check once more. Stop after three checks total and report ongoing processing. SUCCESS confirms processing, not an available AI summary; ERROR indicates processing failure. Distinguish prepared, transferred, added, and processed materials in the result.

After verifying uploads, confirm completion with the document names grouped under their destination folders so the user can review both the materials and folder structure. Keep this confirmation user friendly: omit byte counts, MIME types, upload keys, processing codes, internal identifiers, and transport details. Describe pending processing or failures in plain language. Keep exact technical metadata in tool calls and any disclosure explicitly required for upload approval, rather than repeating it in completion summaries.

## Names and potential gaps

Once the Space is created and its available materials are organized, proactively review file names for clarity and consistency without waiting for a separate request. Suggest content-supported replacements for ambiguous names such as “Document 1,” “Scan,” or “Final v2.” Do not invent dates, versions, or approval status. Ask whether to apply suggestions unless renaming was already authorized. Use `rename_space_content` for approved changes and verify them. If a shared-document confirmation is returned, explain its cross-Space/link impact and confirm that impact before retrying with `force: true`.

Next, if applicable, proactively assess potential content gaps against deal purpose, stage, user context, and reviewed materials without waiting for a separate request. Distinguish “appears missing from reviewed materials” from “could not inspect.” Explain why each proposed addition may be useful; do not present a generic checklist as mandatory. The structure and gap assessment are organizational guidance, not a statement that the room satisfies every diligence requirement. Do not create placeholder documents or represent suggested materials as existing.

## Setup summary

Return a concise summary containing:

- Space name, verified admin URL, and folder structure. Use the Space URL returned by DocSend; never construct one from an internal identifier. Report if an admin URL is unavailable.
- Added materials and destination folders, including processing still underway.
- Suggested or completed name improvements.
- Potentially missing materials and their relevance, separately identifying inaccessible materials.
- Unresolved placements and actions that could not be completed, including unsupported branding or content operations.

Once organization, the proactive file-name review, and any applicable gap assessment are complete, ask whether the user is ready to share the Space. If sharing was already authorized, proceed within that authorization; if the user requested a private room, respect that preference. Creating a room alone never authorizes granting external access.

## Sharing and visits

Configure sharing/access only when requested. Links and groups are the Space's access methods. Groups grant external visitor access; they are not internal collaborators.

For a shareable URL, use `create_space_link` with supported settings matching the user's instructions. Name new links recognizably, such as the intended company/person or a readable creation date/time in the user's timezone. Ask only for missing consequential access choices. Return the link URL and summarize its effective settings in plain language: whether downloads are enabled, whether an email is required, whether that email must be verified, whether screenshot protection is enabled and at what level (including mobile protection when reported), and any configured expiration, watermark, or access restrictions. Distinguish email collection from verification. Describe screenshot protection settings without promising that all screenshots are impossible. Identify any requested setting not applied or setting that could not be confirmed; do not guess defaults.

If the user explicitly wants DocSend to send invitations, create a named group with `create_space_group` rather than a regular link. Use only authorized recipients and invitation text. After a successful invitation operation for the specified recipients, tell the user the invite has been sent. Do not add caveats about email deliverability. If the operation fails or does not invite anyone, report that action accurately rather than claiming an invite was sent.

Check `list_space_permissions` before modifying existing access. Follow explicit confirmation requirements for link updates and visibility changes. For group updates, show the before/after state, every email added/removed, exact invitation message, and setting changes; obtain confirmation before calling `update_space_group`. Email removals must be separate from other changes. Stop on group capacity errors; do not retry smaller batches.

Current tools do not configure NDA settings; links also lack passcode/media-playback controls. Direct users to the admin page for unsupported settings. Group screenshot protection requires a subsequent update: do not claim it exists at creation or invite recipients before resolving protection required to precede access.

Retrieve available visits using `list_visits` scoped to the Space, following pagination. Attribute activity to a particular link/group only when returned evidence supports it; do not label room-wide activity as recipient-specific. Omit `contact_id` except for a specific visitor resolved with `search_contacts`. Summarize visitor identity, dates, documents, and relevant engagement with correct units. No recorded visits does not prove non-delivery.

Retrieve visits when available during the task or on follow-up; do not imply a subscription to future events. If the user requests ongoing monitoring, use supported scheduling tools when available; otherwise explain the limitation.

## Tool handling

On `insufficient_scope`, ask the user to re-authenticate before retrying. Check structured responses and text errors before reporting success. Keep all values named `id` or ending in `_id` internal, including in displayed links and summaries. Identify items by names, returned URLs, emails, or dates. Do not call live write tools merely to test this skill.

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.

Track coverage separately for visits and internal activity for each resource. Distinguish:

- Successful complete retrieval with no in-period activity.
- Partial retrieval or incomplete pagination.
- Data unavailable because of plan or permission limits.
- Failed retrieval.

When the response establishes that the user's plan lacks Space analytics, state that the current plan does not include the Space analytics needed through MCP and that upgrading to an eligible DocSend plan, such as Advanced Data Rooms when identified by the tool, is required. Do not diagnose a generic permission or retrieval error as a plan limit. If entitlement is unverified, state the observed limitation without asserting which plan the user has. On `insufficient_scope`, ask for re-authentication before retrying. Continue with independently accessible data and disclose its limits.

## Compute only supported metrics

Report new or returning viewers, unique counts, downloads, and engagement changes only when available evidence supports them.

- Count identifiable viewers using stable internal identifiers or normalized email evidence where available; a display name alone may not identify a unique person. Keep anonymous visits separate from identified unique viewers. Do not turn visit counts into people counts.
- Define whether counts are per document, per Space, or across the briefing. Do not add per-resource unique counts and call the sum an overall unique count.
- Distinguish new-to-this-resource viewers from returning viewers only with sufficient earlier history for that same resource. If only the reporting window was retrieved, say “first observed in this period” rather than claiming a viewer is new. Lifetime contact totals do not establish prior visits to this deal.
- Visits expose views and viewing measures, not download events. Report downloads only when audit events or another source explicitly records them. Keep bulk downloads distinct from individual-document downloads unless their contents are known.
- Visit and audit logs can describe the same view. Use visits for view metrics and events for complementary actions; do not sum both into duplicate activity counts.
- Total visit duration is in milliseconds; per-page duration is in seconds. Convert units correctly. Describe notable changes only with a supported comparison baseline and label its dates and scope; otherwise describe the observed activity without a trend claim.

## Write the briefing

Start with a concise overall summary highlighting the most useful observed findings, the exact reporting dates and timezone, and any limits affecting the overall conclusion. Keep it clear, short, and scannable.

Organize the rest by Space or shared document, prioritizing notable activity. Link resource names with verified source URLs when available; do not construct URLs from internal identifiers or create sharing links for citations. For each resource, include relevant sections:

- **Visitor engagement:** Supported new/returning viewer information, documents viewed or downloaded, activity dates, and notable supported changes.
- **Internal activity:** Document additions or versions, file/folder changes, link creation or updates, and permission changes. Name the actor when identified in the activity data.
- **Recommended follow-ups:** Only concrete, actionable recommendations supported by the observed activity. Label them as recommendations and omit this section when none is meaningful.

Group resources with no activity in a brief closing line only when both relevant activity sources were successfully covered. For partial coverage, state specifically which source had no records and which was unavailable. Clearly identify resources whose activity could not be retrieved. Do not imply inaccessible data was reviewed.

Separate observed facts from interpretations and recommendations. Viewing and downloading do not establish purchase or investment intent. Do not overstate attention, concern, or understanding from duration or viewing percentage.

## Scope boundary

This skill produces a one-time briefing. It does not configure recurring delivery or create scheduled tasks. Handle any scheduling request separately, and only when a supported scheduling capability can run the workflow with DocSend access.

Discover live tool schemas and obey access checks. Keep result fields named `id` or ending in `_id` internal, referring to human-readable names, emails, dates, and verified URLs. Check text errors as well as structured results. Preparing the briefing does not authorize changes to documents, Spaces, links, groups, or permissions. Do not call live write tools merely to test this skill.

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 date boundary if the tool guarantees that ordering. Preserve the distinction between no matching records, inaccessible records, and incomplete pagination.

Select activity and documents relevant to the meeting purpose. Use `search_documents` / `list_content_library` for Library materials and `list_space_content` for room materials; they are separate surfaces. Read relevant accessible documents, including material linked from the meeting when authorized. Call `read_document` once without `page`, download its `file_url` exactly once for a full-document read, and analyze locally. Use a page request only for a specific-page question or when file access is unavailable; do not loop over every page as a substitute for the full-file download.

Report only observable events and supported measures. The current visit records expose views, pages, viewing percentage, and duration; they do not establish a download event. Report downloads only when another available source explicitly records them. Total viewing duration is in milliseconds; per-page duration is in seconds. A view, download, long duration, or repeated visit does not prove interest, concern, comprehension, or purchase intent. Frame possible implications as interpretations and talking points as suggestions.

## Write a concise, scannable brief

Lead with the most useful meeting takeaway or, when clear, the meeting goal, grounded in available evidence. Do not invent a goal when the purpose is unclear. Include the meeting date, counterparty, and purpose when known; label assumptions. Do not fabricate missing meeting details. Prefer short bullets over long paragraphs.

Use short sections suited to the available information. Adapt these headings to the request rather than treating them as a fixed template:

- **Goal:** What the user should aim to learn, explain, or agree on. Omit this section when the goal is unclear; do not force a generic goal from limited context.
- **DocSend activity:** A brief summary of the exact activity window and timezone, preparation cutoff, and the most relevant materials, with document evidence and engagement presented together.
- **Prepare / Bring:** Specific documents (linked for easy reference), figures, or topics to have ready.
- **Questions to consider:** Suggest up to three optional, high-value questions only when they would materially help the user prepare. Tailor them to the meeting purpose and evidence, prioritizing important discrepancies or gaps. Do not script the meeting or imply the user should ask every question. Omit this section when there are no especially useful questions.
- **Agree before you leave / Next step:** A concrete decision, owner, or follow-up date to propose. Label proposed commitments as suggestions; do not present them as already agreed.

Omit empty sections, generic advice, and repeated points. Include only information that could affect the meeting. Keep observed facts distinct from interpretations and suggestions, explicitly labeling suggestions.

## Present activity and source materials together

For each relevant document, link its name at first mention, alongside who viewed or interacted with it and when, plus useful facts or topics from its contents. Include relevant activity from other people at the company here, identifying each person accurately rather than attributing their activity to the meeting attendee.

Keep engagement and document facts together where useful. Avoid a redundant document inventory or repeated facts. Link specific documents in Prepare / Bring when they should be ready for the meeting, including a repeated link when needed for easy reference; do not let a mention-once convention prevent useful preparation links. Include relevant accessible materials even if there is no recorded engagement, making that distinction clear.

If a document is a sample, fictional, inaccessible, or its contents could not be verified, say so clearly alongside that document. Do not present sample or fictional figures as the counterparty's actual results, or infer unverified contents from a filename. Distinguish observed document engagement from verified document facts.

If only some of the total activity is relevant, distinguish the total from the selected items. State the scope and period of any total, and do not imply the selected documents or visits exhaust all activity. Disclose incomplete retrieval rather than giving an unsupported total.

## Keep evidence clear

Use verified returned or user-provided source URLs; never invent document URLs from internal IDs or create sharing links to supply citations. Prefer durable source links over expiring download URLs. If no usable source link is available, identify the document by name and relevant page/section at its first mention and state the citation limitation.

Include activity dates or periods where available. Distinguish observed facts from interpretations and suggestions. Explain when unavailable information or an uncertain match limits the brief, while providing the portions supported by available evidence. Do not imply that a view or download proves interest, concern, or intent.

## Recurring preparation

For a one-time brief, offer recurring preparation after delivering the brief, unless the user has already requested or declined it. Offering it does not authorize creating an automation.

When recurring preparation is explicitly requested, use the available, authorized calendar and automation connections and discover the supported scheduling tool. Reuse or update a matching automation rather than creating duplicates. Resolve the calendar scope, timing relative to meetings, timezone, and delivery destination from context; ask only for missing choices needed to configure it. Use the current chat as the default destination when supported. Preserve the user's requested one-hour lead time when specified.

Verify that calendar access and the scheduling mechanism can support event-relative preparation. A recurring calendar check is not an exact event-triggered guarantee. If using a supported polling approach, disclose its timing precision and handle rescheduled/cancelled meetings, changed attendees, and duplicate preparation for the same event. Keep runs quiet when there is no newly actionable meeting. Do not claim exact one-hour delivery unless supported.

Save instructions to re-read the current event, resolve attendees, retrieve fresh DocSend activity, and produce this brief for each relevant meeting. Confirm the actual schedule and destination only after the scheduling tool succeeds. If calendar or scheduling access is unavailable, explain what is missing without claiming the recurring task is active. Do not send briefs to attendees or other people unless the user explicitly requests it.

## Tool boundaries

Discover live tool schemas and obey their access checks. On DocSend `insufficient_scope`, ask the user to re-authenticate before retrying. Check text errors as well as structured responses before reporting success. Keep result values named `id` or ending in `_id` internal; identify items by names, emails, verified URLs, or dates.

Preparing a brief does not authorize changing documents, Spaces, sharing settings, invitations, or calendar events. Do not call live write tools merely to test this skill.

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 purpose, stage, and user-provided relationship context when available. A contact opening more documents may simply have received more materials; avoid presenting unequal access or missing data as a fair engagement comparison. Do not claim someone is an investor, buyer, or decision-maker unless context supports that role. Qualify close rankings or state when evidence does not meaningfully distinguish contacts. Do not manufacture a priority order when no identifiable, usable evidence is available.

When grouping by company, use verified company information or label domain-based affiliation as an assumption. Match actual company-specific domain boundaries, not loose substrings. Do not group public email-provider domains as one company. Keep individual contributors identifiable within a company summary; do not imply a colleague's activity belongs to the primary contact.

Describe inactivity as “no observed activity in this period,” not proof of lost interest. Viewing, repeated visits, downloads, duration, and coverage do not prove purchase or investment intent. Keep observed facts distinct from possible interpretations and recommendations.

## Return a short prioritized list

Start with the reporting window, scope, and a brief explanation of the comparison factors. For each recommended contact or company, include:

- **Contact or company:** A human-readable identity, with affiliation assumptions when needed.
- **Observed engagement:** Relevant dates, materials, and supported measures.
- **Why follow up:** Why a follow-up may be useful, framed as a recommendation rather than a conclusion about intent.
- **Next action:** A concrete, proportionate suggestion tailored to the evidence and known context.

Link relevant documents or Spaces with verified source URLs where available; never construct URLs from internal identifiers or create sharing links merely for citations. Flag limited evidence and comparisons based on partial data. If there is no defensible outreach recommendation, say so and identify what would help resolve it.

## Draft personalized follow-ups when requested

Use document topics and verified contents to make each requested draft relevant. When contents are needed, call `read_document` once without `page`, download its `file_url` once, and analyze locally. Do not loop over all pages when full-file access is available. If content is inaccessible, do not invent details from the filename.

Keep drafts concise with a useful next step. Avoid unnecessarily exposing detailed tracking information, such as exact viewing time, visit count, or page-by-page behavior, to the recipient. Do not claim prior discussions, unanswered outreach, concerns, or commitments without supporting context. Include only verified, appropriate source links already available; do not create new access permissions to complete a draft.

Deliver requested reusable drafts in the appropriate writing-block format. Preparing or displaying a draft does not authorize sending it or saving it into an external messaging account.

## Boundaries and tool handling

Do not send outreach without explicit authorization and an available messaging capability. If sending is authorized, resolve the intended recipient and message from that authorization and obey the messaging tool's requirements. Report send failures or uncertain outcomes accurately; inspect available status before retrying an uncertain send to avoid duplicates.

Discover live schemas and obey access checks. On DocSend `insufficient_scope`, ask the user to re-authenticate before retrying. Check text errors as well as structured responses. Keep result fields named `id` or ending in `_id` internal. Prioritizing follow-ups does not authorize document changes, access changes, invitations, or scheduling. Do not call live write tools merely to test this skill.

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.

If the user requested suggestions, stop after the proposal. Otherwise ask the user to approve the proposed rename table before applying changes. A general request such as “find unclear file names and make them consistent” authorizes inspection and proposal preparation but does not substitute for approval of the proposed names. Once the user explicitly approves those changes and the convention is clear, apply only the approved rows without asking again for unchanged details. Ask only when an unresolved choice materially affects the result; leave unapproved or unresolved rows unchanged. If proposed names materially change after approval, obtain approval for those revised rows before applying them.

Use `rename_space_content` with `content_type: "document"` and the recorded document identifier, not name matching alone. Rename only the intended documents. If the tool returns a shared-document `confirmation_message`, explain the impact on other Spaces or links and obtain confirmation for that broader impact unless already explicitly authorized. Do not treat this response as a completed rename. After confirmation, retry the same change with `force: true`.

Verify resulting names with `list_space_content` in the affected folders. If a rename times out or its outcome is uncertain, inspect the current name before retrying. If an item changed since inspection, reassess instead of overwriting an unexpected name.

## Report results and boundaries

Report successful renames and failures separately, showing old and new names for successful changes. Separately identify skipped or unresolved items and why they remain unchanged. If no changes were needed, say so. Keep summaries concise and user friendly.

Do not move, delete, replace, or change access to documents as part of naming cleanup. Do not rename folders or sections unless separately requested. Discover current tool schemas and obey access checks; on `insufficient_scope`, ask the user to re-authenticate before retrying. Check text errors and structured responses before reporting success. Keep result fields named `id` or ending in `_id` internal. Do not call live write tools merely to test this skill.