AfriResolve

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

No annotations are provided, so the description carries the burden. It accurately describes a read-only search operation with no side effects, but offers no additional behavior details such as return format, error conditions, or limits. This is adequate for a simple lookup.

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 a single, concise sentence that conveys the core purpose immediately. No unnecessary words or tangential 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?

Given the simplicity of the operation and absence of an output schema, the description covers the essential context. It does not explicitly state the return type (e.g., a list of dish names), but 'Find' implicitly suggests returning matching dishes.

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 has one property 'country' with description 'Country to search for', which is minimally informative. While the top-level description clarifies it must be an African country, the parameter description adds little beyond the name and does not specify format or examples.

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 action ('Find') and the resource ('African dishes') with a specific filter ('associated with a specific African country'). It distinguishes this from sibling tools like find_foods_by_country by specifying 'dishes'.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it does not mention when to prefer this over similar sibling tools (e.g., find_foods_by_country), leaving selection to inference from the name.

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?

With no annotations and no behavioral details in the description, the tool does not disclose whether it is read-only, what output format to expect, or any potential limitations. The full burden falls on the description, which only states the basic search purpose.

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 a single clear sentence with no unnecessary words or redundant details. It is well-structured and immediately understandable.

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 tool is simple with one parameter and no output schema, but the description does not mention what the returned results will look like or any additional context such as whether results include dish names, countries, or recipes. It is adequate but not richly contextual.

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 fully covers the single parameter with a description that matches the tool's purpose. The description adds no additional nuance beyond the schema, so it meets the baseline but does not exceed it.

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 ('Find') and resource ('African dishes') with a clear search criterion ('a specific ingredient or food'). This distinguishes it from sibling tools that search by country, region, or food name.

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—when searching by ingredient—but does not explicitly mention alternative tools or state when not to use it. Usage guidance is implicit rather than explicit.

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?

With no annotations, the description carries the full burden. It only states that it finds dishes by region but does not disclose what the tool returns (e.g., list of dishes), whether it is a read-only operation, or any side effects. The phrasing 'associated with' is vague about the exact matching 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?

The description is a single, tightly worded sentence that conveys the essential information without unnecessary detail. It is easy to parse and immediately actionable.

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 is minimal and lacks context about the output format (e.g., list or single result), the possibility of empty results, or any constraints. Given that there is no output schema, this omission leaves the tool's behavior under-specified for an agent.

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 parameter 'region' has a descriptive schema ('African region to search for') and the tool description enriches it with concrete examples ('West Africa or Central Africa'). This provides clear guidance on expected values beyond the basic 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 uses a specific verb ('Find') and clearly identifies the resource ('African dishes') and the scope ('by region'). It is distinct from sibling tools like find_dishes_by_country and find_dishes_by_ingredient, making its purpose unambiguous.

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 mentioning 'geographic region' and providing examples, but it does not explicitly state when to prefer it over alternatives. There is no direct comparison or condition like 'use this if you have a region rather than a country'.

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?

There are no annotations to offload behavioral disclosure, so the description must carry the full burden. It does not mention side effects, whether the operation is read-only, or what the return format is. While 'find' implies a read operation, this is not explicitly stated, and the output shape is left undefined.

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 a single, concise sentence that directly states the purpose and gives examples. No redundant information or fluff; it is well-structured 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?

Given the simplicity of the tool (single parameter, no output schema), the description is adequate for basic intent, but it lacks details about the result format (e.g., list vs. single item, ordering, pagination). Since there is no output schema to fill this gap, the description could be more complete by mentioning what the output looks like.

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 parameter 'category' has a basic schema description ('Food category to search for'), but the tool description adds valuable context by listing example categories (grain, root, fruit, legume, etc.). This effectively defines the expected input domain beyond the bare schema, though it does not provide an exhaustive list or constraints.

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 tool's purpose: finding African foods by category. It names the resource (African foods), the action (find), and provides concrete examples of accepted categories (grain, root, fruit, etc.), leaving no ambiguity about what the tool does.

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 does not explicitly state when to use this tool versus alternatives (e.g., find_foods_by_country). While the category-based scope is implicit, no direct guidance or comparison to sibling tools is provided, leaving the selection criteria unstated.

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 gives no indication of side effects, read-only nature, or any behavioral details. With no annotations to supplement, the description fails to disclose whether this operation is safe and non-mutating.

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 extremely concise with no redundant words, directly stating the tool's function in a single sentence.

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 single-parameter tool, the description is adequately complete. It does not specify output format, but given the simplicity and lack of an output schema, this absence is acceptable. It could mention that results are limited to African foods, but that is already implied.

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 'country' parameter is described as 'Country to search for' in the schema, and the tool description adds that it should be an African country, providing useful context beyond the schema. The singular parameter is 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?

