Skip to main content
Glama

price_increase_email

Communicate a rate increase to an ongoing client with a confident, warm email that gives clear notice and states the new rate plainly.

Instructions

Write the email notifying a long-term client that your rates are increasing. One of the hardest emails a freelancer writes — most either avoid it entirely (and undercharge for years) or frame it apologetically (which invites pushback). This email is confident, warm, and forward-looking: gives clear notice (typically 30–60 days), states the new rate plainly, optionally anchors it in specific value delivered, and closes with an offer to discuss. Distinct from budget_proposal (negotiating a project price before signing), discount_request_response (responding to a client's pushback on price), and budget_update_email (explaining a cost overrun on a current project) — this is the proactive rate change communication to an ongoing client or retainer. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient's first name or full name
new_rateYesYour new rate or pricing (e.g. '$150/hour', '$5,000/month retainer', '$2,800 per project')
current_rateNoYour current rate — including it makes the change concrete and shows transparency (e.g. '$120/hour')
effective_dateNoWhen the new rate takes effect (e.g. 'August 1', 'from your next project', 'in 60 days') — gives the client time to plan
project_nameNoName of the ongoing engagement or retainer, if relevant
value_highlightNoA specific result or achievement from your work together that anchors the value (e.g. 'tripling their newsletter open rate', 'launching three products on time and on budget') — optional but makes the email stronger
your_nameNoYour name for the sign-off
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the tool writes an email but does not clarify whether it automatically sends the email or just generates a draft. This omission leaves the agent uncertain about side effects. Otherwise, the tone and structure are transparent.

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 moderately long but well-structured: it starts with the tool's purpose, adds context about typical challenges, describes the email's structure, distinguishes from siblings, and ends with a note on draft limits. Each sentence adds value, though some redundancy exists (e.g., parameter details already in schema). It is front-loaded with critical information.

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?

Given the tool has 7 parameters, no output schema, and no annotations, the description comprehensively explains its purpose, typical use, and parameter meanings. However, it does not describe the output format (e.g., whether it returns plain text or HTML), which would help the agent understand how to use the result. Overall, it covers most essential aspects for a mutation 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% with each parameter described in the schema. The description adds context by explaining the email's structure and emphasizing optional elements like value_highlight. It reinforces the purpose of key parameters but does not introduce new semantics beyond what the schema already provides, earning a score above the baseline of 3.

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 notifying a long-term client about rate increases. It specifies the context (freelancer), tone (confident, warm, forward-looking), and key elements. It also distinguishes from sibling tools like budget_proposal, discount_request_response, and budget_update_email, leaving no ambiguity about its purpose.

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 explicitly states when to use this tool ('proactive rate change communication to an ongoing client or retainer') and contrasts it with three specific sibling tools, each with a different use case. It also mentions that it does not count against a monthly draft limit, providing practical 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