> ## Documentation Index
> Fetch the complete documentation index at: https://docs.letshum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Hum Broadband MCP

> Connect an AI agent to Hum for broadband availability, exact-offer validation, authorized ordering, and outcome recovery

# Hum Broadband MCP

Hum's public MCP gives an agent four structured tools for a U.S. broadband workflow: resolve an
address, compare reported coverage with live-qualified offers, validate one exact offer, submit the
review the user authorized, and retrieve Hum's recorded fulfillment evidence.

The MCP endpoint is:

```text theme={null}
https://mcp.letshum.com/mcp
```

It uses stateless Streamable HTTP. The connector is accountless and does not require an API key.
See the [quickstart](/mcp/quickstart) for connection settings and the complete workflow.

<Warning>
  Do not use the MCP endpoint or contract as an extension of Hum's partner REST API. The partner API
  still does not place orders. Its widget, analytics, identifiers, and order states remain separate.
</Warning>

## What the connector supports

| Step               | Tool                 | What it does                                                                                            | Commitment boundary                                           |
| ------------------ | -------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| Find service       | `check_availability` | Resolves an address and returns FCC-reported coverage, live qualification, clarification, or questions. | Read-only. A poll reads the same lookup.                      |
| Prepare an order   | `validate_order`     | Refreshes one exact executable offer, collects requested details, and returns an exact review.          | Creates no order and sends no fulfillment request.            |
| Submit             | `create_order`       | Records the authorized review and queues its fulfillment submission.                                    | Committing. Call once after host authorization.               |
| Recover and follow | `get_order`          | Returns the latest persisted submission and fulfillment evidence for a checkout.                        | Read-only. Use after every lost or uncertain create response. |

The normal sequence is:

1. Resolve the address and start availability.
2. Poll the same lookup or answer its current qualification questions.
3. Select an exact executable offer returned by Hum.
4. Validate the selection and provide only the requested customer details.
5. Present the returned review and obtain authorization through the host's own approval mechanism.
6. Submit the validated draft once.
7. Retrieve the persisted result, especially when a submission response is missing or uncertain.

## Evidence and offers

Availability can be partial and asynchronous. Hum keeps two kinds of evidence separate:

* **FCC findings** describe provider-reported coverage in a census block or tract. They do not
  prove service at the exact address.
* **Live qualification** can return executable offers for the resolved address. It can still be
  running, need information, fail, or time out while FCC findings remain useful.

Catalog plans are informational. Only an offer with a server-returned `offer_id` and
`orderable_through_hum: true` can move to validation. See
[Availability and offers](/mcp/availability-and-offers).

## Ordering boundary

Validation returns the current review and the exact terms that can be authorized. It does not
place an order. The host is responsible for showing that review and obtaining authorization before
calling `create_order`.

Hum does not collect payment through this connector. Cancellation, modification, Social Security
numbers, existing-account credentials, bundles, provider installation tracking, final ISP
acceptance, and completed installation are outside this version.

The public fulfillment states describe only what Hum can prove about the submission:

* `queued`
* `submitting`
* `accepted_by_fulfillment`
* `rejected_by_fulfillment`
* `submission_unknown`
* `not_submitted`

None confirms ISP acceptance, serviceability, an installation appointment, or completed
installation. See [Ordering and recovery](/mcp/ordering-and-recovery) for exact meanings.

## Agent instructions

Hum publishes a provider manual through the server's existing skill-over-MCP mechanism:

* Public Markdown: [Order internet service](https://mcp.letshum.com/skills/order-internet-service/SKILL.md)
* MCP resource: `skill://order-internet-service/SKILL.md`

The manual explains Hum's workflow and data semantics. The host remains responsible for tool
selection, user interaction, information access, presentation, and its own authorization
interface. Clients that do not load the skill can still complete the workflow from tool
descriptions, schemas, and responses.

The availability-focused skill remains available for clients that only use
`check_availability`. Both public skills describe the schema-version 4 contract at the same
endpoint. See [Releases and migration](/mcp/releases-and-migration).

## Privacy and support

Tools request customer fields only when the selected provider requires them. Sensitive values are
not returned in public reviews or receipts. Do not send card data, Social Security numbers,
existing-account credentials, or payment authorization.

* [Hum privacy policy](https://letshum.com/privacy-policy/)
* [Testing instructions](/mcp/testing)
* [Support](mailto:support@letshum.com)

Include the response's correlation ID when the connector directs you to support. Do not send
opaque lookup, offer, checkout, or validation capabilities by email.