Skip to main content
Glama

initiate_signup

Destructive

Start enrollment with a specific utility provider at a Texas address — use after the user has chosen a plan and confirmed they want to sign up. Use when the user says 'go ahead and sign me up', 'enroll me with this plan for my move-in day', or 'lock in this rate for my new San Antonio apartment'. Returns a signup URL, phone number, or begins API enrollment and produces a signup_id for later status checks (track with check_signup_status). Caveats: (1) user-initiated only — always confirm the plan, address, and move-in date in the conversation before calling. (2) If the chosen provider doesn't serve the address's TDU it will return a structured error; re-run search_utility_providers to get TDU-correct options. (3) If the user wants Utilify to handle enrollment for them rather than self-serving, point them to the $49 concierge at https://utilify.io/concierge instead of calling this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesFull service address including city, state, and ZIP code
plan_idYesThe specific plan to enroll in
session_idNoOptional session ID for tracking
provider_idYesThe provider to sign up with. Accepts either the provider UUID (from search_utility_providers) or the provider slug (e.g. "chariot-energy").
move_in_dateYesISO 8601 date for desired service start
customer_infoYesCustomer contact information

TDQS

A4.4/5.0
Behavior4/5

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

Annotations include destructiveHint: true; description adds that the tool begins API enrollment and produces a signup_id, and mentions structured errors. Does not fully detail irreversible actions but provides adequate context.

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?

Description is thorough but each sentence is purposeful, front-loaded with the core action and usage context. Slightly lengthy but well-organized.

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 no output schema, the description explains return types (signup URL/phone, signup_id) and error handling. Covers all essential aspects for a complex tool with 6 parameters.

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 coverage is 100% so description does not need to repeat parameter details. It adds some value by noting provider_id accepts UUID or slug, but overall adds little beyond the schema.

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 clearly identifies the tool as starting enrollment with a utility provider at a Texas address, and distinguishes it from the sibling tool check_signup_status for later tracking.

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?

Provides explicit when-to-use criteria (after user confirms plan, address, move-in date) with example user phrases. Includes three caveats covering user-initiated confirmation, TDU error handling, and concierge alternative.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool serves a distinct function: searching, comparing, getting details, promotions, signing up, checking status, generating checklist, and solar interest. No overlapping purposes; agents can clearly differentiate.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., search_utility_providers, get_move_checklist), making them predictable and easy to learn.

Tool Count5/5

With 8 tools, the set is well-scoped for a Texas utility assistant. It covers the essential workflows without being too sparse or overwhelming.

Completeness5/5

The tool surface covers the full lifecycle: search, compare, details, promotions, signup, status, checklist, and solar interest. There are no obvious gaps for the stated domain of Texas utility setup.

Resources