Sautikit

desk_send_message

Sends a message (SMS, WhatsApp or email) to a person. Say who: contact_id, or to for a number or address. The message lands on their open ticket, or opens one; the reply says which (ticket.ref, ticket.opened). There is no send on a ticket.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "desk_send_message"
  }
}

Input Schema

Name	Required	Description
`to`	No	phone number or email of someone who may not be a contact yet (or give contact_id)
`body`	No	message text
`name`	No	their name, used when the contact is new
`channel`	No	sms (default), whatsapp or email
`purpose`	No	Required on tools that read data or reports; recommended on every tool. One sentence: what you are doing and why (for example "finding this caller's open ticket to answer them"). Building a report, dashboard, analytics or an export is a SautiDesk Pro feature done by the report tools, not by pulling records.
`subject`	No	email subject
`sender_id`	No	SMS only: an approved alphanumeric sender ID of the workspace to send as
`ticket_id`	No	optional hint: the ticket you are looking at; used only if it is open and the contact's
`contact_id`	No	contact UUID to message (or give to)
`forward_of`	No	email only: UUID of a message to forward; body becomes your note above it
`template_id`	No	approved WhatsApp template UUID
`idempotency_key`	No	optional Idempotency-Key header

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=false, openWorldHint=true), the description discloses the real side effect: the message attaches to the contact's open ticket or opens a new one. It even names the response fields (ticket.ref, ticket.opened) so the caller knows how to verify which happened. It does not mention channel-specific constraints such as the WhatsApp template/24-hour window requirement implied by sibling tools like desk_get_whatsapp_window and desk_list_templates.

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?

Four short sentences, front-loaded with the action and the recipient rule, with no filler. The telegraphic fragments ("Say who:", "There is no send on a ticket") are dense but slightly cryptic on first read.

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 twelve-parameter, no-output-schema, open-world send tool, the description covers the essential behavior an agent could not get from structured fields: where the message lands and how the reply reports it. The remaining gaps (channel-specific requirements, idempotency, sender ID) are covered by the schema, so nothing critical is missing.

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 100%, so all twelve parameters are already documented in the input schema; a baseline of 3 applies. The description reinforces the contact_id-vs-to choice but says nothing about ticket_id being only a hint, sender_id restrictions, template_id for WhatsApp, or forward_of — all left entirely to the schema.

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 opens with a specific verb+resource ("Sends a message (SMS, WhatsApp or email) to a person") and adds the key scoping fact that there is no send action scoped to a ticket. It does not name the overlapping siblings (desk_send_sms, desk_send_dm, send_whatsapp_message), so an agent must infer that this is the channel-agnostic unified sender rather than the single-channel ones.

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?

"Say who: contact_id, or to for a number or address" gives a usable selection rule between recipient parameters, and "There is no send on a ticket" rules out a natural wrong assumption. However, there is no explicit when-to-use-this-instead-of guidance against the several sibling send tools, so the agent must derive the routing from the channel list alone.

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

All Sautikit tools Inspect

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

Need Help?