Skip to main content
Institution and school integration, with separate DeanDesk employee access — the MCP server is hosted by DeanDesk. Institution connections are authorized per institution. Once connected, the tools exposed to your AI client can read and write data across the institution and any selected school, subject to the scopes and roles you grant.
DeanDesk runs a Model Context Protocol (MCP) server for AI clients that support remote MCP connections. After authorization, the client can use DeanDesk tools to look up institution details, manage memberships, work with school users and courses, manage course materials and curricula, take attendance, create invoices, edit products and pages, read documentation, and store files in the institution Shared Drive.

How authorization works

The MCP server uses OAuth 2.1 with PKCE and supports dynamic client registration. When you add DeanDesk to an MCP client, the client opens a DeanDesk authorization page in your browser. For institution or school access, sign in with your institution Identity, review the requested scopes, choose a school context when school tools are needed, and approve the client. DeanDesk employees can instead select Employee access and sign in with their registered employee Google account. Employee access does not require a school or institution selection. The tools that appear in your AI client depend on four things:
  • The scopes you approve
  • Your institution role
  • Your school role, when a selected school is required
  • The environment, because some migration tools are sandbox-only
Refresh tokens are issued when the client requests offline_access, so long-running clients can stay connected without asking you to sign in again.

How to set it up

Use the MCP endpoint provided by DeanDesk support or your institution administrator. For hosted DeanDesk environments, the endpoint is usually:
1

Add DeanDesk as a remote MCP server

In your MCP client’s settings, create a new server named DeanDesk and enter the DeanDesk MCP endpoint. Some clients call this a remote server URL, connector URL, or streamable HTTP endpoint.
2

Authorize the client

The client opens the Connect DeanDesk page in your browser. Under School or institution access, click Continue with Google, or enter your Email or username and Password and click Continue. DeanDesk employees click Employee access instead. Review the requested permissions and approve only the access the client needs.
3

Select a school when needed

Employee connections skip this step. School-level tools require a selected school context. On the consent page, pick a school from the DeanDesk context list (you can search by school name or hostname), then click Allow access. Choose a school when you want the client to manage school users, courses, course materials, curricula, rosters, products, assignments, surveys, forms, attendance, invoices, pages, email drafts, or school settings.
4

Confirm the tools loaded

Return to the MCP client and refresh its tool list if needed. The DeanDesk tools that match your approved scopes and roles should now appear under the DeanDesk server.
Start with read-only scopes when testing a new client. Add write scopes only when the client needs to create, update, delete, or send data.

DeanDesk employee access

Select Employee access, sign in with the Google account registered for your active DeanDesk employee account, then select Authorize employee access. The consent page shows your employee role and the permissions for this connection. No school picker appears. Owners and employee admins can manage the employee support queue and view institution information. Read-only employees can view tickets and institutions but cannot update tickets or send replies. Institution and school accounts do not grant DeanDesk employee access. Removed employee access is enforced on existing connections; role promotions require a new authorization to grant additional permissions. Employee ticket reads include private staff notes. Public replies can send email or WhatsApp messages, so review the recipient and message before sending. Employee connections expose only the employee tools allowed by your role and approved permissions. The institution and school tools below apply to institution and school connections.

Available scopes

Scopes control which tools the AI client can call.
The scopes offered during authorization depend on your roles. School admins can receive every school scope. Teachers also receive attendance:read and attendance:write so they can take attendance for their courses. Institution Admin Read-Only identities receive financialAid:read and invoices:read alongside their other read scopes.

Available tools

Institution super-admins can discover all school-level tools allowed by their approved scopes before selecting a school. Use list_school_contexts and switch_school_context to choose a school before calling those tools. Switching schools keeps the same tool list, and subsequent calls use the newly selected school. Each call still checks your current permissions and the selected school’s environment. Institution Admin Read-Only identities and members retain their existing access limits. School connections only expose tools allowed by their approved scopes, school roles, and environment. School admins can also use DeanDesk AI for account activation, course enrollment changes, curriculum maps and reusable templates, custom user fields, global page themes and fonts, and archived-product deletion. These actions are also available in institution AI chats with a selected school and the required permissions. Destructive and bulk actions require confirmation.

Institution and memberships

Migration

Shared Drive and documentation

School users, courses, materials, curricula, and rosters

For large course videos or files, use create_course_material_with_upload with a public or signed fileUrl. filePath is only for trusted local MCP deployments where MCP_ENABLE_SERVER_FILE_UPLOADS=true; hosted DeanDesk MCP servers cannot read files from an agent’s local disk.

File library

URL uploads must point directly to a downloadable file. Browser preview pages, sign-in pages, and HTML error pages are rejected. For a large file, use a reachable download URL with the upload tool that supports it. Your local computer path is not accessible to the hosted server.

School settings and pages

Blog posts and reusable templates

