Namandu Evidências
Server Details
Psicoeducação em saúde mental, em português, com a fonte e a licença de cada trecho. Sem login.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 3 tools
The three tools target distinct content types (practices, psychoeducation, scientific literature), but there is overlap: exercises appear in both list_wellbeing_practices and search_psychoeducation_content, which could cause misselection for exercise requests.
All tools use consistent snake_case with a verb_noun pattern (list_..., search_..., search_...), making them predictable and easy to distinguish.
Three tools cover the three main content types (practices, psychoeducation, literature) without redundancy; the count is well-scoped for a read-only content discovery server.
The surface provides listing and searching for all content types, with filters and links to full content. No obvious gaps for a read-only mental health content server.
Available Tools
3 toolslist_wellbeing_practicesListar práticas de bem-estarARead-onlyIdempotentInspect
Lista as práticas de bem-estar autoguiadas do Namandu — exercícios curtos de respiração, de voltar ao presente, de relaxar o corpo, meditações guiadas em áudio, escrita e rotinas — com título, categoria (o grupo por ação da prática), duração estimada em minutos e o link para fazer a prática no app. Filtros opcionais: category e maxDurationMinutes (só as práticas que cabem nesse tempo); sem filtros, devolve o catálogo inteiro. Use quando a pessoa pedir um exercício prático para lidar com estresse, ansiedade, sono ou emoções difíceis. É conteúdo educativo: não é indicação clínica e não substitui acompanhamento profissional.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| maxDurationMinutes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| practices | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As anotações já cobrem readOnly, idempotência, não-destrutivo e escopo fechado. A descrição agrega o comportamento dos filtros (sem filtros devolve o catálogo inteiro), os campos retornados e o aviso educativo, mas não detalha autenticação, limites de taxa ou paginação.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é front-loaded: começa pelo que a ferramenta lista, depois filtros, uso e aviso. A lista de campos retornados pode sobrepor-se ao output schema, mas não há frases desperdiçadas; é moderadamente longa, porém justificada.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta simples de listagem com dois parâmetros opcionais, output schema existente e anotações de segurança, a descrição cobre propósito, uso, comportamento dos filtros e escopo educativo. Nada essencial para invocação correta está ausente.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Com cobertura de descrição de esquema em 0%, a descrição carrega o ônus: explica 'category' como grupo por ação da prática e 'maxDurationMinutes' como teto de duração em minutos, além de indicar que ambos são opcionais e que a ausência de filtros retorna tudo. Os valores do enum ficam no schema, mas o significado dos parâmetros está claro.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
O verbo 'Lista' e o recurso 'práticas de bem-estar autoguiadas do Namandu' são específicos, e a descrição ainda detalha campos retornados e filtros. Não há diferenciação explícita dos irmãos search_psychoeducation_content e search_scientific_literature, o que impede o 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Define claramente o gatilho de uso: quando a pessoa pedir exercício prático para estresse, ansiedade, sono ou emoções difíceis. Também alerta que é conteúdo educativo e não indicação clínica, mas não menciona quando NÃO usar nem alternativas explícitas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_psychoeducation_contentBuscar conteúdos de psicoeducaçãoARead-onlyIdempotentInspect
Busca, pelo texto da consulta (query), os conteúdos de psicoeducação publicados no Namandu — artigos, exercícios, vídeos, áudios, materiais e guias sobre saúde mental e bem-estar — e devolve título, formato, resumo, tempo estimado em minutos e o link para o conteúdo: a página pública no blog do Namandu, quando o texto está nele, ou a do app, que pede para entrar ou seguir sem conta antes de abri-lo. Filtros opcionais: type (o formato) e limit (até 10; sem ele, 5). Escreva a consulta com os temas, como "ansiedade antes de dormir"; não ponha nela nome, contato ou qualquer dado que identifique alguém. Se o resultado trouxer crisisReferral, mostre esse texto à pessoa antes de tudo, sem resumi-lo. É conteúdo educativo: não é diagnóstico nem indicação clínica e não substitui acompanhamento profissional.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| contents | Yes | |
| crisisReferral | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavioral detail beyond them: the exact returned fields, that links may point to a public blog page or an app page requiring login/skip, the default limit of 5 with a max of 10, the special crisisReferral handling rule, and a privacy constraint on the query. This is rich context that materially shapes correct invocation and response handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and key constraints are front-loaded, and every sentence carries operational or safety value. It is a single dense paragraph and slightly restates return fields already present in the output schema, which costs a little efficiency but does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with three parameters, 0% schema description coverage, and an output schema, the description supplies everything an agent needs: parameter behavior, return shape, link/auth caveat, privacy rule for query construction, and mandatory crisisReferral display behavior. Nothing critical is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. It explains all three parameters: query content/style and privacy limits, type as the format filter, and limit's default (5) and ceiling (10). Only the enum values themselves live in the schema, but the description maps type to its meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Busca, pelo texto da consulta') and resource ('conteúdos de psicoeducação publicados no Namandu'), and enumerates the content formats it covers (artigos, exercícios, vídeos, áudios, materiais, guias). It does not explicitly contrast itself with siblings like search_scientific_literature, so an agent must infer the distinction from scope alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: how to phrase the query ('Escreva a consulta com os temas, como "ansiedade antes de dormir"'), what not to include (identifying data), and a boundary ('não é diagnóstico nem indicação clínica'). It stops short of naming alternative tools or stating when another sibling should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_scientific_literatureBuscar na literatura científicaARead-onlyIdempotentInspect
Busca, pelo texto da consulta (query), trechos da base científica curada do Namandu: resumos em português que o Namandu traduziu e adaptou de artigos científicos de acesso aberto sobre saúde mental e bem-estar, só de obras sob licença CC BY ou em domínio público. De cada trecho devolve o título do resumo, os autores, o ano, o periódico, o DOI quando houver, o link da obra original (url, fora do Namandu), a licença (licenseUrl, quando a versão é conhecida) e a linha de atribuição (attribution); notice diz o que os trechos são. Filtro opcional: limit (até 10; sem ele, 5). Escreva a consulta com os temas, como "terapia de aceitação e compromisso"; não ponha nela nome, contato ou qualquer dado que identifique alguém. Ao usar um trecho, repasse a linha attribution e o link da obra como vieram, sem encurtá-los nem trocá-los. Se a ferramenta responder UPSTREAM_UNAVAILABLE, diga que a base não pôde ser consultada agora, e não que não há estudos sobre o tema. Se o resultado trouxer crisisReferral, mostre esse texto à pessoa antes de tudo, sem resumi-lo. É conteúdo educativo: não é diagnóstico nem indicação clínica e não substitui acompanhamento profissional.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| results | Yes | |
| crisisReferral | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, idempotent, non-destructive, closed-world); the description adds substantial behavior beyond that: the UPSTREAM_UNAVAILABLE error semantics and the explicit instruction not to report it as 'no studies exist', the mandatory surfacing of crisisReferral before anything else, mandatory attribution/license preservation, and the educational-not-clinical framing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, corpus scope, and returned fields are front-loaded before the operational rules, and every clause carries actionable content. It is delivered as one very dense paragraph, which slightly hurts scannability of the distinct rules (filter, privacy, errors, crisis).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return fields need not be spelled out, yet the tool still flags the 'notice' field's meaning, downstream obligations (attribution, links), privacy restrictions, error handling, and crisis routing. Nothing an agent needs to call this correctly and safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load and largely does: it supplies the default for limit ('sem ele, 5'), restates the max of 10, and gives content-level guidance for query. It omits the query maxLength of 200 from the schema, a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Busca... trechos da base científica curada do Namandu') and precisely scopes the corpus (Portuguese abstracts translated from open-access CC BY/public-domain mental-health articles). This implicitly separates it from search_psychoeducation_content and list_wellbeing_practices, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage direction: how to phrase the query ('Escreva a consulta com os temas'), what must NOT go in it (names, contact, identifying data), the optional limit filter, and how to react to UPSTREAM_UNAVAILABLE or crisisReferral. It stops short of naming the sibling tools or stating when to prefer this over search_psychoeducation_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- First observed
list_wellbeing_practices - First observed
search_psychoeducation_content - First observed
search_scientific_literature
Related MCP Connectors
Plain-English child psychiatry library — short explainers and decision guides for parents.
Acervo jurídico brasileiro: busca, Markdown, grafo de normas e precedentes, citação verificável.
Chilean online mental-health clinic (Spanish): articles, professionals, availability, tests.
Read-only MCP for public mental-health workflows and Evidence from 病み期の読み物.
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables querying Brazilian PCDT clinical protocols from Conitec and generating concise, context-specific treatment summaries using a local LLM, with verified literal citations and links to official PDFs.2Apache 2.0
- FlicenseNot gradedqualityFmaintenanceCC0 open-data registry of community support helplines worldwide. TypeScript MCP server providing verified contacts with citation, staleness, and country-context guardrails. 15+ countries indexed.-
- FlicenseNot gradedqualityCmaintenanceEnables natural-language querying and cross-referencing of official mental health resources in Tainan, allowing users to find clinics, free counseling sessions, and analyze inconsistencies across multiple government datasets.-
- AlicenseNot gradedqualityCmaintenanceEnables natural-language querying of Brazilian public health indicators from DataSUS microdata — mortality, dengue, hospitalizations, ICSAP, and births — through 41 tools covering consultation, analysis (peer-stratum comparison, dengue endemic channel, weekly bulletin), reliability warnings, and anomaly detection. It runs locally against the public API with anti-hallucination rules so every figure comes from a tool with its source cited.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.