← Mintlify MCPCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Mintlify MCP
Snapshot Sep 30, 2026 · 22:48 UTC · version 1.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "updating-site-config",
"description": "Use when changing docs.json through the Mintlify Admin MCP — theme, colors, logo, favicon, navbar, footer, fonts, SEO metadata, site name or description, banners, redirects, or any site-wide setting.",
"included_files": [],
"skill_md_contents": "---\nname: updating-site-config\ndescription: Use when changing docs.json through the Mintlify Admin MCP — theme, colors, logo, favicon, navbar, footer, fonts, SEO metadata, site name or description, banners, redirects, or any site-wide setting.\n---\n\n# Updating Site Config\n\n## Overview\n\n`update_config` (inside a checked-out session) edits any top-level `docs.json` field except `navigation`. Changes land on the session branch and publish via `save`, like content edits. The full field reference is https://www.mintlify.com/docs.json.\n\n## Operations\n\n**`set`** — merge at the top level only. Each top-level key you provide **replaces that key's entire value**; sibling keys you omit are untouched, but nested fields inside a key you provide are not merged.\n\n```\nupdate_config {\n op: 'set',\n docsConfig: { name: 'Acme Docs', colors: { primary: '#0D9373', light: '#07C983', dark: '#0D9373' } }\n}\n```\n\nSending `colors: { primary: '#0D9373' }` alone would drop `colors.light` and `colors.dark`. There is no config-read tool, so use this recovery loop: send the `set`, then inspect the returned `diff` — it reports the `before` values of everything you changed, including nested fields you accidentally dropped. If the diff shows unintended removals, re-`set` that key with the complete object reconstructed from the diff's `before` values. Nothing is live until `save`, so this loop is safe.\n\nSet a top-level key to `null` to remove it entirely. The merged result is validated against the full schema — any violation rejects the whole call with no partial writes. `navigation` and `$schema` keys are rejected.\n\n**`add_redirect`** — append to `redirects`:\n\n```\nupdate_config { op: 'add_redirect', redirect: { source: '/old-path', destination: '/new-path', permanent: true } }\n```\n\nRejects on duplicate `source`. Sources match by exact string comparison against stored redirects — keep the leading-slash form consistent.\n\n**`remove_redirect`** — `{ op: 'remove_redirect', source: '/old-path' }`. Rejects if the exact source string is not present.\n\n## Response\n\nReturns `{ diff }` of only what changed: scalars as `{ before, after }`, nested objects recurse under `{ changed }`, arrays (`redirects`, `navbar.links`) as `{ added, removed }`. Read the diff to confirm the merge did what you intended.\n\n## Which description tool?\n\n| Target | Tool |\n|--------|------|\n| Site-level SEO/social description (`docs.json` `description`) | `update_config` |\n| One page's frontmatter `description` | `update_node` with `data.type: 'page'` |\n| Text inside a page body | `edit_page` |\n\n## Common mistakes\n\n- Sending `navigation` through `set` — rejected; use the node tools (`create_node`, `move_node`, …).\n- Sending a partial nested object — `set` replaces the whole top-level key; follow the diff-recovery loop above when you don't know the current nested values.\n- Editing `docs.json` as if it were a page via `write_page` — config has its own tool and validation path.\n- Forgetting `save` — config edits are session-scoped until published.\n"
}SHA-256: 8564aaba991344eb2153090cb576f0742acdd6eebdcdf24fe25418af61c9961f