Igbo Atlas

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

The verb 'calculate' denotes a pure, deterministic computation over a supplied date, yet the annotations declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description makes no attempt to reconcile this – it never says what would be destroyed, what state changes, or why repeated calls would differ. The conflict between the described operation and the declared safety profile leaves the agent unable to trust either signal.

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 single front-loaded sentence with the resource and its constituent day names stated first and the input scope trailing. There is no filler, hedging, or restatement of the title.

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 one-optional-parameter computation with no output schema, the description covers what is computed and over what input domain. The remaining gap is the return shape – it names the four market days and the lunar month but does not say whether the response is a market-day name, an index, a lunar month label, or a combined object – which matters given there is no output schema to fall back on.

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 100% and the single parameter already documents the 'YYYY-MM-DD' format, an example, and the default-to-today behavior. The description adds only the framing 'any Gregorian date, past, present, or birthday', which confirms accepted range but adds no format or edge-case detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (calculate) and a precisely named resource: the Igbo 4-day market cycle with its four named days (Eke, Orie, Afọ, Nkwọ) plus the lunar month. The scope 'for any Gregorian date, past, present, or birthday' further pins it down, and no sibling tool (proverb, dictionary, lineage, nsibidi lookups) overlaps with this computation.

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 reader can infer this is the tool for converting a Gregorian date into the Igbo market cycle, and the phrase 'past, present, or birthday' signals valid input contexts. However, there is no explicit 'use this when…' clause, no mention of when another tool (e.g. search_cultural_archive) might be the better choice, and no stated exclusions or calendar-range limits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description frames the tool as a pure read ('Get a ... proverb'), but the annotations declare readOnlyHint=false and destructiveHint=true, so these two signals directly conflict. Even setting that aside, the description reveals nothing about whether the proverb is cached per day, how 'random' selection works despite idempotentHint=false, or what the openWorldHint means here.

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?

This is one sentence, with the action front-loaded and the return content appended; there is no padding. It could be tightened slightly, and the parenthetical name 'Ilụ' is helpful context rather than 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?

For a zero-parameter, output-schema-less tool, the description is almost adequate: it tells the agent what comes back (proverb, origin, meaning). However, it omits the randomness/daily-cache behavior and leaves the safety profile unresolved against destructiveHint=true, which is material for a tool an agent may call repeatedly.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the schema to document and nothing for the description to clarify. The description correctly implies a no-argument call by describing a single fixed retrieval.

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 verbal phrase 'Get a curated, authentic Igbo proverb of the day (Ilụ)' names a specific verb and resource, and it also previews the payload ('folkloric origin and philosophical meaning'). It never distinguishes itself from the sibling tool `search_proverbs`, so an agent cannot tell from this sentence alone which one to pick.

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 'of the day' implies that this tool returns a rotating pick, but the description never states when to use this tool instead of `search_proverbs` or `search_cultural_archive`, and it never says whether the agent should call it once per session. There is no when-not guidance and no mention of the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description reads as a pure retrieval of name attributes (gender, meaning, etymology, market-day alignment), yet annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true — an agent cannot tell whether calling this mutates state. The description does add useful return-content detail beyond the annotations, but discloses nothing about permissions, side effects, or result shape.

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 single front-loaded sentence that opens with the verb and resource before enumerating the returned attributes. The parenthetical example list and attribute list are dense but each item contributes domain specificity; no filler sentences.

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 does describe the returned fields well (gender classification, philosophical meaning, morphemic etymology, market-day alignment). It leaves gaps on result shape (single record vs. list), no-match behavior, and — critically for destructive-annotated tooling — whether the call is safe to repeat.

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 both parameters are documented, so the schema carries the parameter burden. The description adds domain framing for the 'name' input (given vs. baby vs. compound 'Aha Igbo' names) but says nothing extra about the optional gender filter's accepted values or matching behavior.

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 ('Look up') and a well-bounded resource ('traditional Igbo personal given names, baby names, and full compound names / Aha Igbo') with concrete examples ('Adaeze', 'Chidubem', 'Okeke'). The domain boundary implicitly separates it from siblings like lookup_nsibidi, search_proverbs, and calculate_market_day, but 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?

