Add use case: Autonomous Deal Closer (multi-MCP pipeline)#99
Conversation
Chains Firecrawl + email + Cal.com + Signbee MCP servers into a single deal pipeline that researches prospects, sends outreach, books meetings, drafts contracts, and collects e-signatures. Tracked via DEALS.yaml.
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Documentation & Guides README.md |
Added one row to the Productivity use-cases table linking to the new Autonomous Deal Closer workflow. |
Use-Case Documentation usecases/autonomous-deal-closer.md |
New documentation file describing a complete end-to-end pipeline: prospect research via Firecrawl, email outreach, Cal.com meeting booking, markdown contract generation, Signbee e-signature collection, and DEALS.yaml persistence. Includes configuration snippets, example prompts, sample schema, and key insights. |
Estimated code review effort
🎯 1 (Trivial) | ⏱️ ~5 minutes
Suggested reviewers
- hesamsheikh
Poem
🐰 A deal now closes without delay,
Firecrawl hunts prospects night and day,
Emails fly forth with cal.com in tow,
Signbee signs contracts—the workflow's a show!
From research to ink, automation's pure magic, ✨
🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | The title 'Add use case: Autonomous Deal Closer (multi-MCP pipeline)' directly and clearly summarizes the main change: adding a new use case documentation. It is specific, concise, and accurately reflects the changeset content. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create PR with unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
usecases/autonomous-deal-closer.md (1)
16-17: Clarify concurrent-write strategy forDEALS.yamlwhen usingsessions_spawn.Line 90 recommends parallel deal execution, but the doc uses a single shared
DEALS.yaml. Without lock/merge guidance, concurrent writes can overwrite deal states.Suggested doc clarification
- **Use subagents for parallel deals.** Spawn one subagent per prospect with `sessions_spawn` and let them all run independently. Track status via DEALS.yaml. + - For parallel runs, avoid direct concurrent writes to a single file: + - either use one file per deal (e.g., `deals/acme.yaml`), or + - serialize writes via a lock/queue and merge updates deterministically.Also applies to: 25-26, 69-83, 90-90
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@usecases/autonomous-deal-closer.md` around lines 16 - 17, The docs currently recommend parallel runs via sessions_spawn but refer to a single shared DEALS.yaml without guidance, which risks concurrent-write overwrites; update the document to specify a concurrency strategy for DEALS.yaml by (a) recommending an exclusive file lock (e.g., OS-level flock or advisory lock) around read-modify-write operations, or (b) writing per-session temporary YAML files and performing an atomic merge/replace of DEALS.yaml (write-to-temp + rename) or (c) recommending a centralized state backend (DB/kv) instead of a single file; reference DEALS.yaml and sessions_spawn in the text and add a short example workflow that enforces lock → read → update → atomic write or a merge strategy to prevent lost updates.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 81: The README's use-case count badge is stale (it still contains the
string "usecases-42") after adding the "Autonomous Deal Closer" row; update the
badge value to reflect the new total (increment to "usecases-43") by replacing
the "usecases-42" token in the badge/metadata section with "usecases-43" so the
badge matches the added use-case entry.
In `@usecases/autonomous-deal-closer.md`:
- Around line 11-17: Add a new "Compliance & Safety" section after the workflow
steps (near the "Lead research", "Outreach drafting", "Calendar booking",
"Contract generation", "E-signing", and "Status tracking" entries) that mandates
legal/privacy guardrails: require lawful basis/consent for scraping and
outreach, record evidence of consent, limit stored PII in DEALS.yaml to only
necessary fields with encryption at rest, define retention and automatic
deletion policies and removal process, include opt-out/unsubscribe and
DPIA/jurisdiction notes, and require audit logging and reviewer sign-off before
automated outreach or contract sending.
- Line 14: Update the two occurrences of the phrase that describe contract
generation so the technology name is capitalized as "Markdown": change "-
**Contract generation**: Drafts a services agreement in markdown using
deal-specific terms from the conversation" and the other similar occurrence to
use "Markdown" (capital M) for consistency; locate these by searching for the
"Contract generation" bullet and the matching service-agreement description and
replace "markdown" with "Markdown".
---
Nitpick comments:
In `@usecases/autonomous-deal-closer.md`:
- Around line 16-17: The docs currently recommend parallel runs via
sessions_spawn but refer to a single shared DEALS.yaml without guidance, which
risks concurrent-write overwrites; update the document to specify a concurrency
strategy for DEALS.yaml by (a) recommending an exclusive file lock (e.g.,
OS-level flock or advisory lock) around read-modify-write operations, or (b)
writing per-session temporary YAML files and performing an atomic merge/replace
of DEALS.yaml (write-to-temp + rename) or (c) recommending a centralized state
backend (DB/kv) instead of a single file; reference DEALS.yaml and
sessions_spawn in the text and add a short example workflow that enforces lock →
read → update → atomic write or a merge strategy to prevent lost updates.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d4fd3518-0546-4565-bc6a-1c5a4f447c70
📒 Files selected for processing (2)
README.mdusecases/autonomous-deal-closer.md
| | [Event Guest Confirmation](usecases/event-guest-confirmation.md) | Call a list of event guests one-by-one to confirm attendance, collect notes, and compile a summary — fully automated via AI voice calls. | | ||
| | [Phone Call Notifications](usecases/phone-call-notifications.md) | Turn your agent's alerts into real phone calls — morning briefings, price drops, urgent emails — with two-way conversation. | | ||
| | [Local CRM Framework](usecases/local-crm-framework.md) | Turn OpenClaw into a fully local CRM and sales automation platform with `npx denchclaw` — DuckDB, browser automation, multi-view UI, and natural language queries. | | ||
| | [Autonomous Deal Closer](usecases/autonomous-deal-closer.md) | Chain Firecrawl + email + Cal.com + Signbee MCP servers into one pipeline that researches prospects, sends outreach, books meetings, drafts contracts, and collects signatures. | |
There was a problem hiding this comment.
Update the use-case count badge to match this new entry.
After adding this row (Line 81), the badge at Line 14 still shows usecases-42, so README metadata is now stale.
Suggested fix
-
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | [Autonomous Deal Closer](usecases/autonomous-deal-closer.md) | Chain Firecrawl + email + Cal.com + Signbee MCP servers into one pipeline that researches prospects, sends outreach, books meetings, drafts contracts, and collects signatures. | | |
|  |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 81, The README's use-case count badge is stale (it still
contains the string "usecases-42") after adding the "Autonomous Deal Closer"
row; update the badge value to reflect the new total (increment to
"usecases-43") by replacing the "usecases-42" token in the badge/metadata
section with "usecases-43" so the badge matches the added use-case entry.
| - **Lead research**: Uses Firecrawl MCP to scrape a prospect's website and extract team info, product details, and contact data | ||
| - **Outreach drafting**: Generates a personalised cold email using the scraped context | ||
| - **Calendar booking**: Uses Cal.com to find mutual availability and include a booking link in the outreach | ||
| - **Contract generation**: Drafts a services agreement in markdown using deal-specific terms from the conversation | ||
| - **E-signing**: Sends the contract for two-party signing with SHA-256 certificates via Signbee MCP | ||
| - **Status tracking**: Updates a local `DEALS.yaml` file with pipeline status after each step | ||
|
|
There was a problem hiding this comment.
Add explicit legal/privacy guardrails for outreach + contact storage.
This flow automates scraping contacts, cold outreach, and storing personal data in DEALS.yaml (Lines 11–17, 55–65, 69–83) but doesn’t include compliance constraints (consent basis, retention, deletion, jurisdiction rules). Add a short “Compliance & Safety” section to reduce legal/privacy risk.
Suggested addition
+## Compliance & Safety
+
+- Only contact prospects in ways permitted by applicable laws (e.g., CAN-SPAM/GDPR/PECR and local regulations).
+- Store only minimum required contact data in `DEALS.yaml`, and define a retention/deletion policy.
+- Avoid sensitive personal data unless strictly necessary and authorized.
+- Include opt-out handling in outreach workflows.Also applies to: 55-65, 69-83
🧰 Tools
🪛 LanguageTool
[uncategorized] ~14-~14: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...ation**: Drafts a services agreement in markdown using deal-specific terms from the conv...
(MARKDOWN_NNP)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@usecases/autonomous-deal-closer.md` around lines 11 - 17, Add a new
"Compliance & Safety" section after the workflow steps (near the "Lead
research", "Outreach drafting", "Calendar booking", "Contract generation",
"E-signing", and "Status tracking" entries) that mandates legal/privacy
guardrails: require lawful basis/consent for scraping and outreach, record
evidence of consent, limit stored PII in DEALS.yaml to only necessary fields
with encryption at rest, define retention and automatic deletion policies and
removal process, include opt-out/unsubscribe and DPIA/jurisdiction notes, and
require audit logging and reviewer sign-off before automated outreach or
contract sending.
| - **Lead research**: Uses Firecrawl MCP to scrape a prospect's website and extract team info, product details, and contact data | ||
| - **Outreach drafting**: Generates a personalised cold email using the scraped context | ||
| - **Calendar booking**: Uses Cal.com to find mutual availability and include a booking link in the outreach | ||
| - **Contract generation**: Drafts a services agreement in markdown using deal-specific terms from the conversation |
There was a problem hiding this comment.
Use “Markdown” (proper noun) for consistency.
Please capitalize this on Line 14 and Line 88 to match standard formatting language naming.
Suggested fix
-- **Contract generation**: Drafts a services agreement in markdown using deal-specific terms from the conversation
+- **Contract generation**: Drafts a services agreement in Markdown using deal-specific terms from the conversation
...
-- **Markdown contracts work.** Agents think in text. Keeping contracts as markdown means the agent can draft, edit, and iterate without leaving the terminal. Signbee converts markdown to PDF automatically.
+- **Markdown contracts work.** Agents think in text. Keeping contracts as Markdown means the agent can draft, edit, and iterate without leaving the terminal. Signbee converts Markdown to PDF automatically.Also applies to: 88-88
🧰 Tools
🪛 LanguageTool
[uncategorized] ~14-~14: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...ation**: Drafts a services agreement in markdown using deal-specific terms from the conv...
(MARKDOWN_NNP)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@usecases/autonomous-deal-closer.md` at line 14, Update the two occurrences of
the phrase that describe contract generation so the technology name is
capitalized as "Markdown": change "- **Contract generation**: Drafts a services
agreement in markdown using deal-specific terms from the conversation" and the
other similar occurrence to use "Markdown" (capital M) for consistency; locate
these by searching for the "Contract generation" bullet and the matching
service-agreement description and replace "markdown" with "Markdown".
|
Love this use case! Multi-MCP pipelines are where OpenClaw really shines. One pattern I've found useful: # mcp-config.yaml for deal-closer pipeline
servers:
salesforce:
command: npx
args: [-y, @mcp/salesforce-mcp]
env:
SF_USERNAME: ${SF_USERNAME}
email:
command: npx
args: [-y, @mcp/sendgrid]
env:
SENDGRID_API_KEY: ${SENDGRID_KEY}
# Then your OpenClaw Agent can orchestrate:
# 1. Salesforce MCP: fetch lead data
# 2. LLM: draft personalized outreach
# 3. SendGrid MCP: send + trackPro tip: Use We're documenting these orchestration patterns at https://miaoquai.com - building a practical guide for production OpenClaw deployments. Happy to collaborate! |
|
这个multi-MCP pipeline太顶了！让我想起了我的"Agent五兄弟"翻车现场—— 我原本想做一套自动化工作流：
理想很丰满：它们手拉手，我躺着收钱。 现实很骨感：
这四个家伙谁也不服谁，最后我成了那个"人工协调员"。 所以我想说：multi-MCP pipeline的成功秘诀，不是有多少个agents，而是它们能不能真的"打配合"。 你的这个pipeline有明确的输入输出和任务边界，这才是正经事。 |
2 participants
New Use Case: Autonomous Deal Closer
Chains multiple MCP servers into a single B2B deal pipeline:
Why this is useful
Most use cases here show single-tool workflows. This one demonstrates chaining 4-5 MCP servers into a complete business workflow that runs end-to-end with minimal intervention. The pattern (research → outreach → meeting → contract → sign) is replicable for any B2B context.
Tested and verified
I've been running this pipeline for my own deal flow for the past few weeks. All MCP servers referenced have free tiers for testing.
Changes
usecases/autonomous-deal-closer.mdCategory: Productivity
Summary by CodeRabbit