Tools

The tools of the MCP server come in fifteen toolsets: docs, which needs no token, and one per resource in the order of the CLI's nouns. The query ?toolsets= on the endpoint URL selects them by name, and readonly=true keeps the reads, as Toolsets describes.

Each table lists a tool's name, what it does and the required parameters, the ones that locate its object. The optional filters and fields are in the tool's own description, which the client shows. Every id is a UUID, resolved from a name through the list tool of its resource: list_organizations, then list_apps, then list_channels.

Reads, writes and destructive toolsCopy Anchor Link

Of the 59 tools, 27 read and survive readonly=true, and the other 32 write. Twelve of the writes do what cannot be undone and carry the destructive annotation, so a client asks you before running them: update_organization, delete_organization, update_member, delete_member, delete_invitation, delete_sso_provider, delete_app, transfer_app, delete_channel, delete_bundle, revoke_release and delete_webhook.

Tools an API token cannot useCopy Anchor Link

Changing who acts in an organization, or spending its money, takes a person: a signed-in session or an OAuth access token. What a token cannot do lists those endpoints. The server registers these 26 tools for an OAuth access token alone, and a client signed in through OAuth gets them all:

• organization: create_organization, update_organization, delete_organization
• member: update_member, delete_member
• invitation: list_invitations, create_invitation, delete_invitation
• audit-log: list_audit_logs
• sso-provider: get_sso_provider, delete_sso_provider, verify_sso_provider_domain
• app: delete_app, transfer_app
• webhook: list_webhooks, get_webhook, create_webhook, update_webhook, delete_webhook, test_webhook
• webhook-delivery: list_webhook_deliveries, redeliver_webhook_delivery
• telemetry-export: get_telemetry_export, test_telemetry_export, list_telemetry_export_deliveries, redeliver_telemetry_export_delivery

docsCopy Anchor Link

The docs toolset is public: it reads this site without a token. A request that selects it is counted by IP address, 600 a minute, as Troubleshooting describes.

A search answers 5 pages unless limit says otherwise, 20 at most. get_doc_page takes a URL from a result or a path such as /docs/quickstart. Both are reads.

organizationCopy Anchor Link

The organization toolset manages the organizations the token's user belongs to, as hotcodepush organization does from the terminal. list_organizations comes first in nearly every session.

The two reads survive readonly=true and register for an API token. The three writes register for an OAuth access token alone, and the deletion takes the Owner role.

memberCopy Anchor Link

The member toolset manages who belongs to an organization and with which role, as hotcodepush member does from the terminal. A memberId is the membership, not the user, and list_members finds it by email with query.

The two reads survive readonly=true and register for an API token. The two writes are destructive, take the Owner or Admin role and register for an OAuth access token alone.

invitationCopy Anchor Link

The invitation toolset invites people to an organization with a role, as hotcodepush invitation does from the terminal. The person receives a mail with the link to accept. An invitation never grants owner.

The whole toolset registers for an OAuth access token alone. list_invitations is the read readonly=true keeps, delete_invitation is destructive, and inviting takes the Owner or Admin role.

audit-logCopy Anchor Link

The audit-log toolset reads the organization's audit log: who released, revoked, paused or changed what, when and from where. What devices did is not here. That is get_update_statistics and the counters of get_release.

The tool is a read, stays under readonly=true and registers for an OAuth access token alone, and it needs a plan that includes the audit log.

sso-providerCopy Anchor Link

The sso-provider toolset reads, verifies and removes an organization's single sign-on provider, as hotcodepush sso-provider does from the terminal. Setting the provider carries the identity provider's secret and stays the console's one-time setup.

The whole toolset registers for an OAuth access token alone. get_sso_provider is the read readonly=true keeps, and delete_sso_provider is destructive and takes the Owner or Admin role.

appCopy Anchor Link

The app toolset manages the apps of an organization, as hotcodepush app does from the terminal. The list_apps tool resolves a name to the appId every channel, bundle, release and statistics tool takes. A project's hotcodepush.json carries the same id.

The two reads survive readonly=true, and the other four tools register for an API token too. The writes delete_app and transfer_app are destructive, take the Owner or Admin role and register for an OAuth access token alone.

channelCopy Anchor Link

The channel toolset manages the channels of an app, as hotcodepush channel does from the terminal. list_channels resolves a name to the channelId a release takes. The failure* fields set the auto-pause policy.

The two reads survive readonly=true, delete_channel is destructive, and every tool registers for an API token. A pause or a resume applies within about a minute, as How an update reaches a device describes.

bundleCopy Anchor Link

The bundle toolset reads and deletes the bundles of an app. Uploading one stays with hotcodepush bundle upload or release create --path. list_bundles then finds it, and create_release releases it.

The two reads survive readonly=true, delete_bundle is destructive and refused for a bundle a release serves, and every tool registers for an API token.

releaseCopy Anchor Link

The release toolset manages the releases of an app, as hotcodepush release does from the terminal. Bundles and releases is the concept. A create_release call takes exactly one of bundleId or fromChannelId, and the conditions of Target devices with attributes narrow its audience.

The two reads survive readonly=true, revoke_release is destructive and final, and every tool registers for an API token. A rollback is a release of its own with the next number, as Roll back a release lays out.

statisticsCopy Anchor Link

The statistics toolset reads the three statistics of an app, as hotcodepush statistics does from the terminal. The channelId parameter narrows the fleet and the updates to one channel, releaseId the updates to one release. The periodSince and periodUntil parameters set the period as UTC days.

All three are reads, stay under readonly=true and register for an API token, and the usage is what Billing and MAU bills.

audienceCopy Anchor Link

The audience toolset counts devices, as hotcodepush audience does from the terminal. It previews how many of a channel's active devices a release would reach before it exists, and counts the devices an existing release reaches. The preview takes the same conditions and rolloutPercent as create_release.

Both answer deviceCount, reachedDeviceCount, estimatedDeviceCount, the split by platform and binary version, and warnings such as fingerprint_unknown. Both are reads and register for an API token.

webhookCopy Anchor Link

The webhook toolset manages the webhooks that post an organization's events, as hotcodepush webhook does from the terminal. Webhooks is the concept. Owners and Admins use it on a plan that includes webhooks, and a raw webhook's signing secret is answered once, by create_webhook.

The two reads survive readonly=true, and delete_webhook is destructive. Turning a webhook off for a while is update_webhook with isEnabled: false, which is reversible. No tool registers for an API token.

webhook-deliveryCopy Anchor Link

The webhook-delivery toolset reads a webhook's deliveries and sends one again, as hotcodepush webhook-delivery does from the terminal. A delivery is one event with its attempts and the receiver's last answer, kept for 30 days.

The read survives readonly=true, and neither tool registers for an API token. A redelivery never counts toward the failures that disable the webhook, and the receiver may see the event twice.

telemetry-exportCopy Anchor Link

The telemetry-export toolset reads and tests an organization's telemetry export and sends its deliveries again, as hotcodepush telemetry-export does from the terminal. Telemetry export is the concept. Owners and Admins use it, and testing and redelivering need a paying plan.

The whole toolset registers for an OAuth access token alone, and the two reads survive readonly=true. Setting the export carries the vendor's credentials, so setting, switching and removing it stay with a person in the console or the CLI.