Mansa African Markets

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety traits. It adds value by explaining the two lookup modes (country vs. single code) and the types of identifiers returned, giving the agent useful context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that efficiently communicates the tool's scope, search modes, and an example. No redundant or filler 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 simple tool with two optional parameters and no output schema, the description is mostly complete. It does not state behavior when both parameters are omitted, which is a minor gap, but the overall usage is clear enough for an agent to invoke 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?

The schema already covers both parameters with descriptions (100% coverage). The description reinforces their meaning by mentioning 'country' and 'single bank code', and adds a concrete example ('058 = GTBank') that clarifies the format of the code parameter.

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: 'Look up African banks and mobile-money institutions' with specific search criteria (country or code). It includes concrete data types (NIBSS sort codes, SWIFT/BIC, USSD) and an example, making it distinct from sibling market-data 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 when to use the tool by specifying two filtering modes (by country or by single code). It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly for exchange/financial data, so the context is sufficiently clear.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying the returned data fields, but it does not disclose additional behaviors like pagination, rate limits, or special error handling. This is adequate but not exceptional.

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. It front-loads the action ('Get detailed data') and then packs the scope ('one specific African exchange by ID') and expected content ('index value, change, trading hours, currency, and status') with zero wasted words.

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 (one parameter, no output schema), and the description provides a clear list of return fields, making it self-contained for an agent to understand what it will receive. It could be slightly more explicit about the meaning of 'status' or the exact return shape, but overall it is sufficiently 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 input schema is fully self-documented: the 'exchange' parameter has a clear description and an exhaustive enum with all 13 options. The description's 'by ID' adds no new semantic value beyond what the schema already provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and clearly identifies the resource ('detailed data for one specific African exchange by ID'). It also lists concrete data fields (index value, change, trading hours, currency, status), which distinguishes it from sibling tools like get_african_exchanges (plural) and get_african_exchange_movers.

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 'one specific African exchange' implicitly communicates that this tool is for single-exchange lookups, contrasting with plural/listing alternatives. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a perfect 5.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Get' is consistent. The description adds the time scope ('today') and the exchange specificity, but it does not disclose return format, pagination, or sorting behavior beyond what the schema implies. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured sentence with no redundant words. It front-loads the purpose and is perfectly sized for a tool with a clear function.

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 has a simple purpose, full parameter descriptions, and safe annotations. The description adequately communicates the 'when' and 'what' for a filtered-list tool. Although no output schema exists, the return type (list of movers) is clear from the description and param names, so completeness is high.

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 all parameters are described (type, limit, exchange) with enums and defaults. The description adds no new parameter-specific meaning beyond what is in the schema, maintaining the baseline score.

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 retrieves top gainers and/or losers for a specific African exchange, using a specific verb and resource. It distinguishes from sibling tools like get_ngx_top_gainers (Nigeria-specific) and get_pan_african_movers (multi-exchange) by emphasizing a specific exchange.

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 'specific African exchange' implies this is for exchange-specific movers as opposed to pan-African movers, but the description does not explicitly state when to use this tool versus alternatives like get_pan_african_movers or get_ngx_top_gainers. Usage is implied 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds value by disclosing the exact scope (the list of exchanges and the types of data returned: index levels, daily change, stocks count, status). This goes beyond the annotations without contradicting them, but does not elaborate on error conditions or data freshness.

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 lists the exchanges and the output fields without unnecessary words. It is front-loaded with the core purpose ('Get a list of all African stock exchanges') and provides the valuable detail in a compact format. Every element 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?

