Identity Forge

Set the order the client meets the directions in. The share page walks the variations in this order, so the first id is the direction the client sees first, which is worth deciding deliberately rather than leaving on the order you happened to attach them in. This OVERWRITES the stored order of the whole project and takes effect on the client's next view. You must list every variation in the project exactly once: a partial list is rejected with 400 and the expected id set, because writing positions for only some of them would collide with the ones left behind. Get the current ids from the response of add_brand_variation, or from a previous call to this tool, which returns the variations in their new order. Requires the kits:write scope.

Withdraw the client's access permanently. The /p/<token> URL stops resolving wherever it was pasted, including in an email already sent. NOT UNDOABLE: sharing again mints a new token and deliberately never the old one, so a withdrawn link can not be brought back to life. This tool requires `confirm: true`; without it nothing changes. Reach for update_brand_share with `enabled: false` instead when the client should see it again later — that is the reversible one, and it is almost always what is wanted. Revoking is for a link that leaked or an engagement that ended. The project, its variations and the comments the client already left all survive; only the access is withdrawn. Requires the kits:write scope.

Search the Google Fonts catalog by name or category, or ask for fonts that resemble one you already have. `like` is the way to find a font by resemblance: pass a family you know and get back neighbours ranked by category, popularity, the partners they share in the curated pairing table, and whether published kits use them together, each with a `why` naming the signals that placed it. Nothing here reads a letterform, so `like` is a shortlist to confirm visually, not a verdict on how a face looks. Results are compact metadata — name, family, category, designer, popularity rank, available weights, license — and carry no font files, no CSS and no specimen. Fonts do not stand alone: use suggest_font_pairings for what to set beside one, and remember a design kit already ships a chosen heading, body and mono. Read-only and free, no key needed.

Run up to 20 web searches you author yourself against a candidate name through Identity Forge's self-hosted SearXNG. Each query spends one account-wide monthly API unit. Returns dated raw results and nothing else: it does not score, rank, decide whether a collision is real, or constitute trademark clearance. Attach evidence and interpretation with move_name_candidates. For domain registration and DNS evidence use check_domains. Requires naming:read.

Return the entire catalog at once, unranked, as compact summaries carrying each kit's moodSummary, vibeTags, tags, audience, and a font and palette glimpse, so you can judge fit yourself. Despite the name it runs no server-side search: `query` is echoed back to keep your brief in context, and the ordering is neutral. Use it when the brief is subtle or cuts across categories and you would rather weigh every option than trust a ranking. Prefer list_themes when the brief maps cleanly onto a use case or search phrase, since it narrows and ranks the catalog for you and pages rather than returning everything. Read the summaries, pick one to three, then get_design_md to read the full brief or apply_theme to write it into the project. Read-only and free.

Store what the product is, so every later proposal is grounded in it and you never re-send a paragraph of prose. This REPLACES the whole context: nothing is merged, so any field you leave out is deleted, not kept. That is deliberate — a merging update would let you drop a surface from the list and silently keep the old one — but it means the safe way to edit is get_project_context first, then send the whole object back with your change applied. `product` is the only required field and must be a real sentence rather than a label; a description under 12 characters is refused, because a proposal built on one reads as grounded while being generic. Every string is bounded and an over-long field is refused by name rather than truncated, so nothing is silently cut. Requires the kits:write scope; reading needs only kits:read.

Publish a project to a client and return the full /p/<token> URL to send them. The page is read-only, serves only this project's kits, and lets the client cycle the variations and leave comments without an account. Anyone holding the link can open it, so set a password for sensitive work. Calling it again returns the existing link unchanged unless you pass rotate, which mints a new token and permanently breaks any link already sent. Add the variations before sharing, since the client sees whatever is attached at the moment they open it. Requires the kits:write scope.

Find published kits close to one you already have, ranked by palette proximity, shared tags, and audience. Use it when the user likes a direction but wants options, or when a candidate is nearly right and you want neighbours to compare. It needs an existing slug, so start from list_themes or search_themes if you do not have one yet. Returns compact summaries with a similarity score; judge the actual fit yourself, since proximity in palette and tags is a starting point rather than a verdict. Read-only and free, and it lists Pro kits without exposing their contents.

Heading, body and mono faces that work together. Called with no arguments it returns the curated table, each entry carrying the label a person would recognise it by, such as 'Modern tech' or 'Quiet luxury'. Called with a family it answers what goes beside that one: the curated entries naming it, then category-contrast suggestions for the cases the table does not cover. `role` says which slot the family occupies; omit it and both are searched. The suggestions are contrast rules and are not ranked by quality, so read them as candidates. A design kit already carries a chosen trio, so reach for this when composing typography outside a kit or when a user has one fixed face. Read-only and free, no key needed.

Change an existing client link WITHOUT reissuing it. `enabled: false` pauses it, so the client sees nothing until you resume; `password` sets one after the fact, and `null` removes it. The token is untouched, so a link already with the client starts working again the moment you resume. This is the tool to reach for when work is mid-revision and the client should not be looking yet, or when you shared something before realising it was confidential. It takes effect immediately for anyone holding the URL, including a client with the page already open. A project with no share yet answers 404: create one with share_brand_project first. Requires the kits:write scope.

Edit one brand proposal already attached to a project, in place. This OVERWRITES the stored variation, and the client sees the new version the moment they next load the share link, including a client who has the page open right now, so treat it as publishing rather than drafting. Send only the fields that move; passing null for brandName, domain, label or notes clears that field rather than leaving it. Changing kitSlug repoints the proposal at a different design kit, which re-checks that you can resolve that kit and that a Pro kit has an entitled key behind it. Use it to act on client feedback from list_client_comments without making the client re-review a whole new set of directions. Add a new direction with add_brand_variation instead when the old one should stay on the board. Requires the kits:write scope.

Edit a design kit you already saved, in place. This OVERWRITES the stored kit without asking: the slug, id and publication state all stay the same, so everything already pointing at that kit follows the edit, including brand variations that reference it, any client share link that serves it, and a repo that installed its registry entry. The overwrite itself has no undo, but it is recorded: every save mints a version, so the state you replaced stays readable through list_kit_versions and get_kit_version, and diff_kit_versions shows exactly what your edit moved. Reach for remix_theme instead when you want the original left alone, which is usually the right call while you are still exploring directions; use this one when the kit is the brand and the brand has genuinely changed. It only edits kits saved under your key. A catalog kit, another user's kit, or an unknown slug all return 404 alike. `kit` is deep merged over the stored payload, so you state only what moves and everything else survives, and `overrides` applies on top of that merge. The one thing you cannot change is the slug itself: it is the kit's public handle and moving it would break every link already using it, so a payload carrying a different slug is rejected with 400 rather than quietly ignored. Pass `expectedUpdatedAt` from the last read to get a 409 instead of silently overwriting a change someone else made in between; the 409 body carries the current marker so you can re-read, reapply and retry. Requires the kits:write scope.

Your plan, the scopes this key holds and the ones it lacks, how much of the monthly quota is left, your AI credit balance, and how many saved-kit slots remain. Call it before promising a user something the key cannot deliver: every one of these limits is otherwise discoverable only by hitting it, as a 403 for a missing scope or a locked Pro kit, a 429 for quota, a 402 for credits, or a refused save at the free tier's kit cap. This call is free. It spends no quota units and no AI credits, and it is deliberately never refused for being over quota, so it still answers after a 429 has already happened and is safe to call first. Any valid key may read its own entitlements, whatever scopes it holds.