Skip to main content
Glama
Sign In

Tradify MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Send quote

send_quote
Destructive

Approve the quote and email it to the customer with a link to accept or decline online. Approves a draft quote (it becomes awaiting acceptance) and emails it from Tradify with the link where the customer accepts or declines it online. Without to it goes to the customer's email. Subject and text default to your quote email template. An approved quote can be sent again. Tradify sends this mail only when the login has 2-Step Security set up; otherwise the call stops before approving. By default you confirm each call, and you can switch that off for this tool. Waits for the owner's approval.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "quote_id": "<quote_id>"
    },
    "name": "send_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoRecipient emails. Default: the customer's email.
messageNoEmail text. Default: your quote template.
subjectNoDefault: your quote email template.
quote_idYesQuote ID from list_quotes or create_quote.
send_me_a_copyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, but the description adds real depth beyond them: the state transition (draft to awaiting acceptance), the hard 2-Step Security precondition that aborts before approving, resend behavior, the default per-call confirmation and its opt-out, and that it waits on the owner's approval. An agent knows exactly what will happen and what can block it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded, but the first two sentences restate the same approve-and-email-with-link behavior almost verbatim, wasting space. Several distinct constraints are packed into one dense block rather than ordered by importance.

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 destructive, open-world mutation with no output schema, the description covers the state change, prerequisites, resend semantics, confirmation behavior and parameter defaults well. Only minor gaps remain, such as the send_me_a_copy flag and what the response returns.

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 80%, so the schema already documents most parameters. The description nonetheless clarifies defaulting behavior for 'to', 'subject' and the message body against the email template, which is meaningful added context; only send_me_a_copy goes unmentioned.

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 states a specific verb and resource plus the concrete effect: approves a draft quote, moving it to awaiting acceptance, and emails it with an accept/decline link. This is clearly distinguishable from siblings like send_invoice or create_quote without opening the schema.

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

Usage Guidelines4/5

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

It gives clear operating context: omission of 'to' routes to the customer's email, an already-approved quote can be resent, and sending is blocked unless 2-Step Security is configured. What's missing is an explicit pointer to alternatives (e.g. send_invoice) when the user's intent is ambiguous.

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

All Tradify MCP Server and API by Cotlet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources