Cited library on Ifá, the Orishas and Yoruba philosophy in 4 languages. Read-only; not an oracle.
Devolve um post do blog pelo slug, em Markdown com links absolutos, mais os posts relacionados. O blog é gratuito e sai completo.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds useful behavioral context beyond that: the response is Markdown with absolute links, includes related posts, and is described as free and complete. No contradiction with annotations exists.
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 first sentence is dense and front-loaded with the core behavior and output format. The second sentence ('O blog é gratuito e sai completo') adds behavioral context but is slightly vague; overall the description is compact with minimal waste.
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 simple read-only tool with only two parameters and no output schema, the description covers the essential call semantics: what to pass, what comes back, and extra content (related posts). It is missing only minor clarifications like missing-slug behavior or how related posts are ordered.
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 coverage is 50%: lone locale has a description, while slug does not. The description does clarify that slug is the lookup key, but it does not add any information about locale beyond the schema, and the slug parameter still lacks a formal description.
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 uses a specific verb ('Devolve'), a clear resource ('post do blog'), and the key selector ('pelo slug'), and adds output details (Markdown, absolute links, related posts). This distinguishes it clearly from siblings like list_articles and search_library.
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?
Usage is implied: if an agent needs a full blog post by slug, this is the tool. However, the description does not explicitly state when to prefer this over list_articles or get_glossary, nor does it mention any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
O glossário do site (mais de 70 termos: Odu, Aché, ebó, babalawo, patakí…), com as variantes de grafia do Candomblé, da Santería e da Nigéria. Sem term devolve tudo, por seção; com term devolve só os verbetes que casam.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive behavior. The description adds meaningful behavioral detail beyond that: returning all entries per section vs. filtering to matching verbetes, and highlighting spelling variants from Candomblé, Santería, and Nigeria. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with scope and examples, and wastes no words. The behavioral rule about `term` is placed at the end but remains crisp and easy to parse.
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 read-only lookup tool with two optional parameters and no output schema, the description covers the resource, supported spelling variants, and filtering behavior. It does not explicitly mention `locale`, but the schema already provides that, so no critical invocation detail 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?
The schema only documents `locale`; `term` is undocumented in the schema. The description compensates by explaining the semantic effect of `term` through the 'sem/com' distinction and the idea of matching entries. Together with the schema's `locale` description, the parameters are well covered.
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 resource ('O glossário do site'), gives concrete examples of the 70+ terms, and specifies the two retrieval modes: without `term` returns everything by section, with `term` returns matching entries. This clearly distinguishes it from siblings like get_article or search_library.
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?
The description explicitly explains when to omit or provide the `term` parameter, which is the main usage decision. It does not explicitly compare against sibling tools, but the glossary scope is clear and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devolve um dos 256 Odus pelo slug (ex.: "ogbe", "oyeku", "ogbe-oyeku"; formas antigas como "eji-ogbe" são normalizadas). Os 16 Meji trazem texto próprio no idioma pedido; os 240 combinados trazem descrição editorial em português. A nomenclatura lucumí vem citada com a página do Tratado Enciclopédico de Ifá. Campos de conselho e texto litúrgico sem fonte verificada NÃO são devolvidos (listados em omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and idempotent safety. The description adds substantial behavioral context beyond that: slug normalization of old forms, the fact that only Meji Odus are translated while combined ones always return Portuguese, the citation of the Tratado Enciclopédico, and the explicit omission of unverified fields listed in 'omitted'. This is exactly the kind of disclosure that helps an agent interpret responses.
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?
Every sentence earns its place: scope, language behavior, source citation, and omission policy. The main action is front-loaded, and the structure is tight despite covering multiple behavioral details.
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?
The description covers slug variants, locale expectations, citation info, and omitted unverified fields, which is enough for an agent to invoke the tool correctly and interpret most responses. It does not specify the output envelope or error behavior for unknown slugs, but given the annotations and focused scope, this is a minor gap.
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?
The slug parameter has no schema description, but the description compensates with concrete examples and normalization rules. For locale, the schema only says 'language of response', while the description clarifies a critical nuance: locale only affects the 16 Meji texts, not the 240 combined Odus. This adds real meaning over the schema.
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 opens with 'Devolve um dos 256 Odus pelo slug' — a specific verb plus resource — and clarifies the two content types (16 Meji with own text, 240 combined with editorial description). It clearly differentiates itself from the sibling get tools by targeting Odus only.
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?
The intended use is clear: call this when you have an Odu slug and want its corresponding content, optionally in a specific locale. It does not explicitly name alternatives or state when not to use it, but the narrow resource scope makes the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devolve o perfil de um Orixá pelo slug (ex.: "exu", "oxum", "xango", "iemanja") no idioma pedido, com a nomenclatura yorubá / lucumí / brasileira lado a lado (citada) e os Estudos ligados a ele. O perfil em si é editorial; os mitos citados por título estão nos Estudos.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover non-destructive, read-only, idempotent behavior. The description adds value by explaining the editorial nature of the profile, the side-by-side cited nomenclature, and that myths are only referenced by title and located in Estudos. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with the core action and resource. The first sentence handles functionality and examples; the second adds an important content boundary without redundancy.
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?
No output schema exists, so the description usefully sketches the returned composition: profile, cited nomenclature, and linked Estudos. It does not describe not-found behavior or fallback language handling, but for a simple read-only slug lookup these are minor gaps.
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?
With 50% schema description coverage, the description compensates by mapping both parameters: slug is exemplified with 'exu', 'oxum', 'xango', 'iemanja', and locale is implied by 'no idioma pedido'. It could add slug normalization or locale default details, but the schema already provides the enum/default for locale.
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?
'Devolve o perfil de um Orixá pelo slug' names a specific action and resource, reinforced with concrete slug examples. The description clearly differentiates this tool from article/glossary/odu siblings by focusing on Orixá profile lookup.
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?
The description gives clear lookup context: slug plus requested language, with a boundary that the profile is editorial while myth content lives in Estudos. It does not explicitly name a sibling tool as the alternative, but it implies where fuller myth content should be found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os posts publicados do blog (mais novo primeiro), com resumo, categoria, tags e URL. Filtre por categoria se quiser.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the read-only and idempotent annotations by disclosing the sort order (newest first), the output shape (summary, category, tags, URL), and the optional category filter. It does not mention pagination or limit behavior, but the annotations already cover the safety profile, so this is a reasonable level of transparency.
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 description is two short sentences with no filler. It front-loads the core action and resource, then the ordering and output fields, then the optional filter. Every sentence earns its place.
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 simple list tool with no output schema, the description adequately covers return values and ordering, and the annotations cover read-only/idempotent behavior. It could add a note about limit/pagination behavior or an explicit pointer to get_article for full post content, but the current description is sufficient for an agent to call it correctly in most cases.
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 only 33%: only 'locale' is described. The description adds meaning for 'category' by saying users can filter by it, but it does not explain 'limit' or how ordering interacts with that parameter. The enum values and defaults help, but the description only partially compensates for the low schema coverage.
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 clearly states the verb 'Lista' (lists) and the resource 'posts publicados do blog' (published blog posts), and specifies the returned fields: summary, category, tags, and URL. It also names the ordering ('mais novo primeiro'), which distinguishes it from 'get_article' and other sibling tools that fetch single items or different content types.
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?
The description gives clear usage context: it is for listing published blog posts with optional category filtering. It does not explicitly state when not to use it or name alternatives, but the blog-post scope and ordering make its role evident relative to siblings like get_article, list_studies, and search_library.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os Estudos publicados: recontos de patakís citados por edição e página (Tratado) ou por título exato do mito (Prandi), em duas trilhas (Odu e Orixá). Devolve título, resumo, o teaser público em Markdown e as fontes. O corpo completo é para assinantes e não está disponível por esta ferramenta.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: it specifies the exact output fields (title, summary, public Markdown teaser, sources) and the limitation that the full body is not returned.
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 description is two sentences with no redundancy. The main action and scope are front-loaded, followed by the return-value list and the subscription limitation. Each clause contributes to the agent's understanding.
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 simple listing tool with one optional enum parameter and no output schema, the description covers what the tool returns and what it does not return. Minor gaps such as pagination, ordering, or filtering are not critical here, so completeness is slightly above average.
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 100%, and the single locale parameter is fully documented with enum values and a default. The description adds no parameter-level information, so the baseline score of 3 is appropriate.
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 action ('Lista os Estudos publicados') and clearly identifies the resource and scope: published Studies with patakí retellings cited by edition/page or exact myth title, in two tracks (Odu and Orixá). It also lists the returned fields, making it easy to distinguish from siblings like get_article or list_articles.
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?
The description explicitly says the full body is for subscribers and not available through this tool, which implicitly frames it as a metadata-only listing tool. However, it does not name alternatives for full-body access or state when to prefer this over list_articles or search_library.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca por termo em toda a biblioteca: os 256 Odus (nomes yorubá e lucumí), os Orixás (grafias do Brasil, de Cuba e da Nigéria), os Estudos, os posts do blog e o glossário. Devolve os melhores resultados com a URL da página. Use antes de get_odu / get_orixa / get_article quando não souber o slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Termo de busca, ex.: "Oxum", "Ika Bemi", "ebó", "Ogum ferro". | |
| locale | No | Idioma da resposta: pt-BR (base), en, es, de. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by specifying the breadth of the search and that results include page URLs, going beyond merely repeating the annotations.
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?
Three concise sentences with no filler: scope, output, and usage condition. The most important identifying information is front-loaded, and the alternative-tool routing appears at the end without bloating the description.
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 read-only search tool with strong annotations and clear schema coverage, the description is complete for selection and invocation. It tells the agent what the search covers, what output to expect (best results with URL), and when to prefer it over sibling tools.
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 coverage is 67%, covering query and locale. The description adds meaning by clarifying what kinds of terms are valid to search for (Odus, Orixás, Estudos, blog posts, glossary), which goes beyond the schema's generic 'Termo de busca' wording. The limit parameter is not elaborated, but its schema constraints are sufficient.
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 uses a specific verb ('Busca por termo') and names the resource ('toda a biblioteca') while enumerating exactly which content types are searched. It also distinguishes itself from get_* tools by stating it returns best results with page URLs and is meant for unknown slugs.
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?
The description explicitly instructs when to use the tool: 'Use antes de get_odu / get_orixa / get_article quando não souber o slug.' This names the alternative tools and the precise condition that selects search_library over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_articleget_glossaryget_oduget_orixalist_articleslist_studiessearch_libraryClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Personalised Yoruba cosmology orientation report, rooted in Ifa and Isese tradition.
Read-only Wheel of Heaven corpus: myth search, primary texts, datasets, typed graph. CC0.
Read-only access to S. Araba Lawson's Afromorphism essays, glossary, books, and site.
I-Ching (周易) oracle: cast a hexagram, read classical commentary, get a reflection. Bilingual.
Add one secure layer between your agents and this server.
As ferramentas têm papéis majoritariamente distintos: get_ para itens únicos, list_ para coleções e search_library para busca transversal. A única sobreposição possível é entre get_glossary e search_library, mas a primeira é consulta direta ao dicionário e a segunda é busca geral.
Todos os nomes seguem o padrão verbo_substantivo em snake_case, com verbos claros como get_, list_ e search_. Isso torna o conjunto previsível e fácil de usar.
Sete ferramentas é um número bem equilibrado para uma biblioteca de conteúdo sobre Ifá e Orixás. Cada ferramenta cobre um tipo de recurso ou operação essencial sem excesso.
A superfície cobre os principais conteúdos: artigos, glossário, Odus, Orixás, estudos e busca integrada. Falta uma forma direta de listar todos os Odus ou Orixás, mas a busca pode mitigar essa lacuna.
