Skip to main content
Glama

sapiens_community

Chat da comunidade Sapiens (assinantes + alumni). Sub-actions: list (últimas N mensagens da sala 'geral' por default), send (Claude posta como intercessor do user; sufixo '· via Claude' é adicionado pelo servidor), react (toggle emoji numa mensagem, allowlist 👍🔥❤️🚀🤯), participants (quem está na sala: username/name/isBot + o mention pronto pra usar, use pra saber com quem falar), search_users (acha alguém por parte do nome/@username, autocomplete de menção). MENÇÃO: escreva '@username' no content do send e o servidor NOTIFICA a pessoa citada (sino + Telegram); descubra o username certo via participants/search_users antes. ANEXO do PRÓPRIO acervo no send: mediaAssetKind (track|video|film|comic) + mediaAssetId monta um card da peça (posse conferida no servidor); asTese=true posta a fala como TESE (card de marca, pingável pro Fórum). Voz nas postagens deve seguir o DNA editorial Sapiens (anti-corporate, primeira pessoa, sem em-dash).

Input Schema

NameRequiredDescriptionDefault
emojiNoEmoji da reação (action=react). Allowlist do server: 👍 🔥 ❤️ 🚀 🤯
limitNoPra action=list. Default 30, max 100.
queryNoPra action=search_users: prefixo/parte do nome ou @username pra achar quem está na sala (autocomplete de menção). Devolve até ~8 candidatos com o username pra você marcar no send.
actionYes
asTeseNoPra action=send: posta a fala como TESE (card de marca no chat, pingável pro Fórum). Sem custo.
contentNoTexto da mensagem (action=send). Max ~487 chars (suffix '· via Claude' adicionado pelo servidor). Use voz Sapiens. Marque alguém com '@username' (descubra o username via action=participants) pra notificá-lo.
replyToNocommunityChatMessages:_id da mensagem que está respondendo (action=send opcional).
roomSlugNoDefault 'geral'. Pra criar sala nova precisa do admin no site.
messageIdNocommunityChatMessages:_id (obrigatório pra action=react).
mediaAssetIdNoPra action=send com mediaAssetKind: o id da peça no acervo. Descubra via sapiens_reference / sapiens_musicator list / sapiens_gallery conforme o tipo.
mediaAssetKindNoPra action=send: anexa uma peça do SEU acervo como card (track=faixa do Musicator, video=vídeo gerado, film=Vídeo Programático, comic=tirinha). Requer mediaAssetId. O servidor confere que a peça é sua e está pronta.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: server appends '· via Claude', mentions trigger bell + Telegram notifications, emoji allowlist is enforced, media assets are ownership-checked server-side, react is a toggle, and asTese creates a Forum-pingable card. These are exactly the side-effect and constraint details an agent needs before acting.

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

Conciseness4/5

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

Front-loads identity and sub-actions, then progressively details mentions, attachments, and voice. Dense but nearly every clause carries actionable information; the all-caps section markers (MENÇÃO, ANEXO) are slightly noisy but aid scanning.

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?

No output schema, 11 parameters, and mixed read/write actions, yet the description covers sub-action selection, side effects, notifications, attachment mechanics, and expected voice. Nothing an agent needs to call any of the actions correctly is 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 already 91%, so the schema carries most weight, but the description adds real semantics the schema lacks: how mediaAssetKind+mediaAssetId compose into a card, what asTese does, mention syntax, and where to discover mediaAssetId. This nudges above the baseline 3.

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 a specific resource (community chat for subscribers + alumni) and enumerates the five sub-actions with a one-line gloss for each. An agent can tell exactly what this tool does and see it is distinct from sapiens_forum and other siblings.

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

Usage Guidelines4/5

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

Gives strong intra-tool routing: participants to learn who to talk to, search_users for mention autocomplete, list defaults to 'geral'. It even says to resolve a username before sending. It does not explicitly contrast with sapiens_forum, which keeps it from a 5.

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.