Skip to main content
Glama

sapiens_gallery

Browse, publicação e upload das imagens do user. Sub-actions: list (últimas N peças, com prompt/model/url + isPublic + acervoUrl; kind=image por default, kind=video traz os takes com posterUrl, a capa, e kind=all mistura. Depois de ingerir ou gerar vídeo, é o list kind=video que dá a capa pra mostrar miniatura + player em vez de link solto), get (1 imagem com metadados, opcionalmente base64), publish (torna a PRÓPRIA peça pública, imagem ou vídeo: a imagem entra na galeria pública + feed Pinterest e ganha página indexável /imagem/, o vídeo ganha a /video/, pela mesma régua do botão Publicar da ficha (peça oculta ou reprovada não publica, upload de fora também não, ingest da ponte sim); publicPageUrl volta null em peça +18 e de modelo degen; publicado NÃO despublica, não existe unpublish), upload (traz pra galeria uma peça gerada FORA da casa, por sourceUrl https, filePath local ou base64; ADMIN por ora), ingest (A PONTE, qualquer conta logada: peça que a PESSOA dirigiu com a ficha do personagem daqui e um motor de fora renderizou, no crédito dela (Kie, fal, Magnific, Sogni, a própria placa): entra NATIVA na timeline e nasce PRIVADA (isPublic false), publicável DEPOIS por ela como qualquer geração da casa, nunca sozinha, com custo 0 em Sinapses e o custo real guardado em externalCost; carrega o prompt VERBATIM, as referências da casa (referenceImageIds), o personagem (characterId) e o motor (externalEngine 'provedor-motor'); a peça chega por filePath (local, só no MCP instalado), sourceUrl (o render, baixado pelo MCP na máquina da pessoa, nunca pelo servidor) ou base64; o carimbo +18 nasce na entrada pela CLASSE do provedor (peso aberto como Sogni, Replicate, HF, fal, WaveSpeed, Civitai e a própria placa entram carimbados, só a curadoria tira; serviço com moderação como Kie, Magnific, Freepik, Krea entra sem) ou por unfiltered=true dito pela pessoa (carimbo dela, ela tira depois); idempotente por sourceUrl ou pelo hash do arquivo, então re-ingerir corrige a ficha em vez de duplicar; tetos 12 MB imagem, 60 MB vídeo, 40 por dia. A chave do provedor NUNCA passa por aqui: quem gerou foi o harness da pessoa. Passo a passo na skill 'pontes'), refs (acopla peças da casa como REFERÊNCIA numa peça que já existe, de upload ou de ingest; ADMIN, e só na própria peça), processo (O COMO JUNTO DO QUE: anexa a uma peça as peças que mostram como ela foi dirigida, o mapa de rota desenhado sobre o still, a prancha de frames com o tempo de cada marco, o antes e depois de duas rodadas; elas viram a seção 'Como foi feito' na página pública da peça, na ordem que você mandar e com a sua legenda por peça; qualquer membro, só na própria peça, teto de 12. É IRMÃ do refs e a diferença importa: refs é o INSUMO que entrou na geração, processo é o REGISTRO de como ela foi dirigida, e uma lista não mexe na outra. Peça de processo privada não aparece pra quem está de fora nem em miniatura: pra aparecer, publique ela também), cast (QUEM ESTÁ EM CENA numa peça que já existe, quando é mais de uma criatura: characterIds em ordem, o protagonista primeiro, e a peça passa a contar na ficha de todos eles em vez de sumir da segunda; qualquer membro, na própria peça), parts (O INTEIRO E OS PEDAÇOS de um vídeo: o clipe de 30s que foi montado a partir de dois takes de 15s, a fita longa feita de partes. COM imageId devolve a ficha de parentesco daquela peça, quais são as partes dela e de qual inteiro ela é parte, com a url do arquivo completo pra baixar. SEM imageId devolve o que AINDA NÃO FOI MONTADO: varre os takes soltos da conta, agrupa os que têm cara de par (mesmo personagem, mesmo período, prompt de 'Part one/Part two' ou arquivo terminando em -a/-b) e diz o PORQUE de cada agrupamento, pra você saber o que falta juntar antes de o autor perguntar. É heurística e não monta nada sozinha: adianta a descoberta, quem decide é quem lê. characterId filtra por personagem. Sem custo), link_parts (LIGA o inteiro aos pedaços: imageId é o vídeo montado e partIds são os takes NA ORDEM em que aparecem nele. O juntador da casa e o ingest que traz referências de vídeo já gravam esse laço sozinhos; esta porta é pra montagem feita FORA (ffmpeg na máquina, ingest do arquivo já pronto) e pra corrigir ligação errada. Só na própria peça, teto de 16 partes, e a lista TROCA o que estava gravado antes. Sem custo), reprovar (O VETO do dono: imageId + motivo, o porquê numa frase concreta. A peça que errou (rosto do personagem trocado, mão quebrada, a referência errada) não sai mais por porta nenhuma, fila do Distribution, publicar, Telegram, e some das levas do garimpo; fica no acervo com o porquê, pra ensinar. Chame NO MESMO TURNO em que o dono condena uma peça: peça condenada e não marcada volta numa leva. desfazer=true tira o veto. Imagem e vídeo, só na própria peça, sem custo), reprovadas (as peças vetadas da conta com o prompt que as gerou e o motivo, a mais recente primeiro; characterId filtra por personagem. LEIA ANTES de gerar de novo um personagem que já teve peça reprovada: é a lista do que não repetir. Sem custo), carimbo (o +18 da peça: imageId + adulta true liga, false tira, com a regra do botão da ficha: a curadoria mexe em qualquer carimbo, inclusive o que a ponte põe por classe de motor sem autor, e o dono liga na própria peça e só tira o que ele mesmo pôs. Peça carimbada não entra em praça sfw do Distribution, então tirar o carimbo de peça vestida destrava Instagram, TikTok, YouTube e LinkedIn; peça com nudez fica carimbada. Sem custo), apagar (APAGA DE VEZ a própria peça, imagem ou vídeo, pela mesma saída do botão de excluir da ficha: imageId + confirmar=true. A peça e o arquivo saem e não tem volta, então só depois que o dono pediu pra apagar AQUELA peça; peça que errou e deve ficar como lição vai por reprovar. Peça ainda gerando é recusada (apagar no meio cortaria o estorno: espere fechar ou falhar). Volta apagada=false, sem erro, quando não há peça com esse id na conta, inclusive ao repetir depois de um Timeout. Sem custo). Use list/get pra reusar imagem como referência (passe o imageId em sapiens_image mode=edit ou mode=variation) ou pra mostrar pro user o que ele já tem; publish quando o user quer divulgar a peça dele (imagem ou vídeo). IMPORTANTE sobre upload: a peça entra PRIVADA e continua privada: o servidor recusa publicar e recusa compartilhar na comunidade, porque ela é do usuário e a responsabilidade é dele. O caminho pra ela virar coisa pública é usar como referência numa geração daqui e publicar o resultado. O refs escreve só proveniência (de que ficha/folha a peça nasceu): não promove nada, e um upload continua sem publicar depois de ganhar referência. COMO A PEÇA FOI FEITA: list aceita skill= e devolve só o que saiu daquela skill (o mesmo slug que sapiens_image gravou em skills), com a busca varrendo as últimas 200 peças antes de cortar no limit; cada item volta com o campo skills, e null ali quer dizer que ninguém marcou, não que foi feita sem skill.