The description clearly states that the tool finds foods associated with a specific country, and specifying 'African' distinguishes it from generic food finders. It is distinct from sibling tools like find_dishes_by_country and find_foods_by_region.

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?

No guidance is provided on when to use this tool as opposed to alternatives like find_dishes_by_country or find_foods_by_region. The description does not explain the distinction between foods and dishes or between country and region.

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 implies a read-only search operation, but it does not explicitly state side-effect-free behavior, output format, or error handling. Since annotations are empty, the description carries the full burden and provides only minimal behavioral information.

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 a single, concise sentence with no unnecessary words. It directly conveys the tool's purpose and includes an illustrative example, making it easy to parse quickly.

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 one-parameter search tool, the description is sufficient to understand its function. It would benefit from mentioning the nature of the returned data, but given the lack of an output schema and the simplicity of the operation, the description does not leave critical 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?

The schema provides a description for the 'region' parameter, giving 100% coverage. The tool description supplements this with concrete examples ('West Africa', 'Central Africa'), making the parameter's meaning clearer than the schema alone.

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 'Find' and the object 'African foods' with a specific filter by geographic region. This distinguishes it from sibling tools like find_dishes_by_region (which targets dishes) and find_foods_by_country (which targets countries).

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 provides a clear use case (finding foods by region) and gives examples of valid values, but it does not explicitly mention when to choose this tool over the many sibling search tools (e.g., find_dishes_by_region, find_foods_by_category).

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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation (returning data) and does not warn about side effects, permissions, or rate limits. The term 'return' strongly suggests a safe get operation, but without explicit statements or annotations, transparency is only moderate.

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 a single, clear sentence with no redundant words. It efficiently conveys purpose and scope without unnecessary elaboration.

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 the tool's simplicity (no output schema, one optional parameter), the description covers the key aspects: what is returned and the parameter's effect. It does not specify the default behavior when 'limit' is omitted or the exact output format, but these are minor omissions for a straightforward get 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?

The single parameter 'limit' is fully described in the schema ('Maximum number of rows returned in each intelligence list'), achieving 100% schema coverage. The description adds meaningful context by clarifying that the limit applies per intelligence list, which is useful for agents. Thus it slightly exceeds the baseline.

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 a specific verb ('Return') and a distinct object ('aggregated AfriResolve usage intelligence'), enumerating the contents (total activity, demand signals, popular queries, tool usage, knowledge gaps). This clearly differentiates it from the sibling tools, which focus on finding, resolving, or listing specific dishes or terms.

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 (when aggregated usage intelligence is needed) but does not explicitly state when not to use it or mention alternatives. Since the purpose is unambiguous and distinct from siblings, the lack of explicit exclusions is a minor gap, so a 4 is appropriate.

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?

Annotations are empty, so the description carries the full burden of behavioral disclosure. It conveys only that the tool returns a complete unfiltered listing and that records are 'standardized', but it does not disclose the return format, pagination behavior, whether unstandardized or unclassified records are excluded by the 'standardized' filter, or any performance implications of listing all records. For an unannotated tool, this is a significant gap.

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 sentence with zero redundancy, front-loading the verb 'list' and the resource immediately. Every word earns its place, and no filler or irrelevant detail is present.

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 tool is simple (zero params), but there is no output schema, so the description should compensate by describing the shape of a dish record or the return format. It does neither, and it leaves the meaning of 'standardized' undefined. It is minimally adequate for a simple list tool, but the lack of any return-format disclosure leaves an agent guessing about the result structure.

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 schema covers everything (100% coverage trivially) and there is nothing for the description to explain. Per the rubric, a zero-parameter tool earns a baseline of 4; the description adds no parameter information, which is acceptable since no parameters exist to document.

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 ('list'), a specific resource ('standardized African dish records'), and a scope ('all... in the AfriResolve knowledge base'), which clearly distinguishes it from the filtered find_dishes_by_country, find_dishes_by_ingredient, and find_dishes_by_region siblings. It stops just short of a 5 because it does not explicitly name any sibling it is not, leaving differentiation to inference from the 'all' wording.

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?

No guidance is given on when to use this tool versus its siblings. The description never mentions that find_dishes_by_* and search_african_foods are the filtered alternatives, nor does it state when a full unfiltered listing is appropriate. The 'all' wording implies unfiltered usage, but this is only implicit and no exclusions or alternatives are named.

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?

Annotations are empty, so the description is the sole source of behavioral information. It states the operation is a list, but it does not disclose pagination, sorting, limits, or the shape of the returned records. For a read-only listing tool with no annotations, this is a minimal disclosure.

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, well-formed sentence with no redundancy. It is appropriately concise and front-loaded with the core action and scope.

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 the tool's simplicity (no parameters, no output schema), the description provides the essential purpose but omits return format details and any constraints on the list size or ordering. An agent might not know whether it receives full records or just names.

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?

