## TL;DR
The SCIM base URL or credentials are wrong, or the endpoint needs a path segment the agent is not using. Verify with a direct request to the ServiceProviderConfig endpoint before blaming the check logic.

```text
agent unable to read SCIM endpoint, provisioning check failed
```

## Use this when
- An agent's provisioning check fails to read the SCIM endpoint.
- The failure is on connection, not on data.
- The check logic is believed correct.

## Not for this skill when
- Reads work but the data is wrong. That is mapping.
- The endpoint works from elsewhere. Compare environments.
- The failure is a 401 with known-good credentials. Check the auth scheme.

## Steps
1. Request the SCIM ServiceProviderConfig with the stored credentials. Verify: you get a direct answer.
2. On 401, fix the credentials. On 404, fix the base URL path. Verify: the fix matches the status.
3. Confirm the expected resource types are listed. Verify: the endpoint is a real SCIM server.
4. Re-run the provisioning check. Verify: it proceeds past the connection.
5. Confirm the check completes. Verify: the original failure is gone.

## Variant phrasings
### SCIM endpoint unreadable
The state-first phrasing.
### 404 SCIM
The status-first search.
### provisioning check failed
The symptom-first phrasing.

Compatibility: Any SCIM 2.0 endpoint; agent runtimes doing provisioning checks.

## Why it happens
SCIM base URLs vary by vendor, and some require a tenant path segment. Guessing the URL wastes runs; one direct request settles it.

## Edge cases / pitfalls
- The endpoint requiring a trailing slash that the client strips.
- Mutual TLS on some enterprise SCIM endpoints; the client needs the certificate.
- The ServiceProviderConfig existing but the Users path differing; read the config.
- Credentials valid for the config endpoint but not for Users; check scopes.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WHKsvzq8hdFmEOPQtnMZLA