Skip to main content
Glama

post_discovery_follow_up_email

Recap key points from a discovery call and set the next step to keep momentum toward a proposal. Choose from three routes: warm, interested but not ready, or send a proposal.

Instructions

Write the follow-up email sent after a productive discovery or intro call with a prospect — the email most freelancers either skip or fumble. Its job: confirm you listened, recap the key points so nothing gets lost, set the next step clearly, and keep the momentum toward a proposal. Distinct from discovery_call_no_show_email (for when they don't show) and client_followup (for chasing a sent proposal). Three routes: warm (engaged prospect, moving forward — default), interested_but_not_ready (good conversation but they need more time or internal buy-in — play the long game), send_proposal (they asked for one on the call — confirm it's coming and when). Required: contact_name, what_discussed (2-4 bullet points or a brief paragraph of what you covered on the call). Optional: next_steps (what you agreed to do next — e.g. 'send a proposal by Friday', 'schedule a follow-up in two weeks'; defaults to a warm but open close), your_service (what you do — helps personalise the recap line), timeline (their stated timeline or urgency — e.g. 'looking to start in July', 'hoping to launch before Q3'), route, your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contact_nameYesThe prospect's first name
what_discussedYesThe key points from the call — 2-4 bullets or a brief paragraph (e.g. 'their rebrand timeline, budget range of $5-8k, need for brand guidelines and logo, internal stakeholder review required before sign-off'). This becomes the recap section.
next_stepsNoOptional: what was agreed as the next step (e.g. 'I'll send a proposal by Friday', 'you'll come back to me once you have internal sign-off', 'we'll speak again in two weeks'). If omitted, the email closes warmly without a hard next step.
your_serviceNoOptional: a short description of what you do — helps personalise the recap line (e.g. 'brand identity and packaging design', 'React development for SaaS products', 'copywriting for B2B tech companies'). If omitted, the email stays generic.
timelineNoOptional: the prospect's stated timeline or urgency (e.g. 'looking to start in July', 'hoping to launch before Q3', 'no fixed deadline yet'). If provided, the email acknowledges it.
routeNowarm: engaged prospect, ready to move forward — default for most calls. interested_but_not_ready: good conversation but they need more time, budget approval, or internal buy-in. send_proposal: they asked for a proposal on the call — confirm it's on its way and when they'll have it.
your_nameNoOptional: your name for the sign-off
Behavior5/5

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

Given no annotations, the description fully discloses behavior: generates an email, does not count against monthly draft limit, requires specific inputs, and varies output by route. No contradictions.

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?

Well-structured and front-loaded with purpose and differentiation. While verbose, every sentence adds value. Could be slightly trimmed but remains efficient for the complexity.

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?

Fully covers tool purpose, usage, parameters, routes, and special behavior (draft limit). No output schema, but description implicitly covers return value (email content). Contextually complete for a tool with 7 parameters and 3 routes.

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%, baseline 3. Description adds value: explains how each parameter affects the email (what_discussed becomes recap, next_steps defaults, route changes tone, etc.), going 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 explicitly states the tool writes a follow-up email after a productive discovery call, with specific goals (confirm listening, recap key points, set next step). It distinguishes from sibling tools by naming them and contrasting their use cases.

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?

Provides clear when-to-use guidance, including three routes (warm, interested_but_not_ready, send_proposal) and explicit differentiation from sibling tools like discovery_call_no_show_email and client_followup.

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