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

# Testing

> Verify Hum MCP discovery, availability, validation, authorization, submission recovery, and environment limits

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

<Warning>
  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.
</Warning>

## Public connection smoke test

Connect a generic MCP client to:

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

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:

* [Availability skill](https://mcp.letshum.com/skills/check-internet-availability/SKILL.md)
* [Ordering skill](https://mcp.letshum.com/skills/order-internet-service/SKILL.md)

Their byte counts and SHA-256 digests must match the corresponding skill discovery entries.

## Contract and fixture checks

The [released contract](/mcp/contracts/released-contract.json) contains the exact public schemas and
runtime input combinations. The [scenario file](/mcp/examples/scenarios.json) 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](mailto:support@letshum.com) for an approved end-to-end review
arrangement.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.