Skip to main content
Glama

Utilify

by io.github.Utilify-io

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 set destructiveHint=true, and description reinforces this by noting enrollment is user-initiated and requires confirmation. Adds caveats about error handling and API enrollment, though does not explicitly mention destructiveness.

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 well-structured with enumerated caveats, but somewhat lengthy. Front-loaded with main purpose and usage, but could be trimmed slightly without losing value.

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?

Covers return types (signup URL, phone, signup_id), error scenarios (TDU mismatch), and alternatives (concierge, check_signup_status). Adequate given no output schema.

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 provides 100% coverage with descriptions for all 6 parameters. Description adds minor context (provider_id accepts UUID or slug) but mostly restates schema info, so baseline 3 is appropriate.

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?

Clearly states the tool initiates enrollment with a utility provider at a Texas address, after user confirmation. Uses specific verbs ('Start enrollment') and distinguishes from siblings like check_signup_status.

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?

Explicitly describes when to use (after user chooses plan and confirms, with example phrases) and when not to (TDU mismatch -> search again; concierge request -> point to URL).

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

All Utilify toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: search, details, comparison, promotions, signup, status, checklist, and solar lead. No overlaps.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., check_signup_status, compare_providers, get_move_checklist).

Tool Count5/5

8 tools cover the utility setup domain well, from discovery to enrollment and status tracking, without being excessive or too sparse.

Completeness4/5

Covers the main lifecycle: search, details, compare, promotions, signup, status, checklist, and solar. Missing update/cancel for signups but that's acceptable as enrollment is often handled externally.

Resources