There are zero parameters, so there is nothing to explain. The description adds no parameter-specific information because none is needed. Baseline 4 applies.

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 a specific action ('List') and a specific resource ('all standardized African food records in the AfriResolve knowledge base'), which distinguishes it from the filtered search siblings like find_* and search_african_foods. It unambiguously indicates a comprehensive, unfiltered listing.

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 the use case is retrieving the complete set of foods without filters, but it does not explicitly mention alternatives or when not to use other tools. It is clear but leaves the agent to infer that filtered searches belong to siblings.

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?

No annotations are provided, so the description carries the burden. It indicates a read-only search/rank operation with no side effects. While not explicitly stating 'read-only', the nature of the tool implies it, and no destructive behavior is suggested.

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 concise, one sentence, and front-loads the primary action (search and rank) followed by the specific fields. No redundant content or fluff.

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 search tool with one parameter and no output schema, the description thoroughly covers what the tool does (ranking across multiple attributes). It provides enough context for an agent to decide when to use it without needing additional details.

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 single parameter 'query' is described as 'Search text for ranked African food discovery', which adds meaningful context beyond the schema's raw type. This clarifies that the input is free-text search terms, and the 'ranked' aspect hints at the output ordering.

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 a specific verb (search and rank) and resource (African food records) with a detailed scope of fields (names, aliases, categories, etc.). It distinguishes itself from siblings like list_african_foods by emphasizing ranking by relevance.

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 this tool (when ranking by relevance is desired) but does not explicitly mention alternatives or exclusion conditions. The naming and description make the use case clear enough without direct comparison to siblings.

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?

Annotations are empty, so the description carries the full burden. It implies a read-only lookup and return of information, but does not disclose potential normalization, canonicalization, error behavior, or whether it ever falls back to partial matching. It is not misleading, but it is minimal.

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 one concise sentence with no redundant words or filler. It front-loads the action and resource, making it easy to scan.

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 tool is simple with one parameter and no output schema, but the description leaves the return format vague as 'standardized dish information' and does not specify what fields are included. It is adequate for a basic resolver but lacks detail an agent might need to confidently use the result.

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 single 'query' parameter is described in the schema as 'The African dish name or alias to resolve', which fully covers its meaning. The tool description repeats this but adds no extra nuance; still, the parameter is simple and clearly specified.

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 a specific action ('Resolve') and resource ('African dish name or alias'), and indicates the result ('standardized dish information'). It is distinct from sibling search/find/list tools, which focus on lookup by criteria rather than resolving a specific name or alias.

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?

No guidance is given about when to use this tool versus the many siblings such as search_african_foods, find_dishes_by_country, or resolve_african_term. The intended use case is only implicit in the verb 'resolve', with no explicit conditions or exclusions.

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?

No annotations are present, and the description does not disclose whether the operation is read-only or has side effects. There is no mention of output behavior, errors, or side effects such as caching or state changes.

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 a single short sentence, but it lacks necessary details. It is concise in wording but not in conveying substantive information, leaving the reader with many questions.

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?

There is no output schema and no description of what 'standardized information' includes. The tool is incomplete for an agent to understand what to expect in the response, such as fields, format, or possible status codes.

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 only parameter 'query' is described as 'The African term to resolve' which is minimally informative. It does not specify expected format (e.g., single word, phrase, language), possible values, or any constraints beyond minLength.

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 it resolves an African word or food term but 'resolve' is ambiguous and does not clarify whether it means lookup, disambiguation, or translation. It does not differentiate from the sibling tool resolve_african_dish, which likely handles dish names specifically.

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?

No guidance is provided on when to use this tool versus alternatives like search_african_foods, find_foods_by_country, or resolve_african_dish. The description lacks any context for selection criteria.

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 indicates the action is a read-only search but does not disclose result format, pagination, limits, or error behavior. With no annotations provided, some behavioral details are missing, though the core search behavior is clear.

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 a single, compact sentence that conveys the purpose and scope without unnecessary words or repetition.

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 gives sufficient context for a simple search tool, but it does not mention output shape or any constraints such as maximum results. Given its simplicity and clear scope, this is adequate though not exhaustive.

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 description for the 'query' parameter is basic ('Search text for discovering African food records'), but the main description adds meaningful context by specifying that the query applies across names, aliases, categories, countries, regions, descriptions, uses, and nutrition information.

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 'Search' and the specific resource 'AfriResolve African food knowledge base', and enumerates the fields searched (names, aliases, categories, countries, regions, descriptions, uses, nutrition). This distinguishes it from the more specific find/list/resolve sibling tools.

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 a general cross-field search use case, which contrasts with the more targeted sibling tools (e.g., find_by_country, list_african_foods). However, it does not explicitly state when to prefer this tool over those alternatives, so guidance is slightly implicit.

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