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 <instance>-pub|vpc.cnc[.bd].<region>.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-core-id>.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-core-id>.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/<group>/<filter> 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="<iam-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-core-id>.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-core-id>.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 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.