Skip to main content
Glama

re_engagement_email

Draft warm re-engagement emails to past clients with three route options—check-in, new service, or availability—requiring only client name and last project detail to refresh the relationship.

Instructions

Write the email you send to a past client you haven't worked with in a while — to reopen the relationship, explore new work, or simply stay on their radar. Distinct from cold_pitch (these people already know and trust you — the tone is warm, not selling), referral_request (you're not asking for a name, you're reopening your own relationship), and testimonial_request (you're not asking for a review). Three routes: check_in (low-pressure — catch up, mention what you've been up to, no explicit ask; best for high-value relationships you don't want to pressure), new_service (flag a specific new offering that's relevant to what you did together; works when you have something concrete to offer), availability (you're available and thought of them first; works when you ended on a strong note and timing is the only variable). Required: client_name, last_project (a brief description of what you worked on together — keeps the email from feeling generic). Optional: time_since (how long it's been — e.g. '6 months', 'last year', 'a while'; omit and the copy stays vague), what_you_did (a specific outcome or result from the last project — adds credibility), new_service_name (for new_service route — the specific offering to highlight), new_service_relevance (for new_service route — why it's relevant to this client), route ('check_in' | 'new_service' | 'availability' — default check_in), your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesFirst name of the past client
last_projectYesBrief description of what you worked on together — e.g. 'the brand refresh', 'your Q3 campaign', 'the e-commerce migration'. Keeps the email specific and personal.
time_sinceNoOptional: how long it's been since you last worked together — e.g. '6 months', 'about a year', 'a while'. Omit to keep it vague.
what_you_didNoOptional: a specific outcome or result from the last project — e.g. 'the site we built is still converting well', 'the campaign hit 140% of target'. Adds credibility without bragging.
new_service_nameNoFor new_service route only: the specific new offering you want to flag — e.g. 'a new SEO audit package', 'a monthly retainer model', 'video content production'.
new_service_relevanceNoFor new_service route only: why this new service is relevant to this particular client — e.g. 'given the growth you were seeing with organic', 'now that you've launched the new product line'.
routeNocheck_in (default): warm catch-up, no explicit ask — best for high-value relationships. new_service: flag a specific new offering that's relevant to what you did together. availability: you're available and they're your first call — works when you ended on a strong note and timing is the variable.
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 the full burden. It discloses that the tool 'writes' an email (implying draft generation) and that it does not count against a monthly draft limit. However, it does not explicitly state that it generates a draft (not sending) or describe any other side effects, though the context and sibling tools imply drafting. Minor gap, but still fairly transparent.

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 well-structured and efficient: it leads with the core purpose, then differentiates from siblings, explains routes, and details parameters. Every sentence adds necessary context without redundancy. The length is appropriate for the complexity of the tool.

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?

The description covers the tool's purpose, usage distinctions, parameter semantics, and a key behavior (no draft limit). However, it does not describe the output format (e.g., that it returns a draft email text) or any potential side effects beyond the draft limit note. Given the tool's simplicity and the richness of other fields, this is a minor gap.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3. The description adds substantial value beyond the schema by explaining the purpose and implications of each parameter (e.g., 'last_project keeps the email from feeling generic', 'time_sense: omit and the copy stays vague', route context for each enum). This makes the parameters much more meaningful for the agent.

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's purpose: writing a re-engagement email to a past client. It distinguishes itself from three related sibling tools (cold_pitch, referral_request, testimonial_request) by highlighting differences in tone and intent, and explains three specific routes with their contexts.

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?

Excellent usage guidance: the description explicitly contrasts with cold_pitch, referral_request, and testimonial_request, telling the agent when to use this tool and when to use alternatives. The three routes (check_in, new_service, availability) are each described with their best-fit scenarios, providing clear decision criteria.

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