Skip to main content

Quickstart

Connect an MCP client to Hum’s stateless Streamable HTTP endpoint:
Hum does not require an account or API key. Your MCP client must support Streamable HTTP and the server’s negotiated MCP protocol version.

Connect

Adapt this connection setting to your client’s configuration format:
Restart or reconnect the client, then confirm that tools/list returns all four tools:
  • check_availability
  • validate_order
  • create_order
  • get_order
You can also load the Hum manual from skill://order-internet-service/SKILL.md. Loading the skill is optional; the tool descriptions and schemas contain the instructions needed to operate safely.

Complete workflow

The examples below show tool arguments, not raw HTTP requests. IDs are inert placeholders. Always use the exact opaque values returned to your client.
1

Start availability

Call check_availability with one complete U.S. service address:
Do not send continuation fields with the initial address.
2

Resolve clarification or questions

If Hum returns address candidates, ask the user to select one and continue with its exact ID:
Add unit only when the result requests it:
If Hum returns a current typed question set, collect the required answers without guessing and send the set together:
Use the answer keys and value types in the returned questions. Stale, missing, or extra answers can be rejected.
3

Preserve partial results and poll

Present FCC findings as area-level reported coverage even when the live check is still running. If the result says checking, wait at least retry_after_seconds, then call:
Polling the same lookup reads its current snapshot. It does not start another qualification.
4

Choose an executable offer

Show the user the facts Hum returned, keeping unknown values unknown. A catalog_plans item is informational. Select only an item from offers that has orderable_through_hum: true, and keep its exact offer_id.
5

Start validation

Pass the selected executable offer and its lookup to validate_order:
This creates or refreshes a draft. It does not create an order or contact fulfillment.
6

Provide only requested details

When validation returns required_fields, ask only for those values. Continue with the exact checkout and revision:
Do not send card data, a Social Security number, existing-account credentials, or fields that Hum did not request. If validation is still checking, poll with only checkout_id.
7

Present the exact review

When validation is ready, present the returned review without filling in unknown facts. Include all returned charges, discounts, fees, conditions, contract terms, installation preferences, and consents. If Hum reports a changed or expired offer, stop and follow the returned next action.
8

Obtain authorization and submit once

Use your host’s approval mechanism to obtain authorization for the current review and terms_hash. Only then call create_order:
Keep the idempotency key stable for this exact intended order. Do not reuse it for different terms or a different checkout.
9

Retrieve the outcome

Use the checkout ID to read the latest persisted evidence:
Call get_order after a normal submission and whenever the create_order response is lost, times out, disconnects, or is otherwise uncertain. Retrieve first; do not create a new checkout or blindly resubmit.

Interpret the result

queued means Hum durably recorded the authorized order. Later states describe the fulfillment submission evidence Hum has recorded. They do not confirm ISP acceptance, serviceability, an installation appointment, or completed installation. Read Ordering and recovery before presenting a fulfillment status. See the tool reference for complete input variants, fields, errors, and output schemas.

Before using production

Follow the testing instructions. Do not place a live order unless Hum has given you an explicit test arrangement with approved address and customer data.