Given the tool's simplicity (no parameters, no output schema, no nested objects), the description is fully adequate. It explicitly names the exchanges and the fields returned, which is sufficient for an agent to understand what the tool returns. The sibling context further clarifies that this is the plural overview tool, making the tool's place in the family 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 coverage is 100% (vacuously). The baseline for zero-parameter tools is 4. The description does not need to explain parameter meaning, but it compensates by describing the output structure, which is the primary semantic burden for a no-parameter tool.

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 explicitly states the tool 'Get a list of all African stock exchanges' and enumerates the specific exchanges included. This distinguishes it clearly from sibling tools like 'get_african_exchange' (singular) and 'get_african_exchange_movers'. The output fields are also specified, leaving no ambiguity about the tool's function.

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 clear context for when to use this tool: when a comprehensive list of African exchanges is needed. While it does not explicitly mention alternatives or exclusions, the sibling names (e.g., 'get_african_exchange' for a single exchange, 'get_african_exchange_movers' for movers) imply the use cases. This meets the 'clear context, no exclusions' level.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns prices, change percent, volume, market cap, and sector, and supports filtering/sorting. It does not go deeper into behavior like default limits or error handling, but with annotations covering the key aspects, this is adequate.

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 that communicates the core purpose and capabilities without any waste. It earns its place by being informative yet compact.

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 complete parameter schema, clear annotations, and a straightforward list-retrieval use case, the description is sufficiently complete for an agent to invoke the tool correctly. It could mention pagination or result format, but the absence of an output schema lowers that burden. The description covers the essentials well.

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 every parameter thoroughly described (exchange enum values, limit default, sort options). The description only echoes 'filtering and sorting' without adding details beyond the schema, so it provides no extra meaning. 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?

The description clearly identifies the action ('Get') and the resource ('stocks on a specific African exchange') and lists the data fields returned. It does not explicitly distinguish from sibling tools like get_african_exchange_movers or get_ngx_all_stocks, but the focus on exchange-specific stocks makes the purpose clear enough.

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 alternatives. Sibling tools such as get_african_exchange_movers, get_african_indices, and get_ngx_all_stocks overlap in scope, but the description does not mention any exclusions or preferred use cases. The only implication is that it is for listing stocks per exchange, which is weak guidance.

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 already mark the tool as read-only and idempotent. The description adds behavioral context by specifying the data scope (~40 currencies) and the presence of as-of timestamps and sources in the response, going beyond the annotation's safety profile.

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 13-word sentence, front-loading the core purpose and key attributes (currency count, timestamp, source) without superfluous detail. 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 parameterless, read-only tool with no output schema, the description sufficiently conveys what the agent will receive: current USD rates for ~40 currencies with timestamp and source. This is complete for an agent to select and invoke correctly, especially with good 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?

The tool takes no parameters, and the input schema is empty with 100% coverage. With zero parameters, the description has no obligation to explain parameter semantics, so the baseline score 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?

The description clearly states the tool returns current USD exchange rates for approximately 40 African currencies, including per-currency timestamp and source metadata. This specific scope differentiates it from sibling tools like get_african_policy_rates or get_african_yield_curve, which cover different financial instruments.

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 'Current USD rates' conveys a clear use case: obtaining up-to-date FX rates for African currencies. It implies an exclusion of historical data but does not explicitly name alternatives or when-not-to-use scenarios, placing it at clear context without explicit 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful content details (included indices, daily change, YTD performance) but does not disclose response format, pagination, or any limitations. It complements the annotations without contradicting them.

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 is informative without excess. It front-loads the core action and then lists specifics 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 read-only tool with no parameters and no output schema, the description provides sufficient context: what it returns (indices, values, daily change, YTD). It could mention that it's a snapshot or any caveats, but for its simplicity this is adequate.

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, so the schema trivially covers everything. The description does not need to explain parameters, and per guidelines baseline is 4.

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 identifies the action (Get), the resource (African market indices), and the scope ('all major') with explicit examples. It distinguishes itself from sibling tools that focus on stocks, exchanges, or macro indicators.

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 usage for fetching a broad set of African indices in one call, but it does not explicitly state when to prefer this over sibling tools like get_african_exchange_stocks or get_country_macro_indicators, nor does it mention any 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?

