Skip to main content
Glama

retainer_expansion_email

Propose expanding an existing retainer by adding services, increasing hours, or upgrading the tier, based on current work and client needs.

Instructions

Write the email proposing to expand an existing retainer — adding services, increasing hours, or upgrading to a higher tier. For when you're in an ongoing retained relationship and want to deepen it based on the work done so far. Three routes: add_services (default — propose adding new service lines to the current retainer, e.g. adding SEO audits to a design retainer or copywriting to a strategy retainer), increase_hours (propose increasing the monthly hours allocation — works when you're consistently hitting the cap and both parties are getting value), upgrade_tier (propose moving the client to a higher package that better fits their current usage or needs — works when they've outgrown what they're on). Distinct from retainer_proposal (initial pitch to a new client), retainer_check_in_email (a routine check-in with no commercial ask), and new_service_announcement_email (broadcasting a new service to all clients). Required: client_name. Optional: current_retainer (what they're currently on — e.g. '5 hours/month design support', '$800/month strategy'), proposed_expansion (what you're proposing to add or change — be specific), project_name, route ('add_services' | 'increase_hours' | 'upgrade_tier' — default add_services), your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient first name
current_retainerNoWhat they're currently on — e.g. '5 hours/month design support', '$800/month strategy retainer'.
proposed_expansionNoWhat you're proposing to add or change — be specific, e.g. 'add monthly SEO audit and content brief', 'move from 5 to 10 hours/month', 'upgrade to the Growth package which includes analytics and reporting'.
project_nameNoOptional: name of the retainer or account for context
routeNoadd_services (default) — add new service lines; increase_hours — more hours per month; upgrade_tier — move to a higher package.
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, but the description covers the three routes, clarifies required vs optional parameters, and mentions that it does not count against a monthly draft limit, adding valuable behavioral context.

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, front-loading the purpose and routes, then distinguishing siblings, then listing parameters. While slightly long, each sentence adds value.

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?

It covers all necessary context: purpose, routes, parameter details, sibling differentiation, and even mentions the draft limit. Lacks explicit output description but otherwise complete.

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%, and the description enhances parameters with examples and context (e.g., example values for current_retainer and proposed_expansion, route enum explanation).

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 to expand an existing retainer, specifies three distinct routes, and differentiates from sibling tools with explicit examples.

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?

It explicitly states when to use ('ongoing retained relationship...based on work done so far') and distinguishes from sibling tools like retainer_proposal, retainer_check_in_email, and new_service_announcement_email.

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