# Providers

Routed from `skills/SKILL.md`. The authoritative operation list is
[api-reference.md](api-reference.md).

## What is served

Six operations, and only six:

- `bun.provider.list_categories`
- `bun.provider.list_providers`
- `bun.provider.connect`
- `bun.provider.disconnect`
- `bun.provider.health`
- `bun.provider.switch`

NOT-SERVED: `bun.provider.create` `bun.provider.update` `bun.provider.delete`

There is no provider create/update/delete, no credential-storage operation in
this family (`bun.credential.*` is separate), and no per-category operation. Call
`list_categories` to discover categories at runtime rather than hardcoding them —
the catalogue has grown more than once.

## The claim you must not make

**Nothing in the provider catalogue is `PROVEN`.** No commercial provider
credential exists in this repository, and mock coverage is not provider proof. A
provider adapter with a passing test suite has demonstrated that the adapter code
behaves as written against a fake — nothing about the real vendor.

A small number of **self-hosted** services have live lanes running against real
containers. Those are real evidence for those services and for nothing else. When
writing docs, code comments or UI copy, say "adapter implemented, not verified
against the live vendor" rather than "supported".

`bun.provider.health` reports adapter-level health. A healthy response from a
fake adapter is not a statement about a vendor.

## Connecting

`bun.provider.connect` and `bun.provider.disconnect` require tenant context and
the `provider:connect` / `provider:disconnect` permission. `list_categories`,
`list_providers` and `health` do not require tenant context.

For moving between providers, see [switching.md](switching.md) — `switch` is a
distinct operation with distinct constraints, and two categories cannot be
switched at all.