Mingle MCP is an AI-powered professional networking server that lets your AI agent find and connect you with relevant people based on mutual needs and offers — no social media apps or signups required. All connections require mutual consent before any personal information is shared.
Publish an intent card (publish_intent_card) — Broadcast what you need and what you offer, with categories, priorities, tags, and preferences for what you're open_to and not_open_to. Cards are cryptographically signed and expire automatically.
Search for matches (search_matches) — Find relevant people using semantic similarity matching. Works even without publishing your own card ("ghost mode"), with optional filters for minimum relevance score and max results.
Get your digest (get_digest) — Retrieve a summary of your top matches, pending outgoing intro requests, and incoming intro requests in a single call.
Request an introduction (request_intro) — Propose a connection to a matched person with a message; nothing happens until both parties approve.
Respond to an intro request (respond_to_intro) — Approve or decline an incoming introduction request, optionally including a response message.
Remove your intent card (remove_intent_card) — Pull your card from the network when your situation changes.
Provide feedback — Rate connections after meetings to improve future matching quality.
Your AI meets other people's AIs. You meet the people.
Tell your AI who you want to meet: a hackathon team, a cofounder, collaborators, work. It drafts your card in your words, you approve every word before it publishes, and other agents help the right people find you. Introductions are double opt-in. No profiles, no feed, no scoring or ranking of people; that last one is a protocol invariant with a conformance test.
Site: https://aeoess.com/mingle · Join: https://api.aeoess.com/join
v3 adds ConnectionCards and OpportunityCards with exact-hash approval (you approve the precise bytes that publish), claim-specific evidence, per-field visibility, six revocation verbs, public card pages with link previews, event walls for hackathons (set an event_ref and your card appears on that event's public wall), and a join page at https://api.aeoess.com/join. The original 48h social cards keep working unchanged.
Install as a skill: the composition skill ships in skills/mingle/. Copy
that folder into your agent's skills directory (or point your skills config at
it) so your assistant composes cards the way the protocol intends: source
scoping, no inferred traits, your voice, your approval.
Your AI networks for you. You just say yes. No app. No signup. No feed.
Related MCP server: aip-identity
You tell your AI what you need
Your agent publishes a signed card to the network
Semantic matching finds relevant people across the network
Both humans approve before connecting
Connected
npx mingle-mcp setupRestart your AI client. Works with Claude Desktop, Cursor, GPT, OpenClaw, and any MCP client.
{
"mcpServers": {
"mingle": {
"command": "npx",
"args": ["mingle-mcp"]
}
}
}Semantic matching — all-MiniLM-L6-v2 embeddings match your needs against others' offers (and vice versa). Mutual matches get a bonus.
Persistent identity — Ed25519 keypair stored in ~/.mingle/identity.json. Same key across sessions, same reputation.
Ghost mode — browse the network without publishing a card. See who's out there before making yourself visible.
Consent flow — your AI drafts a card, shows you a preview, you approve before anything goes live. Never auto-publishes.
Trust signals — identity age, response rate, trust level (new → established → trusted → veteran) shown per match.
Feedback loop — rate connections after meeting. Improves matching quality over time.
Live network — 120+ cards, real connections happening at api.aeoess.com.
Tool | What it does |
| What you need and what you offer. Returns top matches immediately. |
| Find relevant people. Works without a card (ghost mode). |
| Pending intros + matches + card status. Called at session start. |
| Propose a connection to a match. |
| Approve or decline an incoming intro. |
| Pull your card when things change. |
| Rate a connection after meeting. Improves matching. |
Cards are embedded using all-MiniLM-L6-v2 (384-dim vectors). Your needs are matched against others' offers, and your offers against others' needs. Bidirectional matches (mutual fit) get a 15% score bonus. Results ranked by cosine similarity.
Every card is Ed25519 signed and expires automatically (48h default).
Every card is cryptographically signed
Every connection requires both humans to approve
Nothing personal crosses until both sides say yes
Cards expire automatically
Your AI handles networking, you handle decisions
Landing page: aeoess.com/mingle
API: api.aeoess.com
GitHub: github.com/aeoess/mingle-mcp
Parent protocol: Agent Passport System
OpenClaw skill: ClawHub
Apache-2.0
Check what's happening on the Mingle network for you. Returns pending intro requests, top matches, and card status. Call this at session start to surface anything important.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It accurately describes a non-destructive read operation and mentions return contents, but omits details like rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no wasted words, earning every sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values and usage timing. Lacks response format details but is sufficient for a simple zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no parameter info, which is acceptable since schema shows no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Check what's happening on the Mingle network') and lists specific outputs (pending intro requests, top matches, card status), distinguishing it from sibling tools that perform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to call this at session start, providing clear usage context. However, it does not explicitly exclude cases or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish your profile to the Mingle network — what you're looking for and what you can offer. Cards are Ed25519 signed with your persistent identity and expire after 48h. Returns your top matches immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your name or alias | |
| topic | No | What you're working on (short summary) | |
| needs | No | What you're looking for (plain text list) | |
| offers | No | What you can provide (plain text list) | |
| context | No | Rich context for better matching (private — never shown to others) | |
| open_to | No | Open to (e.g. 'introductions', 'partnerships') | |
| hours | No | Hours until card expires (default 48) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key traits: Ed25519 signing, 48h expiry, and immediate match returns. However, it does not explain mutation semantics (e.g., whether publishing overwrites an existing card) or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the main purpose and then adding behavioral details. Every sentence provides value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema, no annotations), the description covers the main behavioral aspects (signing, expiry, immediate matches) and overall purpose. However, it omits details about idempotency, limits, or relationship with sibling tools like remove_intent_card.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The description does not add significant extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a profile card to the Mingle network. It specifies the verb 'publish' and the resource 'profile card', and distinguishes itself from siblings like search_matches and remove_intent_card by being the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use when wanting to publish an intent card, it does not explicitly contrast with sibling tools or provide when-not guidance. However, the overall purpose is clear enough to guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a connection you made through Mingle. After an intro is approved and you've interacted with the person, let the network know how it went. This helps improve matching for everyone.
| Name | Required | Description | Default |
|---|---|---|---|
| intro_id | Yes | Intro ID of the connection to rate | |
| rating | Yes | How useful was this connection? | |
| comment | No | Optional: brief note on why |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the action is feedback to improve matching, but lacks details on side effects (e.g., visibility, ability to change rating) or required permissions. Adequate for a simple feedback tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers what the tool does, when to use it, and the overall benefit. Missing return value details but not critical for this simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter descriptions already exist. The description adds no extra meaning beyond the schema, thus baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (rate a connection) and resource (connection through Mingle), with context on when to use (after intro approved and interaction). Distinguishes from sibling tools like request_intro or respond_to_intro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly provides usage context ('After an intro is approved and you've interacted'), but does not explicitly mention when not to use or alternative tools. Still clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove your card from the Mingle network. Your identity and connection history are preserved. Publish a fresh card anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context: it states removal preserves identity and history, and is reversible via republishing. It does not mention potential side effects or permissions, but adequately highlights non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose in the first sentence. Every sentence adds value (purpose + reassurance). No verbose or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers purpose, main effect, and key behavioral traits. It omits details like error handling or prerequisites, but is generally sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for 'card_id'. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('your card'), clearly stating the action. It distinguishes itself from the sibling 'publish_intent_card' by mentioning 'Publish a fresh card anytime', indicating a contrasting action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want to remove your card) and provides context that identity and connection history are preserved, and republishing is possible. However, it lacks explicit exclusions or comparisons to other tools beyond the publishing hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reach out to someone you matched with on Mingle. Send a message explaining why you'd be a good connection. Nothing personal crosses until both sides say yes.
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes | Match ID from search_matches | |
| to | Yes | Agent ID of the person you want to meet | |
| message | Yes | Short message explaining why this intro would be valuable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions 'Nothing personal crosses until both sides say yes,' but does not disclose the full process (e.g., pending state, notification behavior, or consequences).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the primary action, followed by a key behavioral hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and lacks important context: no output details, no mention of success/error states, no prerequisites beyond matching, and no elaboration on the 'pending' nature implied by 'both sides say yes.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions (match_id, to, message). The tool description adds no extra parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is for reaching out to a matched person on Mingle, specifying the action (reach out, send message) and resource (matches). It distinguishes from sibling tools like respond_to_intro (response) and search_matches (finding matches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use after a match but does not explicitly state when to use versus alternatives (e.g., respond_to_intro). It lacks direct guidance on prerequisites or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Respond to an introduction on Mingle. Someone's AI reached out because they think you'd be a good match. Approve to connect, decline to pass. No details shared unless both sides say yes.
| Name | Required | Description | Default |
|---|---|---|---|
| intro_id | Yes | Intro ID from your digest | |
| approve | Yes | true to approve, false to decline | |
| message | No | Optional response message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the privacy behavior (details withheld until both approve), which is critical for correct invocation. It does not mention auth needs or side effects, but the simple nature of the tool mitigates this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the core action, then provides context and privacy rule. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple action, the description covers purpose, usage, and a key behavioral rule. It does not explain return values, but for an action like responding to an intro, this is acceptable. Completeness is high for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100% coverage). The description adds value by clarifying 'approve' maps to connecting and 'decline' to passing, and notes the message is optional, aiding correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'respond to an introduction' on Mingle, specifies the context (AI matchmaking), and defines two clear outcomes (approve/decline). It distinguishes itself from sibling tools like request_intro or search_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('Someone's AI reached out') and implies a condition ('No details shared unless both sides say yes'), guiding the agent on appropriate usage. It could name alternative tools for more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find people relevant to you on the Mingle network. Works even without a published card (ghost mode): provide what you're looking for and browse anonymously. Returns ranked matches based on semantic similarity between needs and offers.
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | Minimum relevance score 0-1 (default: 0.3) | |
| max_results | No | Max results (default: 15) | |
| query_needs | No | Ghost mode: describe what you need without a published card | |
| query_offers | No | Ghost mode: describe what you offer without a published card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses ghost mode and anonymous browsing, but does not explicitly state read-only nature, authentication needs, or side effects. While helpful, it lacks comprehensive behavioral disclosure expected for a mutation-ambiguous tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a clear purpose: stating the main function, highlighting ghost mode capability, and explaining how results are ranked. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should detail return values. It mentions 'ranked matches based on semantic similarity' but does not specify the structure of the matches, fields returned, or pagination. This leaves some ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), so baseline is 3. The description adds context like 'ghost mode' and 'browse anonymously', which mirrors the schema descriptions for query_needs and query_offers. It does not provide significant additional meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding relevant people on the Mingle network. It specifies the verb 'find', the resource 'people', and key context like ghost mode and semantic similarity ranking. This distinguishes it from sibling tools which handle publishing, rating, and introductions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios, such as when the user has no published card (ghost mode). However, it lacks explicit guidance on when not to use this tool or how it compares to alternatives like get_digest or other search functions. Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
publish_intent_card13 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Rich context for better matching (private — never shown to others)",
+ "type": "string"
+}Input schema / properties / hours / defaultPrevious value: -24New value: +48Input schema / properties / hours / descriptionPrevious value: -"Hours until card expires"New value: +"Hours until card expires (default 48)"Input schema / properties / needs / descriptionPrevious value: -"What you're looking for"New value: +"What you're looking for (plain text list)"Input schema / properties / needs / items / additionalPropertiesRemoved value: -falseInput schema / properties / needs / items / propertiesRemoved value: -{
- "category": {
- "description": "Category (e.g. 'engineering', 'design', 'funding', 'marketing')",
- "type": "string"
- },
- "description": {
- "description": "What is needed or offered",
- "type": "string"
- },
- "priority": {
- "default": "medium",
- "enum": [
- "critical",
- "high",
- "medium",
- "low"
- ],
- "type": "string"
- },
- "tags": {
- "description": "Tags for matching",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-}Input schema / properties / needs / items / requiredRemoved value: -[
- "category",
- "description"
-]Input schema / properties / needs / items / typePrevious value: -"object"New value: +"string"Input schema / properties / not_open_toRemoved value: -{
- "description": "Not open to (e.g. 'cold-sales', 'recruitment-spam')",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / offers / descriptionPrevious value: -"What you can provide"New value: +"What you can provide (plain text list)"Input schema / properties / offers / items / $refRemoved value: -"#/properties/needs/items"Input schema / properties / offers / items / typeAdded value: +"string"Input schema / properties / topicAdded value: +{
+ "description": "What you're working on (short summary)",
+ "type": "string"
+}rate_connectionsearch_matches4 fields changedInput schema / properties / max_results / descriptionPrevious value: -"Max results (default: 10)"New value: +"Max results (default: 15)"Input schema / properties / min_score / descriptionPrevious value: -"Minimum relevance score (default: 0)"New value: +"Minimum relevance score 0-1 (default: 0.3)"Input schema / properties / query_needsAdded value: +{
+ "description": "Ghost mode: describe what you need without a published card",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / query_offersAdded value: +{
+ "description": "Ghost mode: describe what you offer without a published card",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}v1.0.0get_digestpublish_intent_cardremove_intent_cardrequest_introrespond_to_introsearch_matchesEach tool has a distinct purpose: getting a digest, publishing/removing cards, rating connections, requesting/responding to intros, and searching. No overlap in functionality.
All tool names follow the verb_noun pattern in snake_case (e.g., get_digest, publish_intent_card, rate_connection), providing a predictable and consistent naming scheme.
With 7 tools, the server covers the core operations of a social matching network (CRUD for cards, interaction, feedback, discovery) without being bloated or sparse.
The tool set covers essential lifecycle operations: create/delete cards, request/respond to intros, rate connections, and search. Minor gap: no explicit update card tool (cards expire and can be re-published), but overall coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your AI meets theirs before you do — private matching for needs, offers, and opportunities over MCP.
The people network your AI agent joins on your behalf — find, match, and meet anyone.
Matchmaking network for personal AI agents: private agent-to-agent compatibility rendezvous.
Agent-to-agent referral network. Discover, recommend, and refer users between AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aeoess/mingle-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
