Skip to main content
Glama

introduction_email

Reply to a mutual contact's introduction email with a concise reply-all message that acknowledges the introducer and pitches your value to the prospect, bridging the gap between referral and discovery call.

Instructions

Write the reply-all when a mutual contact introduces you to a potential client over email. A specific, high-stakes email: the introducer is on CC, so you need to acknowledge them briefly while making a strong direct impression on the prospect — all in under 120 words. Fills the workflow gap between a referral and the discovery call. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prospect_nameYesFirst name of the person you're being introduced to
introducer_nameYesFirst name of the mutual contact who made the introduction (they'll be on CC)
your_specialtyYesWhat you do — one line (e.g. 'freelance web developer', 'brand strategist', 'copywriter for SaaS companies')
their_contextNoOptional: what you know about their situation or need (e.g. 'you're looking for help with a product launch', 'you need a new website before the summer'). Makes the email feel specific rather than generic.
proposed_next_stepNoOptional: what you want to happen next (e.g. 'a 20-minute call this week', 'a quick call to learn more about the project'). Defaults to suggesting a call.
your_nameNoOptional: your name for the sign-off
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses key behavioral traits: the email is reply-all, high-stakes, under 120 words, and does not count against monthly draft limit. It also sets expectations for tone and structure. The description is transparent about the tool's purpose and constraints, though it does not cover error conditions or exact output format.

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

Conciseness5/5

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

The description is concise (about 4 sentences) and front-loaded with the primary purpose. Every sentence adds value: use case, importance, constraints, and a unique benefit (does not count against monthly limit). No wasted words, making it efficient for an agent to parse.

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

Completeness4/5

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

Given the tool's complexity (generating an email), no output schema, and no annotations, the description provides sufficient context: it explains the email's purpose, audience, constraints, and workflow position. It doesn't specify the return format, but for a generative tool, the output (email) is implied. The sibling list shows many email tools, and this description clearly positions this one.

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 the schema already describes each parameter. The description adds valuable context: for example, 'their_context' is explained as making the email feel specific, and 'proposed_next_step' defaults to a call. This extra guidance helps the agent use parameters effectively beyond the schema's basic 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 a reply-all email when a mutual contact introduces you to a potential client, with a specific verb (write) and resource (email). It distinguishes itself from sibling tools like cold_pitch or referral_request by specifying the exact scenario.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool: 'when a mutual contact introduces you to a potential client over email'. It explains the email's goals and constraints (under 120 words, acknowledge introducer, impress prospect). While it doesn't explicitly list when not to use it, the specific framing and mention of 'workflow gap' effectively guide appropriate use.

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