Annotations already indicate read-only and idempotent behavior. The description adds value by disclosing data provenance (source institution and URL per value) and the live nature of Nigeria's CBN data. This goes beyond the structured hints, though it doesn't cover all potential nuances like rate limits or fallback 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 front-loads the core purpose and includes only relevant details. Every clause contributes useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema tool, the description adequately conveys the data returned (policy rates, inflation, source attribution) and geographic scope. It is sufficient for an agent to select and 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?

There are zero parameters, so the schema is trivially complete. The baseline for 0 params is 4, and the description does not need to add parameter details.

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 'Get' and the resource 'central bank policy rates and latest inflation' for '18 African economies', with specific details like 'Nigeria live from CBN' and 'source institution and URL per value'. This distinguishes it from siblings such as get_african_fx_rates or get_african_banks.

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 clear context by specifying exactly what data is returned, making it evident when the tool should be used. However, it does not explicitly mention alternatives or exclusions, so it misses the full when/when-not guidance.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about data freshness ('latest auction per tenor') and coverage ('13 countries covered'), but it does not elaborate on return format, pagination, or potential errors. This is consistent with annotations and provides moderate added transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary purpose and immediately followed by a key limitation. Every word adds value, with no redundancy 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?

For a simple single-parameter read-only tool, the description covers the essential information: what data is returned (yield curve, auctions, stop rates, yields) and the coverage limit (13 countries). While it doesn't specify the exact response structure, the tool's simplicity and schema coverage make this sufficient.

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 describes the 'country' parameter with ISO-2 code examples, achieving 100% schema coverage. The description adds little beyond reinforcing that it covers African countries, so the baseline of 3 is appropriate given the schema already handles parameter semantics.

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 returns the current government yield curve for African countries, specifically mentioning T-bill/bond auctions per tenor with stop rates and yields. This specific verb-resource combination distinguishes it from sibling tools like get_african_policy_rates or get_african_fx_rates.

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 is for yield curve data and notes the 13-country coverage limitation, but it does not explicitly state when to use this tool over alternatives or provide any exclusion criteria. The usage context is implied rather than explicitly guided.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety behavior. The description adds context about the Nigeria-specific response (listing indicators like MPR, T-bill, etc.), which is useful but does not disclose other behavioral aspects such as error handling or response format. Given the annotation coverage, a score of 3 is appropriate.

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 primary action, then a concrete example. Every word adds value, with no redundancy or padding. It is concise and well-structured.

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 single-parameter tool with strong annotations and no output schema, the description is mostly complete. It explains what the tool returns and gives a specific example. However, it does not detail the return format or mention that indicator sets may vary by country, which would be helpful. Given the tool's simplicity, this is a minor gap, so a 4 is appropriate.

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% for the only parameter 'country', which already describes it as an ISO-2 code with examples. The tool description reinforces this with 'ISO-2 code' and the Nigeria example, but adds minimal new meaning beyond the schema. Since schema does the heavy lifting, baseline 3 is justified.

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 function: 'Get all macro indicators for one African country (ISO-2 code).' It specifies a specific verb, resource, and scope, and distinguishes itself from siblings like get_african_policy_rates by focusing on comprehensive macro indicators for a single country. The Nigeria example further clarifies expected content.

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 description suggests the tool is for retrieving macro indicators for one country, but it does not explicitly state when to prefer this over alternatives like get_macro_history or get_african_policy_rates, nor does it provide exclusion criteria. The guidance is adequate but not explicit about 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context by specifying the data frequency ('monthly') and the depth of history for Nigeria (2006 onward), which sets expectations about data availability. It also lists example indicators and notes 'and more', indicating an extensible set. This goes beyond the annotations without contradicting them.

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 core functionality and key data coverage detail. There is no fluff or redundant phrasing; it earns its place by adding the Nigeria history depth and example indicators. Ideal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries some burden to set expectations. It clarifies the data frequency (monthly), the region (Africa), and that history depth varies by country (Nigeria since 2006). It does not describe the response format (e.g., array of {period, value}), but for a straightforward history fetch this may be inferred. The tool is adequately contextualized within its sibling suite.

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%, with all four parameters (country, indicator, from, to) already described in simple terms. The description adds a minor hint about data availability (Nigeria reaches back to 2006) that could inform the 'from' parameter, but it largely repeats indicator examples already present in the schema. Since the schema fully documents parameter formats, the description's incremental semantic contribution is limited.

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 retrieves monthly historical data for African macro indicators. The verb 'history' and resource 'African macro indicator' make the primary function clear. It is distinguishable from sibling tools like get_country_macro_indicators (which likely returns current values) and get_african_policy_rates (current rates), though it does not explicitly name alternatives.

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 usage for historical macro data, especially given the mention of Nigeria's data extending back to January 2006. However, it does not explicitly state when to use this tool versus alternatives like get_country_macro_indicators or get_african_policy_rates, nor does it provide exclusions. The data availability note gives some practical context, but the guidance is mostly implicit.

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 already indicate a safe, read-only, idempotent operation. The description adds valuable behavioral context by listing the exact output fields (reason, local time, session, next open/close) and disclosing that Sun–Thu markets and holidays are handled. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the purpose question, and each sentence adds relevant information—purpose, return fields, and market handling—without any wasted words.

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 (one parameter, read-only, with annotations), the description is complete for an agent to understand what it does and what it returns. It explicitly lists the return fields and notes holiday handling, which is sufficient in the absence of an output schema.

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 input schema fully covers the single parameter 'exchange' with examples (NGX, JSE, EGX), so schema coverage is 100%. The description does not add any additional meaning about the parameter itself, meriting the baseline score of 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 clearly states the tool's function: checking if an African exchange is open right now. It specifies the resource (African exchange) and the return content (reason, local time, session, next open/close), distinguishing it from sibling tools like get_ngx_market_status by its African-wide scope.

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 (checking market open status for African exchanges) and notes a limitation (handles Sun–Thu markets and holidays), but it does not explicitly state when to use this tool versus alternatives or when not to use it. No 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating the exact number of equities (45) and explaining the market's nature (OTC for unlisted/growth-stage companies), which informs the agent about the expected scope and content. It does not introduce any contradictions with annotations, and no additional side-effect disclosures are necessary for a read-only, parameterless 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 a single, well-structured sentence that front-loads the verb and resource ('Get all 45 equities...') and adds clarifying context in the second clause. There is no redundancy or filler; 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?

Given the tool has no parameters, a clear purpose, and helpful annotations, the description is nearly complete for a simple list tool. It does not specify the output structure (e.g., fields like symbol, price), which would be useful since no output schema exists, but the description's statement 'all 45 equities' sufficiently implies a list of securities. The slight gap in detailing return data prevents a perfect score.

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 coverage is 100% (empty schema). The description does not need to explain parameters because there are none. It implicitly conveys that the tool returns the full list of 45 equities without requiring any input, which is the baseline for parameterless tools.

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 'Get all 45 equities on Nigeria's NASD OTC Securities Exchange', identifying the specific verb (get), resource (equities), and market (NASD OTC). It distinguishes from sibling tools like get_ngx_all_stocks by naming the exchange and further clarifying it is an over-the-counter market for unlisted and growth-stage companies, leaving no ambiguity about what this 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 provides clear context about when to use this tool by specifying the NASD OTC Securities Exchange and its focus on unlisted and growth-stage companies. It does not explicitly mention alternatives or exclusion criteria, but the context is sufficient to differentiate it from NGX-focused tools. It lacks an explicit 'use this for...' or 'when not to use' statement, but the market scope is clearly defined.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about returning current prices and a fixed list size, but does not disclose potential behaviors like data freshness, sorting, or pagination. With annotations covering the safety profile, a score of 3 is appropriate.

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 that provides essential information without unnecessary words. It earns its place by clearly communicating the tool's purpose and output.

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 with no output schema, the description is complete: it states the scope, the data fields, and the approximate count. Nothing essential is missing, and the sibling tools provide contextual differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema is fully covered at 100%. The description doesn't need to explain parameters, and the baseline for 0 params is 4. No additional parameter semantics are required.

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 'Get' and the resource 'full list of all 148+ equities listed on the NGX' with specified fields (current prices, daily change percent, volume, market cap, sector). This distinguishes it from sibling tools like get_ngx_stock_price or get_ngx_top_gainers.

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 usage for fetching the complete equity universe on NGX, distinguishing it from more focused tools. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to choose this when a full list is needed.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a concrete behavioral detail: the fixed 200-item limit and the types of content included. This is useful context beyond what annotations provide.

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, front-loaded with 'Get the latest 200', clearly structured with a dash listing content categories. There is no fluff, and every word adds value.

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 parameterless read-only tool with safety annotations, the description fully specifies the purpose, scope, limit, and content types. No output schema exists, but the description is sufficient for an agent to select and invoke the tool 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?

The tool has zero parameters, so the input schema is complete at 100% coverage. The description correctly avoids inventing parameters. Baseline 4 applies for parameterless tools since there is nothing to explain.

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 'Get' and resource 'corporate disclosures and regulatory announcements' with clear scope 'NGX-listed companies' and enumerates content types (earnings, dividends, board changes, filings). This clearly distinguishes it from sibling market-data tools like get_ngx_stock_price or get_ngx_top_gainers.

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 alternatives are named, but the description clearly defines a niche: corporate disclosures vs. market data. Sibling tools all focus on market statistics, so the context is obvious. The 'latest 200' provides a clear usage expectation, though it lacks an explicit when-not-to-use statement.

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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'real-time' qualifier and return fields but does not disclose additional behavioral aspects such as rate limits or data freshness caveats. It is consistent with annotations, so not contradicted.

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-sentence description with no filler. The first sentence identifies the action and resource; the second lists returns and usage. Every sentence earns its place and is front-loaded with the core purpose.

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 adequately explains return values (ASI, market cap, volume, deals, advancers, decliners) and provides usage context. For a parameterless, read-only tool, this fully satisfies the contextual needs for an agent to select and invoke it.

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, so schema coverage is effectively complete and the description has no parameter semantics to add. 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?

Description states 'Get a real-time overview of the Nigerian Stock Exchange (NGX)' and lists specific return metrics (ASI, market capitalisation, trading volume, deals, advancers, decliners), clearly distinguishing it from siblings like get_ngx_top_gainers which focus on subsets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when the user asks about the Nigerian stock market at a high level,' providing clear context. However, it does not name alternatives or state when not to use, so it lacks full exclusion/alternative guidance.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by disclosing the exact output values (OPEN, CLOSED, ENDOFDAY) and that it checks 'currently' open status, which provides behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately states the tool's function and return values. Every word earns its place; there is no fluff 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?

