Skip to main content
Glama

project_extension_email

Request a project deadline extension by stating the current deadline, proposing a specific new date, providing a brief honest reason, and confirming what will be delivered by then.

Instructions

Write the email requesting more time on a project when the agreed deadline can no longer be met — the confirmed ask, not a risk warning. Distinct from project_delay_warning (sent when a deadline is at risk but not yet missed) and late_delivery_apology (sent after you've already missed it): this is the professional middle ground — you know you need more time, you're requesting it before the deadline passes, and you're being specific about the new date. Structure: states the current deadline, requests the specific extension needed, gives a brief honest reason (one sentence), and confirms what will be delivered by the new date. Does not grovel or over-explain. Most freelancers either say nothing until they're late, or send a vague 'I might need a bit more time' — this is the direct, professional ask that respects the client's schedule. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient's first name or full name
project_nameNoName of the project
original_deadlineYesThe agreed deadline (e.g. 'Friday 20 June' or 'end of this week')
new_deadlineYesThe specific new date or timeframe being requested (e.g. 'Wednesday 25 June' or 'the following Monday')
reasonNoBrief honest reason for the extension — one sentence (e.g. 'the API integration took longer than anticipated', 'I had an unavoidable client emergency this week')
deliverableNoWhat you will deliver by the new date (if different from the full project, e.g. 'the first draft', 'the complete build')
your_nameNoYour name for the sign-off
Behavior4/5

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

No annotations are provided, so the description carries full burden. It describes the tone (professional, not groveling), structure, and timing (before deadline passes). It does not mention destructive behavior or rate limits, but the non-destructive nature is evident. Could be more explicit about whether the tool sends or just generates the email.

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?

The description is well-structured and front-loaded: purpose, distinction from siblings, structure, and behavioral notes. Every sentence adds value without redundancy. It is concise given the amount of context provided.

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 covers usage, structure, and tone well, but does not explicitly state what the tool returns (likely the email text). With no output schema, this is a minor gap. Overall, it provides sufficient context for an agent to use the tool effectively.

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%, so baseline is 3. The description adds meaning by explaining how each parameter fits into the email structure (e.g., reason should be one sentence, deliverable is optional). This enhances understanding beyond the schema 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 an email requesting more time on a project, and distinguishes it from similar tools like project_delay_warning and late_delivery_apology. The verb 'write the email' and resource 'requesting more time' are specific.

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 clearly defines when to use this tool vs alternatives: it's the middle ground between a warning (at risk) and an apology (already missed). It also states it does not count against the monthly draft limit, providing additional context.

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