Skip to main content
Glama

payment_plan_proposal

Draft a professional email offering an installment payment plan when a client cannot pay an invoice in full, specifying payment schedule and amounts to resolve payment difficulty.

Instructions

Write the professional email proposing an installment payment plan when a client cannot pay an invoice in full immediately — either proactively offered when you sense payment difficulty, or as a structured reply when a client has asked for more time. States the plan clearly (number of payments, amounts, schedule), confirms the arrangement in writing, and keeps the tone solution-focused rather than punitive. Distinct from late_payment_reminder (chasing an already-overdue invoice), invoice_dispute_response_email (client is disputing a charge), and deposit_request_email (requesting upfront payment before work begins). Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesClient's first name or full name
invoice_totalYesThe total amount owed (e.g. '$3,500', '£2,200')
invoice_numberNoInvoice reference number (e.g. 'INV-051') — included in subject line if provided
number_of_paymentsNoHow many instalments the plan is split into (e.g. 2, 3, 4) — defaults to 2 if not provided
first_paymentNoAmount due in the first instalment (e.g. '$1,750', '50%') — if omitted, equal splits are implied
schedule_descriptionNoWhen subsequent payments are due (e.g. 'every two weeks', 'on the 1st of each month', '30 days after the first payment')
total_periodNoOptional: total timeframe the plan spans (e.g. 'six weeks', 'three months') — used to frame the offer naturally
project_nameNoName of the project for context (e.g. 'the brand identity project', 'your website')
your_nameNoYour name for the sign-off
Behavior4/5

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

With no annotations, the description carries full burden. It discloses tone (solution-focused, not punitive), content (states plan clearly, confirms in writing), and a key behavioral trait: 'Does not count against your monthly draft limit.' No mention of auth or side effects, but email drafting implies read-like safety.

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 concise (two sentences plus sibling list) and front-loaded with purpose and usage. Every sentence adds value without redundancy.

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?

For a tool with 9 parameters and no output schema, the description adequately explains the email's content and tone, plus a useful behavior note about draft limits. While it doesn't detail the return value, the purpose is clear enough for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter already has a description. The tool description does not add significant meaning beyond the schema. It implies that parameters like number_of_payments, first_payment, schedule_description are used to construct the plan, but that is inferrable.

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 it writes a professional email proposing an installment payment plan when a client cannot pay in full. It specifies the action, resource, and distinguishes from sibling tools immediately.

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?

Provides explicit conditions for use: proactively offered when sensing payment difficulty or as a reply when client asks for more time. Also clearly distinguishes from three sibling tools (late_payment_reminder, invoice_dispute_response_email, deposit_request_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