Skip to main content

​
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:
It uses stateless Streamable HTTP. The connector is accountless and does not require an API key. See the quickstart for connection settings and the complete workflow.
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.

​
What the connector supports

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.

​
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 for exact meanings.

​
Agent instructions

Hum publishes a provider manual through the server’s existing skill-over-MCP mechanism: 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.

​
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. 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.