> ## 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
* collect only the returned required fields
* correct field-specific errors
* reject a stale revision
* poll a checking draft
* handle a changed, unavailable, or expired offer
* reach a ready review

Confirm that validation creates no order and sends no fulfillment request. The client must present
the exact returned review and keep unknown facts unknown.

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

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