Skip to main content
Glama

project_go_live_email

Write a warm, forward-looking email to celebrate a client's project launch. Mark the moment their new site, app, or campaign goes live with real users. Plant a seed for future work without pitching.

Instructions

Write a short celebratory email to a client when their project goes live — website launch, app release, campaign drop, product ship. Different from project_completion_email (the handover) and project_closure_email (the relationship wrap-up) — this is the real-world moment when the thing you built together is in front of real users and getting real results. Under 100 words. Warm, genuine, forward-looking. Positions you as invested in their success, not just the delivery. Natural moment to plant a seed for next work without pitching. Required: client_name, what_went_live. Optional: live_url (shareable link), early_result (any early metric or signal — e.g. '47 sign-ups in the first hour', '200 views in 3 hours'), next_hook (a natural follow-on if something obvious presents itself — e.g. 'once you have a few weeks of traffic data, it would be worth running an A/B test on the hero'), your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient's first name
what_went_liveYesWhat just launched (e.g. 'the new site', 'the iOS app', 'the rebrand campaign', 'the landing page')
live_urlNoOptional: the live URL — included as a direct link so the email is shareable and bookmarkable
early_resultNoOptional: any early signal or metric worth acknowledging (e.g. '47 sign-ups in the first hour', 'already ranking on page 1 for the target keyword', '200 organic views in 3 hours'). Omit if it's too early for data.
next_hookNoOptional: a natural follow-on suggestion — keep it one sentence, observation-based not pitch-based (e.g. 'once you have a few weeks of traffic data, it would be worth running an A/B test on the hero', 'the next logical step is wiring up the email sequence so every sign-up gets a follow-up'). Omit if nothing obvious presents itself.
your_nameNoYour name for the sign-off
Behavior4/5

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

With no annotations, description conveys it generates a short celebratory email. It doesn't explicitly state side effects or output format, but the generative nature is clear and common for such tools. Slightly lacking explicit non-destructive behavior.

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?

Description is thorough but not overly verbose; front-loaded with core purpose. Each sentence adds value, though could be slightly more concise. Well-structured with parameter explanations integrated.

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 no output schema, description covers usage, parameters, and differentiation well. It omits explicit output description but implies generated email text. Contextual completeness is high for a content generation tool.

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% and description adds meaningful context for optional parameters like 'early_result' and 'next_hook', including examples and usage guidance. Provides value beyond schema definitions.

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 celebratory email for a project go-live, distinguishing it from sibling tools (project_completion_email, project_closure_email). It uses specific verbs and resources.

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?

Explicitly states when to use (project go-live), distinguishes from alternatives, and provides constraints (under 100 words, warm tone, no pitching). Includes natural moment for next work without hard sell.

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