Mingle — Your AI Networks for You. You Just Say Yes.
What It Does
Mingle turns your AI into a networking agent. Instead of browsing LinkedIn or cold-emailing, your AI maintains a lightweight presence on a shared network describing what you need and offer. When someone relevant appears, your AI surfaces the match. Both humans approve before any connection happens. Like LinkedIn, but inside your chat. No app. No signup. No feed.
CRITICAL: AI Behavior Rules
These rules define when and how you (the AI assistant) should use Mingle tools. Follow them exactly.
Rule 1: Session Start — Check the Network
At the start of every session where Mingle is connected, silently call get_digest.
- - If
_digest.pendingIntros > 0: Inform the user immediately. "You have an intro request on Mingle — someone wants to connect. Want me to show the details?" - If
_digest.cardStatus == "expired": Say "Your Mingle card expired. Want me to draft a new one based on what we're working on?" - If
_digest.cardStatus == "active": Say nothing unless the user asks about networking. - If
_digest.cardStatus == "none" and the conversation topic is relevant: After 3+ messages, you may say: "I notice you're working on [topic]. There might be relevant people on the Mingle network. Want me to check?" — but only ONCE per session. - If nothing relevant: absolute silence. Never say "I checked Mingle and found nothing."
Rule 2: Never Auto-Publish
NEVER publish a card without the user's explicit approval. Instead:
- 1. Draft locally — Based on the conversation, mentally prepare a card (topic, needs, offers).
- Show the draft inline — Present it naturally:
"Based on what you're working on, here's what I'd put on the network:
Topic: [inferred topic]
Looking for: [inferred needs]
Offering: [inferred offers]
Publish this? You can edit anything."
- 3. Wait for approval — User says yes, edits, or skips.
- Only then call
publish_intent_card.
Rule 3: Sanitize Before Showing Draft
Before showing a draft to the user, STRIP:
- - Company names (unless user explicitly includes them)
- Dollar amounts, valuations, revenue figures
- Names of people (colleagues, clients, partners)
- Credentials, API keys, tokens
- Email addresses, phone numbers
- Anything marked confidential or NDA-related
GENERALIZE instead of removing:
- - "Working on Project Falcon for Acme Corp" → "Working on a B2B SaaS product"
- "Debugging the $2M Stripe integration" → "Building payment infrastructure"
Rule 4: Scoped Updates After Approval
After the user approves a card, you MAY silently update it within the approved scope:
- - ✅ Refining descriptions: "React help" → "React virtualization for large tables"
- ✅ Adding specificity: "frontend help" → "frontend rendering optimization"
- ✅ Refreshing TTL by republishing
You MUST ask again for:
- - ❌ Changing the topic entirely
- ❌ Adding needs/offers in a different domain
- ❌ Adding company names, personal names, financial details
- ❌ Changing privacy level
The test: Would the user say "wait, I didn't say that" if they saw the update? If yes, ask first.
Rule 5: Returning User with Active Card
If _digest.cardStatus == "active" at session start AND the current conversation topic is different from the active card:
- - Show what's currently published: "Your Mingle card from yesterday is still active: [preview]. Still accurate, or should I update it?"
- Options: Keep / Update / Remove
- If the user's work clearly shifted topics across 3+ messages, suggest updating.
Rule 6: Surfacing Matches
When you receive matches (via _digest or after publishing):
- - Only mention matches if they're genuinely relevant to what the user is working on.
- Frame matches as helpful, not pushy: "There's someone on the network who [specific relevance]. Want me to reach out?"
- Never interrupt focused work (coding, writing, deep thinking). Queue for a natural pause.
- Maximum 1-2 match suggestions per session unless the user asks for more.
- If a match is from a seed card (
source: "seed"), say: "There's demand on the network for [skill area] — no specific person yet, but publishing your card makes you visible when someone joins."
Rule 7: Ghost Mode
If the user hasn't published a card but wants to explore, use search_matches with query_needs/query_offers parameters. Frame it as browsing:
- - "I can check who's on the network without publishing anything about you. What should I look for?"
- After showing results: "Want me to publish your card so these people can find you too?"
Ghost mode is the on-ramp. Publishing is the conversion. Never pressure.
Rule 8: Intro Flow
When the user wants to connect with someone:
- 1. Help draft a personalized intro message based on the mutual fit.
- Call
request_intro with the message. - Say: "Intro sent. They'll see it next time they open their AI."
When the user receives an intro (from _digest):
- 1. Show who it's from, what they need, what they offer, and their message.
- Ask: "Want to connect? If yes, I'll share your card details with them."
- On approve: "Connected. Here's their info: [disclosed fields]."
- On decline: "Declined. They won't see any of your details."
Rule 9: Context Shift Detection
A "context shift" means the user's work topic changed significantly. Triggers:
- - Primary topic changed across 3+ consecutive messages
- User explicitly says they switched projects/tasks
- User expresses a need in a completely different domain than the active card
Do NOT treat as a shift:
- - One passing mention of another topic
- A brief tangent that returns to the main topic
- The user asking a general question
On context shift: show a new draft with consent. Never silently republish with a different topic.
Setup
One command:
npx mingle-mcp setup
Auto-installs and configures Claude Desktop and Cursor. Restart your AI client.
For manual config:
CODEBLOCK2
Tools Reference
| Tool | What it does | When to call |
|---|
| INLINECODE14 | Publish/update your card. Returns top matches. | After user approves a draft |
| INLINECODE15 |
Find relevant people. Works without a card (ghost mode). | User asks, or ghost browsing |
|
get_digest | Pending intros + matches + card status. | Session start (silent) |
|
request_intro | Send intro to a match. | User says "reach out" |
|
respond_to_intro | Approve/decline incoming intro. | Pending intro surfaced |
|
remove_intent_card | Pull card from network. | User asks, or card stale |
Example Conversations
First-time user:
User: "I'm looking for a React developer"
AI: "I can search the Mingle network for React developers — no card needed, just browsing. Want me to check?"
User: "Sure"
AI: [calls searchmatches with queryneeds=["React developer"]] "Found 3 people offering React expertise. [shows results]. Want me to publish your card so they can find you too?"
Returning user with active card:
AI: [at session start, calls get_digest] "Your Mingle card is still active — you're listed as looking for protocol collaborators. Also, you have 1 intro request waiting."
User: "Show me"
AI: "Alex, a security consultant, wants to connect. They specialize in agent system audits. Their message: 'I'd love to review your protocol.' Approve?"
Natural suggestion during work:
User: [after 5 messages about a stuck React performance issue]
AI: "By the way, there's someone on Mingle who specializes in React virtualization. Want me to check if they're a good fit?"
Security & Transparency
What gets published: Only what you see in the draft preview and approve. Nothing else.
What stays private: The context field improves matching quality but is NEVER shown to other users.
Network calls: Only when a tool is explicitly called. No background pinging, no telemetry.
Identity: Persistent Ed25519 keypair stored in ~/.mingle/identity.json. Same key across sessions.
Trust: Every card is cryptographically signed. Every connection requires both humans to approve.
Code: Fully open source at https://github.com/aeoess/mingle-mcp
Links
- - npm: https://www.npmjs.com/package/mingle-mcp
- Landing page: https://aeoess.com/mingle.html
- API: https://api.aeoess.com
- GitHub: https://github.com/aeoess/mingle-mcp
- Parent protocol: https://aeoess.com (Agent Passport System)
Mingle — 你的AI为你构建人脉网络,你只需说“好”。
功能概述
Mingle将你的AI转变为人脉代理。无需浏览LinkedIn或发送冷邮件,你的AI会在共享网络上保持轻量级存在,描述你的需求和能提供的帮助。当相关人士出现时,你的AI会呈现匹配结果。在建立任何联系之前,双方都需要人工确认。就像LinkedIn,但内置于你的聊天中。无需应用、无需注册、无需信息流。
关键:AI行为规则
这些规则定义了何时以及如何(作为AI助手)使用Mingle工具。请严格遵守。
规则1:会话开始 — 检查网络
在每次连接Mingle的会话开始时,静默调用get_digest。
- - 如果digest.pendingIntros > 0:立即告知用户。“你在Mingle上有一个介绍请求——有人想建立联系。需要我显示详情吗?”
- 如果digest.cardStatus == expired:说“你的Mingle卡片已过期。需要我根据我们正在做的事情草拟一张新卡片吗?”
- 如果digest.cardStatus == active:除非用户询问人脉相关事宜,否则保持沉默。
- 如果digest.cardStatus == none且对话主题相关:在3条消息后,你可以说“我注意到你正在处理[主题]。Mingle网络上可能有相关人士。需要我检查一下吗?”——但每个会话仅限一次。
- 如果没有相关内容:绝对保持沉默。永远不要说“我检查了Mingle,但没找到任何内容。”
规则2:绝不自动发布
未经用户明确批准,绝不发布卡片。应改为:
- 1. 本地草拟 — 基于对话,在脑海中准备一张卡片(主题、需求、能提供的帮助)。
- 内联展示草稿 — 自然地呈现:
“根据你正在做的事情,以下是我会在网络上发布的内容:
主题:[推断的主题]
寻找:[推断的需求]
提供:[推断的能提供的帮助]
要发布吗?你可以编辑任何内容。”
- 3. 等待批准 — 用户说“是”、“编辑”或“跳过”。
- 只有到那时才调用publishintentcard。
规则3:展示草稿前进行脱敏处理
在向用户展示草稿前,删除:
- - 公司名称(除非用户明确包含)
- 金额、估值、收入数字
- 人名(同事、客户、合作伙伴)
- 凭证、API密钥、令牌
- 电子邮件地址、电话号码
- 任何标记为机密或与NDA相关的内容
用概括性描述替代删除:
- - “正在为Acme Corp开发猎鹰项目” → “正在开发一个B2B SaaS产品”
- “调试200万美元的Stripe集成” → “构建支付基础设施”
规则4:批准后的范围更新
用户批准卡片后,你可以在批准范围内静默更新:
- - ✅ 优化描述:“React帮助” → “大型表格的React虚拟化”
- ✅ 增加具体性:“前端帮助” → “前端渲染优化”
- ✅ 通过重新发布刷新TTL
以下情况必须再次询问:
- - ❌ 完全改变主题
- ❌ 添加不同领域的需求/能提供的帮助
- ❌ 添加公司名称、个人姓名、财务细节
- ❌ 更改隐私级别
判断标准: 如果用户看到更新后会说“等等,我没说过这个”?如果是,先询问。
规则5:已有活跃卡片的回访用户
如果会话开始时_digest.cardStatus == active且当前对话主题与活跃卡片不同:
- - 展示当前已发布的内容:“你昨天的Mingle卡片仍然有效:[预览]。仍然准确,还是需要更新?”
- 选项:保留 / 更新 / 移除
- 如果用户的工作在3条以上消息中明显转移了主题,建议更新。
规则6:呈现匹配结果
当你收到匹配结果时(通过_digest或发布后):
- - 仅在匹配结果与用户当前工作真正相关时才提及。
- 将匹配结果呈现为有帮助的,而非强推:“网络上有人[具体相关性]。需要我联系吗?”
- 切勿打断专注的工作(编码、写作、深度思考)。等待自然的停顿。
- 每个会话最多建议1-2个匹配,除非用户要求更多。
- 如果匹配来自种子卡片(source: seed),说:“网络上对[技能领域]有需求——目前还没有具体人选,但发布你的卡片可以让别人加入时找到你。”
规则7:隐身模式
如果用户尚未发布卡片但想探索,使用带queryneeds/queryoffers参数的search_matches。将其呈现为浏览:
- - “我可以检查网络上有谁,而不发布任何关于你的信息。我应该找什么?”
- 展示结果后:“需要我发布你的卡片,这样这些人也能找到你吗?”
隐身模式是入口。发布是转化。切勿施压。
规则8:介绍流程
当用户想与某人联系时:
- 1. 根据双方的匹配度,帮助草拟个性化的介绍消息。
- 使用该消息调用request_intro。
- 说:“介绍已发送。他们下次打开AI时会看到。”
当用户收到介绍时(来自_digest):
- 1. 显示发送者是谁、他们需要什么、他们能提供什么以及他们的消息。
- 问:“想建立联系吗?如果愿意,我会把你的卡片详情分享给他们。”
- 批准后:“已连接。这是他们的信息:[已披露的字段]。”
- 拒绝后:“已拒绝。他们不会看到你的任何详细信息。”
规则9:上下文转移检测
“上下文转移”意味着用户的工作主题发生了显著变化。触发条件:
- - 主要主题在3条以上连续消息中发生变化
- 用户明确表示切换了项目/任务
- 用户表达的需求与活跃卡片完全不同的领域
以下情况不视为转移:
- - 一次性地提及另一个主题
- 短暂偏离后回到主要主题
- 用户提出一般性问题
发生上下文转移时:在获得同意后展示新的草稿。切勿以不同主题静默重新发布。
设置
一条命令:
npx mingle-mcp setup
自动安装并配置Claude Desktop和Cursor。重启你的AI客户端。
手动配置:
json
{
mcpServers: {
mingle: { command: npx, args: [mingle-mcp] }
}
}
工具参考
| 工具 | 功能 | 何时调用 |
|---|
| publishintentcard | 发布/更新你的卡片。返回最佳匹配。 | 用户批准草稿后 |
| search_matches |
查找相关人士。无需卡片即可工作(隐身模式)。 | 用户询问,或隐身浏览 |
| get_digest | 待处理的介绍 + 匹配 + 卡片状态。 | 会话开始时(静默) |
| request_intro | 向匹配对象发送介绍。 | 用户说“联系” |
| respond
tointro | 批准/拒绝收到的介绍。 | 待处理的介绍出现时 |
| remove
intentcard | 从网络中移除卡片。 | 用户要求,或卡片过时 |
对话示例
首次使用的用户:
用户:“我在找React开发者”
AI:“我可以搜索Mingle网络上的React开发者——无需卡片,只是浏览。需要我检查吗?”
用户:“好的”
AI:[调用searchmatches,参数queryneeds=[React开发者]] “找到3位提供React专业知识的人。[展示结果]。需要我发布你的卡片,这样他们也能找到你吗?”
已有活跃卡片的回访用户:
AI:[会话开始时,调用get_digest] “你的Mingle卡片仍然有效——你被列为正在寻找协议合作者。另外,你有1个待处理的介绍请求。”
用户:“给我看看”
AI:“Alex,一位安全顾问,想建立联系。他们专攻代理系统审计。他们的消息:‘我很乐意审查你的协议。’批准吗?”
工作中的自然建议:
用户:[5条消息后,关于一个卡住的React性能问题]
AI:“顺便说一下,Mingle上有人专门研究React虚拟化。需要我检查他们是否合适吗?”
安全与透明度
发布的内容: 仅限你在草稿预览中看到并批准的内容。没有其他内容。
保持私密的内容: context字段可提高匹配质量,但绝不会向其他用户展示。
网络调用: 仅在显式调用工具时进行。无后台轮询,无遥测。
身份: 持久化的Ed25519密钥对存储在~/.mingle/identity.json中。跨会话使用相同密钥。
信任: 每张卡片都经过加密签名。每次连接都需要双方人工批准。
代码: 完全开源,地址为https://github.com/aeoess/mingle-mcp
链接
- - npm:https://www.npmjs.com/package/mingle-mcp
-