Skip to main content
Glama
abryfs
by abryfs

willitsend

ci license: MIT

Your AI agent sends texts. Carriers silently drop the non-compliant ones, and the API never tells you. willitsend is the missing check between the model and the carrier: a deterministic preflight for outbound SMS/iMessage that catches silent filtering, segment blowups, and dropped iMessage features before you spend the send.

Try it in the browser: runs client-side, nothing leaves the page.

npx -y -p github:abryfs/willitsend willitsend-cli "Hey! Your appointment is tomorrow at 2pm." --first-message
Verdict: BLOCK
Segments: 1 (gsm7, 41 septets)
Channel: unknown
[BLOCK] first-message.opt-out: First message doesn't include opt-out instructions (e.g. "Reply STOP
to unsubscribe"). Carriers may silently filter first messages that lack one, with no API error.
  Fix: Append "Reply STOP to unsubscribe." to the message body.
  Source: https://docs.agentphone.ai/documentation/reference/messaging-rate-limits#first-message-requirements
[WARN] first-message.opt-in: No opt-in acknowledgment language found …
[INFO] first-message.brand: No brand_name was provided …

The problem

Messaging APIs report "sent" when a message reaches the downstream carrier, not when it reaches a phone. AgentPhone's rate-limit docs spell out the consequence: first messages that skip brand identification, opt-in acknowledgment, or opt-out instructions "may be silently filtered by carriers. The API will not return an error."

AI agents now send texts autonomously, and nothing sits between the model and the carrier. An agent that drops the opt-out line gets no error and no delivery. An agent that adds one emoji turns a 160-character message into three billable segments and never notices.

willitsend is the missing check: a deterministic, stateless lint for a draft message. Text and context in, verdict and evidence out. It sends nothing and stores nothing.

sequenceDiagram
    participant A as AI agent
    participant W as willitsend
    participant API as Messaging API
    participant C as Carrier
    participant P as Phone

    rect rgba(255,69,58,0.08)
    note over A,P: without preflight
    A->>API: send_message (no opt-out language)
    API-->>A: "sent" ✓
    C--xP: silently filtered. no error, no delivery
    end

    rect rgba(52,199,89,0.08)
    note over A,P: with preflight
    A->>W: preflight_message(draft, context)
    W-->>A: BLOCK · missing opt-out · fix + citation
    A->>W: preflight_message(fixed draft)
    W-->>A: PASS
    A->>API: send_message
    API-->>A: "sent" ✓
    C->>P: delivered
    end

Related MCP server: Twilio SMS MCP Server

Why not just prompt the rules into your agent?

A fair question: AgentPhone's docs are agent-readable, so you could feed them into every generation call and ask the model to comply. Two things break, and one gets expensive:

  1. Generation is probabilistic; verification is deterministic. A model with the rules in context complies usually. This checker returns the same verdict every time, and its failure mode is a visible finding rather than a silently filtered message. Compose-time guidance and pre-send verification are complements — this repo ships both (the agent skill is the compose-time half).

  2. Models can't do segment math. Septet counting, GSM-7 extension characters, encoding flips from one smart quote, placement-aware packing — token-based models are structurally bad at exactly this arithmetic. No amount of prompting fixes it; a 300-line deterministic function does.

  3. The token math, measured (char-count/4 heuristic on the actual pages, July 2026):

Approach

Tokens per message

10,000 msgs/day at $3/M input

Feed both AgentPhone doc pages into each generation call

~7,700

$231/day ($23/day with 90% prompt caching)

preflight_message call result (default)

~250 (+ ~1,450 once per session for the tool definition)

~$7.50/day

preflight_message with response_format: "concise"

~4 on pass, ~44 on block (measured)

~$0.35/day at a 90% pass rate

Roughly 30× fewer tokens per message in default mode — several hundred× in concise mode — and the checker's own compute rounds to zero (~4µs locally, no API). If you compress the rules into your system prompt instead — our skill file does, at ~950 tokens — you keep the compose-time benefit but still have no verifier and no segment math. Bulk senders feel this most: the tool exists precisely for AI agents sending texts at volume.

Quickstart

As an MCP tool (Claude Code):

claude mcp add willitsend -- npx -y -p github:abryfs/willitsend willitsend-mcp

or in any MCP client config:

{
  "mcpServers": {
    "willitsend": {
      "command": "npx",
      "args": ["-y", "-p", "github:abryfs/willitsend", "willitsend-mcp"]
    }
  }
}

For AI agents — paste this block into your agent (or point it at this README):

