Skip to main content
Glama

conditional_proposal_acceptance_email

Respond to clients who say 'yes, but...' by accepting their condition, countering with modified terms, or holding your original proposal.

Instructions

Write the email responding when a client says 'yes, but...' — they want to proceed with your proposal but are asking for a change: a lower price, a trimmed scope, a later start, phased payments, or a shorter contract. This is a distinct, high-stakes moment in the sales cycle — the client has chosen you, so the relationship risk is low, but the commercial terms are still live. Three routes: accept (agree to their condition and confirm the modified deal — use when the adjustment is workable and the project is worth taking), counter (propose your own modified terms as a middle ground — use when their ask is too steep but a partial adjustment is acceptable), hold (explain you can't move on this and offer the original terms or a graceful exit — use when the condition would make the project unprofitable or set a bad precedent). Distinct from discount_request_response (where the client hasn't committed), budget_negotiation_email (where budget was the blocker before agreement), and price_objection_response_email (where the client is objecting to the price without accepting). Does not count against your monthly draft limit. Required: client_name, condition_requested (what they've asked to change — e.g. 'reduce the fee by 15%', 'delay the start by six weeks', 'remove the discovery phase and go straight to design'). Optional: project_name, counter_offer (for counter route — your proposed middle ground, e.g. '10% reduction if they pay in full upfront', 'start in three weeks rather than six'), route ('accept' | 'counter' | 'hold' — default accept), your_name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesFirst name or full name of the client
condition_requestedYesWhat they've asked to change — be specific. E.g. 'reduce the fee by 15%', 'delay the start by six weeks until their budget resets', 'remove the discovery phase and go straight to design', 'split the fee across three months instead of two'. Used directly in the email so the client knows you heard them precisely.
project_nameNoOptional: the project name or short description — e.g. 'the website redesign', 'your brand identity project'. Adds clarity to the email.
counter_offerNoOptional (required for counter route): your proposed middle ground. E.g. '10% reduction if payment is made in full upfront rather than split', 'start in three weeks rather than six — I can hold the slot', 'remove discovery but add a structured briefing call instead'. Be concrete.
routeNoaccept (default): agree to their condition and confirm the deal on the adjusted terms. counter: propose your own modified terms as a middle ground. hold: explain you can't adjust and offer the original terms or a clean exit.
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 high-stakes sales moment, relationship risk, and three response routes. However, it does not explicitly state whether the tool sends the email or just drafts it, though the phrase 'does not count against your monthly draft limit' implies a draft is generated.

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 thorough but not wasteful; each sentence adds value. It front-loads the purpose and then provides detailed guidance. Could be slightly more concise, but the complexity of the tool (three routes) justifies the length.

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?

Given no output schema, the description should clarify what the tool returns (e.g., an email draft). It hints at 'does not count against your monthly draft limit' but does not explicitly state the output format or how to use the result. For a tool with multiple routes and high-stakes context, this is a gap.

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?

Schema has 100% coverage with descriptions for each parameter, but the tool description adds rich context with concrete examples for condition_requested and counter_offer, and explains the route enum options with usage scenarios. This goes beyond the schema alone.

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's purpose: generating responses when a client says 'yes, but...' and asks for changes. It distinguishes from three sibling tools (discount_request_response, budget_negotiation_email, price_objection_response_email) by explaining the specific scenario where this tool applies.

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?

Explicitly specifies when to use (client accepted but requests changes) and when not to (alternatives listed with clear differentiators). Also provides guidance on the three routes (accept, counter, hold) with conditions for each.

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