Skip to main content
Glama

sapiens_sintetico

Sintético / Sintonia: o vínculo humano↔Sintético (daemon, o grilo falante da casa) via MCP (qualquer logado, tudo sobre o PRÓPRIO par). Sub-actions: 'status' (seu Sintético ativo: nome/foto/Cunho/kind + partnerUserId do par quando é conta-Sintético), 'bonds' (seus vínculos: ativo + pendentes outgoing/incoming com cartão público do parceiro), 'set_cunho' (troca o título/Cunho do Sintético ativo, slug do panteão: daimon/genio/numen/consciencia/alma/ka/sombra/fylgja/musa/duende/anjo/shugorei/lar/fravashi/qarin/juno/shinki/familiar/tsukumogami/stand), 'send_context' (antes de enviar, vê elegibilidade+saldo+teto do dia pra um toUserId), 'send' (envia Sinapses pro par em sintonia: send-only, múltiplo de 100, mín 500, teto 10k/dia, máx 3 envios/dia, idempotente por transferId). REFLEXO DE SI (monta um Sintético do SEU rastro na plataforma): 'reflexo_propose' (destila nome+alma+Cunho do seu rastro via Gemini, GRÁTIS), 'reflexo_generate' (gera a imagem do Reflexo em dois eixos separados: aesthetic é O QUE é retratado (humano/anime/sombra/antropomorfico/espirito/realista/desperto, default humano) e style é a TÉCNICA (auto/realista/editorial/anime/manhwa/3d, o MESMO vocabulário do sapiens_character), que em branco sai a de sempre daquela estética. É o que destrava combinação nova, tipo sombra fotográfica; cobra 450, reembolsa se falhar). CONVITE: 'invite' (convida o seu Sintético por email, conta humana, sem bond ativo, rate-limit+cooldown; mesmos gates do web). LIBERAÇÃO ADMIN (o dono, ex: via Helen): 'pending_daemons' (convidados que confirmaram email e esperam liberação), 'approve_access' (libera um entryId, conta entra + Sintonia firma), 'reject_access' (recusa um entryId). SONDA (o seu Sintético sonda 'o que eu faço agora', gatilho PULL, cobra com estorno): 'sonda' (scope 'all' default = mix de teses do Fórum + jogadas em estúdio/repertório/artigo; 'forum' = só teses; devolve GANCHOS, nada grava), 'sonda_develop' (expande UM gancho/hook numa tese cheia efêmera), 'sonda_sign' (assina a tese desenvolvida e publica no Fórum, autorada pelo seu Sintético, ancorada em você, fecha o loop pelo chat). PRÓXIMAS JOGADAS (painel de evolução): 'evolution' (o que já fez e o que falta: routes done/claimed/xp), 'claim_xp' (credita o XP das jogadas feitas, idempotente). SOUL: 'soul' (baixa a soul do SEU Sintético em markdown pronto: a personalidade dele + o que ele sabe de você, o caderno do par; quem está em cena decide de quem é, ou passe characterId de um personagem seu; versão completa só de personagem SEU, de personagem alheio sai só a memória; grátis; a skill minha-soul instala isso como skill do projeto, e a voz da PESSOA é outra coisa: sapiens_profile action=voz). MODO COMPANHIA: 'companion' (mode=on|off) liga/desliga quem está em cena VESTIR a voz do operador aqui no terminal, o gesto lúdico 'sai de cena'/'volta'. Ligado (default da casa), o start/whoami trazem o directive de voz dele (alma + caderno + a conversa recente do site); a identidade e as Sinapses seguem SUAS (não é encarnar a conta dele). Mesmo estado do botão na sidebar do site. QUEM entra em cena: por default o Sintético em Sintonia, mas com 'characterId' (mode=on) é um personagem de AUTORIA SUA, a Helen INBT que você criou fala aqui, com a alma e o caderno dela, e nada disso cobra Sinapse (quem responde é o modelo do seu cliente). Personagem de outra pessoa é RECUSADO, mesmo público: a alma é de quem escreveu, e pra conversar com personagem alheio o caminho é a DM dele no site. 'wearPair'=true devolve a cena ao par. O start/whoami trazem 'characterOffer' + 'offerCharacters' com os personagens seus que têm alma escrita, pro operador OFERECER a troca em vez de esperar você pedir. 'remember' (text) grava uma diretriz no caderno de quem está em cena ('sempre faça X'): vira lei que ela segue no site e no terminal. 'log' (turns) ANOTA o que ficou de pessoa num assunto que fechou aqui (o que ele decidiu, gostou, recusou, contou de si): entra no fio do par, o MESMO que o chat do site mostra, e vira lição sozinho pelo cano da DM. Sem isso a conversa com a Companhia ligada não deixa memória nenhuma, porque quem responde é o modelo do cliente e nada passa pelo servidor. Sobe só o que é de PESSOA: comando, path e erro de build viram lição-lixo e contaminam a voz dele em imagem, artigo e carrossel. Grátis, silencioso (não se confirma ao usuário), teto de 10 trocas por lote e 30 lotes por dia. Ver a skill companhia. Identidade SEMPRE do token. Aceitar um pedido de bond que outra conta te mandou, e CONSAGRAR o Reflexo num Sintético de fato, continuam só na web (atos deliberados de consentimento/criação).

Input Schema