Install the willitsend MCP server (pre-send SMS/iMessage lint, no API key needed):
- Claude Code: run `claude mcp add willitsend -- npx -y -p github:abryfs/willitsend willitsend-mcp`
- Any other MCP client: add {"command": "npx", "args": ["-y", "-p", "github:abryfs/willitsend", "willitsend-mcp"]} to its MCP server config.
Then, before every send_message (or equivalent) call, call preflight_message with the
draft body, is_first_message_to_contact (true/false when known), and brand_name.
Treat verdict "block" as do-not-send: apply the returned fix strings and re-run until
pass. Treat "needs_context" as a signal to determine whether this is a first message
(check conversation history), never as permission to send. For high-volume loops pass
response_format: "concise" (~4 tokens on pass).

No API key required. Set AGENTPHONE_API_KEY if you want a live iMessage/SMS capabilities lookup for phone-number destinations; without it the tool runs offline. The config above installs straight from this repo (a prepare script builds on install) — nothing to sign up for. willitsend also publishes to npm and the MCP Registry under the server name io.github.abryfs/willitsend; once a release is cut, registry-aware clients can add it by name and npx -y willitsend starts the server directly. See docs/publishing.md for the release runbook.

As a library (npm install github:abryfs/willitsend):

import { preflight } from "willitsend";

const report = preflight({
  body: "Acme: thanks for signing up. Your order shipped. Reply STOP to unsubscribe.",
  is_first_message_to_contact: true,
  brand_name: "Acme",
});

report.verdict; // "pass" | "warn" | "block" | "needs_context"
report.findings; // each with severity, fix, and a citation URL
report.trace.segments; // { encoding, units, segments, perSegment, ... }

As a CLI: npx -y -p github:abryfs/willitsend willitsend-cli --help (or npx -y -p willitsend willitsend-cli once installed from npm). Exit codes: 0 pass/warn, 1 block, 2 needs context, 3 usage error. It drops into CI or a shell pipeline as-is.

What it checks

Rule

Severity

Source

first-message.opt-out: first message to a contact must carry opt-out instructions

block

AgentPhone docs

first-message.brand: first message must identify the brand (checked only against a brand_name you provide, never guessed)

block

AgentPhone docs

first-message.opt-in: first message should acknowledge how the contact opted in

warn

AgentPhone docs

first-message.media-only: compliance text can't ride in an image

warn

AgentPhone docs

segments.unicode-blowup: one non-GSM character re-encodes the whole message as UCS-2

warn

AgentPhone docs

imessage.feature-fallback: send_style, threaded replies, and carousels drop without a trace on SMS fallback

warn

AgentPhone docs

imessage.invalid-send-style, imessage.carousel-count: invalid effect names, carousels outside the documented 2-20 range

block

AgentPhone docs

imessage.new-contact-cap: iMessage caps new-contact sends at 50/day per line

info

AgentPhone docs

destination.invalid, destination.voip: malformed destinations; known-VoIP lines (line type is never guessed from the number)

block / warn

send API / AgentPhone docs

content.shaft: sex/alcohol/firearms/tobacco terms carriers filter (hate speech has no keyword rule: word lists can't detect it and we don't pretend)

warn

Twilio guidelines

content.url-shortener: shared public shorteners (bit.ly, tinyurl, …) conflict with CTIA dedicated-shortener guidance

warn

CTIA MP&BP (PDF)

content.spam-patterns: ALL-CAPS runs, $$$, !!!

info

heuristic

Rules come in two labeled tiers. Rules sourced from AgentPhone's own documentation can block. Industry-sourced rules warn at most, because a keyword heuristic has no business vetoing your send.

The verdict model

A finding that depends on context you didn't supply doesn't pretend to be certain. If you never say whether this is the first message to a contact, the opt-out rule reports conditionally and the verdict is needs_context. You get no fake pass and no fake block.

flowchart LR
    F[findings] --> B{any block finding<br/>with known context?}
    B -- yes --> BLOCK
    B -- no --> C{any block finding<br/>waiting on context?}
    C -- yes --> NC[NEEDS_CONTEXT]
    C -- no --> W{any warning?}
    W -- yes --> WARN
    W -- no --> PASS

Every report also carries a send trace: destination classification, assumed channel (iMessage/SMS/MMS), full segment math (encoding, septet and code-unit counts, placement-aware per-segment packing), and, given a 10DLC campaign tier, what this message costs against published daily segment caps.

Benchmarks

