Skip to main content
Glama

project_pause_email

Draft a formal project pause email for unpaid invoices, missing client materials, or planned breaks. Choose from three routes to maintain professionalism and clarity.

Instructions

Write the email formally pausing work on a project — the hardest email most freelancers delay sending until it's awkward, or send too aggressively and damage the relationship. Three routes: non_payment (default — work is on hold until an outstanding invoice is settled; firm but not aggressive, states the pause clearly and gives a single clear path to resume), blocked_on_client (work can't proceed until the client provides something — a missing brief, asset, decision, or approval; names the specific blocker, sets a soft deadline, and keeps the tone collaborative not accusatory), planned_pause (both parties are pausing the project for a defined period — a client budget gap, seasonal pause, or mutual decision; warm tone, confirms the resume expectation, keeps the relationship intact). Distinct from project_delay_notification_email (your own delay without pausing), late_materials_impact_email (timeline impact from late materials, not a formal pause), and project_scope_reduction_email (reducing scope rather than pausing). Does not count against your monthly draft limit. Required: client_name. Optional: project_name, pause_reason (brief context — omit for non_payment to let the invoice speak), outstanding_invoice (non_payment route: what's owed — e.g. 'Invoice #42 for £1,200 due 5 June'), missing_item (blocked_on_client route: what you need — e.g. 'the final logo files', 'sign-off on the wireframes', 'the content brief for section 3'), response_deadline (blocked_on_client route: by when you need a response to stay on schedule — e.g. 'by end of Wednesday', 'within the next 48 hours'), resume_date (planned_pause route: when you expect to pick up again — e.g. 'early July', 'the week of 14 July'), route ('non_payment' | 'blocked_on_client' | 'planned_pause' — default non_payment), your_name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient first name
project_nameNoOptional: project name — e.g. 'the Hartley website', 'your brand refresh'. Makes the email specific rather than generic.
pause_reasonNoOptional: brief context for the pause — e.g. 'while we wait for the Q3 budget to open up', 'while you're sorting the internal sign-off'. Omit for non_payment to let the invoice speak for itself.
outstanding_invoiceNoOptional (non_payment route): what's owed — e.g. 'Invoice #42 for £1,200 due 5 June', 'the deposit invoice sent on 2 June'. Makes the path to resume concrete.
missing_itemNoOptional (blocked_on_client route): what you need from the client — e.g. 'the final logo files', 'sign-off on the wireframes', 'the content brief for section 3'. Be specific — vague blockers create vague responses.
response_deadlineNoOptional (blocked_on_client route): by when you need a response to stay on your current schedule — e.g. 'by end of Wednesday', 'within the next 48 hours'. Creates urgency without being demanding.
resume_dateNoOptional (planned_pause route): when you expect to pick up again — e.g. 'early July', 'the week of 14 July'. Keeps the project alive and sets a shared expectation.
routeNonon_payment (default) — work on hold pending an outstanding invoice; blocked_on_client — can't proceed without something from the client; planned_pause — mutual pause for a defined period.
your_nameNoOptional: your name for the sign-off
Behavior4/5

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

Despite no annotations, the description reveals important behavioral traits: it states the email is 'formal,' outlines three behavioral tones per route, and mentions it does not count against the draft limit. However, it does not explicitly clarify whether the tool sends the email or just generates text, leaving some ambiguity about the actual action performed.

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?

The description is well-structured and front-loaded with the main purpose, but it is somewhat lengthy due to detailed route explanations. Every sentence adds value, but could be slightly condensed without losing clarity.

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 is comprehensive for a complex tool with three routes and nine parameters. It covers all parameter usage and sibling differentiation. The only gap is the lack of explicit output description, but given the tool's name and context, the agent can infer it generates an email draft.

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?

The description adds significant meaning beyond the input schema. It maps each optional parameter to specific routes (e.g., outstanding_invoice for non_payment, missing_item for blocked_on_client), provides concrete examples, and explains the rationale behind default choices. With 100% schema coverage, this extra context is valuable.

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 formal email pausing a project, specifies three distinct routes (non_payment, blocked_on_client, planned_pause), and explicitly distinguishes it from sibling tools like project_delay_notification_email, late_materials_impact_email, and project_scope_reduction_email. This makes the purpose highly specific and unambiguous.

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?

The description provides explicit guidance on when to use each route, including defaults and alternatives. It also directly contrasts the tool with three sibling tools, telling the agent when not to use this tool. This level of detail fully equips the agent to select the appropriate tool.

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