Skip to main content
Glama
cotletdev

Tradify MCP server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Send invoice

send_invoice
Destructive

Approves a draft invoice and emails it to the customer with a view-and-pay link, optionally including payment reminders.

Instructions

Approve the invoice and email it to the customer, with payment reminders if enabled.

Approves a draft invoice (Tradify gives it its number) and emails it from Tradify with the link to view and pay it; payment reminders follow if you enabled them. Without to it goes to the customer's email. Subject and text default to your invoice email template. An approved invoice can be sent again. Tradify sends this mail only when the login has 2-Step Security set up; otherwise the call stops before approving.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRecipient emails. Default: the customer's email.
messageNoEmail text. Default: your invoice template.
subjectNoDefault: your invoice email template.
invoice_idYesInvoice ID from list_invoices or create_invoice_from_quote.
send_me_a_copyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.9/5.0
Behavior5/5

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

Beyond annotations, it discloses the approval step, email link, payment reminders, default recipient/subject/text, resend behavior, and a hard prerequisite (2-Step Security) that stops the call before approval. This gives the agent a complete behavioral picture.

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 opening sentence front-loads the core action, but the second sentence partially repeats the approval/email flow, adding some redundancy. Overall it remains readable and appropriately sized.

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 state-changing, external-send tool with no output schema, the description covers the key prerequisites, side effects, and defaults. It could mention what a successful call returns or error behavior beyond the 2-Step Security stop, but the gaps are minor.

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 coverage is 80% and already documents the default behavior for to, message, and subject. The description repeats those defaults but adds no further parameter semantics, and send_me_a_copy remains undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (approve and email) and resource (invoice), including side effects like payment reminders. It does not explicitly differentiate from close siblings such as send_quote, leaving that inference to the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage—approve a draft invoice and email it, with resend allowed—but offers no explicit when-to-use or when-not-to-use guidance relative to alternatives like send_quote or record_payment. It does note the 2-Step Security prerequisite, but does not compare alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools