Cited library on Ifá, the Orishas and Yoruba philosophy in 4 languages. Read-only; not an oracle.
Scored across 7 tools
Each tool targets a distinct resource or action: retrieval by slug, enumeration, glossary lookup, and cross-library search. Overlap between search_library and the get_* tools is complementary rather than confusing, since search is explicitly positioned as a slug-discovery step.
All tool names use snake_case with a consistent verb_noun convention: get_* for detail retrieval, list_* for enumeration, and search_library for search. No mixed styles or vague verbs.
Seven tools is well-scoped for a read-only content library covering articles, glossary, Odus, Orixás, studies, and search. Each tool earns its place without redundancy.
Core retrieval for all advertised content types is covered, including search as a fallback when slugs are unknown. A minor gap is the lack of direct list_odus or list_orixas enumeration, though search_library provides a workaround.
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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavior: the response is Markdown with absolute links and also contains related posts, and the content is free/complete (no paywall truncation) — details an agent cannot get from 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?
Two compact sentences with the core behavior front-loaded: what is returned, in what format, plus what comes along with it. The trailing 'O blog é gratuito e sai completo' carries some informational value (no truncation/paywall) but edges toward promotional filler.
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?
With no output schema, the description must characterize the return value, and it does: Markdown with absolute links plus related posts. What is missing is any note on locale behavior or what happens when a slug is not found, but for a two-parameter read tool this is largely complete.
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%: locale is documented in the schema, but slug has no schema description, and the description only restates that lookup is by slug without adding format, length, or slug-discovery guidance. The locale parameter is never mentioned, so the description does not fully compensate for the coverage 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?
States a specific verb and resource ('Devolve um post do blog pelo slug') plus the return format, so an agent can tell this is single-article retrieval rather than a listing. It does not explicitly name the sibling it differs from (e.g. list_articles, search_library), so it stops short of a 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?
The phrase 'pelo slug' implies the precondition that a known slug is required, which is useful context. However, there is no explicit when-to-use guidance, no mention of when to prefer search_library or list_articles instead, and no exclusion 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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: the unfiltered call returns the whole glossary organized by section, while a `term` call returns only matching verbets.
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 sentences, zero filler: the first front-loads what the glossary is and its scope, the second front-loads the `term`-present vs `term`-absent behavior. The example terms earn their place by conveying entry type and script variants.
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?
With no output schema and four annotations, the return-shape question (all sections vs. matching entries) is the one thing that most needed covering, and the description covers it. Minor gap: no note on response language interplay between `locale` and the multilingual spelling variants mentioned.
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 only 50% (`term` has no schema description), and the description compensates by defining exactly what `term` does and what its absence means, which is the key semantic an agent needs. It adds nothing for `locale`, but that parameter is self-documented via its enum and schema 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?
States a specific verb+resource: it is the site's Yoruba glossary, and it even enumerates the kind of entries (Odu, Aché, ebó, babalawo, patakí) and coverage (>70 terms). The resource is clearly distinct from siblings like get_article, get_odu and get_orixa, though it never explicitly contrasts itself with them.
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 explains the two operating modes — omit `term` to get everything section by section, pass `term` to get only matching entries — which is genuine usage guidance for selecting behavior. However, it gives no guidance on when to prefer this tool over search_library or the individual get_orixa/get_odu tools.
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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe idempotent read, yet the description adds substantive behavior: legacy slug forms are normalized, the 16 Meji return native text in the requested language while the 240 combined return Portuguese editorial prose, citations come with a source page, and unverified counsel/liturgical fields are withheld and surfaced in an omitted list. This is exactly the extra context annotations cannot carry.
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?
Four sentences, front-loaded with verb + resource + key, followed by scope, content-type, provenance and omission rules. Dense but every sentence adds information; the parenthetical slug examples are the only near-redundant part.
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?
With no output schema, the description carries the burden and does well: it explains what text each Odu class returns, that citations include a page, and that fields lacking a verified source appear under omitted. It stops short of describing the response's overall field structure, which is a minor gap for a 2-param lookup.
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 only 50% (slug has no description), and the description compensates by giving slug examples and documenting legacy-form normalization. The locale parameter is covered by the schema enum description, and the description reinforces it by tying language choice to which Odus return native text. Slight gap in not naming the locale default.
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 ("Devolve") and resource (one of the 256 Odus) with an explicit key (slug), and the resource is inherently distinct from siblings like get_article, get_glossary and get_orixa. The description also carves out sub-scopes (16 Meji vs 240 combined), so an agent knows exactly what is retrievable.
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 use case (fetch a single Odu by slug, in a chosen locale) is implied by the slug examples and normalization note, but there is no explicit when-to-use / when-not statement and no sibling alternative (e.g. search_library or get_orixa) is named. Adequate but leaves routing to inference.
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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It adds useful content semantics (editorial profile, cited nomenclature, myths located in Studies) but says nothing about return format, pagination, or missing-slug behavior.
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 tightly packed sentences that front-load the operation and slug examples, then clarify what the payload contains. Dense but every clause earns its place; nothing is redundant.
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?
With no output schema, the description must describe the return, and it does: profile plus trilingual nomenclature and linked Studies. For a simple 2-param read-only lookup this is adequately complete, missing only error/empty-result behavior.
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 only 50% (slug is undocumented in the schema), and the description compensates by supplying concrete slug values ('exu', 'oxum', 'xango', 'iemanja'). It also reinforces the locale intent via 'no idioma pedido', which the enum already partially documents.
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 ('Devolve o perfil') and resource (an Orixá profile) and gives concrete slug examples. It also clarifies content scope (editorial profile; myths live in the Studies), which helps separate this from study/article tools, 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?
Usage is implied: fetch a single Orixá profile by slug, with linked Studies mentioned. There is no explicit 'use this when / use get_glossary or get_article instead when' routing, so an agent must infer the boundary from the sibling list.
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. | pt-BR |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully adds sort order and the returned fields (no output schema exists), but says nothing about pagination or the default/maximum result count, which matters for a list operation.
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 tight sentences with the core behavior (list published posts, newest first, fields returned) front-loaded. The trailing filter hint is short and relevant, though slightly softer than the leading content.
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?
Given 3 optional params, no output schema, and present annotations, the description covers the essentials of what is returned and how to filter. It still omits limit semantics (default 50, max 200) and pagination behavior, which an agent needs for a list tool.
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%: locale is documented, but limit and category are not. The description compensates partially by explaining that category acts as a filter, but it adds nothing about limit, pagination, or the meaning of the locale parameter beyond what the schema already states.
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 ('Lista') and resource ('posts publicados do blog'), plus sort order (newest first) and the fields returned (summary, category, tags, URL). This clearly separates it from the singular sibling get_article, though it never names an alternative 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?
The clause 'Filtre por categoria se quiser' signals that category filtering is optional, which is useful implied usage. However, it gives no guidance on when to use this list tool versus search_library or get_article for retrieval, leaving the routing decision to inference.
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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's contribution is the disclosure of what is returned (title, summary, public teaser in Markdown, sources) plus a real access limitation (full body is subscriber-only and unavailable here). That is meaningful context beyond the annotations, though nothing is said about volume, pagination or ordering.
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 tightly packed sentences with no filler; the core action and content shape are front-loaded, and the limitation is placed last. It is dense but every clause 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?
With no output schema, the description responsibly enumerates the returned fields (title, summary, teaser, sources) and flags the subscriber-only boundary. What is missing is minor: no indication of result size, ordering, or whether the teaser is always present.
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?
Only one optional parameter (locale) exists and schema description coverage is 100%, including enum values and default, so the schema carries full meaning. The description says nothing about locale or response language, which is acceptable at this coverage level but adds no extra value.
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+resource ('Lista os Estudos publicados') and goes further by specifying the citation modes (edition/page for Tratado, exact myth title for Prandi) and the two tracks (Odu/Orixá), so an agent understands the domain shape. It does not explicitly name or contrast itself with siblings like list_articles or get_article, so differentiation is left to inference.
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 rather than stated: the note that the full body is subscriber-only and 'não está disponível por esta ferramenta' signals a boundary, hinting the agent should look elsewhere for full content. However, no alternative tool is named and there is no explicit when-to-use/when-not framing.
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. | pt-BR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the return behavior: "Devolve os melhores resultados com a URL da página." It discloses what comes back and that results are ranked, though it omits the default limit of 12 / cap of 30 and any pagination notes.
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 sentences, both front-loaded: scope first, then the routing instruction. Every clause earns its place and nothing is repeated from the schema or annotations.
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 no output schema, the description supplies what an agent needs: the indexed corpora, the returned artifacts (ranked results plus page URL), and the decision rule for choosing it over the get_* tools. The only omission is limit defaults, which is minor.
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%: query and locale are documented in the schema (including examples), but limit is not. The description does not add syntax, format, or range meaning beyond what the schema already states, so the baseline of 3 for partial coverage 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?
States a specific verb ("Busca por termo") and resource ("toda a biblioteca"), then enumerates exactly what is indexed: the 256 Odus, Orixás across three spelling traditions, Estudos, blog and glossary. This makes it immediately distinguishable from the entity-specific get_* siblings.
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?
Explicitly instructs "Use antes de get_odu / get_orixa / get_article quando não souber o slug" – naming the alternatives and the exact condition that routes the agent here. This is textbook when-to-use guidance.
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.
get_article2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]get_glossary2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]get_odu2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]get_orixa2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]list_articles2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]list_studies2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]search_library2 fields changedInput schema / properties / locale / descriptionPrevious value: -"Idioma da resposta: pt-BR (base), en, es, de."New value: +"Idioma da resposta: pt-BR (base), en, es."Input schema / properties / locale / enumPrevious value: -[
- "pt-BR",
- "en",
- "es",
- "de"
-]New value: +[
+ "pt-BR",
+ "en",
+ "es"
+]get_articleget_glossaryget_oduget_orixalist_articleslist_studiessearch_libraryPersonalised 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.
