Skip to main content
Glama

sapiens_brand

Brand Sapiens (= Design System): paleta + tipografia + voz + estilo de imagem + persona como FONTE ÚNICA de estilo (espelha o Estúdio de Brand do app). Sub-actions: list (oficiais curados + os custom do user, leve, grátis), get (1 brand completo por slug: voz + imageStyle + persona/logo; só oficial ou o próprio), generate (CRIA design system novo a partir de descrição em texto livre; Gemini monta tudo e já nasce com card premium gpt-image-2; 150 Sinapses pelo texto + o card no gpt-image-2-high a preço de catálogo, hoje 1350 Sinapses no total, reembolsa se falhar), refine (ajusta brand custom por feedback livre tipo 'fundo mais escuro'/'voz mais seca', ~75 Sinapses), reroll (regenera SÓ 1 peça voice|palette|imageStyle numa direção diferente, grátis), card ((re)gera o card premium, preço de catálogo do modelo), delete (apaga brand custom do próprio user), set_visibility (torna um brand custom do user público/privado: público = aparece no perfil + galeria da comunidade, qualquer logado adota), list_public (galeria de design systems PÚBLICOS da comunidade, opt-in pelos donos, com atribuição), adopt (clona um brand público/oficial numa cópia NOVA e PRIVADA na conta do user; persona é dropada), persona (pluga um personagem DO PRÓPRIO user como a cara recorrente das imagens do brand custom dele, por character=<slug|id> de sapiens_character action=list_mine, ou character=null pra tirar; as refs saem da galeria do personagem e o personagem precisa ter pelo menos uma imagem; grátis), favorite (marca, ou com isFavorite=false desmarca, um brand custom do user como o FAVORITO, o escolhido entre as tentativas de um projeto: sobe pro topo da list e dos seletores do app, as outras tentativas ficam guardadas; oficial não se favorita; grátis), import (TRANSCREVE um design system que JÁ EXISTE fora, de outro app, do Figma, do kit de um cliente: o que veio é o que grava, hex e fonte exatos, sem IA no meio, mesmo título e corpo na mesma família ou fonte fora do Google Fonts; grátis, o card nasce em SVG; aceita o ARQUIVO DE DESIGN TOKENS como veio, DTCG ou Tokens Studio, mapeado por papel com o de-onde-saiu em mapping, ou o shape da casa; o retorno avisa em warnings o que pode não aparecer igual), font (sobe o ARQUIVO de uma fonte que não é do Google Fonts pro papel headline, body ou mono, por filePath, sourceUrl ou base64, até 2 MB, grátis; só fonte com licença pra web), logo (põe a logo no brand custom pelo ID da imagem na galeria do user, img_… de sapiens_gallery action=upload, ou handle=null pra tirar; grátis). Brand que a pessoa JÁ TEM vai por import, nunca por generate: o generate cria e reinterpreta. O personagem só APARECE na imagem quando a marca é persona: depois de plugar, gere com sapiens_image brandSlug= brandMark=persona. Qualquer conta logada; Sinapses saem do dono do sessionToken. Pra generate: converse com o user e monte uma description rica (vibe, cores, voz, públicos, refs; se ele colar amostra de texto dele, inclua pra a voz sair dali) ANTES de chamar. Confirme o custo (1350 Sinapses) antes de gerar. Valor explícito na descrição (hex, nome de fonte, nome) o generate respeita, mas pra copiar um brand inteiro o import é exato e de graça.

Input Schema