Input Schema

NameRequiredDescriptionDefault
kindNoaction=list: que mídia listar. 'image' (default) é o de sempre; 'video' traz só os takes, cada um com `posterUrl` (a capa) e `acervoUrl` (a ficha); 'all' mistura. Use kind=video depois de uma leva de ingest ou de geração de vídeo: é o que permite MOSTRAR a peça (capa + player) em vez de devolver link solto. posterUrl null = capa ainda em produção, volte em alguns segundos.
noteNoaction=upload: o que é a peça (prompt original, contexto). Vira a descrição na galeria e a busca acha por ela.
sizeNoaction=ingest: resolução ('720p', '1080p'). Default 720p.
limitNoDefault 20. Max 100. Pra action=list (e action=reprovadas, teto 60). Sem offset: com filtro de model ou skill a busca varre só as últimas 200 peças. Pra achar o imageId de peça que não é de hoje, use sapiens_reference action=browse bucket=history term=<palavra> (paginado, devolve o imageId) ou sapiens_reference action=resolve handle=img_xxx.
modelNoFiltro de model (action=list). Ex: 'nano-banana-max' pra ver só Pro.
skillNoFiltro por SKILL que dirigiu a peça (action=list): devolve só o que saiu daquela skill, pelo slug exato que a geração gravou (ex: 'camarim', 'escala-gigantismo'). É o que responde 'me mostra tudo que saiu do camarim'. Com filtro, a busca varre as últimas 200 peças antes de cortar no limit, então acha coisa antiga. Peça sem marcação nenhuma volta com skills null e nunca casa com filtro.
actionYes
adultaNoaction=carimbo: true LIGA o carimbo +18 na peça, false TIRA. Obrigatório nessa action. A regra é a do botão da ficha: a curadoria (admin) liga e tira qualquer carimbo, inclusive o que a ponte põe por CLASSE de motor sem autor; o dono liga na própria peça e só tira o carimbo que ele mesmo pôs. Peça carimbada não entra em praça de teto sfw do Distribution (Instagram, TikTok, YouTube, LinkedIn): tirar o carimbo de peça vestida é o que destrava a fila. Não tire carimbo de peça com nudez.
base64Noaction=upload/ingest: os bytes já em base64, se você mesmo os tem em mãos (imagem; vídeo vai por filePath ou sourceUrl).
motivoNoaction=reprovar: O PORQUÊ do veto, numa frase concreta que a próxima geração consegue usar ('trocou o rosto da Helen: gerada só com influencerId, sem as refs do passaporte'; 'mão esquerda com seis dedos'). É a lição que fica na peça: sem ele, reprovar só esconde e não ensina. Até 500 caracteres. Reprovar de novo sem motivo mantém o que já estava escrito.
promptNoaction=ingest: o PROMPT DE GERAÇÃO, copiado inteiro do motor externo, exatamente como foi enviado. É o que a ficha mostra e a busca acha, e é o que permite regerar a peça depois. NÃO escreva aqui nota, resumo, título ou comentário sobre a peça: isso deixa a ficha sem sentido pra quem abrir. Re-ingerir a mesma sourceUrl com um prompt novo CORRIGE o que já está gravado, sem duplicar.
skillsNoaction=ingest: COMO A PEÇA FOI FEITA, os slugs das skills da casa que dirigiram o take (ex: ['clipe'], ['rasante','storyboard']). Aparece como 'Feito com /clipe' na ficha e na página pública da peça. No Claude Code com o plugin Sapiens o hook carimba sozinho; em outro cliente, passe sempre que o take saiu de uma skill da casa. Re-ingerir SOMA às que já estavam, nunca apaga. Metadado puro: não muda custo nem alcance.
imageIdNogeneratedImages:_id (obrigatório pra action=get/publish/refs/cast/processo, e em link_parts é o vídeo INTEIRO). Em action=parts é OPCIONAL: com ele vem a ficha de parentesco daquela peça, sem ele vem o que ainda não foi montado na conta inteira.
partIdsNoaction=link_parts: os PEDAÇOS que viraram o vídeo inteiro, NA ORDEM em que aparecem nele (take A, depois take B). generatedImages:_id de vídeo seu, teto de 16, aceita lista ou os ids separados por vírgula. A lista TROCA o que estava gravado antes, então mande sempre todas as partes, não só a que faltou.
replaceNoaction=refs: false (default) SOMA às referências que já existem; true troca a lista inteira. Pra limpar tudo, mande a lista vazia com replace=true.
desfazerNoaction=reprovar: true TIRA o veto (a peça volta a poder sair e a entrar nas levas), e o motivo vai junto. Ausente/false reprova.
filePathNoaction=upload/ingest: caminho ABSOLUTO de um arquivo local: no upload só imagem (png, jpg, webp, gif, avif), no ingest também mp4 e mov. O conteúdo é conferido pelos bytes antes de subir, e arquivo que não é peça é recusado sem ser enviado. SÓ no MCP instalado (stdio): é a porta de quem gerou na própria máquina ou baixou o render antes; no remoto use sourceUrl. No ingest, o sha256 do arquivo vira a chave de idempotência.
mimeTypeNoaction=upload/ingest: tipo do arquivo (image/png, video/mp4...). Detectado sozinho a partir da URL/extensão/resposta HTTP quando omitido. Em filePath e base64 vale o tipo que os bytes mostram, não este.
processoNoaction=processo: as peças de processo, NA ORDEM em que o processo aconteceu (o still, o mapa, a prancha). Teto de 12.
confirmarNoaction=apagar: tem que vir true. Apagar não tem volta (a peça e o arquivo saem), então a tool recusa sem ele: só mande depois que o dono pediu pra apagar AQUELA peça. Peça que errou e deve ficar como lição vai por action=reprovar.
sourceUrlNoaction=upload/ingest: URL https direta da peça pronta no motor de fora (o link do render da Kie, da fal, da Magnific). No ingest ela também é o RASTRO e a chave de idempotência: repetir a mesma sourceUrl corrige a ficha em vez de duplicar. Quem baixa é o cliente MCP (na sua máquina, no stdio; no remoto, o servidor do site): URL de render expira (Kie em 24h, Magnific no mesmo dia), então ingira no mesmo turno do render. Alternativa a filePath/base64.
unfilteredNoaction=ingest: true quando o motor rodou SEM filtro de conteúdo (modo livre, spicy, uncensored) num serviço que normalmente modera. A peça nasce com o carimbo +18 da casa DECLARADO por você (você pode tirar depois na ficha): publica, fica no seu perfil e no link direto, e sai da vitrine anônima e dos feeds. Não precisa dizer pra provedor de peso aberto (Sogni, Replicate, Hugging Face, fal, WaveSpeed, Civitai, a própria placa): esses já entram com o carimbo por CLASSE, que só a curadoria tira, igual ao motor sem freio da casa. Serviço com moderação (Kie, Magnific, Freepik, faceless, Krea, Midjourney, Runway, Higgsfield) entra sem carimbo, a menos que você diga isto ou o nome do motor tenha '-spicy', '-nsfw', '-uncensored'.
aspectRatioNoaction=ingest: proporção da peça ('16:9', '9:16'). Default 16:9.
characterIdNoaction=ingest: o personagem de quem é a peça (influencers:_id, ache com sapiens_character action=list_mine). A peça nasce ligada à ficha, igual ao que sai dos motores da casa: conta no personagem e resolve a miniatura dele. PODE OMITIR quando as referenceImageIds já são peças da casa feitas com aquele personagem (folha de storyboard, ficha): o servidor deduz o personagem da primeira ref que tem um. O que você diz aqui manda sobre o que ele deduz. Re-ingerir a mesma sourceUrl com characterId AMARRA uma peça que já entrou sem personagem, sem trocar o id. Aceita personagem seu ou público. Em action=reprovadas, FILTRA as vetadas daquele personagem.
characterIdsNoQUEM ESTÁ EM CENA, quando é mais de uma criatura (action=ingest e action=cast). Em ordem de cena: o PRIMEIRO é o protagonista (é ele que a ficha e o cartão do vídeo mostram) e o resto vira elenco, então a peça conta na ficha de TODOS eles em vez de sumir da segunda. Teto de 6. Use quando a fita foi dirigida com duas folhas de personagem: sem isto, ela aparece só na ficha de um. Aceita lista ou os ids separados por vírgula, personagem seu ou público. Pra peça de uma criatura só continue usando characterId.
externalCostNoaction=ingest: quanto custou lá fora, em texto livre ('4200 créditos Freepik'). A peça entra com 0 Sinapses, então é isto que preserva o custo real no histórico.
includeBase64NoDefault false. Quando true, action=get devolve os bytes em base64 (pesado, evite em listagens).
externalEngineNoaction=ingest: qual motor renderizou, sempre no formato provedor-motor ('kie-kling-3.0', 'fal-krea-2', 'magnific-minimax-h3', 'sogni-minimax-h3', 'bancada-ltx-2.5'). É ESTE campo que a ficha da peça mostra em 'Motor', então a marca sozinha ('kie', 'magnific') é recusada pelo servidor: provedor é a loja, não o motor. O provedor decide o carimbo +18 na entrada: peso aberto (sogni-, replicate-, hf-, fal-, wavespeed-, civitai-, bancada-, comfy-, local-) ou provedor que a casa não conhece entra com o carimbo por classe (publica e fica no perfil, só não vai pra vitrine anônima); serviço com moderação (kie-, magnific-, freepik-, faceless-, krea-, midjourney-, runway-, higgsfield-, modelark-) entra sem.
uploadedSourceNoaction=upload: de onde veio ('magnific', 'suno', 'camera'). Fica registrado na peça e no aviso do Discord.
referenceImageIdsNoaction=ingest/refs: generatedImages:_id das peças DA CASA que serviram de referência (folha de storyboard, ficha de personagem, frame inicial). Ficam acopladas à peça e aparecem na ficha dela: é o que prova que a receita saiu daqui. Se alguma delas foi feita com um personagem, a peça HERDA esse personagem sozinha (no ingest, e no refs quando a peça ainda não tem um). Só peça sua entra, no máximo 8. Aceita lista ou os ids separados por vírgula.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries the real burden and does so richly: uploads stay private and cannot be published, publish is irreversible with no unpublish, apagar is permanent, reprovar removes a piece from all distribution paths, ingest is idempotent and capped at 12 MB image / 60 MB video / 40 per day, and the +18 stamp rules are spelled out. No contradiction with annotations.

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

