Skip to main content
Glama

TaScan

by io.github.snowbikemike
OverviewDiscussionsAdmin

tascan_send_sms

Send a transactional TaScan SMS text to a worker (by worker_id, using their phone on file) or to a raw phone number. Optionally attach a task list — the recipient gets a tap-to-open checklist link. Attach images (MMS) with media_url (public https image URL) or media_base64 + media_type (jpeg/png/gif, max 3.5 MB) — e.g. a diagram, a tutorial photo or a site photo; the message text is optional when an image is attached. Sends from TaScan's carrier-registered A2P number (or the org's own Twilio if BYOK). Counts against the org's monthly SMS quota unless BYOK. Messages are auto-prefixed with "TaScan:" per carrier registration; transactional/work-related content only, no marketing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
phoneNoRaw phone number (e.g. "+17025551234") — used when no worker_id given
list_idNoOptional task list ID — appends a tap-to-open worker checklist link
messageNoMessage text. Transactional and work-related only.
media_urlNoOptional image to attach (MMS): a public https URL of a JPEG, PNG or GIF. The carrier fetches it at send time.
worker_idNoWorker ID — sends to their phone on file (preferred over raw phone)
media_typeNoMIME type of media_base64 (not needed when media_base64 is a data: URI).
include_linkNoWhen a list_id is given, append the tap-to-open link to the SMS body (default true). Set false to send the message text alone — the link is still returned for you to share another way.
media_base64NoOptional image to attach (MMS) as base64 bytes (a data: URI prefix is accepted). JPEG, PNG or GIF, max 3.5 MB. Stored privately by TaScan and sent through a short-lived link.
idempotency_keyNoB1: optional replay key (up to 1024 chars, no braces) sent verbatim as the Idempotency-Key header instead of a fresh one per call — a retried call with the SAME key replays the original response instead of sending a second text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / media_base64
      Added value: +{
+  "description": "Optional image to attach (MMS) as base64 bytes (a data: URI prefix is accepted). JPEG, PNG or GIF, max 3.5 MB. Stored privately by TaScan and sent through a short-lived link.",
+  "type": "string"
+}
    • addedInput schema / properties / media_type
      Added value: +{
+  "description": "MIME type of media_base64 (not needed when media_base64 is a data: URI).",
+  "enum": [
+    "image/jpeg",
+    "image/png",
+    "image/gif"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / media_url
      Added value: +{
+  "description": "Optional image to attach (MMS): a public https URL of a JPEG, PNG or GIF. The carrier fetches it at send time.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "message"
-]New value: +[]
  2. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "B1: optional replay key (up to 1024 chars, no braces) sent verbatim as the Idempotency-Key header instead of a fresh one per call — a retried call with the SAME key replays the original response instead of sending a second text.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / include_link
      Added value: +{
+  "description": "When a list_id is given, append the tap-to-open link to the SMS body (default true). Set false to send the message text alone — the link is still returned for you to share another way.",
+  "type": "boolean"
+}
  4. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false. The description adds valuable context beyond those hints: the message is sent from TaScan's carrier-registered A2P number (or org Twilio if BYOK), counts against the org's monthly SMS quota unless BYOK, and is auto-prefixed with 'TaScan:' per carrier registration. It does not mention rate limits or failure modes, but for a send tool it is meaningfully transparent about billing and sender identity.

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 a single dense paragraph that front-loads the core action before covering optional features and sending constraints. Every sentence carries relevant information, though bullet-point structure would improve scanability for the media and sender details.

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?

With no output schema and full annotation coverage, the description must explain send behavior, media handling, link attachment, sender identity, quota impact, and content policy — and it does. It omits any mention of idempotency_key (though the schema covers it) and doesn't point to get_sms_status for delivery verification, but overall it is complete enough for an agent to invoke the tool correctly.

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%, so the schema already documents all nine parameters thoroughly. The description adds minor extra meaning, such as 'the message text is optional when an image is attached,' but largely restates what is already in the schema (MMS constraints, list link behavior, worker_id preference). Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Send a transactional TaScan SMS text to a worker ... or to a raw phone number.' It also implicitly distinguishes itself from siblings like tascan_schedule_sms and tascan_cancel_scheduled_sms by focusing on immediate sending. An agent can tell what this tool does without opening the schema.

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?

The description gives clear context (transactional, work-related, no marketing) and explains when to use worker_id vs phone, but it never names alternatives such as schedule_sms, send_task_email, or post_message. Usage is implied by the send action, not explicitly contrasted with sibling tools.

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

All TaScan toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources