African intelligence infrastructure for AI apps, developers, and data products via MCP.
Find African dishes associated with a specific African country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. The verb 'Find' suggests a read-only lookup, and the wording communicates scope, but it does not disclose output format, exact-versus-partial country matching semantics, behavior for non-African country names, or empty-result handling. It is not misleading, just under-specified.
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 brief sentence that front-loads the verb and object. There is no redundant material, and every word contributes to defining the tool's 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?
For a one-parameter tool with no output schema, the core call is simple, but 'associated with' is ambiguous—it could mean country of origin, common availability, or cultural association. The description also does not help an agent distinguish this from find_foods_by_country, so an agent could call it but might not handle edge cases confidently.
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, 'country', is already fully documented in the schema with 'Country to search for', so schema coverage is 100%. The tool description adds no extra detail about expected country name formats, case sensitivity, or valid values, leaving it at the baseline 3.
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 names a specific action ('Find'), a specific resource ('African dishes'), and a specific criterion ('associated with a specific African country'). It distinguishes from ingredient- and region-based sibling tools, though it does not clarify how 'dishes' differs from 'foods' in find_foods_by_country.
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 'with a specific African country' implies this tool is for country-based dish lookups. However, there is no explicit guidance about when to prefer this over sibling tools like find_dishes_by_region or find_dishes_by_ingredient, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find African dishes that use a specific ingredient or food.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient | Yes | Ingredient or food to search for |
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 only restates the core purpose and does not reveal how matching works, whether results are returned as a list, or whether there are any filtering or exact-match behaviors.
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, front-loaded sentence with no redundant words. It conveys the essential purpose efficiently.
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 tool, the description is minimally viable, but it lacks guidance on matching behavior and return format. With no output schema and no annotations, a bit more context about what the agent can expect from the results would improve completeness.
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 ingredient parameter already has a clear description. The tool description adds the context that the search targets African dishes, but it does not add meaning beyond the schema for the parameter itself.
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 ('Find'), a resource ('African dishes'), and the selection criterion ('use a specific ingredient or food'). This distinguishes it from sibling tools like find_dishes_by_country and find_dishes_by_region, which filter by different attributes.
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 tool should be used when searching for dishes by an ingredient, but it does not explicitly state when not to use it or mention alternative tools. With multiple sibling search tools, the lack of explicit routing guidance leaves some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find African dishes associated with a geographic region such as West Africa or Central Africa.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | African region to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read-only lookup ('Find') and names the entity returned, but it does not disclose edge-case behavior such as empty results, partial matches, or the exact return 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 states the action and scope immediately with no filler or repeated schema information.
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-parameter lookup the description is mostly sufficient, but with no output schema it leaves the return format unstated, and it does not route between the closely related sibling tools. A sentence naming the alternative country- or food-based tools would make it 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 100%, so the baseline is 3. The description adds value by giving concrete examples of valid region values ('West Africa or Central Africa') beyond the schema's generic 'African region to search for'.
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 ('Find'), a resource ('African dishes'), and a scoping dimension ('geographic region') with concrete examples ('West Africa or Central Africa'). This makes it distinguishable from siblings like find_dishes_by_country and find_foods_by_region, even without naming 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?
Usage is implied: use this tool when the request asks for African dishes by region. However, it provides no explicit when-not-to-use guidance or mentions overlapping alternatives such as find_dishes_by_country or find_foods_by_region, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find African foods by category such as grain, root, fruit, legume, seed, tuber, vegetable, or leafy_vegetable.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Food category to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It describes a simple lookup operation with no apparent side effects, but it does not disclose output shape, handling of unknown categories, or whether the listed categories are a complete or open set. That is a moderate gap for an unannotated tool.
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 tight sentence that leads with the action and resource, then gives useful examples. There is no redundant phrasing or 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?
The tool is simple with one required parameter, so the description is mostly adequate. However, with no output schema and no note on invalid, empty, or partial category matches, an agent has to infer the return behavior. The examples help, but the description could be more 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?
The schema already documents the category parameter with 100% coverage, but the description adds concrete example values such as grain, root, fruit, and leafy_vegetable. Since there is no enum in the schema, these examples materially help the agent provide a valid input, though 'such as' leaves some ambiguity about the full allowed set.
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 (find) and resource (African foods), and the example category list clarifies the intended dimension. It does not explicitly contrast with sibling tools like find_foods_by_country or search_african_foods, but 'by category' is a distinct and understandable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when searching for foods by category. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions such as searching by country, region, or ingredient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find African foods associated with a specific African country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country to search for |
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 only restates the purpose and provides no information about return format, matching behavior, unsupported countries, or edge cases. It does not contradict annotations, but it also reveals no behavioral detail beyond the tool's stated action.
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 filler. It front-loads the action and resource, and every word contributes meaning.
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 tool with one required parameter and no output schema, this is minimally viable: it states what the tool finds and what input is expected. However, it does not explain what the output looks like, how to handle unknown or non-African countries, or when a sibling tool would be a better fit, so the description leaves meaningful 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 describes 'country' only as 'Country to search for', while the tool description adds the meaningful constraint that it should be a specific African country. This helps the agent pass a valid value even though the schema itself does not enforce that restriction.
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 clear resource ('African foods') with a scope qualifier ('associated with a specific African country'). This distinguishes it from siblings like find_foods_by_region and find_foods_by_category, and from find_dishes_by_country, which targets dishes rather than foods.
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 explicit guidance about when to choose this tool over its siblings. It implicitly suggests country-based lookup, but it does not mention alternatives like find_foods_by_region, find_foods_by_category, or find_dishes_by_country, nor when one would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find African foods associated with a geographic region such as West Africa or Central Africa.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | African region to search for |
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, and 'Find' does convey that this is a non-mutating lookup operation. However, it discloses nothing about return shape, result limits, or behavior when no foods match a given region. For a simple read tool the surface is small, but with zero annotation support the description could reasonably state what the caller gets back.
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 14-word sentence with the verb and resource front-loaded and the clarifying examples at the end. Every word earns its place, and the length is proportionate to a one-parameter tool. There is no filler or repetition of schema 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?
For a one-parameter lookup with full schema coverage, an agent can successfully invoke the tool with just this description plus the schema. What is missing is guidance on the foods-vs-dishes sibling overlap and any indication of the return value, since there is no output schema and no annotation coverage. It is adequate but does not fully equip the agent to disambiguate among related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the region parameter is already documented as an 'African region to search for'. The description adds value above the schema by giving concrete value examples ('West Africa or Central Africa') that clarify the expected granularity and format of the region string.
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 names a specific verb ('Find'), resource ('African foods'), and scope ('associated with a geographic region'), which is clearly distinct in intent. The concrete examples 'West Africa or Central Africa' distinguish region-based lookup from country- or ingredient-based siblings. However, it does not explicitly differentiate from the near-twin find_dishes_by_region, leaving the foods-vs-dishes distinction to the tool names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The region examples imply the intended input scale (broad regions, not countries or ingredients), which provides some usage guidance. There is no explicit statement of when to prefer this tool over find_foods_by_country or find_dishes_by_region, and no exclusions are mentioned across the 12 sibling tools. The guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return aggregated AfriResolve usage intelligence, including total activity, demand signals, popular queries, tool usage, and recurring knowledge gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows returned in each intelligence list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the result is aggregated and names the included intelligence components, implying a read-only analytics operation. It does not mention freshness, caching, or output structure, but it gives a reasonable behavioral picture for a getter.
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 wasted words. It states the action, the resource, and the specific content categories efficiently, earning every part of the 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?
The description provides enough information to select and invoke the tool correctly: it is a zero-required-parameter analytics getter with an optional row limit, and it names the main output categories. It lacks exact return field names or temporal scope, but for this low-complexity tool it 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?
The only parameter, limit, is fully explained in the input schema as the maximum rows per intelligence list, so the schema carries the semantic weight. The description adds no additional parameter-level detail, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return'), a clear resource ('AfriResolve usage intelligence'), and enumerates the categories of data included. It is immediately distinguishable from sibling tools, which all operate on food/dishes rather than system usage analytics.
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 context is implied rather than explicit: the tool clearly returns usage analytics while siblings perform food lookups, but the description never states when to choose this over alternatives or when not to use it. It is inferable but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all standardized African dish records in the AfriResolve knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It communicates that the tool returns all standardized dish records, but it does not clarify output shape, ordering, pagination, potential payload size, or any other behavioral characteristics. This is a noticeable gap 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?
The description is a single, clear sentence with no filler or repetition. It front-loads the main action and resource immediately, making it easy for an agent 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 zero-parameter list operation, the description is minimally viable: it tells the agent exactly what will be listed. However, it omits any detail about the returned records' structure, list size, or pagination behavior, and it does not address the potential confusion with sibling list_african_foods. These gaps keep it from being fully 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?
The tool has zero parameters, and the schema documents this completely with 100% coverage. The description adds no parameter-specific detail, but none is needed; the baseline of 4 is appropriate because there is no parameter ambiguity to resolve.
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 names a specific verb ('List'), a clear resource ('all standardized African dish records'), and a location ('AfriResolve knowledge base'). It is understandable and correctly indicates a read-only enumeration operation, though it does not explicitly differentiate itself from the similarly named sibling list_african_foods.
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 no guidance on when to use this tool versus the many sibling tools such as find_dishes_by_country, find_dishes_by_ingredient, or resolve_african_dish. There are no explicit exclusions or alternative routing hints; the intended usage is only implied by the word 'List all'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all standardized African food records in the AfriResolve knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates a read-style listing operation and the scope of the dataset, but does not mention pagination, result size limits, ordering, or return format.
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 no filler, and the core scope is front-loaded right after the verb. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, invocation is trivial, but the description does not explain the output shape or differentiate from list_african_dishes. Since there is no output schema, the description could have provided more closure about return values.
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 has zero parameters and the schema covers 100% of the empty parameter space, so there is no parameter burden for the description to carry. The baseline of 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?
States a clear verb ('List') and resource ('all standardized African food records') in the AfriResolve knowledge base. It conveys unfiltered enumeration, but does not explicitly distinguish it from close siblings like list_african_dishes or the filtered find_foods_by_* 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 word 'all' implies this tool is for retrieving the complete unfiltered set, and the sibling names suggest filtered alternatives. However, the description provides no explicit when-to-use/when-not-to-use guidance and does not name any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and rank African food records by relevance across names, aliases, categories, countries, regions, descriptions, uses, and nutrition information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text for ranked African food discovery |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates search and relevance ranking, and it enumerates the fields searched, which is useful. However, it does not disclose output limits, ordering details, pagination, or whether this is a read-only operation beyond the implication of 'search'.
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, well-structured sentence that front-loads the core behavior and packs relevant search-scope details without redundancy. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter search tool with no output schema, the description covers the essential behavior, search scope, and ranking intent. It could be slightly more complete by stating what the returned ranked result set looks like, but the current definition is sufficient for an agent to invoke it correctly.
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 query parameter is already documented, but the description adds meaningful context by listing the specific fields the query searches across: names, aliases, categories, countries, regions, descriptions, uses, and nutrition information. This goes beyond the generic 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?
The description states a specific verb ('Search and rank') and resource ('African food records'), and clarifies that results are ordered by relevance across multiple attributes. This distinguishes it from sibling find/list tools, which are filtered lookups rather than ranked searches.
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 what the tool does but gives no guidance on when to choose it over siblings like search_african_foods, find_foods_by_country, or find_foods_by_category. There is no mention of alternatives, exclusions, or conditions that would select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an African dish name or alias and return standardized dish information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The African dish name or alias to resolve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full behavioral burden, but it only promises to 'resolve' an input and return 'standardized dish information'. It does not disclose behavior for unknown names, ambiguous matches, partial/alias matching, case sensitivity, or what fields the standardized information contains.
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 no filler; the operation, target, and outcome are front-loaded. Every part of the sentence earns its place, and 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?
This is a low-complexity single-parameter lookup with no output schema, and the description covers the essential query and result promise. However, it omits edge-case behavior (unknown or ambiguous dishes) and the shape of 'standardized dish information', so it is adequate but not fully 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 description coverage is 100% for the only parameter, query, and the description essentially repeats the schema text. The phrase 'African dish name or alias' adds no new format, normalization, or example guidance beyond what the schema already provides, so the baseline of 3 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 uses a specific verb ('Resolve') and resource ('African dish name or alias') and states the output ('standardized dish information'). This clearly differentiates it from siblings like find_dishes_by_country, search_african_foods, and especially resolve_african_term, which resolves a term rather than a dish.
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 when-to-use or when-not-to-use guidance is provided. The intended use—given a known dish name or alias, not browsing by country or ingredient—is implied by the description and sibling names, but the tool does not state that it should be preferred over search/list/find variants for aliases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an African word or food term and return standardized information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The African term to resolve |
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 only says the tool 'return[s] standardized information,' but does not explain what resolution means, how ambiguous or unknown terms are handled, whether it accepts partial matches, or what the standardized output structure contains.
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, focused, front-loaded sentence with no redundant phrases. It could be slightly more informative, but the structure itself is clean and efficiently conveys the core operation.
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 no annotations, the description should explain what 'standardized information' actually includes, but it does not. The tool also lacks any guidance about term types, edge cases, or relationship to sibling tools, leaving the agent under-informed for correct selection and interpretation.
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 already fully described in the schema as 'The African term to resolve.' The description adds no extra meaning beyond that, so the baseline score of 3 applies due to 100% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('resolve'), a resource ('African word or food term'), and an outcome ('return standardized information'). This is clear on its own, but it does not distinguish itself from the sibling tool resolve_african_dish, which likely has substantial overlap.
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 guidance on when to use this tool versus resolve_african_dish, search_african_foods, or find_foods_by_country. The description implies a simple lookup use case but provides no exclusions, alternatives, or contextual conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the AfriResolve African food knowledge base across names, aliases, categories, countries, regions, descriptions, uses, and nutrition information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text for discovering African food records |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of conveying behavior. 'Search' clearly implies a read-only lookup, and the list of searched fields adds useful context. However, it does not disclose potential edge cases such as pagination, result limits, or whether matches are fuzzy or exact.
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 focused sentence with no filler. The main action and target resource appear first, followed by a clear enumeration of searchable fields. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema and no annotations, the description is reasonably complete. It identifies the resource, the query scope, and the major fields searched. The main gap is not explaining how this broad search compares with the many targeted sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the query parameter well, but the description adds meaningful layers by explaining that the query applies across names, aliases, categories, countries, regions, descriptions, uses, and nutrition information. This exceeds the schema's generic 'search text' wording.
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 ('Search') and a specific resource (the AfriResolve African food knowledge base), and enumerates the fields it covers. This distinguishes it from the more targeted sibling tools like find_dishes_by_country or find_foods_by_category, which are limited to particular dimensions.
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 explicit guidance on when to use this tool versus its siblings. It does not mention that this is the broad free-text search option, nor does it say to use the find_* tools for structured lookups. The existence of many sibling tools makes this absence more significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
find_dishes_by_countryfind_dishes_by_ingredientfind_dishes_by_regionfind_foods_by_categoryfind_foods_by_countryfind_foods_by_regionget_afriresolve_intelligencelist_african_disheslist_african_foodsrank_african_foodsresolve_african_dishresolve_african_termsearch_african_foodsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Agent-first data marketplace — AI agents search, purchase, and sell datasets via MCP.
Let AI agents query data and act across all your business apps via MCP.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Add one secure layer between your agents and this server.
rank_african_foods and search_african_foods have nearly identical descriptions and field lists, making their boundary unclear. find_dishes_by_country vs find_foods_by_country and find_foods_by_country vs find_foods_by_region also create overlapping selection paths, though the facet descriptions help somewhat.
All tools follow a consistent snake_case verb_noun pattern: find_X_by_Y for faceted lookups, list_african_X for enumerations, resolve_african_X for normalization, and search/rank/get for other operations. There are no mixed naming conventions or camelCase deviations.
Thirteen tools is within a reasonable range for a food and dish knowledge base. However, rank_african_foods and search_african_foods largely duplicate each other, and some find_* variants could be consolidated, so not every tool fully earns its place.
The set covers listing, faceted lookup, name resolution, and food search/ranking well, but dishes lack a general keyword search tool equivalent to search_african_foods. There is also no dish category filter, so agents cannot search across all dish metadata without enumerating the full list.