For a parameterless tool with no output schema, the description fully covers the essential information: a precise check of NGX market status and the three possible results. There are no hidden complexities or missing prerequisites, making it complete in context.

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, so the baseline is 4. The description correctly implies that no configuration is needed. There are no parameter semantics to clarify, and the description does not introduce any confusion.

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 'Check' and clearly identifies the resource: whether the Nigerian Stock Exchange (NGX) is open or closed. It also specifies the exact return values (OPEN, CLOSED, ENDOFDAY), making the tool's purpose unambiguous and distinct from siblings like get_market_open_status or get_ngx_market_overview.

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 clearly implies when to use this tool: whenever an agent needs to know the current trading status of the NGX. While it does not explicitly name alternatives or exclusions, the context is clear and there are no prerequisites. Given the simplicity of the tool, this is sufficient.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds that the tool returns 'latest price and trading history', which is some behavioral detail, but it doesn't disclose formatting, freshness, or potential limitations. Given the annotation coverage, the description provides moderate value beyond the structured data.

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 every sentence earns its place. It efficiently covers what, for whom, and when to use it without any fluff. This is a model of conciseness.

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 low complexity (one required parameter, read-only, no output schema), the description is complete enough. It specifies the input (ticker symbol) and the output (latest price and trading history), and the explicit usage context resolves ambiguity. The annotations fully cover safety, so no further behavioral disclosure is necessary.

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 single `symbol` parameter, which already includes examples and case-insensitivity. The description also mentions ticker examples, but this adds little beyond the schema. Since the schema already does the heavy lifting, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Get the latest price and trading history for a specific NGX-listed stock by ticker symbol', using a specific verb and resource. It also distinguishes from sibling tools by emphasizing 'specific' stock, contrasting with broader tools like get_ngx_all_stocks or get_ngx_market_overview. Examples of tickers further clarify the intended use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when the user asks about the price of a particular Nigerian stock.', providing clear context for when to invoke it. It does not explicitly name alternatives or exclusions, but the guidance is sufficient for a single-purpose tool. This matches the 'clear context, no exclusions' level.

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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context like 'today' and the ranking criterion, but does not disclose additional behavioral details such as default limit or output format. This is adequate, matching the baseline for annotation-covered read-only list tools.

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: the first states the action and result, the second gives usage guidance. Every word earns its place, with no redundancy 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 tool with one optional parameter, no output schema, and strong annotations, the description fully covers what the tool does and when to use it. The context is 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 input schema fully describes the only parameter, 'limit', including its default value. The description does not add extra meaning, but the schema coverage is 100%, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the top gaining stocks on the NGX, ranked by percentage price increase today. This specific verb+resource+scope easily distinguishes it from siblings like get_ngx_top_losers or get_ngx_all_stocks.

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 second sentence explicitly says to use this when a user asks which Nigerian stocks are up the most today, providing clear usage context. However, it does not mention alternatives or when not to use, so it misses the full 'when-not' guidance for a 5.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the time window ('today') and ranking criterion ('percentage price decline'), which goes beyond the annotations. However, it does not describe return format, pagination, or other behavioral traits, so it offers moderate added value.

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 purpose, and contains no filler. Every word contributes to understanding what the tool does and when to use it.

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 (one optional parameter, no output schema), the description fully covers the tool's purpose, usage context, and ranking behavior. It is complete for a filtered-list tool with good 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?

The input schema has 100% description coverage for the single 'limit' parameter, which is documented with type and default. Since the schema fully explains the parameter, the description's lack of parameter detail is acceptable. 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 clearly states the tool's function: 'Get the top losing stocks on the NGX today, ranked by percentage price decline.' It uses a specific verb ('Get'), specifies the resource (NGX stocks), and adds a distinguishing scope ('top losing', 'ranked by percentage price decline') that differentiates it from sibling tools like get_ngx_top_gainers and get_ngx_all_stocks.

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 explicit usage guidance: 'Use this when the user asks which Nigerian stocks are down the most today.' This clearly identifies a triggering user request. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a full 5.

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 already mark readOnlyHint and idempotentHint true. The description adds useful context: aggregation across all African exchanges, metric is % change, timeframe is today, and categories include top gainers and losers. No contradiction.

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 action and scope, with no filler or repeated 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 simple read-only tool with one optional parameter and good annotations, the description covers action, scope, metric, timeframe, and output category. No output schema exists, but the description provides enough context for an agent to invoke 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?

The input schema already fully describes the only parameter, limit, with 'Number of movers per category. Defaults to 10.' The description adds no additional parameter detail, 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 'Get' with a precise resource: 'biggest stock movers across ALL African exchanges combined — top gainers and losers by % change'. It clearly distinguishes from per-exchange siblings by emphasizing 'ALL' and 'combined'.

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 signals when to use this tool through 'ALL African exchanges combined' and 'every covered market today', implying it is for a pan-African view rather than exchange-specific tools. However, it does not explicitly name alternatives or exclusions.

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