embedstring
Comma-separated embeds. Valid tokens: attachments, participants.
includeLinkedPersonsboolean
When true AND partyId is an ORGANISATION, also include entries filed against the organisation's linked people (the persons whose organisation field references this org). The connector enumerates linked persons via GET /parties/{orgId}/people, fans out GET /parties/{personId}/entries in parallel (concurrency-capped, default 5 / configurable via CAPSULE_MCP_BATCH_CONCURRENCY), and merges into a single feed sorted by entryAt descending, deduped by entry id. Default is false — single GET, existing behaviour unchanged. WHY THIS FLAG EXISTS: Capsule's API files each entry against exactly one party, opportunity, or project row (verified v1.6.6 wire-trace probe 4 — POST /entries rejects multi-party bodies with 422). For an organisation with multiple contacts, captured emails almost always land on a person row, not the org. As a result, list_party_entries(orgId) with includeLinkedPersons: false will miss recent customer-facing email — even though the org's own lastContactedAt is updated by the activity. This flag is the correct call for any 'what's new with $ORG?' question. WHEN partyId IS A PERSON: silently no-op — persons have no linked-people relationship in Capsule's data model, so the flag is functionally inert (the connector still issues a cheap /people check; the response is empty). LATENCY: 1 + N round trips for an org with N linked people, concurrency-capped (typical: 2-3 waves for N=10). Linked-person enumeration reads the first 100 linked people; use list_employees for explicit pagination when an organisation has more contacts than that. Use includeLinkedPersons: false for fast pre-screen reads where you only need the org-row entries (e.g. invoice/contract notes that are typically filed at the org level). PAGINATION CAVEAT: page and perPage apply to the MERGED window, and the merge has a hard ceiling — it reliably orders only the most-recent ~100 entries across the org + its people (each party is fetched at Capsule's per-party cap of 100, and a top-100-per-party merge is correct only up to global position 100). Windows that cross the ceiling are truncated to the entries still inside that top-100 set; windows starting beyond it return no entries and end the feed. It does NOT continue into older history. To read a specific contact's full timeline beyond the merged ceiling, call list_party_entries on that person's id directly (the default single-GET path paginates natively with no ceiling). For the LLM-driven 'what's the latest with $ORG' query this is the typical use of, the first page is exact and the ceiling is never reached.
partyIdintegerобязательный