These are school-level tools. Select a school with admin access. Reading requires school.settings:read; saving, publishing, and unpublishing require school.settings:write. You can also manage the same content in Website → Blog in the school’s Admin Dashboard. Ask your assistant to create a blog draft with a title, URL slug, and article content. Use read_blog_post to review it and update_blog_post to revise it. Draft saves leave the live article unchanged. Request publication separately with publish_blog_post. To remove an article from public view, use unpublish_blog_post; its draft remains available. Unpublish before changing a live article’s slug. Discover reusable layouts with list_builtin_page_templates. The blog template controls /blog, blogPost controls articles, and blogCard controls cards across all feeds. Read a template’s starters and component reference with get_builtin_page_template, save edits with update_builtin_page_template, and publish the saved draft with publish_builtin_page_template. Use disable_builtin_page_template to restore the default layout without deleting the draft. To add a feed to a custom HTML page, generate a snippet with get_blog_feed_embed, then use read_page and update_page to insert it while preserving the page’s other content, styles, and publication state. Feed embeds use the shared published blogCard template. Reuse list_page_images and upload_page_image for article covers and body images; use the returned stable permalink as the image URL.

Products, discounts, communications, assignments, and surveys

Forms

School forms are the application, acceptance, and general-purpose forms created in the Form Manager — distinct from course surveys. Repeatable groups support short answer, long answer, checkboxes, and dropdown fields. Read the existing form before replacing questions so you preserve the question IDs and questions you want to keep.

Booking sessions

Booking sessions are products with type="booking". Both MCP clients and DeanDesk AI use the same booking tools in the selected school. Read tools require products:read; management actions require products:write and an administrator role. Institution identities must select a school and have its administrator permissions. Booking lists use the selected school’s live/test payment environment, and the backend continues to enforce record permissions and state transitions. Use recommend_product_configuration with purpose="booking", select a provider with list_booking_providers, and create the product with create_product. Its booking object controls provider, IANA timezone, weekly hours, duration, buffers, advance limits, daily cap, meeting details, effective dates, and calendar conflict checks. All durations and advance limits use minutes. Add pricing separately with add_product_price, using billingType="one_time" or isFree=true. Booking products cannot be bulk imported or converted through bulk updates. Attach a public, active form from the same school using requiredPurchaseFormId; checkout forms support short answers, long answers, and multiple choice, but not uploads. Customers choose a session and time at /bookings, enter contact details, and complete the form during shared checkout. Paid bookings are confirmed only after payment succeeds; free sessions confirm after completed free checkout. Reading slots, creating products, and processing payments do not establish confirmation. For configuration changes, first read get_product_details, preserve unchanged fields, and send the complete booking object to update_product. Availability belongs to the product editor at /admin/finance/products; session management is at /admin/bookings. Legacy availability records and manual unpaid confirmation are not part of this flow. Get explicit confirmation identifying the session before cancellation, completion, or no-show changes. Completion notes are included in customer notifications. Handle any refund separately.

Academic calendar

Attendance

Attendance tools are available to school admins and teachers.

Invoices and financial aid

Financial aid rate tools require an institution Identity in addition to the selected school, and changes are limited to Super Admin identities or school admins granted financial aid access. Admin Read-Only identities can read aid rates and invoices.
create_invoice bills real money and can charge a saved payment method immediately. Review the recipient, line items, and delivery mode carefully before approving the call.

Time and payroll

Payroll tools require an institution Identity in addition to the selected school: Super Admin identities can read and write, and Admin Read-Only identities can read. School-only sessions do not see these tools. See Time and payroll.
Payroll write tools change staff compensation data. Review the intended change carefully before approving a write.

Support tickets

School tools manage tickets in the selected school and require a school User with the admin role. Institution tools manage tickets across the current institution, without requiring a selected school: Super Admin Identities can read and write, while Admin Read-Only Identities can only read. School and institution assignments use different account IDs. Read the ticket before changing it. To resolve or reopen it, use the appropriate update tool with status: "resolved" or status: "open". Public replies set the status to waiting_on_member; private notes preserve the current status. Public replies can send email or WhatsApp to the requester. Ticket creation, updates, and escalation can also notify staff or the requester. For example: “List overdue institution support tickets,” “Assign this school ticket to an admin,” or “Add a private note explaining what we checked.” Review the intended audience before approving a reply.
Existing MCP connections may need to reconnect and authorize the new support scopes before these tools appear. Service agents can use school support tools with explicit support scopes and school admin access. Institution support tools require an authenticated institution Identity.

Best practices

  • Grant the minimum scopes needed for the task.
  • Use a dedicated client name for each MCP client so you can revoke clients independently.
  • Review write actions in your institution audit history.
  • Read existing records before asking the client to update or delete them.
MCP tools that send communications or modify DeanDesk data act on your institution’s behalf. Treat client authorizations like API keys and grant write scopes only to clients you trust.