Reproduce every number here from the repo; none of them require an account.

  • Segment-math parity: agrees with Twilio's reference segment calculator on encoding and segment count across a frozen 126-vector corpus: GSM-7/UCS-2 boundaries, extension characters, emoji, ZWJ sequences, and a deterministic fuzz sweep. The corpus and suite live in test/parity.test.ts; run npm test.

  • Latency: median ~4µs per message, ~100,000 messages/second on one thread (Node 22, Apple Silicon laptop; single-pass code-point tables, zero per-character allocation). Run npm run bench on yours. Preflighting every outbound message is cheaper than logging it.

  • Worked cost example, from published caps: a sole-proprietor 10DLC campaign gets 1,000 T-Mobile segments/day (≈3,000 total US, per AgentPhone's published estimate). One stray emoji that flips a 2-segment GSM-7 message to 4 UCS-2 segments halves the number of messages that quota buys. Same text, same recipients, half the reach.

You will find no delivery-rate improvement claims here. That claim needs send data we don't have.

What this can't do

Carriers filter with systems whose rules they don't publish. The policy layer is public (conduct codes, content categories, volume caps); the runtime filtering decisions are deliberately opaque, and only part of the outcome is observable (some blocks return explicit filter errors, some messages are accepted and silently never delivered). This tool covers the deterministic, documented layer, and nothing else:

  • A pass is not a delivery guarantee. It means nothing documented will kill the message.

  • The opt-in check verifies language presence, not that consent exists. Consent lives in your records, not in message text.

  • Detection is English-only in v1 (findings carry a locale field).

  • Quota math is a static illustration from published caps, not your account's live state.

  • The tool never infers line type (VoIP/mobile) from a phone number. Pass destination_line_type from a lookup service if you have one; libphonenumber-js gives a free approximation, with known limits for US numbers.

Prior art

  • TwilioDevEd/message-segment-calculator is the reference for segment math. This library is tested for parity against it rather than competing with it.

  • sms_policy_checker covers similar compliance ground for Ruby/Rails with an LLM layer; willitsend is the deterministic, zero-network counterpart.

  • Web checkers (10dlccheck.com, Calilio) cover overlapping rules as human-facing forms. willitsend makes those checks embeddable: a library an agent can call a hundred thousand times a second, with citations.

  • As far as we can tell, this is the first MCP tool for pre-send SMS content compliance. Corrections welcome.

Privacy

No telemetry. No network calls, except the optional capabilities lookup you enable with an API key. The tool never logs, stores, or echoes message bodies in its output. The playground runs in your browser and sends nothing anywhere.

Future

  • The engine's natural home is server-side: a dry_run parameter on the send endpoint itself. The library is written to drop in, as a pure function with no state and a dependency-free core.

  • Close the loop: correlate preflight verdicts with delivery-status webhooks, so rule precision is measured against real outcomes instead of assumed. Filtering is partially observable (explicit filter errors on some blocks, silence on others), which is exactly enough signal to grade a deterministic ruleset honestly. Learning the opaque layer itself takes aggregate send data across many senders; that belongs to platforms, not to a stateless client tool.

  • A rendered deliverability report card via the MCP Apps extension.

  • Locale packs beyond English.

Developing

git clone https://github.com/abryfs/willitsend && cd willitsend
npm install   # builds via prepare
npm test      # 191 tests: unit, Twilio parity, held-out acceptance
npm run bench

License

MIT

Available Tools

1 tool
preflight_messagePreflight a message before sendingA
Read-onlyIdempotent

Analyzes (lints) a draft SMS/iMessage BEFORE you send it — it sends nothing itself, makes no delivery attempt, and has no side effects. Call this first, before send_message or any other messaging tool, on every outbound draft. Returns: a verdict (pass, warn, block, or needs_context — block-severity issues that depend on context you didn't provide, like whether this is the first message to this contact); a list of findings, each with a severity, a stable rule id, a plain-language explanation, an optional concrete fix, and a citation URL (AgentPhone docs, CTIA, or Twilio guidelines) backing the rule; and a send trace with the destination classification, the assumed delivery channel (imessage/sms/mms/unknown), SMS segment math (encoding, segment count), and — given a 10DLC campaign_type — a daily-quota illustration. Use it to catch carrier-filtering risks (missing opt-out language, missing brand identification, missing opt-in wording on first messages), invalid iMessage send_style values, oversized media carousels, and GSM-7/UCS-2 segment blowups from stray unicode before spending a real send. Every finding's fix field is directly actionable: apply it to the draft verbatim (e.g. append the exact quoted sentence), then call preflight_message again — loop until the verdict is pass. Never treat needs_context as permission to send; supply the missing context and re-check.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesThe exact message text to preflight. Pass an empty string for a media-only send. This text is used only for local analysis — the tool never stores or forwards it anywhere.
to_numberNoSingle destination: E.164 phone number (e.g. +15551234567), email (iMessage only), a 5-6 digit short code, or a grp_ group id. Omit when using `recipients` for a multi-recipient group.
brand_nameNoSender brand or company name that should be identifiable in a first message. Without it the brand-identification check degrades to advisory only.
media_urlsNoMedia attachment URLs. 2-20 entries triggers an iMessage carousel; check the returned findings for carousel-size warnings on other channels.
recipientsNo2+ destinations to create a new iMessage group (iMessage only, never delivers as SMS). Do not combine with to_number.
send_styleNoiMessage-only visual send effect (e.g. "confetti", "slam"). Silently dropped outside iMessage — flagged unless the channel is confirmed iMessage.
campaign_typeNo10DLC campaign tier, if known, to attach a static daily-send-cap illustration to the trace.
response_formatNoOutput size. "detailed" (default): full messages, fixes, and citation URLs. "concise": one line per finding (severity, rule, fix), ~10x fewer tokens — same engine, same verdict, everything needed to act; use it for high-volume loops.
reply_to_message_idNoiMessage-only threaded reply target message id.
destination_line_typeNoDestination phone line type, if known from an external lookup. Never guess this from the number itself — VoIP lines often have unreliable iMessage/SMS delivery.
destination_capabilitiesNoKnown delivery capabilities for the destination, if you already looked them up. Passing this explicitly always takes precedence over — and skips — this server's own optional lookup.
is_first_message_to_contactNoWhether this is the first outbound message ever sent to this contact. Set true or false when you know it — first messages carry stricter compliance rules (opt-out language, brand identification, opt-in wording). Leave unset only if genuinely unknown; the tool then reports affected findings as conditional instead of asserting them (verdict needs_context).

Output Schema

ParametersJSON Schema
NameRequiredDescription
traceYes
verdictYes
findingsYes

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (readOnlyHint=true, idempotentHint=true) are reinforced and expanded by the description: 'sends nothing itself, makes no delivery attempt, and has no side effects.' It also details the verdict types, the loop behavior, and that body text is used only for local analysis. There is no contradiction between the description and 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?

The description is long but front-loaded with the essential safety and usage statement. It covers return values, rules, and a verification loop. Some redundancy exists (e.g., 'sends nothing itself' and 'no side effects' are repeated), but the complexity of the tool justifies the length.

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?

The description fully covers what the tool does, what it returns (verdicts, findings, trace), how to use it iteratively, and compliance use cases. An output schema is present, so return-value details are already structured. The description also handles edge cases like needs_context and media carousels.

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 each parameter is individually described. The tool description adds cross-parameter context: how media_urls triggers carousel warnings, how campaign_type affects the quota illustration, and how is_first_message_to_contact influences verdicts. This goes beyond the schema 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?

The description opens with a specific verb and resource: 'Analyzes (lints) a draft SMS/iMessage BEFORE you send it.' It clearly distinguishes itself from send_message by stating it sends nothing and makes no delivery attempt. The purpose is unmistakable and well-aligned with the title.

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?

Explicit guidance is given: 'Call this first, before send_message or any other messaging tool, on every outbound draft.' It also tells the user what not to do: 'Never treat needs_context as permission to send; supply the missing context and re-check.' This covers both when to use and when not to proceed.

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

TDQS

A4.6/5.0
Disambiguation5/5

With only one tool in the server, there is no possibility of confusing it with another tool. The purpose is unambiguous by default.

Naming Consistency5/5

The single tool name 'preflight_message' follows a clear verb_noun snake_case convention. With only one tool, there is no inconsistency to detect.

Tool Count3/5

A single tool feels thin for a typical server, but the purpose here is narrowly scoped to preflight message linting, so the count is borderline but not unreasonable.

Completeness4/5

The preflight_message tool covers the full linting lifecycle: it analyzes drafts, returns verdicts and actionable findings, and provides delivery-channel estimates. Minor gaps exist (e.g., no way to retrieve a rule set or manage campaign types), but the core domain is well covered.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI assistants to read, search, and send iMessages with features like contact name resolution, session grouping, and attachment listing. It provides intent-aligned tools to efficiently navigate conversation history and manage messages through natural language queries.
    6
    MIT
  • A
    license
    C
    quality
    D
    maintenance
    Enables AI agents to send, receive, schedule, and manage SMS and MMS messages using the Twilio Programmable Messaging API. It provides comprehensive tools for handling bulk messaging, conversation threads, and real-time inbox monitoring through a secure, production-grade architecture.
    16
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Programmatic email deliverability testing for AI agents. Create inbox placement tests across Gmail, Outlook, Yahoo, Mail.ru, Yandex — get per-provider placement (Inbox/Spam/Promotions), SPF/DKIM/DMARC auth, Rspamd & SpamAssassin verdicts, DNS health (MX, PTR, DNSBL), and live SSE results.
    5
    57
    1
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Compliance intelligence layer for AI agents sending WhatsApp Business messages. Prevents account suspensions by validating Meta's rules (care windows, opt-outs, rate limits) in real-time before every send.
    1

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/abryfs/willitsend'

If you have feedback or need assistance with the MCP directory API, please join our Discord server