send_smsText a client via Twilio using the mobile number on their MarianaTek profile. Only sends if the client has opted in to transactional SMS unless override_opt_in is true. [requires scope: email]
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| message | Yes | Plain text, max 600 chars | |
| client_id | No | ||
| override_opt_in | No | Send even if the client has not opted in (use only for urgent class changes) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the opt-in gate, the message-source behavior (profile mobile number), and the required scope. It does not describe what happens on failure or the cost of sending, but the annotations already flag the operation as non-read-only and destructive, so the added context is above the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the primary action front-loaded. The opt-in condition and scope requirement each add necessary behavior without verbose framing or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core behavior, opt-in guardrail, and scope requirement, which is adequate for a simple SMS tool. However, with four parameters and no output schema, it leaves a meaningful gap around how the agent should populate email versus client_id and whether at least one identifier is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema coverage, the description compensates only partially: it explains that the recipient's mobile number comes from the MarianaTek profile and clarifies override_opt_in's effect, but it does not disambiguate the email and client_id parameters or state how the client is identified. The schema covers message and override_opt_in, while the description adds only modest meaning to the identifier fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Text a client via Twilio using the mobile number on their MarianaTek profile.' This clearly distinguishes send_sms from send_email and other client-related tools. The opt-in caveat and scope note add precision without blurring the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opt-in condition ('Only sends if the client has opted in to transactional SMS unless override_opt_in is true') gives useful context for when the tool will act, but there is no explicit when-to-use versus send_email or any exclusion guidance. The usage is implied from the SMS-specific wording rather than stated as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, and the descriptions carefully separate operations like attendance_report, list_classes, and get_class_roster. A few reads overlap conceptually (get_client, get_reservation_history, get_credit_history, get_client_notes all return client-related data), but each has a specific output that an agent can distinguish with reasonable effort.
Tool names overwhelmingly follow a consistent action_object pattern: add_client_note, cancel_class, freeze_membership, refund_order, set_client_tag, unfreeze_membership. The get_/list_ prefix distinction is used predictably, and auth tools (login, logout, whoami) are standard exceptions rather than inconsistent naming.
41 tools is well beyond the 25+ threshold for a heavy tool set. Although each tool appears to serve a real studio-operations need, the sheer number creates a large surface for an agent to navigate and places significant burden on selection accuracy.
The tool set covers the core lifecycle well across clients, classes, memberships, orders, payments, and communications, with no obvious dead ends. Minor gaps exist, such as no update_client profile tool and no class-scheduling creation, but staff workflows can generally be completed.