Skip to main content

​
Testing

Use the public endpoint for connection and read-only discovery checks. A complete submission test requires an explicit Hum test arrangement because create_order can reach fulfillment.
Do not place a production order with invented data. Hum does not publish deterministic test addresses, reusable test credentials, or a self-service transactional sandbox. If Hum provides a review arrangement, use only its designated address, customer data, expected outcome, and cleanup procedure.

​
Public connection smoke test

Connect a generic MCP client to:
No API key is required. Record the client name and version, negotiated MCP protocol version, server name and version, endpoint, and test time. Verify:
  1. Initialization succeeds over Streamable HTTP.
  2. tools/list returns exactly check_availability, validate_order, create_order, and get_order with closed input schemas and the documented side-effect annotations.
  3. The server card reports the same endpoint, identity, and version.
  4. skills/list and skills/get expose both public skills.
  5. resources/read returns the exact canonical bytes for:
    • skill://check-internet-availability/SKILL.md
    • skill://order-internet-service/SKILL.md
You can compare the HTTP skill responses with those resources: Their byte counts and SHA-256 digests must match the corresponding skill discovery entries.

​
Contract and fixture checks

The released contract contains the exact public schemas and runtime input combinations. The scenario file contains synthetic responses approved for documentation and client development. For each documented request:
  1. Validate the arguments against the released tool input schema.
  2. Check the argument keys against the tool’s accepted runtime shapes.
  3. Confirm unknown keys are rejected.
For each documented response:
  1. Match it to a named scenario and its release provenance.
  2. Validate it against the released output schema.
  3. Confirm the page does not add fields or stronger claims than the fixture supports.
The fixtures demonstrate shapes and client behavior. They do not guarantee that a public address will produce a particular provider, offer, question, price, timing, or fulfillment result.

​
Availability exercises

With approved test data or the released fixtures, exercise:
  • ambiguous address selection
  • a missing unit
  • FCC findings while the live source is still checking
  • FCC-only, live-only, and both-source matches
  • live completion, failure, and timeout
  • a current typed question set and its continuation
  • informational catalog plans with no executable offer
  • at least one executable offer with an exact offer ID
  • an expired or stale continuation
  • rate limiting and a retry delay
Verify that the client preserves partial results, labels FCC findings as area evidence, waits before polling, sends no stale question answer, and never presents a catalog plan as orderable.

​
Validation exercises

With an executable fixture or approved environment:
  • start validation from an exact lookup and offer
  • use field_errors for actual missing or invalid values while recognizing that required_fields can include filled paths; reuse customer facts already supplied
  • send start, poll, and edit as separate exact input shapes; nest changed values inside details
  • poll only with checkout_id after the returned delay without restarting validation
  • retrieve the current checkout after a stale revision, then edit at its returned revision
  • distinguish root INVALID_PARAMS from a sanitized nested-details tool isError response
  • preserve returned equipment defaults when internet_addons is omitted
  • decline optional equipment with internet_addons: []
  • select returned equipment with exact option IDs and positive integer quantities
  • enforce radio choices, quantity limits, and dependent-option parent selections
  • preserve a customer-owned equipment request rather than substituting a free provider gateway
  • correct field-specific errors
  • reject a stale revision
  • poll a checking draft
  • handle changed equipment, included products, pricing, fees, discounts, or totals
  • handle an unavailable or expired offer
  • reach a ready review with included products, one-time fees, total amount, and any returned bundle discount
  • compare the technically ready review with budget, speed, equipment, billing, and installation intent; stop without submitting when it differs or authorization is unavailable
Confirm that validation creates no order and sends no fulfillment request. The client must present the exact returned review and keep unknown facts unknown. Check that an unknown speed is not called a failed speed check, that the cart total is not presented as a monthly bill or payment due now, and that declined billing preferences do not produce an invented discount adjustment. Do not repeat a service PIN, full birth date, or opaque capability in customer-facing prose.

​
Submission and recovery exercises

Run these only under Hum’s explicit transactional test arrangement:
  • authorization for the exact current review and terms hash
  • one queued submission with a stable idempotency key
  • an identical replay that resolves to the same intended order
  • an idempotency conflict with changed input
  • a lost or interrupted create response followed by get_order
  • recorded accepted, rejected, unknown, and not-submitted outcomes when the arrangement supports them
The client must retrieve before retrying after an uncertain create call. It must not describe any fulfillment state as ISP acceptance or installation confirmation.

​
Released workflow verification

The earlier transactional release was exercised through the public MCP endpoint under an approved test arrangement. One Xfinity order with a selected equipment item reached accepted_by_fulfillment; an earlier approved AT&T exercise also completed successfully. These checks verify the released ordering path for those cases. The September 24 checkout-guidance update was verified through public discovery, skill-byte parity, schemas, and internal synthetic tests; it did not place another live order. None of these checks proves every provider or address will qualify, and fulfillment acceptance is still not ISP acceptance or installation confirmation. The shared ordering flow is available across Hum’s supported provider scope. Use the approved fixtures for cases that cannot be produced safely or deterministically in production.

​
Test with and without the skill

Run the supported workflow twice through a generic MCP client:
  1. Load skill://order-internet-service/SKILL.md before beginning.
  2. Start a new client context and rely only on server instructions, tool descriptions, schemas, and tool results.
Record whether each client correctly handled clarification, partial evidence, executable offers, non-committing validation, exact-review authorization, retrieval-first recovery, and fulfillment status language.

​
Internal mocked tests

Hum’s repository tests cover schema validation, result rendering, skill and metadata parity, and mocked workflow states. These tests are release checks for Hum’s implementation. They are not a public sandbox, do not prove that a provider will return the same result, and do not authorize a live fulfillment submission. Contact support@letshum.com for an approved end-to-end review arrangement.