NameRequiredDescriptionDefault
nameNoPra action=generate e import: o nome do brand (≤40 chars). Vem exatamente como mandado. No generate, sem ele o Gemini sugere um; no import, vence o nome que vier dentro do arquivo.
roleNoPra action=font: o papel da fonte no brand (headline = título, body = corpo, mono = código).
slugNoSlug do brand. Obrigatório em get/refine/reroll/card/delete/set_visibility/adopt/persona/favorite/logo. Pegue via action=list (seus) ou action=list_public (da comunidade).
brandNoPra action=import: o design system que JÁ EXISTE. Serve o ARQUIVO DE DESIGN TOKENS como veio (DTCG com $value/$type, ou Tokens Studio com value/type: o servidor mapeia por papel lendo o caminho do token, color.brand.primary vira primary, color.text vira foreground, e devolve em `mapping` de onde saiu cada cor e fonte; aí mande o nome em `name`) OU o shape do Brand da casa (o mesmo que action=get devolve): { name (obrigatório, ≤40), tagline?, description?, palette: { primary, secondary?, tertiary?, accent?, background, foreground, swatches?: [{name, hex}] }, typography: { headline, body, mono? } (cada uma a família como string, ou {family, note}), voice?: { rules (texto ou lista de regras), lexicon?, avoid?, sampleLines? }, imageStyle?: { styleBase (em inglês), negative?, backgroundSignature? } }. Cor em hex (#RRGGBB, aceita #RGB e sem #). Obrigatórios: name, background, foreground, primary (ou accent), headline e body. PAPÉIS DAS CORES na casa: primary é a cor da marca, accent é a que DESTACA a peça (kicker, número, palavra-chave). Se no sistema de origem o accent é só cor de botão, mande assim mesmo: o carrossel escolhe sozinho a cor que lê no fundo e se separa do texto, e o editor deixa trocar. Mapeie o que a origem chama por outro nome (brand/main → primary, bg/surface → background, text/ink → foreground, cta/highlight → accent). Fonte fora do Google Fonts grava como veio (fidelidade) e aparece na fonte da casa onde o navegador não acha a dela; o retorno avisa em `warnings`.
limitNoPra action=list_public: quantos brands públicos trazer (1-96, default 24).
modelNoPra action=card: tier do card premium (default gpt-image-2-high).
pieceNoPra action=reroll: qual peça regenerar numa direção diferente.
twistNoPra action=generate: a torção aplicada sobre o briefing ('mais bruto', 'mais editorial', 'paleta clara'). Combina com fromSlug (variação de um brand seu) ou com description (torção sobre o briefing que você acabou de escrever). ≤400 chars.
actionYes
base64NoPra action=font: o arquivo de fonte em base64, quando você já tem os bytes.
familyNoPra action=font: o nome da família, como o CSS chama (ex: 'Clash Display'). Omita pra usar a família que o papel já tem no brand (o caso comum: o brand importado com Clash Display ganha o arquivo dela).
handleNoPra action=logo: o ID citável da imagem da logo na galeria do user (img_…). Suba antes com sapiens_gallery action=upload (PNG com fundo transparente é o ideal) e use o ID que voltar. null tira a logo.
sourceNoPra action=import: de onde o brand veio (o nome do app, 'Figma', 'kit do cliente'). Vai pro briefing e pro aviso. ≤60 chars.
feedbackNoPra action=refine: o que ajustar, em texto livre ('escurece o fundo', 'fonte do título mais bruta', 'voz mais seca'). 5..2000 chars.
filePathNoPra action=font: caminho ABSOLUTO do arquivo de fonte local (.woff2, .woff, .ttf, .otf). Só no MCP instalado (stdio); no remoto use sourceUrl.
fromSlugNoPra action=generate: slug de um brand SEU cujo briefing vira a base da variação (o brand original não é tocado, nasce um novo). Com isso, `description` fica opcional. Só funciona em brand que guarda briefing (os criados a partir de ago/2026); veja em action=get, campo `brief`.
isPublicNoPra action=set_visibility: true publica o brand (aparece no teu perfil + galeria da comunidade, qualquer um pode adotar), false volta a privado.
wordmarkNoPra action=logo: o nome escrito que acompanha a logo, quando ele difere do nome do brand (≤60 chars).
characterNoPra action=persona: slug OU id de um personagem SEU (pegue em sapiens_character action=list_mine). Passe null pra tirar o personagem do brand. O personagem precisa ter pelo menos uma imagem na galeria: são elas que viram as referências.
sourceUrlNoPra action=font: URL https pública do arquivo de fonte (o servidor baixa e confere os bytes).
isFavoriteNoPra action=favorite: true (default) marca o brand como o favorito, o escolhido entre as tentativas; false tira. Só brand custom seu.
descriptionNoPra action=generate: descrição em texto livre do brand (o que o projeto/pessoa é, vibe, cores, voz, referências). Mínimo 30 chars; quanto mais rico, melhor o design system. Se o user colou um texto de amostra dele, inclua aqui pra a voz sair dali.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true): discloses per-action costs (150 + ~1350 Sinapses, refund on failure, ~75 for refine, free reroll/persona/favorite/import/font/logo), ownership constraints (only official or your own), that adopt drops persona, and persona requires an existing character image. That is rich behavioral context, though the dense prose sometimes buries it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Information-dense but structured as a single sprawling paragraph where sub-actions are enumerated inline; the critical routing rules and cost warnings are not front-loaded. Every fact is relevant, but the wall-of-text form makes scanning for one action costly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-action, 22-parameter tool with no output schema, the description covers costs, prerequisites, ownership rules, cross-tool dependencies (character, gallery, image), and the import-vs-generate distinction. An agent has essentially everything needed to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 95%, so the schema already documents parameters thoroughly; the description adds operational meaning by tying parameters to specific actions and their costs/constraints (e.g., fromSlug requires a briefing-stored brand, import vs generate semantics). It largely complements rather than duplicates the schema, though some reiteration is redundant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States precisely what the tool manages (palette, typography, voice, image style, persona as single source of style) and enumerates all 15 sub-actions with their specific effects. It is trivially distinguishable from siblings, explicitly cross-referencing sapiens_character and sapiens_gallery for the relevant flows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit routing rules: 'Brand que a pessoa JÁ TEM vai por import, nunca por generate', converse and build a rich description BEFORE calling generate, confirm the 1350 Sinapses cost before generating, and use sapiens_image brandSlug=/brandMark=persona to actually surface the character. When-to-use vs alternatives is spelled out rather than implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.