Routed from skills/SKILL.md. The authoritative operation list is
api-reference.md.
Six operations, and only six:
bun.provider.list_categoriesbun.provider.list_providersbun.provider.connectbun.provider.disconnectbun.provider.healthbun.provider.switchNOT-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.
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.
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 — switch is a
distinct operation with distinct constraints, and two categories cannot be
switched at all.
Same content for machines: providers.md · llms.txt