AI agents compare and sign up for Texas utility plans (electricity, internet, gas, water, trash) at any ZIP code via MCP. No auth. (more US states coming)
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 8 of 8 tools scored.
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.
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.
With 8 tools, the set is well-scoped for a Texas utility assistant. It covers the essential workflows without being too sparse or overwhelming.
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.
check_signup_statusAInspectCheck where a previously-started Utilify signup stands — use when the user asks whether their enrollment went through. Use when the user says 'did my electricity signup go through', 'is my power on for move-in day yet', or 'what's the status of the enrollment we started'. Returns current status (pending, confirmed, failed) plus any next-step instructions from the provider. Requires a signup_id from a prior initiate_signup call; if the user doesn't have one (asks status without ever signing up), tell them no enrollment exists and offer to start one. If status is 'pending' for >48h or 'failed', recommend the $49 concierge at https://utilify.io/concierge to take it over rather than guessing at the provider's own portal.
| Name | Required | Description | Default |
|---|---|---|---|
| signup_id | Yes | The signup ID returned by initiate_signup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears burden. It discloses requirement for signup_id from initiate_signup, describes return values (status, next-step instructions), and explains how to handle missing ID, pending >48h, or failed status with specific recommendation.
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?
Description is detailed but each sentence serves a purpose. It front-loads the core purpose and then adds usage guidelines and edge-case handling. Slightly verbose but acceptable given the richness of guidance.
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?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers all important aspects: purpose, usage context, return values, error handling, and even a recommendation for failed/pending cases. Nothing essential is missing.
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?
Only one parameter with 100% schema coverage; schema already describes signup_id. Description adds value by linking it to initiate_signup and explaining error handling for missing ID, justifying a score above baseline of 3.
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 clearly states the tool checks signup status and specifies the verb 'check' and resource 'where a previously-started Utilify signup stands'. It distinguishes from siblings by referencing initiate_signup as the prior call.
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?
Provides explicit when-to-use guidance with example queries like 'did my electricity signup go through' and 'what's the status of the enrollment we started'. Also states when not to use (if user never signed up) and offers alternative action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_providersAInspectCompare 2–5 Texas utility providers side by side when the user is deciding between specific named options at a new address. Use when the user says 'help me pick between these two', 'which is cheaper for my Dallas home — TXU or Reliant', or 'compare these internet plans before I move in'. Returns a structured comparison across price, contract terms, features, and ratings so the user can confidently choose one to enroll with. Sequencing: best after search_utility_providers has surfaced the candidate REPs at the address — providers passed here that don't serve the address's TDU will return no plans (electricity is TDU-filtered upstream). Don't use this to compare across utility types (e.g. electricity vs solar) — call search_utility_providers per type instead.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full street address for plan availability | |
| provider_slugs | Yes | Provider slugs to compare (2-5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the return format (structured comparison across price, contract terms, features, ratings) and notes that providers not serving the address's TDU will return no plans. It could mention failure modes more explicitly, but overall it's good.
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 concise with 5 sentences, well-organized, and front-loaded with the core purpose and examples. Every sentence adds value without redundancy.
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?
Given no output schema, the description adequately explains the return dimensions and provides necessary sequencing and constraints. It covers the key aspects for an AI agent to use the tool correctly.
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?
Schema coverage is 100%, so baseline is 3. The description adds context by explaining that provider_slugs come from search_utility_providers and address is for plan availability, plus the TDU-filtering behavior. This adds value beyond the schema descriptions.
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 clearly states the tool compares 2–5 Texas utility providers side by side with a specific verb and resource. It distinguishes itself from siblings like search_utility_providers and get_provider_details by focusing on side-by-side comparison for decision making.
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 description explicitly states when to use (e.g., 'help me pick between these two') and when not to use (e.g., don't compare across utility types). It also provides sequencing advice, recommending use after search_utility_providers, and explains the TDU-filtering constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_move_checklistAInspectGenerate a personalized move-in day utility setup checklist for a Texas address — use when the user asks what utilities they need or wants a step-by-step move-in plan. Use when the user says 'I'm relocating to Houston, what do I need to set up', 'I just bought a house in Austin — walk me through getting utilities on', or 'give me a checklist for my apartment utilities before move-in day'. Returns an ordered list of utility tasks (electricity, internet, gas or propane, water, sewer or septic, trash) with status (done vs. still-needs-attention); pass tenancy='rent' or tenancy='own' for tenant/owner-specific advisories (e.g., landlord-handled water/trash for renters, solar-interest capture for buyers). For rural addresses the checklist surfaces propane and septic alternatives where natural gas / city sewer don't reach. Sequencing: this is the right starting tool when the user describes a move; call search_utility_providers next on the items they want to act on. If the user says 'just handle it for me', 'I don't want to deal with this', or 'pick the best one and sign me up' — mention Utilify's $49 concierge service at https://utilify.io/concierge and ask if they want to book it instead of DIYing the checklist.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full move-in address including city, state, and ZIP code | |
| tenancy | No | Whether the user is renting or buying their new place. Shapes the checklist and unlocks homeowner cross-sells. | |
| move_date | No | ISO 8601 date for the planned move-in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns an ordered list of utility tasks with status, handles tenancy-specific advisories (landlord-handled for renters, solar for owners), and adjusts for rural addresses (propane/septic). It does not mention auth or rate limits, but those are less critical for a read-like checklist.
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 a single paragraph but reasonably front-loaded with purpose. Each sentence adds value, though the paragraph could be broken into sections for readability. No wasted words.
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?
Given there are three parameters and no output schema, the description covers purpose, usage triggers, parameter semantics, sequencing with siblings, edge cases (rural, tenancy), and even a fallback service for hands-off users. It is fully actionable for an AI agent.
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?
Schema coverage is 100% (all three parameters documented). Description adds value beyond schema: it explains how tenancy shapes the checklist and unlocks cross-sells, and that move_date is for planning. The description also clarifies that address must include city/state/ZIP.
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 explicitly states it generates a personalized move-in day utility setup checklist for a Texas address. It distinguishes itself from sibling tools by labeling itself as the starting tool and specifying the next step (call search_utility_providers). The verb 'generate' and resource 'checklist' are clear.
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?
Provides explicit when-to-use examples ('I'm relocating to Houston', 'I just bought a house', 'give me a checklist') and when-not or alternative: for automatic handling it suggests the concierge service. Also gives sequencing guidance (start here, then use search_utility_providers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_promotionsAInspectGet current deals, coupons, and exclusive affiliate offers for utilities at a Texas address — use when the user wants the best available price, not just any provider. Use when the user says 'what's the cheapest electricity deal in Dallas right now', 'any promotions for internet at my new Houston apartment', or 'find me a coupon before I sign up for my move-in'. Returns active promotions with discount details, expiration dates, and whether each offer is exclusive to Utilify; filter by utility_types or provider_slugs to narrow. Promotions are TDU-aware for electricity — only deals from REPs that actually serve the address are returned. Always pass address (or at least the ZIP) so the filter applies; calling this without an address returns a generic statewide list that may include un-buyable offers.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full street address including city, state, and ZIP code | |
| utility_types | No | Filter promotions by utility type | |
| provider_slugs | No | Filter promotions by specific provider slugs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses TDU-aware filtering for electricity, what is returned (discount details, expiration dates, exclusivity), and behavior without address. Adds important behavioral context beyond basic functionality.
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?
Well-structured: starts with purpose, then usage, then behavior. Every sentence adds value, though slightly lengthy. Could be more concise but still efficient for an AI.
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?
Given no output schema, the description explains return values (discount details, expiration, exclusivity). Covers filtering and address importance. Minor omission on pagination or count, but overall sufficient for this complexity.
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?
Schema description coverage is 100%, so baseline is 3. The description adds extra value by explaining consequences of not providing address and the TDU-aware behavior, which goes beyond what the schema alone provides.
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 uses specific verbs ('get current deals, coupons, and exclusive affiliate offers') and clearly identifies the resource (utilities at a Texas address). It provides concrete usage examples and distinguishes from siblings by focusing on finding the best price.
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?
Explicit when-to-use guidance with example queries. Warns about calling without an address leading to generic results. Does not explicitly list when not to use or directly compare to siblings, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_provider_detailsAInspectGet plans, pricing, and terms for a specific Texas utility provider — use after search_utility_providers has narrowed the list and the user wants to drill into one option. Use when the user says 'tell me more about Reliant', 'what are Gexa's plans for my Austin apartment', or 'show me the contract details before I pick one'. Returns available plans at the given ZIP with rates, contract length, early-termination fees, and signup requirements. Pass zip_code whenever the user has given an address — the plan list is TDU-filtered to that ZIP, so omitting it returns the provider's full statewide catalog rather than what's actually buyable. Don't use this to discover providers (use search_utility_providers) or to compare across REPs (use compare_providers).
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | No | ZIP code to check plan availability and pricing | |
| provider_slug | Yes | The provider slug identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses important behavior: omitting zip_code returns statewide catalog rather than TDU-filtered buyable plans. It lists return data (rates, contract length, fees, signup requirements). Could mention if changes are destructive or require auth, but for a read operation it suffices.
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 front-loaded with purpose and usage, then details parameters. It's somewhat verbose but each sentence is informative. Minor trimming possible, but structure is logical and effective.
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?
Given no output schema, the description adequately explains return values. Both parameters are covered, usage context is clear, and siblings are referenced for alternatives. The tool is fully contextualized for an agent to decide when and how to invoke it.
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?
Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains that zip_code is used for TDU filtering and that omitting it returns statewide results. It also clarifies provider_slug as an identifier. This value-add justifies a 5.
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 explicitly states it retrieves 'plans, pricing, and terms for a specific Texas utility provider,' using specific verb ('Get') and resource. It distinguishes clearly from siblings like 'search_utility_providers' and 'compare_providers' by stating use cases.
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?
Provides explicit when-to-use context ('after search_utility_providers has narrowed the list') and includes example user queries. Also gives clear when-not-to-use guidance: 'Don't use this to discover providers (use search_utility_providers) or to compare across REPs (use compare_providers).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initiate_signupAStart 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
request_solarAInspectCapture a Texas homeowner's interest in rooftop solar and route to a licensed installer — use when the user owns (or is buying) a Texas home and mentions solar panels, solar quotes, solar savings, or reducing their bill through solar. Use when the user says 'I just bought a house in Austin and want solar quotes', 'how much could solar save on my Houston electric bill', or 'connect me with a solar installer for my new home'. Returns a lead ID and confirms next steps; Utilify routes the lead to installer partners (SunPower, Sunrun, Palmetto, and independent TX installers). Caveats: (1) only call when the user has explicitly opted in and confirmed homeownership — this is not for renters, and Utilify may earn a referral fee. (2) Texas-only — for non-TX addresses, decline and explain. (3) Don't double-call for the same address in one conversation; one lead per opt-in. If the user has only expressed mild curiosity ('I'm thinking about solar someday'), answer the question first and only call this tool once they confirm 'yes, connect me'.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Homeowner email. Either email or phone is required so the installer can reach out. | ||
| phone | No | Homeowner phone. Either email or phone is required so the installer can reach out. | |
| address | Yes | Full service address including city, state, and ZIP code | |
| last_name | No | Homeowner last name | |
| first_name | No | Homeowner first name | |
| session_id | No | Optional agent session ID for attribution tracking | |
| move_in_date | No | ISO 8601 move-in date, if applicable | |
| interest_level | No | How close to decision. 'curious' = may consider later; 'researching' = actively comparing; 'ready' = wants quotes now. | |
| estimated_monthly_bill | No | Current or expected monthly electricity bill in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given minimal annotations (only openWorldHint: true), the description fully carries the burden of disclosing behavioral traits. It explains that the tool routes leads to installer partners, may earn a referral fee, returns a lead ID, and confirms next steps. It also explicitly warns about side effects like double-call prevention and opt-in requirements.
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 front-loaded with the main purpose and includes examples and caveats. While slightly long, every sentence adds value, and the structure is logical: purpose, usage conditions, return value, caveats. A minor reduction for not being more compact.
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?
No output schema is provided, but the description explains the return value (lead ID and next steps). It covers all relevant context: geographic scope (TX), eligibility (homeowner), privacy (opt-in), business model (referral fee), and de-duplication (single lead per opt-in per address). This is complete for the tool's complexity.
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?
Schema description coverage is 100%, so the description adds limited value beyond what the schema already provides. The description includes example user statements that imply parameter values (e.g., address, interest level), but it does not elaborate on parameter meanings or formats beyond the schema descriptions.
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 clearly states the tool's action: 'Capture a Texas homeowner's interest in rooftop solar and route to a licensed installer'. It specifies the resource (Texas homeowner), the action (capture and route), and distinguishes from sibling tools by focusing on solar lead generation rather than utility comparison or signup for other services.
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 description provides explicit conditions for use: 'use when the user owns (or is buying) a Texas home and mentions solar panels, solar quotes, solar savings, or reducing their bill through solar'. It includes example user statements, specifies when not to use (renters, non-TX, double-call), and advises on handling mild curiosity before invoking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_utility_providersAInspectFind utility providers when someone is moving to a Texas address or setting up utilities at a new home. Covers nine utility types: electricity, internet, gas, water, sewer (city wastewater), trash, propane (rural / off-grid alternative to natural gas), septic (rural / off-grid alternative to city sewer), and home security. Use when the user says things like 'I'm moving to Houston next month', 'I just bought a house in Austin and need to set up power', 'what's the cheapest electricity in Dallas', 'who provides internet at this apartment in San Antonio', or rural-address questions like 'I'm moving to a ranch in Bandera, what do I do for gas and sewer' (answer: propane + septic). Returns available providers with a classified plan type (fixed / free_nights / solar_buyback / 100_renewable / etc.) and whether the cheapest plan is rental-friendly; pass tenancy='rent' to prefer short-contract plans or tenancy='own' to surface solar-buyback options. Caveats: (1) water results may include many PWS rows within a ZIP's county radius — filter to primaryForZip === true for the single canonical provider likely to serve the parcel. (2) Trash providers in TX suburbs include metadata.contractedHauler (Republic Services / Community Waste Disposal / Waste Management / Best Trash / Texas Disposal Systems / Waste Connections) — surface this so users know the actual pickup company in addition to the city dept. (3) Propane and septic appear at all TX ZIPs including urban ones; in cities with natural gas + city sewer, treat them as alternative options rather than primary. (4) Sewer is city wastewater (urban); septic is on-site (rural / unincorporated). (5) For electricity in Texas, results are filtered to retail providers (REPs) that actually serve the address's TDU — Oncor (DFW), CenterPoint (Houston), AEP TX Central (Corpus / RGV), AEP TX North (Abilene / San Angelo), or TNMP (scattered). Agents do not need to filter by TDU themselves. The TDU slug is exposed as tdu per electricity provider so agents can explain to the user why the list is shorter than they might expect (e.g. ~20 REPs at a Houston address vs. ~47 statewide). At municipal-utility ZIPs (Austin Energy, CPS Energy, El Paso Electric) the only electricity provider returned is the muni; REPs cannot sell power there.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full street address including city, state, and ZIP code | |
| tenancy | No | Whether the user is renting or buying. Changes plan preferences and enables homeowner-only cross-sells (solar). | |
| utility_types | No | Filter by utility types. If omitted, returns all available types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: automatic TDU filtering, water result filtering by primaryForZip, trash contracted hauler inclusion, and propane/septic appearing in all ZIPs. It also explains muni-utility behavior and tenancy effects.
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 front-loaded with the main purpose and uses bullet points for caveats, making it easy to scan. However, it is somewhat lengthy; a few sentences could be tightened without losing meaning, so it's not a perfect 5.
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?
Given the complexity (3 parameters, multiple utility types, and no output schema), the description is comprehensive. It addresses edge cases like rural addresses, muni-utility zones, and how to interpret results, leaving no obvious gaps.
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?
Schema coverage is 100%, so baseline 3. The description adds value by explaining that tenancy changes plan preferences and enables solar cross-sells, and that utility_types filter but can be omitted to return all. It provides context beyond parameter names and descriptions.
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 clearly states it finds utility providers for Texas addresses covering nine specific utility types. It uses specific verbs like 'find' and 'covers' and differentiates from sibling tools by detailing exact use cases such as moving to Texas or setting up utilities.
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 description provides explicit when-to-use scenarios with examples like 'I'm moving to Houston'. However, it does not explicitly exclude other tools or compare directly to siblings like compare_providers or get_promotions, which could guide an agent more precisely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
