@mgcrea/mcp-cloudkit
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLOUDKIT_DEBUG | No | Set to 1 to log to stderr. | |
| CLOUDKIT_TEAM_ID | Yes | Your 10-character Apple Developer team id. | |
| CLOUDKIT_MAX_RETRIES | No | Retry budget for 429/5xx. Defaults to 3. | 3 |
| CLOUDKIT_ALLOW_WRITES | No | Set to 1 to register cloudkit_deploy_schema and cloudkit_import_schema. Off by default. | 0 |
| CLOUDKIT_CONTAINER_ID | No | Default container, e.g. iCloud.com.acme.App, so it need not be passed on every call. | |
| CLOUDKIT_MANAGEMENT_TOKEN | Yes | Your CloudKit management token (Apple's own variable name used by xcrun cktool). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cloudkit_auth_statusA | Report whether this server has a working CloudKit management token, whether writes are enabled, and — when something is missing — exactly what to set. Call this first when a tool you expected is not listed: an absent tool here means missing configuration rather than a bug. |
| cloudkit_list_containersA | List the CloudKit containers this team can manage, with their ids. Use this to find the container id the other cloudkit_* tools take. |
| cloudkit_list_record_typesA | List a container environment's record types and their fields. This is how you confirm a newly added field actually reached CloudKit: Core Data and SwiftData prefix everything with |
| cloudkit_export_schemaA | Export an environment's full schema as a |
| cloudkit_diff_schemaA | Show what deploying would change: the pending differences between the container's DEVELOPMENT and PRODUCTION schemas, one row per change: ADD, CHANGE_INDEXES, RETYPE, MISSING_IN_DEVELOPMENT (Production keeps it; a deploy cannot remove it) or OTHER (the schemas differ outside any field, e.g. permissions). Read this before cloudkit_deploy_schema. Production is additive-only and irreversible — a field can be added forever, but never removed, renamed or retyped — so a RETYPE is a reason to stop. |
| cloudkit_validate_schemaA | Validate a local |
| cloudkit_requestA | Escape hatch: issue an arbitrary CloudKit management API request. The other cloudkit_* tools cover the documented-by-observation routes; this exists because the API is undocumented, so one endpoint being shaped differently than expected should not make the rest unreachable. Prefer a specific tool when one fits. Only GET is available while writes are disabled. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each specific tool targets a distinct schema operation (list containers, diff, export, validate, list record types), and the descriptions explicitly steer agents away from overlaps (diff vs export, validate vs import). The only real ambiguity is cloudkit_request, a catch-all escape hatch that technically subsumes every other tool, though its description mitigates this by telling agents to prefer specific tools.
All seven tools use the same cloudkit_ prefix followed by a clear snake_case noun/verb label (list_containers, diff_schema, export_schema, validate_schema, auth_status). The pattern is predictable and readable throughout, with no mixed conventions.
Seven tools is well-scoped for a CloudKit schema-management server, with each tool covering a distinct step (auth, discover containers, inspect record types, diff, export, validate, raw request). Nothing feels padded or missing in terms of quantity.
The surface covers inspection, diffing, exporting and validating, but there is no deploy/apply tool — and the descriptions explicitly reference cloudkit_deploy_schema, which is absent here, creating a dead end for the primary write workflow (presumably config-gated by the auth token). Union/import of a .ckdb is also absent, so an agent cannot complete the add-field lifecycle end to end.