Conciseness2/5

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

The description is a dense, run-on wall of text with nested parentheticals and repetitions. It front-loads the basic scope, but the remaining content is not structured into scannable sections and many sentences restate schema descriptions rather than earning their place.

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?

Given 14 sub-actions, 30 parameters, no output schema, and a mix of mutation and external-ingest behavior, the description covers edge cases and return shapes sufficiently: list returns prompt/model/url/isPublic/acervoUrl, get optionally returns base64, publish returns publicPageUrl with +18 caveats, parts returns parentage or unassembled groups. Nothing critical to correct invocation appears missing.

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

Parameters3/5

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

Schema coverage is 97%, so almost all parameter meaning is already in structured fields. The description adds cross-action context and behavioral distinctions (e.g., skill filter scans last 200; link_parts order replaces prior list; refs vs processo), but most parameter-specific detail duplicates or paraphrases what the schema already says.

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?

The description opens with a specific scope (browse, publish, upload user images) and enumerates all 14 sub-actions with distinct verbs and resources. It explicitly distinguishes itself from sapiens_image and sapiens_reference, so an agent can route gallery management here without opening the schema.

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?

It gives explicit when-to-use rules for nearly every action: use list/get to reuse an image as a reference via sapiens_image; publish when the user wants to divulge; upload vs ingest; reprovar vs apagar; refs vs processo. Alternatives and exclusions are named, including the older-image lookup path via sapiens_reference action=browse bucket=history.

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.