Skip to main content
Transform Cursor into a documentation expert that knows your components, style guide, and best practices. No site yet? Have your agent set one up. Have Cursor’s agent complete the following workflow, then continue with the rest of this guide.
If the user asks you to set up Mintlify, a documentation site, or a local Mintlify project, complete the following workflow yourself. Ask the user only for information or approvals you cannot supply. We recommend CLI onboarding. Web onboarding at mintlify.com/start is also available if the user prefers it or you cannot run terminal commands.
  1. Run node --version and confirm it reports Node.js v20.17.0 or newer, preferring an LTS release.
  2. Run mint --version. If the command is unavailable, install the CLI with npm i -g mint or pnpm add -g mint. If the command succeeds, run mint update.
  3. Run mint status before starting authentication. If it already shows an organization, keep the existing session and do not create another account.
  4. Run mint login if the user has an account. Otherwise, don’t create an account now. You can publish without one using mint deploy in step 9, and the user creates their account when they claim the site. Don’t run mint signup for the user: when an agent runs it, it prints the agent signup guide and exits without sending a verification email. If the user wants their own GitHub repository connected from the start, send them to web onboarding at mintlify.com/start.
  5. After mint login, run mint status again. Confirm that it reports their email, organization, and subdomain. If the organization exists but no subdomain appears, ask the user to finish selecting or connecting a GitHub repository in the onboarding browser tab, then retry.
  6. If the user has an existing documentation repository, clone or open it. Preserve its content. For a new local project, scaffold into a new, empty directory with either mint new <directory> --name <name> --theme <theme> or mint new <directory> --template <template-name>. Ask which theme or template they want if they have not specified one. Do not use --force on a directory containing user files.
  7. Run mint dev --no-open from the directory containing docs.json as a background process. Confirm the local URL loads, report it to the user, and stop the process when it is no longer needed.
  8. Run mint validate and mint broken-links. Fix issues caused by your changes before continuing.
  9. Publish when the user asks for a live site.
    • Logged in with a Git repository: commit and push the changes. A push to the production branch triggers a deployment. Do not overwrite an existing repository with starter content.
    • No account: from the directory containing docs.json, run mint deploy --subdomain <name>, choosing a short name based on the project. Follow the steps it prints: clone the hosted repository into a separate directory, copy the docs into its root, commit, and push to main with the write token as an Authorization: Bearer header for that Git command only. Never show the token to the user, put it in a remote URL, or change the user’s own Git remotes. See Agent signup.
  10. Verify that https://<subdomain>.mintlify.site loads before reporting that deployment is complete. If you logged in, run mint status to get the subdomain. If you used mint deploy, use the URL it printed, then hand the site to the user:
    • Tell them the site expires unless they claim it.
    • Ask for the email address that should own it. Never invent one.
    • Run mint claim --email <email> from the same directory and share the claim link.
    • When they return the code shown after they sign in, run mint claim --code <code>.
Have the user complete browser actions only for claiming a site, OAuth approval, and connecting or authorizing GitHub. Keep ownership of the terminal workflow and resume after each user action. For command flags and troubleshooting, use the CLI command reference.

Use Cursor with Mintlify

Cursor rules provide persistent context about your documentation, ensuring more consistent suggestions that fit your standards and style.
  • Project rules live in your documentation repository, so your whole team shares them.
  • User rules apply to your personal Cursor environment.
Create project rules for your docs so that all contributors have access to the same rules. Create rules files in the .cursor/rules directory of your docs repo. See the Cursor Rules documentation for complete setup instructions.

Example project rule

This rule provides Cursor with context to properly format Mintlify components and follow technical writing best practices. You can use this example as-is or customize it for your documentation:
  • Writing standards: Update language guidelines to match your style guide.
  • Component patterns: Add project-specific components or modify existing examples.
  • Code examples: Replace generic examples with real API calls and responses for your product.
  • Style and tone preferences: Adjust terminology, formatting, and other rules.
Add this rule with any modifications as an .mdc file in the .cursor/rules directory of your docs repo.

Enhance with MCP server

Connect the Mintlify MCP server to Cursor to give it access to search the Mintlify documentation while helping you write. When you connect the MCP server, Cursor searches the up-to-date Mintlify documentation for context so you don’t have to leave your IDE to reference documentation. See Model Context Protocol for complete setup instructions. To give Cursor write access to your Mintlify content and settings, connect the admin MCP:
  1. Open the command palette with Cmd + Shift + P (Ctrl + Shift + P on Windows).
  2. Search for Open MCP settings and click Add custom MCP.
  3. In mcp.json, add the admin MCP:
  1. Reload Cursor and complete the OAuth login when prompted.