AfricanMutualFunds

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds a genuinely valuable behavioral fact: the pension side is free while the mutual fund side requires a paid manager edition, which affects whether a call can return full data. It does not cover latency or data-freshness, so it falls short of a 5.

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 dense sentence front-loads the core purpose (month-by-month comparison) followed by the mode definitions, with zero filler. The enum explanations are necessarily wordy but each earns its place. Minor readability cost from the nested quoting.

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

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

With no output schema, the description carries the burden of conveying what is returned, and it does so by describing the paired series for each mode plus the licensing gating. Defaults for period_start/period_end and the granularity/shape of the returned series are unstated, which keeps it from a 5.

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

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

The schema has no description for the enum asset_class, and the description fully compensates by defining all three values in domain terms (e.g., 'money_market' means local money market vs money market funds). period_start and period_end are already documented in the schema. This goes meaningfully beyond the 67% 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?

States a specific comparison (pension funds vs Nigerian mutual funds) on a monthly basis, which is a concrete verb+resource. The three asset_class modes are spelled out with what each pairs against, so an agent knows exactly what the tool produces. It doesn't explicitly distinguish itself from siblings like get_pension_allocation, but the comparative framing is clear.

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

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

The description implies when each asset_class mode applies by defining what each compares, which is useful selection guidance. It also flags an access prerequisite (mutual fund side requires the AfricanMutualFunds manager edition). However, it never names an alternative sibling or states when not to use this tool over get_pension_allocation or get_mutual_funds.

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 openWorldHint=false, so the safety profile is covered. The description adds the useful multi-match behavior ('they are listed') and the accepted identifier forms, but says nothing about not-found handling, result size, or auth needs, so added value is moderate.

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

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

Front-loaded with the core action and resource in the first clause, then a compact enumeration of return fields; no filler sentences. The field list is slightly long but every item is informative for a caller.

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 compensates by naming the returned fields, and it clarifies the accepted identifier forms for the single required parameter. The only real gap is the no-match case, which is left unstated for a lookup tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely extends the allowed value space beyond the schema's single example: it accepts a former name or a page slug, not just a current display name. That is real semantic information the schema does not convey.

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

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

States a specific verb+resource ('One Nigerian mutual fund by name') and enumerates the returned fields (manager, category, currency, returns, filing start, page), so an agent knows exactly what it gets. It implicitly separates itself from the plural sibling get_mutual_funds by emphasizing 'One', but never names that alternative explicitly.

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

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

Gives input flexibility (current or former name, or page slug) and a behavioral rule for ambiguous names ('if the name matches several funds, they are listed'), which implies usage. However, it never says when to prefer this over get_mutual_funds or the league table, and gives no 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-derivable behavior: funds lacking a figure for the period are excluded and the response reports how many were dropped and why. This is useful context beyond the structured fields.

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?

Compact, front-loaded with the primary concept ('the AfricanMutualFunds board') before the qualifiers. The parenthetical default is efficient. Slightly dense but no wasted sentences.

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

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

With no output schema, the description covers the ranking basis, defaults, category scoping, and the omission/counting behavior. Missing detail on return shape and pagination is minor for a read-only ranking tool whose safety profile is already asserted by annotations.

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

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

