Skip to main content
Glama

deliverables_sign_off_email

Formalize client approval on deliverables with a clear email requesting written sign-off, setting a review deadline, and outlining next steps to close the project.

Instructions

Write the email asking a client to formally sign off on completed deliverables before you close the project or send the final invoice. The email most freelancers skip — and then spend weeks chasing verbal approvals that were never properly captured. Confirms exactly what was delivered, sets a clear review window, and requests explicit written approval. Keeps the tone collaborative, not administrative. Distinct from milestone_delivered_email (mid-project delivery update), project_closure_email (final wrap-up after sign-off is received), and project_completion_email (marks the end of work). This is the bridge between 'I'm done' and 'it's officially accepted'. Does not count against your monthly draft limit. Required: client_name, project_name, what_was_delivered. Optional: review_deadline (e.g. 'by Friday 20 June', 'within 3 business days' — defaults to a 5-business-day window), next_step (what happens after sign-off, e.g. 'I'll send the final invoice', 'I'll hand over the source files', 'the project is complete' — defaults to final invoice), approval_method (e.g. 'reply to this email', 'click Approve in the shared doc', 'sign the attached form' — defaults to replying to the email), your_name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesFirst name or full name of the client
project_nameYesName or brief description of the project
what_was_deliveredYesWhat you're asking them to sign off on (e.g. 'the final website design mockups — all 5 pages', 'the completed brand identity package: logo, colour palette, and typography guide', 'Phase 2: the API integration and admin dashboard')
review_deadlineNoOptional: when you need sign-off by (e.g. 'by Friday 20 June', 'within 3 business days', 'by end of next week'). Defaults to a 5-business-day window.
next_stepNoOptional: what happens immediately after sign-off (e.g. 'I'll send the final invoice', 'I'll release the source files', 'the project will be complete and I'll hand over all assets'). Defaults to sending the final invoice.
approval_methodNoOptional: how the client should approve (e.g. 'reply to this email with your approval', 'click Approve in the shared Figma file', 'sign and return the attached form'). Defaults to replying to the email.
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 provided, so description carries full burden. It describes the email's content, tone, and required/optional fields. However, it doesn't clarify whether the tool drafts or sends the email, which is a minor gap. No contradiction with annotations.

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?

Concise yet comprehensive; every sentence adds value. Front-loaded with purpose and usage, then parameter details. No fluff.

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?

Complete for a text-generation tool with no output schema. Covers why, when, what params, and alternatives. No gaps in explaining the tool's role.

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?

All 7 parameters are described in the schema with 100% coverage. The description adds value by listing required params, providing examples and defaults for each optional param, and giving practical usage tips beyond the schema.

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 an email asking for sign-off on completed deliverables, and explicitly distinguishes it from three sibling tools (milestone_delivered_email, project_closure_email, project_completion_email) with concise differences.

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 explicit when-to-use context ('before you close the project or send the final invoice'), contrasts with siblings, and includes practical notes like 'Does not count against your monthly draft limit.'

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