A valid request URL is required to generate request examples{
"status": "success",
"message": "MCP client tools refreshed successfully",
"tool_count": 12
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}Refresh MCP client tools
Re-discovers an MCP client’s tools from its upstream server immediately, instead of waiting for the periodic connection checker’s next tick (the client’s tool_sync_interval, or the global mcp_tool_sync_interval — 10 minutes by default).
Use it after adding, removing, or re-describing a tool on the upstream MCP server. Unlike reconnect, this applies to every client type, including per-call clients (any per-user auth type, and any shared http client with needs_session_stickiness false/omitted), which hold no persistent connection and so have no other on-demand refresh path.
How the refresh runs depends on the client: a sticky client with a live connection is re-listed over it; a per-call client goes through an ephemeral connect-discover-close cycle; a sticky client whose connection is currently down is reconnected, which re-discovers as part of the dial.
The freshly discovered set is persisted and the hosted /mcp surface is re-synced automatically, exactly as for every other discovery path. A refresh also re-reads the server’s instructions, which costs one extra handshake for a sticky http or sse client because tools/list cannot carry that field. STDIO clients are skipped: Bifrost owns the subprocess, so its instructions cannot change without a reconnect. This is the only way to pick up instructions edited upstream without restarting, since MCP defines no change notification for them. Rejected with 400 when the client is not in a state where discovery means anything: disabled (enable it first), needs_reauth (reauthorize it first), or still pending_verification (complete the one-time admin verification instead — refreshing a client awaiting that flow would bypass it). 404 if no client is registered under the given ID.
A valid request URL is required to generate request examples{
"status": "success",
"message": "MCP client tools refreshed successfully",
"tool_count": 12
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>",
"retry_after_ms": 150500
}
}Authorizations
Management API authentication for /api/* endpoints. Use the Authorization header
with Bearer <token>, where <token> is one of:
- a Bifrost management API key,
- a dashboard session token issued by
POST /api/session/login, - base64 of
<admin-username>:<admin-password>(legacy equivalent ofBasicAuth).
Virtual keys (sk-bf-*) and the x-api-key header are not accepted on management APIs -
the sole exception is GET /api/governance/virtual-keys/quota, which is virtual-key-only.
Authentication alone is not sufficient in Bifrost Enterprise: each operation page shows a
Required Permissions table (Resource:Operation, for example Dashboard:View) above
its Authorizations section, and the caller's RBAC role or management API key scopes must
include what it lists, otherwise the request is rejected with 403 Forbidden.
A local admin — authenticated with the admin password, or any caller on a deployment with dashboard auth disabled — bypasses these checks and can call every management endpoint.
OSS setup lock. On Bifrost OSS, while dashboard auth is not active (no admin account,
or auth disabled), every management endpoint except the public ones (/health,
/api/version, /api/session/is-auth-enabled, /api/session/login, ...) requires the
operator's setup token in the X-Bifrost-Setup-Token header, in place of Authorization.
The token is set with setup_token in config.json or the BIFROST_SETUP_TOKEN
environment variable. A missing header returns 401, a wrong token 403. The header
stops working once dashboard auth is enabled. The dashboard instead trades the token once
for an HttpOnly bifrost_setup_session cookie via POST /api/session/setup.
See Required permissions for how
permissions are derived and which endpoints are exempt.
Path Parameters
MCP client ID
Was this page helpful?