Schema coverage is 67% with two enums carrying their own values. The description adds meaning for period (default ytd, the board's ranking basis) and category (all-vs-one selection), but says nothing about limit or the 250 cap. A baseline 3 fits when the schema does most of the parameter work.

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

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

States a specific verb+resource: a league table where mutual funds are ranked on a return. It clarifies scope (all funds or one category) and the ranking basis. It stops short of naming siblings like get_mutual_funds or get_mutual_fund_market_summary, so differentiation relies on inference.

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

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

Usage is implied by the 'across all funds or within one category' framing and the default ytd period, but there is no explicit when-to-use-this-vs-alternative routing. An agent cannot directly tell why it would pick this over get_mutual_funds or get_mutual_fund_market_summary.

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 only declare readOnlyHint and openWorldHint=false, so the description carries most of the behavioral load. It adds genuine context beyond annotations: the data's vintage is a weekly cutoff, flows cover a three-month window, results are aggregate totals only, and per-fund detail is apparently gated ('not free'). It stops short of stating auth, rate limits, 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?

It is a single sentence with no filler, which is efficient, but it is a dense run-on with a semicolon and a cryptic trailing parenthetical. The most decision-relevant fact (totals only, no per-fund detail) is buried at the end rather than front-loaded.

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

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

There is no output schema, so the description effectively doubles as the return-value spec, and it does list the four categories of data returned. For a zero-parameter read-only summary tool this is close to sufficient; only the exact shape and units of the returned aggregates are left unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The schema is an empty object with no fields to misinterpret.

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 enumerates the data points returned (data vintage week, fund counts by category, best YTD return, three-month net flows), so an agent can infer this is an aggregate market-statistics tool. However, it never states a verb or names the resource in a clean phrase — it opens with the fragment 'The week the data runs to' — so the purpose has to be decoded from a list rather than read. It only weakly separates itself from siblings like get_mutual_funds or get_mutual_fund_league_table.

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 parenthetical 'totals only, as on the front page; which funds is not free' implies this is a summary-level tool and that per-fund breakdowns live elsewhere, which is an implied usage boundary. But no sibling is named and there is no explicit 'use this when...' statement, leaving the agent to guess which of the several fund/pension siblings to pick.

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 openWorldHint=false, so the safety profile is covered. The description adds real context beyond annotations: the data source is the SEC weekly return, and each record carries returns, manager, and page — useful for an agent with no output schema.

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?

Dense and front-loaded: the source and result shape come first, then the filter/sort dimensions, then the returned fields. No filler, though the final fragment listing returns is slightly list-like.

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 usefully names what each fund returns, and covers all filter/sort dimensions of a 6-param tool. It is nearly complete; only pagination/limit behavior and the exact default sort mechanics are left implicit.

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

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

Schema coverage is 67% and the description expands the opaque sort_by enums (r1m, ytd, r2025, r1y, r3y) into human terms (last month, year to date, 2025, one year, three years) and confirms query/manager/category/currency filters. Only 'limit' is left solely to the schema.

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

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

States a specific verb and resource: it retrieves Nigerian mutual funds from the SEC weekly return with filtering and sorting. The scope (filtered/sorted list of funds) is clearly distinct from the singular get_mutual_fund, league table, and market summary siblings, though no sibling is named explicitly.

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

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

Implicit usage is clear (search/filter funds by name, category, manager, currency and rank by return), and the sort options hint at typical use. No explicit when-to-use versus alternatives (e.g. compare_pension_vs_mutual_funds or get_mutual_fund_league_table) or exclusions are given.

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 openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond them: the conditional result shape (total plus seven groups, or a single line) and the data-quality caveat that figures held for review are absent rather than estimated.

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

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

Three dense sentences with no filler; the return shape and the conditional behavior are front-loaded. The parenthetical examples add precision rather than padding, though the sentence structure is slightly list-like rather than maximally scannable.

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

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

There is no output schema, so the description correctly carries the burden of explaining what comes back — value, share, total plus seven groups, or one line. Combined with the data-quality note and the defaults documented in the schema, an agent has enough to call it correctly, though the units/periodicity conventions for multi-month requests are left implicit.

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, but the description goes further by clarifying what asset_class accepts — a group such as 'Equities' or a class id such as 'treasury_bills' — which the schema only vaguely calls 'group, class id or label'. It also implies the single-line response shape when that parameter is 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 states a specific resource and scope — monthly Nigerian pension asset allocation with value in naira and share of total assets. It is far more precise than the title 'Pension allocation' and lets an agent distinguish it from get_pension_coverage or get_pension_rotation, though it never names a sibling to sharpen the contrast.

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

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

It explains the effect of supplying asset_class versus omitting it, which is real usage guidance for the parameter. But it gives no guidance on when to choose this tool over the sibling pension tools, and no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: it flags that monthly periods are unaudited and that some figures are 'held for review', which is meaningful data-quality state an agent should know before using the results.

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 dense sentence with no filler; the primary fact (which periods are held/missing) is front-loaded before the qualifiers about frequency and audit status. It is slightly run-on but nothing is wasted.

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

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

With no output schema, the description must convey what comes back, and it does: coverage by frequency, held versus missing periods, and per-period audit status. It is nearly complete for a zero-parameter read tool, missing only the response shape/grouping detail.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. Nothing in the schema needs compensating for, and the description spends its words on output semantics instead.

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 resource and dimension: which PenCom report periods are held versus missing, their frequency, and audit status. It is clearly distinguishable from siblings like get_pension_allocation or compare_pension_vs_mutual_funds, though it never explicitly names those 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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The intent (checking data coverage before relying on pension figures) is only inferable, not stated.

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 openWorldHint=false, so safety is covered. The description goes further by defining the two returned measures (holdings change in naira/market value, share change in percentage points) and warning that a holdings change mixes new money with price moves rather than being a flow — genuinely useful interpretive context with no output schema available.

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

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

Two sentences, no filler, and the output semantics are front-loaded before the caveat. Every clause carries 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?

With no output schema, the description carries the burden of explaining the return shape, and it does so adequately (measures, units, ranking order). It is a read-only, one-parameter tool, so little else is needed; only the tie to sibling tools for cross-queries is absent.

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 single optional 'period' parameter, including the default (latest). The description's 'One month' phrasing loosely implies the period argument but adds no format or behavior beyond the schema, so the baseline 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 names the resource (pension holdings/share by asset class) and the exact scope (one month, versus the month before, ranked largest rise to largest fall), so an agent knows what data comes back. It never states a verb or explicitly distinguishes itself from siblings like get_pension_allocation, leaving that differentiation to inference.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The month-over-month framing hints at a rotation/diff use case, but the agent must infer that on its own.

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