Skip to main content
Glama

mutual_introduction_email

Craft emails to connect two people in your network. Choose double opt-in for high-value introductions or direct for low-stakes connections, with a clear reason to connect.

Instructions

Write the email you send when you're connecting two people in your network — as the connector, not the person being introduced. Distinct from introduction_email (your reply when someone introduces you to a prospect). Common use: connecting a past client with a supplier, two founders who share a problem, a contact with a potential collaborator, or two clients who'd benefit from knowing each other. Two modes: double_opt_in (default — send to each person separately first, checking they're open to the intro before making it; standard best practice for high-value relationships and mutual respect) or direct (one email to both people at the same time; fine when you know both parties well and the introduction is low-stakes). For double_opt_in, use the target parameter to specify which person this individual email is addressed to. Required: person_a_name (first person being introduced), person_b_name (second person), reason_to_connect (why these two people should meet — be specific; 'they're both in tech' is weak, 'you're both solving the same cold-outreach problem from opposite angles' is strong). Optional: person_a_description (what Person A does — one line), person_b_description (what Person B does — one line), mode ('double_opt_in' | 'direct' — default double_opt_in), target (for double_opt_in only: 'a' or 'b' — which person this email is going to; default 'a'), your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
person_a_nameYesFirst name of the first person being introduced
person_b_nameYesFirst name of the second person being introduced
reason_to_connectYesWhy these two people should meet — be specific. 'They're both in marketing' is weak; 'you're both trying to solve the same client-onboarding problem from opposite sides' is strong.
person_a_descriptionNoOptional: one-line description of what Person A does — e.g. 'runs a boutique UX studio', 'heads product at a Series A fintech'. Used to give context to Person B (or the opt-in request to Person A).
person_b_descriptionNoOptional: one-line description of what Person B does — e.g. 'freelance brand strategist', 'co-founder of a B2B SaaS startup'. Used to give context to Person A (or the opt-in request to Person B).
modeNodouble_opt_in (default): send to each person individually first, checking they want the intro before making it — best practice for high-value relationships. direct: one email addressed to both at the same time — fine when you know both well and the intro is low-stakes.
targetNoFor double_opt_in mode only: which person this email is going to — 'a' (asking Person A if they'd like to meet Person B) or 'b' (asking Person B if they'd like to meet Person A). Defaults to 'a'. Ignored in direct mode.
your_nameNoOptional: your name for the sign-off
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the two modes of operation, the draft property (does not count against monthly draft limit), and provides details on how parameters affect behavior. The only minor gap is ambiguity about whether it actually sends or drafts, but overall it is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured: it opens with the core purpose, distinguishes from sibling, outlines common use cases, then explains modes and parameters. Every sentence serves a purpose, though some redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, two modes, and no output schema, the description covers all essential aspects: purpose, usage scenarios, parameter explanations (including examples), mode behavior, and the draft limit. It is comprehensive and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the reason_to_connect with a strong vs weak example, clarifying the use of person_a_description and person_b_description, and detailing the mode and target parameters with specific guidance. This goes well beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool writes the email when you are connecting two people in your network as the connector, not the person being introduced. It uses a specific verb-resource combination and explicitly distinguishes itself from the sibling tool introduction_email.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use double_opt_in mode (default, best practice for high-value relationships) vs direct mode (fine when you know both parties well and the intro is low-stakes). It also contrasts with introduction_email, providing clear usage context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/proposalcraft'

If you have feedback or need assistance with the MCP directory API, please join our Discord server