There is no when-to-use or when-not-to-use guidance and no named alternative. An agent must infer from the examples that this is the name-ontology lookup rather than search_dictionary or search_lineage, and nothing says what to do if the name is not found or whether partial matches are supported.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description's font/typography note is genuinely useful behavioral context beyond the annotations: it warns that plain-text glyph rendering is unreliable and instructs the agent to point users at the canonical web link. But the description frames this as a pure retrieval operation ("Look up") while annotations declare readOnlyHint=false and destructiveHint=true, a direct inconsistency about the operation's nature that the description never addresses.

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 core purpose is front-loaded in one tight sentence, and the supporting note is set off with a clear "Note:" marker. The note runs slightly long on typography detail, but every clause carries actionable information for the agent.

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 two-parameter lookup with no output schema, the description covers the query surface, the glyph-rendering caveat, and the recommended user-facing follow-up. The main omission is any statement about the result set shape or why the tool carries destructive/idempotent annotations that conflict with a lookup operation.

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 100%, so both parameters are already documented in the schema, establishing the baseline of 3. The description adds only marginal meaning, notably that "radical" is a valid query axis, which the schema expresses instead through the category filter example.

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 first sentence gives a specific verb ("Look up") and a precisely scoped resource ("indigenous Nsịbịdị ideograms, root radicals, and compound symbols"), plus the four lookup axes. The Nsịbịdị domain implicitly separates it from siblings like search_dictionary or lookup_name, but 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 by the lookup framing and the enumerated query axes, so an agent can infer when to reach for it. However, there is no explicit when-to-use/when-not guidance and no mention of how it differs from search_dictionary or search_cultural_archive, which are the closest alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description describes a plain retrieval operation ("Search ... articles"), yet the annotations declare readOnlyHint=false and destructiveHint=true. Nothing in the description explains what could be destroyed or why a search would mutate state, so the two signals are in direct conflict and an agent cannot trust either.

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 single front-loaded sentence listing the covered subject areas, with no filler. The topic enumeration is slightly list-heavy but each term plausibly helps an agent match a query.

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 only two fully documented parameters and no output schema, the description covers enough to call the tool. It is still silent on result behavior (ordering, pagination, corpus boundaries) and on the safety profile the annotations flag, which leaves meaningful gaps for a search 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 coverage is 100%, with both 'query' and 'category' fully documented including examples, so the schema carries parameter meaning. The description only restates the topical domain (rituals, festivals, cosmology) without adding syntax, matching, or scoping rules beyond 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 gives a specific verb ("Search") and a well-defined resource ("peer-reviewed encyclopedic articles") scoped to Igbo cultural topics, which implicitly separates it from siblings like search_dictionary and search_proverbs. It stops short of naming any sibling explicitly, so differentiation is inferred rather than stated.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of how this differs from the six sibling search/lookup tools. An agent must guess whether a query for 'Ọfọ' belongs here, in search_dictionary, or in search_proverbs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description adds useful behavioral context beyond the annotations: the dictionary is "living" (content changes over time) and covers dialect variants and tonal diacritics, so the agent knows results may be multi-variant. However, the annotations declare destructiveHint=true, readOnlyHint=false and openWorldHint=true for what is framed here as a pure lookup, and the description never addresses that gap, nor does it mention result limits or pagination. With annotations present the bar is lower, so a 3 reflects real but partial added context.

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, front-loaded with the core action and followed by the routing rule; nothing is redundant. The example-word list is somewhat long, but each item is short and the list genuinely helps an agent match user queries to this tool, so it earns its space.

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 two-parameter lookup with no output schema, the description effectively previews the return payload (definitions, classifications, kinship titles, tone markings, dialect variants, example sentences), which is the main thing an agent needs before calling. It leaves the destructive/openWorld annotations and any result-size expectations unexplained, so it is complete but not airtight.

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%, so both parameters are already documented in the schema, and the description adds little parameter-level meaning. Only indirectly does it hint at schema semantics — the mention of tone marks and dialect variants aligns with the tone-optional `word` field and the `dialect` filter — but it never explains the dialect enumeration or fallback behavior when a dialect has no entry.

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 gives a specific verb and resource ("Search the living Igbo dictionary (Ọkọwa Okwu)") and enumerates the content it indexes: definitions, grammatical classifications, kinship titles, tonal diacritics, dialect variants, example sentences. That is far more informative than a restatement of the name. It does not explicitly contrast itself with the dictionary-adjacent siblings (lookup_name, search_proverbs, lookup_nsibidi), which keeps it just 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?

It states an explicit routing rule — "USE THIS FIRST for questions like 'what does [word] mean' or general Igbo vocabulary" — plus concrete query examples (ada, okpara, chi, mmiri). The word "general" implicitly carves out the specialized sibling lookups, but no sibling is named as an alternative, and no exclusion for proverb/name/nsibidi queries is spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description frames the tool as "Explore" and the name is search_lineage, both implying a read-only search. The annotations instead declare destructiveHint=true and readOnlyHint=false, which contradicts the description's framing. No warning about destructive behavior is provided.

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 single front-loaded sentence with no redundant wording. It is appropriately sized for a two-parameter search tool.

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 only two parameters and full schema coverage, the basic call is technically possible. However, the description omits any disclosure of the destructive behavior declared by annotations, leaving an agent unable to understand the tool's consequences safely.

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%, so both query and level are fully documented in the schema. The description's enumeration of towns, villages, kindreds, and family compounds loosely aligns with the level filter but adds no syntax or mapping beyond 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?

States a specific verb ("Explore") and resource ("ancestral lineage and kinship hierarchy") and enumerates the relevant Igbo levels: towns, villages, kindreds, and family compounds. It does not explicitly distinguish itself from sibling search tools, but the purpose is clear.

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 no when-to-use or when-not-to-use guidance and does not mention alternatives such as search_cultural_archive or lookup_name. Usage is only implied by the topic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description frames this as a search that returns proverb content, which contradicts annotations declaring destructiveHint=true and readOnlyHint=false. For a search operation, those annotations are inconsistent with the described behavior, so the agent cannot reliably infer the tool's side effects.

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 the core action and then the return contents. It is appropriately sized and contains no unnecessary wording.

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 search facets and the returned proverb components, which is useful because there is no output schema. However, it omits result limits, matching behavior, and how search results are structured, and it does not resolve the conflicting destructive annotations.

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%, so both parameters are already documented in the input schema. The description restates the search facets but adds no syntax, matching behavior, or usage constraints beyond what the schema provides.

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: searching Igbo proverbs by theme, life situation, or keyword. It is clearly distinct from a random-proverb tool, though it does not explicitly name siblings like get_random_proverb or search_cultural_archive.

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 implies when to use the tool by listing search facets such as theme and keyword, but it gives no explicit when-to-use or when-not-to-use guidance. It also does not route the agent toward alternatives such as get_random_proverb or search_cultural_archive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.