Sent Profile Provisioning

This skill is the execution counterpart to profile architecture: once the tenancy boundary is decided, it drives the API calls, the completion callback, the campaign registration, and the user administration that make a profile able to send. Design the boundary with sender-profile-architect first; provision it here.

Live MCP profile operations

Use sender_profiles.list, sender_profiles.get, sender_profiles.create, sender_profiles.update, and sender_profiles.delete through client-managed OAuth 2.1/PKCE. Never request or expose credentials. Validate the calling organization with account.get before a mutation.

These tools operate under the authenticated organization. The target argument is id, not profileId; no sender_profiles.* tool accepts an acting profileId. Profile grants own no child profiles and receive an empty list. Reauthorize with organization scope to manage its profiles.

• List/get: list uses page (1-based) and pageSize (1-100, default 20) and reports channel readiness. Use real IDs from that list. Get returns found/item; found: false does not distinguish nonexistent, deleted, and another organization's profile. Do not infer cross-tenant existence.
• Create: requires name, shortName, and idempotencyKey. shortName is 3-11 letters, numbers, or spaces with at least one letter. Optional arguments are description, smsCountry, smsNumberType, smsSenderValue, smsAreaCodes, and compliance. A supplied smsCountry requires smsNumberType; omission uses the organization's shared routes. For a dedicated SMS market, use sent-compliance to inspect requirements and fill its setup plan first. Provisioning can claim a number and incur registration fees. WhatsApp, RCS, billing, document uploads, inheritance flags, and sandbox arguments are not exposed by this MCP create tool. Required document uploads block it before any write; use the dashboard or documented REST flow. No one-time API key is returned.
• Update: fetch the exact target, then supply id and only the changed fields among name, shortName, and description. Omitted fields stay unchanged; explicit description: null clears the description. Name and short name cannot be cleared. At least one field is required. Do not populate omitted fields with null or assume this updates channel configuration.
• Delete: fetch and preview the target. Explain that deletion can disconnect WhatsApp, release numbers, and disable live routes. Supply id and a nonempty idempotencyKey. deleted: false means no matching owned profile was deleted and does not prove another tenant's profile exists.

For every create, update, or delete, preview the organization, exact target or payload, and side effects, then require explicit confirmation immediately before the call. Changes invalidate confirmation. Every retry needs a new preview and confirmation.

Create and delete use durable receipts. Reuse the original key and arguments for the same intended operation; do not generate a new key after a timeout or an in-flight result. Inspect list/get and returned receipt guidance first. A key reused with different arguments is refused. If interrupted provisioning or teardown needs attention, stop and reconcile in the dashboard rather than retry automatically or replace the key. A new key authorizes a separate operation only after the existing outcome has been reconciled. Verify the returned profile and channel readiness; creation alone does not establish permission to send.