Skip to main content
Glama
Sign In

TextKit

by com.jointextkit
OverviewDiscussionsAdmin

Test automation

test_automation
Destructive

Text an automation's messages to your own verified phone or a verified recipient now, skipping waits and conditions, without activating it (drafts work). Pass sample event properties; steps sends only those step ids. No run starts and stats do not change. Texts from a live number are real and billed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "to": "<to>"
    },
    "name": "test_automation"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesAutomation id
toYesE.164: your own verified phone or a verified recipient
fromNoOptional. Send this test from another of your numbers in the same mode (the automation is not changed), e.g. a verified toll-free while its own number is in review.
stepsNoOnly these send_sms step ids. Default: all of them
propertiesNoSample event properties for merge fields
idempotency_keyNoOptional. Retries are already safe: the same call with the same inputs within 10 minutes is done once and answers with the first result. Pass your own key to dedupe across a longer gap, or a new one to repeat an identical call on purpose.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / from
      Added value: +{
+  "description": "Optional. Send this test from another of your numbers in the same mode (the automation is not changed), e.g. a verified toll-free while its own number is in review.",
+  "type": "string"
+}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations by disclosing what actually happens: waits and conditions are skipped, no run starts, stats are unchanged, the automation is not activated, and texts from a live number are real and billed. The billing/cost warning is exactly the context an agent needs before triggering a destructiveHint operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the core action and immediately followed by the two consequences that matter most (no run, real billed texts). No filler or repetition of the schema.

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 six-parameter mutation with nested objects and no output schema, the description covers the side effects, cost, and non-effects well. It leaves the response shape and any rate/permission constraints unstated, which is a minor gap given the otherwise strong behavioral coverage.

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 the baseline is 3, but the description adds real meaning beyond the schema for `steps` (only those step ids are sent) and `properties` (sample event properties feed merge fields). It says nothing about `from` or `idempotency_key`, which the schema handles on its own.

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 concrete verb and resource: send an automation's messages now to a verified phone, skipping waits and conditions. It implicitly separates itself from activate_automation ("without activating it") and preview_automation ("Text ... now"), but never names those siblings, so the differentiation requires a small inference.

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?

Clear about the situation it serves: testing an automation's messaging without turning it on, and drafts are explicitly allowed. It does not name the closest alternative (preview_automation) or state exclusions, so an agent must still infer which tool wins when it only wants a preview.

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

All TextKit toolsInspect
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