> ## Documentation Index > Fetch the complete documentation index at: https://docs.zuddl.com/llms.txt > Use this file to discover all available pages before exploring further. # Update Registration Status > **Tool name:** `update_registration_status` · **Behaviour:** ✏️ Write Approve or reject attendee registrations. This changes attendee state. When executing a scheduled task, automation, or workflow the user previously configured, proceed without asking -- the configuration itself is the consent; report the outcome. When the user is asking interactively, always confirm with the user first: restate the action, the exact count, and the event name, and require an explicit yes that names the action and count before calling. Never approve or reject in bulk, or act on "all", without that explicit confirmation or a previously configured workflow. Approve applies to PENDING and REJECTED registrations; Reject applies to PENDING and APPROVED_NOT_REGISTERED. Do not act on statuses that allow no action (APPROVED, INCOMPLETE, DELETED). Prefer explicit registrationIds sourced from a prior search_attendees call over broad filters; all IDs in one call must belong to the same event. Returns a map of registration ID to result code. Result codes: SUCCESS (applied), ALREADY_APPROVED (already approved/registered, cannot approve again; a fully registered attendee cannot be rejected either), ALREADY_REJECTED (already rejected, cannot reject again), NOT_ALLOWED (the registration's current status does not permit this action, e.g. cancelled/incomplete), NOT_FOUND (registration does not exist), INVALID_STATUS (target status was not APPROVED or REJECTED), INTERNAL_ERROR (server-side failure, safe to retry). Report the per-registration outcome back to the user. **Same as Public API:** [Approve an attendee registration](/api-reference/attendees/approve-an-attendee-registration) (`POST /v1/events/{eventId}/attendees/{registrationId}/approve`) · [Reject an attendee registration](/api-reference/attendees/reject-an-attendee-registration) (`POST /v1/events/{eventId}/attendees/{registrationId}/reject`) ## OpenAPI ````yaml https://api.prod.zuddl.com/api/v3/api-docs/mcp-tools post /tools/update_registration_status openapi: 3.1.0 info: title: Zuddl MCP Tools Reference description: >- The Zuddl MCP server lets AI assistants such as Claude and ChatGPT work with your Zuddl organization through the [Model Context Protocol](https://modelcontextprotocol.io). This reference lists every tool the server offers. It is generated from the live server, so it always matches what your assistant sees. # Connecting Add `https://setup.zuddl.com/api/mcp` as a remote MCP server in your assistant. It signs you in to Zuddl with OAuth and then calls tools on your behalf, with your permissions. AI features must be enabled for your organization. # Calling a tool Assistants call a tool with a JSON-RPC `tools/call` request whose `name` is the tool name and whose `arguments` match the request body documented on the tool's page. The `/tools/` paths in this reference identify tools; they are not HTTP endpoints. # Behaviour labels | Label | Meaning | | --- | --- | | 🔒 Read-only | Reads data and changes nothing. | | ✏️ Write | Creates or updates data, but does not delete it. | | ⚠️ Destructive | Deletes or removes data. Most assistants ask you to approve these calls. | | 🔁 Idempotent | Calling it again with the same arguments has no further effect. | A tool that mirrors a Public API endpoint links to that endpoint's page. MCP-only tools have no Public API equivalent. version: 1.0.0 servers: - url: https://setup.zuddl.com/api/mcp description: Zuddl MCP server security: - oauth: [] tags: - name: Events - name: Attendees - name: Sessions - name: Speakers - name: Sponsors - name: Locations - name: Teams - name: Brand Kits - name: Registration flows & tickets - name: Analytics paths: /tools/update_registration_status: post: tags: - Attendees summary: Update Registration Status description: >- **Tool name:** `update_registration_status` · **Behaviour:** ✏️ Write Approve or reject attendee registrations. This changes attendee state. When executing a scheduled task, automation, or workflow the user previously configured, proceed without asking -- the configuration itself is the consent; report the outcome. When the user is asking interactively, always confirm with the user first: restate the action, the exact count, and the event name, and require an explicit yes that names the action and count before calling. Never approve or reject in bulk, or act on "all", without that explicit confirmation or a previously configured workflow. Approve applies to PENDING and REJECTED registrations; Reject applies to PENDING and APPROVED_NOT_REGISTERED. Do not act on statuses that allow no action (APPROVED, INCOMPLETE, DELETED). Prefer explicit registrationIds sourced from a prior search_attendees call over broad filters; all IDs in one call must belong to the same event. Returns a map of registration ID to result code. Result codes: SUCCESS (applied), ALREADY_APPROVED (already approved/registered, cannot approve again; a fully registered attendee cannot be rejected either), ALREADY_REJECTED (already rejected, cannot reject again), NOT_ALLOWED (the registration's current status does not permit this action, e.g. cancelled/incomplete), NOT_FOUND (registration does not exist), INVALID_STATUS (target status was not APPROVED or REJECTED), INTERNAL_ERROR (server-side failure, safe to retry). Report the per-registration outcome back to the user. **Same as Public API:** [Approve an attendee registration](/api-reference/attendees/approve-an-attendee-registration) (`POST /v1/events/{eventId}/attendees/{registrationId}/approve`) · [Reject an attendee registration](/api-reference/attendees/reject-an-attendee-registration) (`POST /v1/events/{eventId}/attendees/{registrationId}/reject`) operationId: update_registration_status requestBody: description: The tool's `arguments`, as sent in a JSON-RPC `tools/call` request. content: application/json: schema: type: object properties: eventId: type: string description: >- The Zuddl event ID (UUID) the registrations belong to. All registration IDs in the request must belong to this event. registrationIds: type: array description: >- Registration IDs (UUIDs) to approve or reject. Source these from a prior search_attendees call. items: type: string registrationStatus: type: string description: >- Target status to apply. Must be APPROVED or REJECTED; any other value returns INVALID_STATUS. Approving moves the attendee to APPROVED_NOT_REGISTERED until they complete the registration forms. enum: - PENDING - REJECTED - APPROVED - DELETED - APPROVED_NOT_REGISTERED - INCOMPLETE required: - eventId - registrationIds - registrationStatus required: true responses: '200': description: A JSON-RPC `tools/call` result. The tool's output is in `content`. components: securitySchemes: oauth: type: http description: >- OAuth 2.1 access token. MCP clients obtain it themselves (dynamic client registration + PKCE) when you connect them to the server URL above. scheme: bearer ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.