Skip to main content
Glama

Create SMS trunk

create_sms_trunk

Create an inbound SMS destination trunk for the authenticated customer, then optionally route a DID to it with assign_did_to_sms_trunk. Choose the delivery mode with type: type "http_in" (an HTTP IN trunk, default) → DIDWW pushes each incoming SMS to a webhook; pass name and url (defaults to an HTTP GET webhook), or http_method "POST"/"PUT" with a body and body_type for a request body. type "smtp" (an SMS to Email trunk) → DIDWW delivers each incoming SMS as an email; pass name and send_to (recipient email, e.g. "test@example.com" or "John Doe test@example.com"). subject, message and use_smtp_relay have sensible defaults. Available placeholders (substituted per incoming SMS): {SMS_TIME} received time, {SMS_SRC_ADDR} sender, {SMS_DST_ADDR} receiver, {SMS_TEXT} message text, {SMS_TEXT_BASE64_ENCODED} message text base64-encoded. Placeholders work in the smtp subject/message and in http_in query_parameters/headers/body. Returns the created trunk id and key attributes, or a readable error if the configuration is invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNohttp_in only: webhook URL DIDWW pushes each incoming SMS to.
bodyNohttp_in only: request body, required for POST/PUT. May use {SMS_*} placeholders, e.g. {"time":"{SMS_TIME}","text":"{SMS_TEXT}"}.
nameYesTrunk name (must be unique for the customer).
typeNoDelivery mode: "http_in" (webhook, default) or "smtp" (email delivery).
blockedNoWhether the trunk is blocked. Defaults to false.
headersNohttp_in only: HTTP headers (string => string). Values may use {SMS_*} placeholders.
messageNosmtp only: email body text, may use {SMS_*} placeholders. Defaults to "{SMS_TIME}" and "{SMS_TEXT}" on separate lines.
send_toNosmtp only (required): recipient email, e.g. "test@example.com" or "Name <test@example.com>".
subjectNosmtp only: email subject, may use {SMS_*} placeholders. Defaults to "SMS received from {SMS_SRC_ADDR} to {SMS_DST_ADDR}".
priorityNoOptional routing priority.
body_typeNohttp_in only: body encoding, required for POST/PUT.
http_methodNohttp_in only: HTTP method used for the webhook. Defaults to "GET".
use_smtp_relayNosmtp only: use the DIDWW SMTP relay. Defaults to true.
query_parametersNohttp_in only: query string parameters (string => string). Values may use {SMS_*} placeholders.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

With annotations covering the safety profile, the description adds substantial behavioral detail: what each type does, default methods/values, placeholder substitution rules, and that it returns the created trunk id or a readable error. No contradiction with annotations.

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?

Purpose and mode selection are front-loaded, and the dense paragraph avoids fluff. It is long for a single paragraph, but the length is justified by two delivery modes and 14 parameters.

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?

Given 14 parameters, two modes, nested objects, and no output schema, the description covers the critical setup paths, defaults, placeholders, and return/error behavior. Minor fields like priority and blocked are left to the schema, which is reasonable.

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; the description still adds cross-parameter mode conditions (http_in uses url/body/http_method; smtp uses send_to/subject/message) and the full placeholder list that applies across query_parameters, headers, and body.

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 specific verb and resource ('Create an inbound SMS destination trunk') and scopes it to the authenticated customer. It distinguishes the tool from the related routing sibling assign_did_to_sms_trunk and explains the two delivery modes.

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?

Explicitly says to route a DID afterward with assign_did_to_sms_trunk and gives clear conditions for choosing type http_in vs smtp. It does not explicitly exclude create_sms_trunk_group or state when not to use this tool, so it stops short of full when/when-not coverage.

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.

Resources