# Baidu Cloud > Operate or inspect any Baidu AI Cloud BCE resource through cloud-skills-mcp signed HTTPS, CCR Enterprise/Personal Docker or OCI Registry HTTP, IAM-authenticated IoT Core HTTP Publish and MQTT 3.1.1/5.0 over WSS, and the guarded RTC AI Agent WebSocket lifecycle. Use for Baidu Cloud, BCE, BCC, BOS, VPC, RDS, IAM, CDN, CCE, CCR, IoT Core, MQTT, container images, RTC AI Agent, or documented baidubce.com and bcebos.com APIs. - Skill: `tttboy123/baidu-cloud` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add tttboy123/baidu-cloud` - Raw SKILL.md: https://api.skillmd.com/api/skills/tttboy123/baidu-cloud/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tttboy123 (https://skillmd.com/u/tttboy123) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tttboy123/baidu-cloud --- # Baidu AI Cloud Use the universal BCE REST gateway. It implements the official `bce-auth-v1` HMAC-SHA256 signing contract and restricts requests to validated `baidubce.com` service endpoints plus official BOS `bcebos.com` HTTPS endpoints. CCR uses `ccr-registry`: the server obtains only one-hour Registry credentials from fixed BCE-signed control requests, performs the same-origin Harbor Bearer exchange, and never executes Docker or exposes a password/token. IoT Core uses `iotcore-http-pub` or `iotcore-mqtt-ws`: the server derives the documented application-permission username/password from IAM AK/SK, keeps the short-lived HTTP token internal, or performs the exact `/mqtt` WSS upgrade with subprotocol `mqtt`. RTC AI Agent uses a separate guarded `rtc-aiagent-ws` plan: the server signs create/stop through BCE v1, keeps the returned instance token private, activates the operator-held product license internally, and publishes only sanitized bounded WSS events. ## Workflow 1. Call `cloud_provider_status` with `provider="baiducloud"`; `local-material-present` confirms only local AK/SK presence, while `missing-local-material` requires operator credential injection. Neither proves cloud authentication. 2. Call `baiducloud_api_discover(service="bcc")` or another product code to obtain the official API-center and product-doc links, then verify the exact endpoint/path. 3. Use `baiducloud_api_read` for `GET`, `HEAD`, or `OPTIONS` only. 4. For `POST`, `PUT`, `PATCH`, or `DELETE`, obtain explicit human approval for the account, region, URL, method, body, and effect; then use `baiducloud_api_mutate(force=true)`. 5. Secret-resource operations require the separate sensitive gate. STS session credentials, AccessKey creation, login tokens, and other credential issuance/export operations are never exposed by the gateway. 6. Never provide `Authorization` or `x-bce-security-token`; the adapter creates them internally. 7. Treat every RTC AI Agent session as a mutation because create starts a billed instance. Obtain explicit approval, use `baiducloud_api_mutate(force=true)`, and require the server operator to set `BCE_RTC_LICENSE_KEY`; never put AK/SK, the license, or an instance token in MCP arguments. 8. For CCR Registry reads, use `auth_scheme="ccr-registry"`, `service="ccr"`, and an exact namespaced `/v2` resource path. Enterprise endpoints additionally require the non-secret instance, IAM user, and region identifiers; Personal endpoints resolve the current user from AKSK and require those fields to be omitted. 9. For IoT Core observation, use `auth_scheme="iotcore-mqtt-ws"`, `service="iotcore"`, `operation="SubscribeMQTT"`, and `baiducloud_api_read`. Publishing, persistent sessions, or Will configuration use `operation="ClientMQTT"` through `baiducloud_api_mutate(force=true)` after explicit approval. 10. For one-shot IoT Core HTTPS publishing, use `auth_scheme="iotcore-http-pub"`, `operation="PublishHTTP"`, and the mutation tool after explicit approval. The server performs `/auth` and `/pub` internally; never supply its token. ## MCP arguments - `method` and `url`: exact official BCE HTTPS API endpoint. - `auth_version`: `v1` by default; use `v2` only when the product API requires it. V2 also requires the documented `service` and `region` values and signs `x-bce-date` internally. - `headers`: non-credential product headers. - `body`: JSON-compatible request body. - `body_file`: binary/media request body under an operator-approved `CLOUD_SKILLS_ALLOWED_FILE_ROOTS` directory. Generic BCE REST calls do not combine it with `body`; guarded IoT Core HTTP Publish and RTC are explicit exceptions because their body remains a credential-free protocol plan. Use BCE multipart APIs above 64 MiB. - `response_file`: new approved-root file for BOS objects, exports, or other large responses. Use the documented `Range` header above the configured per-call limit; existing files are never overwritten. - CCR Registry: set `auth_scheme="ccr-registry"`, `service="ccr"`, and omit `auth_version`/`api_version`. Personal uses exact `https://registry.baidubce.com` and no region/Registry identifiers. Enterprise uses an exact `-pub|vpc.cnc[.bd]..baidubce.com` endpoint or an operator-pinned official custom domain, plus `region`, `registry_instance_id`, and the non-secret IAM `registry_user_id`. The server internally signs the documented current-user/profile and one-hour temporary-key/password requests, validates a same-origin `/service/token` Bearer challenge, and derives path/method scopes. Manifest/blob upload, delete, or mount requires the mutation tool. Caller authorization, credential endpoints, redirects, fixed passwords, and robot-account secrets fail closed. - IoT Core HTTP Publish: set `auth_scheme="iotcore-http-pub"`, `service="iotcore"`, `operation="PublishHTTP"`, method `POST`, and exact `https://.iot.gz.baidubce.com/pub`. Use `baiducloud_api_mutate(force=true)`. Body contains only optional exact `iot_core_id`, publish `topic`, QoS 0/1, and either `payload_base64` or an approved-root `body_file`; `max_payload_bytes` defaults to 32 KiB and may be raised only to the documented 128 KiB instance maximum. The server derives the same IAM application credential, calls fixed `/auth` for a 60-second token, calls `/pub`, validates the documented success response, and keeps all derived material internal. It enforces the documented 50 publishes/s/IP bound. Query parameters, caller headers/tokens, wildcards, QoS 2, session credentials, and response files fail closed. - IoT Core MQTT: set `auth_scheme="iotcore-mqtt-ws"`, `service="iotcore"`, method `GET`, and exact `wss://.iot.gz.baidubce.com/mqtt`; no query, headers, REST controls, or caller credential fields are accepted. `protocol_version` is `4` (MQTT 3.1.1, default) or `5`. `SubscribeMQTT` is read-only and requires `clean_session=true`, 1–100 wildcard or official `$share//` subscriptions with QoS 0/1/2, `max_messages` 1–256, `timeout_seconds` 1–300, and an approved-root `response_file`; the server respects the provider's eight-subscriptions-per-SUBSCRIBE limit by batching internally. `ClientMQTT` is mutation-only and can add bounded QoS 0/1/2 publishes, subscription state, up to 100 `unsubscriptions` in eight-entry batches, and one Will. MQTT 5 publish/Will plans may set payload format, content type, message expiry, response topic, correlation data, ordered user properties, and Will delay. CONNECT advertises bounded Receive Maximum/Maximum Packet Size and zero Topic Alias Maximum; received unsupported properties and topic aliases fail closed. The body otherwise contains only `iot_core_id` (optional exact host assertion), `client_id`, `clean_session`, `keep_alive_seconds` (30–1200), optional `max_payload_bytes`, topic plans, Base64 payloads, and collection bounds. The message limit defaults to 32 KiB; set `max_payload_bytes` up to 128 KiB only after the provider has approved that documented instance-level increase. The same bound is enforced on outgoing and received payloads. Outgoing publishes are paced internally to the documented QoS rates. The server performs SUBACK/UNSUBACK, PUBACK, and duplicate-safe PUBREC/PUBREL/PUBCOMP in both directions, keeps the derived `bceiam@...` username/password internal, and atomically publishes received messages as NDJSON. - RTC AI Agent: set `auth_scheme="rtc-aiagent-ws"`, `service="rtc-aiagent"`, `operation="RealtimeInteraction"`, `api_version="1"`, method `GET`, and the exact credential-free `wss://rtc-aiotgw.exp.bcelive.com/v1/realtime` URL. Body contains `app_id`, optional credential-free `instance_type`/`config`, `audio_codec` (`raw`, `raw16k`, `pcma`, `pcmu`, `g722`, or `opus`; default `raw16k`), required `device_id`/`user_id`, `messages` before audio, optional `final_messages` after audio, `max_messages` (1–256), `timeout_seconds` (1–300), and `terminal_event` (`tts_end`, `answer`, or `message_limit`). The two command arrays accept at most 64 total official static client commands: break, text/direct TTS, auto-interrupt, device/GIS, remote-player, ASR-mode, system-prompt, variables, credential-free third-party data, scene role, enhanced query, MCP-tool change, direct music, and meeting-summary controls. They reject server-only/license/raw-image events, arbitrary prefixes, embedded credential fields/material, and caller-authored Function Call frames. For event-correlated vision, set `image_file` to one approved-root, non-empty file and optionally set body `image_mode="image_generate"`; the server waits for the exact provider `[E]:[UPLOAD_IMAGE]` event, uploads one official 16 KiB/Base64 chunk sequence atomically against concurrent audio writes, and fails if the request is missing, repeated, or never consumed. For Function Call, declare at most 32 credential-free results in body `function_results`, keyed by exact `function_name`, and optionally bound the session with `max_function_calls` (1–32). Each template has `result="ok|error"`, optional bounded `message`, and/or official unique `post_function` items (`text`, `prompt`, `play_music`); `text` and `prompt` cannot coexist, while a combined music item requires explicit `enableMusicPadTts=false`. The server accepts only the current `[F]:{session_id,content}` provider event, validates its nested function/parameter JSON, rejects credential-shaped parameters, unknown functions, duplicate session IDs, and call-limit overflow, then inserts the provider session ID into the response internally. The server forces `config.audiocodec` and internal WSS `ac` to the same codec. A fixed-rate `body_file` uses 20–200 ms packets (20 ms default), with an exact codec-derived `stream_chunk_bytes`; Opus requires `opus_packet_time_ms` 20/40/60 and `opus_packet_lengths` that exactly partition the file, with optional `opus_packet_max_bytes`. Audio duration must be shorter than the session timeout. `response_file` is required. Example read: `baiducloud_api_read(method="GET", url="https://bcc.bj.baidubce.com/v2/instance")`. CCR Personal Registry read: `baiducloud_api_read(auth_scheme="ccr-registry", service="ccr", operation="ListTags", method="GET", url="https://registry.baidubce.com/v2/team/app/tags/list")`. CCR Enterprise Registry read: `baiducloud_api_read(auth_scheme="ccr-registry", service="ccr", operation="ListTags", region="bj", registry_instance_id="ccr-xxxxxxxx", registry_user_id="", method="GET", url="https://ccr-xxxxxxxx-pub.cnc.bd.bj.baidubce.com/v2/team/app/tags/list")`. IoT Core MQTT 5 read subscription: `baiducloud_api_read(auth_scheme="iotcore-mqtt-ws", service="iotcore", operation="SubscribeMQTT", method="GET", url="wss://.iot.gz.baidubce.com/mqtt", body={"protocol_version":5,"client_id":"observer-1","subscriptions":[{"topic_filter":"$share/observers/sensors/+/temperature","qos":2}],"max_messages":1,"timeout_seconds":60}, response_file="/approved/results/baidu-iotcore.ndjson")`. IoT Core HTTP publish: `baiducloud_api_mutate(auth_scheme="iotcore-http-pub", service="iotcore", operation="PublishHTTP", method="POST", url="https://.iot.gz.baidubce.com/pub", body={"topic":"commands/device-1","qos":1,"payload_base64":"dHVybi1vbg=="}, force=true)`. ## Credentials Set `BCE_ACCESS_KEY_ID` and `BCE_SECRET_ACCESS_KEY` only in the MCP server environment. For IAM/STS temporary credentials, also set `BCE_SESSION_TOKEN` (or `BCE_SECURITY_TOKEN`) for BCE REST and CCR. IoT Core application permission currently documents only IAM AK/SK and no session-token field, so `iotcore-http-pub` and `iotcore-mqtt-ws` deliberately reject a configured BCE session token instead of silently dropping it. Credentials are signed internally and never returned or audited. An entitled RTC AI Agent deployment additionally sets `BCE_RTC_LICENSE_KEY` in the server environment; it is product entitlement material, never an MCP credential input. Read [references/official-docs.md](references/official-docs.md) for v1/v2 signing, IAM/STS, BOS, CCR Registry, IoT Core HTTP/MQTT, and API-center references. For RTC, never use the official direct `ak`/`sk` query mode. The Skill always uses BCE v1 create → private instance-token WSS → signed stop. Only the server constructs `ac` and the Opus-only `ptime`/`plen` query values. License `MUST`/`ACTIVE`/`RES-PASS` events, the activation payload, the 24-hour instance token, and control-plane bodies never enter MCP output or audit; failure before stop prevents `response_file` publication.