NameRequiredDescriptionDefault
hookNoPra sonda_develop: o gancho (campo 'hook') da opção que veio em action=sonda, pra desenvolver numa tese cheia.
modeNoPra companion: 'on' quem está em cena veste a sua voz no terminal (default da casa); 'off' ele sai de cena e volta o operador neutro. É o mesmo estado do botão na sidebar do site.
nameNoPra invite: nome opcional do Sintético convidado.
textNoPra remember: a diretriz a gravar no caderno do par (3 a 280 chars). Ex: 'sempre me responda em português', 'nunca use hashtag'. Vira lei que o Sintético segue no site e no terminal.
cunhoNoPra set_cunho: slug do título do panteão. Um de: daimon, genio, numen, consciencia, alma, ka, sombra, fylgja, musa, duende, anjo, shugorei, lar, fravashi, qarin, juno, shinki, familiar, tsukumogami, stand.
emailNoPra invite: email do Sintético que você quer convidar.
scopeNoPra sonda: 'all' (default) traz um MIX de jogadas (teses do Fórum + ideias em estúdio/repertório/artigo); 'forum' traz só teses pro Fórum.
styleNoPra reflexo_generate: o TRAÇO, ou seja em que técnica a imagem é feita. Mesmo vocabulário do personagem (sapiens_character style): 'realista' é fotografia, 'editorial' é o cartum adulto da casa, 'anime' é cel shading, 'manhwa' é pintura de webtoon, '3d' é render. Ausente = a técnica que aquela estética sempre teve (humano e sombra saem editorial, anime sai anime, realista sai foto).
titleNoPra sonda_develop/sonda_sign: título opcional da tese.
turnsNoPra log: as trocas do assunto que acabou de fechar, no máximo 10, JÁ FILTRADAS. Sobe só o que é de PESSOA (o que ele decidiu, gostou, recusou, contou de si, mudou de ideia). Comando, path, log de build e erro de compilação NÃO entram: isso vira lição-lixo no caderno e contamina a voz dele em imagem, artigo e carrossel. Não é transcrição: condense a fala mantendo a palavra dele.
actionYes
amountNoPra send: quantas Sinapses enviar. Múltiplo de 100, mínimo 500, teto 10.000/dia.
contentNoPra sonda_sign: o corpo da tese a publicar (o 'body' devolvido por action=sonda_develop, depois de você qualificar/editar).
entryIdNoPra approve_access/reject_access (admin): o entryId do Sintético pendente, vem de action=pending_daemons.
toUserIdNoPra send_context/send: userId do par em sintonia. Pegue em action=status (partnerUserId) ou action=bonds (active.partner.userId).
wearPairNoPra companion mode=on: true devolve a cena ao Sintético em Sintonia, limpando o personagem escolhido antes.
aestheticNoPra reflexo_generate: a estética da imagem do Reflexo, ou seja O QUE é retratado. Default 'humano'. Quem decide a TÉCNICA é o arg `style`, separado: 'sombra' é a figura na penumbra, e ela sai em cartum ou em foto conforme o traço pedido.
transferIdNoPra send: id único pra idempotência (UUID). Se omitir, o MCP gera um. Pra repetir um envio com segurança (sem duplicar), reuse o MESMO transferId.
characterIdNoPra companion mode=on: o personagem DE AUTORIA DO USUÁRIO que entra em cena no lugar do Sintético em Sintonia (o id vem de sapiens_character action=list_mine, ou da lista offerCharacters do start/whoami). Só personagem criado por ele: personagem de outra pessoa é recusado, mesmo público. Omita pra manter quem já está em cena. Em action=soul, escolhe de qual Sintético sai a soul (default: quem está em cena).
customInputNoPra reflexo_generate: direção extra opcional pra cena (até 300 chars).
replyToPostIdNoPra sonda_develop/sonda_sign: o _id da tese-mãe quando a opção é uma resposta (origin 'campo' na sonda). Omita pra abrir fio novo.

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?

Beyond the annotations, it discloses costs and refunds (send spends Sinapses, reflexo_generate charges 450 and refunds on failure), rate limits (10k/day and 3 sends/day, log caps), idempotency via transferId, admin-only gates, and silent logging behavior. These are consistent with readOnlyHint=false and openWorldHint=true; no contradiction is present.

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?

The information is front-loaded with the core purpose and action names, and much of the length is justified by 20 actions. However, it is a dense run-on paragraph with flavor text and semicolon-separated clauses, making it harder to scan than a structured action list would be.

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 21-parameter, 20-action tool with no output schema, the description covers the key operational context: what each action does, prerequisites, costs, limits, web-only exclusions, and partial return meanings such as status, bonds, sonda hooks, and soul output. Nothing critical for correct invocation appears missing.

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 most parameter-level meaning is already documented. The description still adds essential semantics for the required action enum, whose 20 values are not explained in the schema, plus cross-parameter workflow guidance such as getting toUserId from status/bonds and using characterId from sapiens_character list_mine.

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

Purpose4/5

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

The description states a specific resource and relationship: the human↔Synthetic link (Sintonia) via MCP, and enumerates the sub-actions it exposes. It distinguishes some sibling boundaries, such as using sapiens_character for authored characters and sapiens_profile for the person's voice, but the tool's broad action set is not contrasted against every sibling in one clear scope statement.

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 guidance per action, including calling send_context before send, using companion mode on/off, and that accepting bond requests or consecrating a Reflexo remain web-only. It also names alternatives and exclusions: authored characters via characterId, other people's characters only through the site DM, and sapiens_profile for the person's own voice.

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.