Skip to main content
Glama

Send this week's client report

client_report_send
Destructive

Send the weekly client report that autopilot_finish drafted (its draft_id) to the client, after asking the person "Send this week's report to ?" (client_report_skip skips it instead). It previews first (to, subject, the first lines, how it is sent) and sends only with confirm true, once the person has said send in this conversation; a scheduled task never confirms a send on its own. edits change the words first (re-checked and re-rendered, same link). contact_name / contact_email save who it goes to when the client has none. Sent through the client's own CRM sub-account when one is linked, else from the agency's own email address when it has set one up (Premium: dashboard → White label; replies go to the agency, with a link for the client to stop these weekly emails), with a copy to the agency. To send every week without asking, set report_mode auto with autopilot_set (never applies to a client's first report).

Input Schema

NameRequiredDescriptionDefault
editsNoThe person's changes to the words, if any, in the client's report language (send previews it as language)
confirmNoLeave false to preview; true only after the person said send.
draft_idYesclient_report.draft_id from autopilot_finish (or autopilot_status)
contact_nameNoWho at the client gets it, when it has no contact yet
contact_emailNoTheir email address

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Send: leave false to preview; true only after the person said send. Skip never needs it."New value: +"Leave false to preview; true only after the person said send."
    • removedInput schema / properties / decision
      Removed value: -{
      -  "enum": [
      -    "send",
      -    "skip"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "draft_id",
      -  "decision"
      -]New value: +[
      +  "draft_id"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / edits / description
      Previous value: -"The person's changes to the words, if any"New value: +"The person's changes to the words, if any, in the client's report language (send previews it as language)"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag it as destructive/open-world; the description adds the crucial safety mechanics: it previews first (to, subject, first lines, channel) and only sends with confirm true. It also discloses delivery routing (client CRM sub-account vs agency email, Premium white-label), that replies go to the agency, that the client gets an opt-out link, and that a copy goes to the agency.

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?

Front-loaded with the primary action and the confirmation gate, and every clause carries operational information. It is dense with nested parentheses (the Premium/white-label routing aside), which slightly hurts scanability but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world send tool with no output schema, the description covers the gate (confirm), the preview content, the delivery path, the edit round-trip, contact fallback, and the automation route. An agent has everything needed to call it correctly without guessing.

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%, so baseline is 3, but the description adds real semantics: edits change the wording first and are re-checked and re-rendered against the same link, and contact_name/contact_email are only needed when the client has no contact. That explains intent of the nested edits object beyond the field-level descriptions.

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?

States a concrete verb and resource ('Send the weekly client report that autopilot_finish drafted') and anchors it to a specific required parameter (draft_id). It also names the sibling that does the opposite action (client_report_skip) so the agent can distinguish the pair 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?

Gives explicit when-to-use conditions: only after asking 'Send this week's report to <name>?' and only after the person says send in this conversation; scheduled tasks may never self-confirm. It names the alternative (client_report_skip), and routes to autopilot_set report_mode auto for the recurring case, including the exclusion (never for a client's first report).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.