Skip to main content
Glama

brief_confirmation_email

Send a written summary of project scope, deliverables, exclusions, timeline, and price to confirm understanding before starting work. Prevents scope disputes by aligning expectations upfront.

Instructions

Write a short email confirming your written understanding of a project brief before work begins. Sends a concise scope summary — what you'll deliver, what's excluded, timeline, price, and what you need from the client to start — and asks them to confirm or correct before you begin. Prevents scope disputes by creating written alignment upfront. Required: client_name, deliverables (comma-separated list of what you're delivering), total (your price or rate, e.g. '$2,400 fixed' or '$120/hr, ~20hrs'). Optional: project_name, out_of_scope (up to 3 items explicitly excluded — omit if nothing needs spelling out), timeline (overall project duration or deadline, e.g. '3 weeks' or 'delivered by July 15'), start_date, what_you_need (assets, access, or information you need from the client to start — e.g. 'brand guidelines and CMS login'), your_name. Workflow: receive brief → discovery_call_follow_up_email (recap) → brief_confirmation_email (written scope sign-off) → project_kickoff_email (start). Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient's first name or full name
deliverablesYesComma-separated list of what you will deliver (e.g. 'homepage redesign, 3 interior page templates, mobile-responsive CSS, one round of revisions')
totalYesYour agreed price or rate (e.g. '$2,400 fixed fee', '$120/hr estimated 20hrs', '$3,000 split 50/50')
project_nameNoShort name for the project — used in the subject line and opening (e.g. 'the website redesign', 'your brand refresh', 'the Q3 campaign'). Omit to keep the opening general.
out_of_scopeNoUp to 3 items that are explicitly NOT included — spell these out when they are the likeliest source of scope creep (e.g. 'copywriting, SEO optimisation, ongoing maintenance'). Omit if nothing needs excluding.
timelineNoOverall project duration or delivery deadline (e.g. '3 weeks from start', 'delivered by 30 July', '2-week turnaround'). Omit if not yet confirmed.
start_dateNoPlanned start date if confirmed (e.g. 'Monday 21 July'). Omit if not yet set.
what_you_needNoAssets, access, or information you need from the client before work can begin (e.g. 'brand guidelines, CMS login, and final copy', 'existing logo files and Google Analytics access'). Omit if you have everything needed.
your_nameNoYour name for the sign-off
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool sends an email, includes a scope summary, and asks for confirmation. It also notes it does not count against a monthly draft limit. However, it does not clarify whether the email is actually sent or just drafted, nor does it mention side effects like saving drafts or authentication requirements.

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

Conciseness3/5

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

The description is detailed and well-structured, starting with purpose, then parameters, then workflow, then a practical note. However, it is somewhat verbose and could be trimmed for conciseness without losing essential information.

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

Completeness3/5

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

The description thoroughly covers the inputs and their usage, but it lacks information about the output (e.g., whether a draft or sent confirmation is returned). Given no output schema, this gap reduces completeness. It also does not mention error handling or what happens on success.

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?

The input schema covers all 9 parameters (100% coverage), and the description adds significant value by explaining the purpose of each parameter, providing examples, and specifying which are required versus optional, including how to omit irrelevant ones.

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 and sends a confirmation email before work begins, using specific verbs and resource. It distinguishes from sibling tools by placing it in a workflow sequence: after discovery_call_follow_up_email and before project_kickoff_email.

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 on when to use the tool (before work begins to prevent scope disputes) and includes a workflow diagram that implicitly indicates alternatives. However, it lacks explicit exclusions or 'when not to use' guidance.

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