Skip to main content
Glama

estimate_revision_email

Send a professional email to a client when a project requires a revised estimate due to underestimation or hidden complexity, offering options to approve a new quote, split the work, or absorb the cost.

Instructions

Write the email you send when you discover mid-project that the work is going to cost more or take longer than your original estimate — through no fault of the client (you under-estimated, the work turned out to be more complex, or hidden dependencies emerged). Distinct from change_order_email (which covers client-requested additions), scope_creep_email (which calls out the client adding work), and project_delay_notification_email (which covers timeline slippage without a cost impact). Three routes: revised_estimate (default — disclose the gap, explain why, present the new number, ask for a go-ahead before continuing; best when the overage is significant and you need client approval to proceed), propose_split (offer to complete the current agreed scope at the original price and quote the additional complexity as a separate phase 2; best when the new work is genuinely separable and you can deliver something useful at the original budget), absorb (you'll eat the extra cost this time — be transparent that you're doing so and why, and set expectations for future estimates; best for small overages on long-term client relationships). Required: client_name, original_estimate (what you originally quoted — e.g. '$3,000', '2 weeks', '$3,000 / 2 weeks'), overrun_reason (what you discovered that changed the picture — be specific). Optional: revised_estimate (the new number or timeline — e.g. '$4,500', '3.5 weeks'), project_name, route ('revised_estimate' | 'propose_split' | 'absorb' — default revised_estimate), your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesFirst name or full name of the client
original_estimateYesWhat you originally quoted — e.g. '$3,000', '2 weeks', '$3,000 and 2 weeks'. Referenced in the email so the client has the context.
overrun_reasonYesWhat you discovered that changed the picture — be specific. E.g. 'the existing database schema is much more complex than the brief suggested', 'the third-party API has no sandbox and every test call costs time', 'the legacy codebase has no test coverage and refactoring safely is taking 3× as long'. Vague reasons ('it was harder than expected') lose trust; specific ones build it.
revised_estimateNoOptional: the new number or timeline — e.g. '$4,500', '3.5 weeks', '$4,500 and 3.5 weeks'. Include for revised_estimate and propose_split routes. Omit for absorb route.
project_nameNoOptional: the project name or short description — e.g. 'the dashboard rebuild', 'your brand identity project'. Adds clarity to the email.
routeNorevised_estimate (default): disclose the gap, explain why, present the new number, ask for approval before continuing. propose_split: deliver the agreed scope at the original price and quote the new complexity as a separate phase 2. absorb: you're eating the extra cost this time — say so transparently and set expectations.
your_nameNoOptional: your name for the sign-off
Behavior4/5

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

Without annotations, the description carries the full burden. It explains that the tool writes an email, details three behavioral routes, and mentions it does not count against monthly draft limits. It does not disclose if it saves or sends the email, but for a drafting tool this is sufficient. No contradictions.

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 purpose and sibling distinctions. It efficiently explains routes and parameter semantics with examples. Though relatively long, every sentence adds value and is organized logically. Slightly verbose but earned.

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?

Given the tool's complexity (7 parameters, 3 routes) and lack of output schema, the description is comprehensive. It covers purpose, usage guidelines, parameter details, and behavioral expectations. No gaps are apparent for an email 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%, so baseline is 3. The description adds significant value beyond the schema by providing examples, contextual advice (e.g., being specific in overrun_reason), and detailed route explanations. This enhances the agent's understanding of how to fill parameters correctly.

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 for mid-project overruns due to underestimation, not client fault. It explicitly distinguishes from three sibling tools (change_order_email, scope_creep_email, project_delay_notification_email), making its purpose unique and clear.

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 when-to-use scenarios (mid-project overrun due to underestimation) and when-not (client-requested changes, scope creep, timeline delay without cost). It also explains three routes with best-use contexts (revised_estimate for significant overages needing approval, propose_split for separable additional work, absorb for small overages).

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