Utilify

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.

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": {
      "provider_id": "<provider_id>",
      "plan_id": "<plan_id>",
      "address": "<address>",
      "move_in_date": "<move_in_date>",
      "customer_info": "<customer_info>"
    },
    "name": "initiate_signup"
  }
}

Input Schema

Name	Required	Description
`address`	Yes	Full service address including city, state, and ZIP code
`plan_id`	Yes	The specific plan to enroll in
`session_id`	No	Optional session ID for tracking
`provider_id`	Yes	The provider to sign up with. Accepts either the provider UUID (from search_utility_providers) or the provider slug (e.g. "chariot-energy").
`move_in_date`	Yes	ISO 8601 date for desired service start
`customer_info`	Yes	Customer contact information

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedApr 22, 2026

changedInput schema / properties / provider_id / description

Previous value: -"The provider to sign up with"New value: +"The provider to sign up with. Accepts either the provider UUID (from search_utility_providers) or the provider slug (e.g. \"chariot-energy\")."

First observedApr 21, 2026

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 tools Inspect

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

Need Help?