Skip to main content
Glama
ptaramona

Conduyt MCP Server

by ptaramona
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

conduyt_send_sms

Send an SMS message to a contact with a phone number who has not opted out, supporting messages up to 1,600 characters.

Instructions

Send an SMS message to a contact. Contact must have a phone number and not have opted out. Max 1600 characters.

Input Schema

NameRequiredDescriptionDefault
bodyNoMessage text (max 1600 characters). Required unless a WhatsApp template is sent (transport whatsapp + whatsappContentSid): then the template Twilio renders is the text, and a media-only template has none.
contactIdYesContact UUID — must have a phone number on file
transportNo'project_blue' sends from the acting user's own Project Blue iPhone line (iMessage when the lead is on Apple, SMS otherwise; the user must have a line assigned in Settings → Project Blue). 'whatsapp' sends from the account's WhatsApp sender (Settings → WhatsApp): free-form text only within 24 hours of the contact's last WhatsApp message (422 whatsapp_window_closed otherwise), or an approved template via whatsappContentSid. 'fromk' sends through the account's FromK.ai workspace (Settings → FromK.ai) from fromkPhoneNumberId, else the workspace's single send-ready line (422 fromk_line_required with several). Default: Twilio.
fromNumberNoSender phone number (defaults to account's primary number)
idempotencyKeyNoOperation key for at-most-once sends: reuse the SAME key when retrying a send whose outcome you did not see; a settled key answers with the original message and never sends twice.
fromkPhoneNumberIdNotransport fromk: the FromK.ai line to send from (a send-ready phoneNumberId from conduyt_fromk_status / conduyt_sms_transports fromk.lines); omit when the workspace has one send-ready line
whatsappContentSidNotransport whatsapp: an APPROVED WhatsApp template (Twilio Content SID from conduyt_whatsapp_templates); Conduyt reads the template from Twilio at send time, records its text with the variables in place, and refuses an unlisted (whatsapp_template_invalid) or unapproved (whatsapp_template_not_approved) one. body is still required but the template's text is what is sent and recorded.
whatsappContentVariablesNotransport whatsapp with a template: placeholder number → value, e.g. { "1": "Alex" }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, and it discloses very little: no mention of idempotency/at-most-once semantics, no mention of 422 failure modes (whatsapp_window_closed, fromk_line_required), no mention that a template's text overrides `body`. Opt-out and phone-number preconditions are the only real behavioral facts conveyed.

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?

Three short sentences, front-loaded with the action and followed by the two gating constraints. Efficient, though the character-limit sentence duplicates schema data rather than adding information.

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

Completeness2/5

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

This is a high-complexity tool: 8 parameters, a transport enum covering four providers, a nested object, no annotations and no output schema. The description omits the multi-channel nature entirely, so an agent that reads only the description would never discover WhatsApp template sending, Project Blue iMessage, or the idempotency retry contract.

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% and each parameter is thoroughly documented in the schema, so the baseline 3 applies. The description adds nothing beyond repeating the 1600-character limit already encoded as maxLength, and never references transport, idempotencyKey, or the WhatsApp parameters.

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?

States a specific verb+resource ("Send an SMS message to a contact") that is clearly distinguishable from siblings such as conduyt_send_email and conduyt_voice_drop. It slightly under-describes actual scope, since the tool also sends WhatsApp templates and Project Blue / FromK transports, but the core purpose is unambiguous.

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?

Gives preconditions ("contact must have a phone number and not have opted out"), which is genuine usage guidance an agent can check before calling. However, it offers no guidance on when to prefer this over conduyt_send_email or conduyt_voice_drop, and no hint that a non-SMS transport may be appropriate.

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