Afriset Fintech

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

The description thoroughly discloses behavioral traits: it explains honest states (published_rule, documented_absence, not_published, located_unverified), pagination (has_more, next_offset), output variations per format, and the absence of rates. Annotations only provide readOnlyHint=true, so the description adds substantial 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 verbose, especially with the full list of 42 jurisdictions which could be trimmed or referenced from the schema. The core purpose is front-loaded, but the length may reduce quick scanning. Overall adequately structured for the tool's complexity.

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

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

The description covers pagination, allowed states, filtering options, and format behaviors. Given the lack of output schema and the tool's complexity, it provides sufficient context for correct invocation. Minor gaps: no mention of error responses or how to interpret multiple rule states per jurisdiction.

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 100% schema coverage, baseline is 3. The description adds contextual meaning to parameters like facet (explaining the 'xborder:' prefix), scope (defining union boundaries), format (details on compare vs full vs summary), and direction (special handling of 'both'). This goes beyond the schema descriptions.

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 provides cross-border money-movement rules for African markets, specifying it includes repatriation windows, licensed-channel requirements, etc., and explicitly distinguishes itself from rate queries ('RULES, NOT RATES'). It differentiates from sibling tools by focusing on rules rather than licensing or mapping.

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 how to filter by jurisdiction, topic, facet, scope, direction, and activity, and describes different output formats (summary, full, compare). However, it does not explicitly contrast with sibling tools like list_licensed or map_license, leaving the decision context 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?

The annotations already indicate readOnlyHint=true, and the description confirms this by describing a read operation (listing data from a register). It adds behavioral context: data comes from official regulator registers, includes source and as-of date, explains absence reasons (structural, unavailable, not ingested, empty), and details pagination behavior. However, it does not mention rate limits or authentication requirements (assuming they are handled elsewhere), but for a read-only tool this is acceptable.

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 structured with the main purpose first, followed by lists of activities and jurisdictions, then output details. It is somewhat long due to the exhaustive list of jurisdictions, but that is arguably necessary for clarity. Every sentence adds value—there is no fluff. The compactness could be improved by summarizing the jurisdiction list, but it remains readable.

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 complexity (multiple activities, 42+ jurisdictions, two output formats, pagination, data provenance, absence explanations), the description covers all critical aspects. Since there is no output schema, the description fully explains return values (compact summary vs. full paginated, per-category coverage, and why empty slices occur). The description is complete enough for an agent to invoke the tool correctly without confusion.

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?

All 5 parameters are described in the schema with 100% coverage. The description adds valuable semantics beyond the schema: default limits (500 for summary, 50 for full), explanation of format difference (compact vs. paginated full), offset's name-sorted ordering, activity examples ('fintech:EMONEY_ISSUE'), and jurisdiction omission meaning 'all'. This substantially enriches parameter understanding.

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 'list' and the resource 'licensed providers', and specifies the scope: canonical activities in African jurisdictions per official registers. It explicitly lists all supported activities and 42 country codes, making the tool's purpose unmistakable. The sibling tools (cross_border_rules, map_license, requirements) are sufficiently different, so there is no confusion.

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 (to check who is licensed for a given activity/jurisdiction) but does not explicitly contrast with siblings or provide when-not-to-use guidance. For example, it could mention that cross_border_rules is for cross-border licensing rules rather than provider lists. The lack of explicit usage boundaries keeps this at a 3.

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, so no safety contradiction. The description adds value by explaining the mapping behavior (equivalence lookup) and providing examples, which goes 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?

One well-structured sentence with a parenthetical example. Front-loaded with the key concept. Every word earns its place; no 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 3-parameter tool with no output schema and simple sibling, the description adequately explains the tool's purpose and concept. It lacks details on output format or edge cases, but the examples compensate sufficiently.

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 documents all three parameters (activity, from, to). The description does not add parameter-specific meanings beyond the schema's descriptions but provides overall context through examples.

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

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

The description uses specific verbs ('normalization', 'map') and clearly states the resource ('canonical activity to local licence category'), providing concrete examples (Nigeria MMO ≈ Ghana DEMI) that distinguish it from the sibling tool 'list_licensed'.

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 cross-jurisdiction license mapping but does not explicitly state when to use this tool versus 'list_licensed' or what conditions warrant its use. No exclusion criteria or alternatives are mentioned.

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?

Beyond the readOnlyHint annotation, the description details honest states (published_value, documented_absence, etc.), pagination with explicit truncation and has_more/next_offset, and format differences. It adds significant behavioral context without contradicting 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 detailed but well-structured, with front-loaded purpose and clear sections. The list of jurisdictions is extensive but necessary for context. Every sentence adds value for a tool with 6 parameters and no output schema.

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?

Without an output schema, the description thoroughly covers return values: honest states, source, as-of, verbatim quotes in full format, and pagination details. It explains capital/fees in statute's currency and the two formats, making the tool self-contained.

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 100% schema coverage, baseline is 3. The description adds meaning beyond the schema by explaining the relationship between activity, jurisdiction, and category, listing valid activities and jurisdictions, and clarifying default limits and truncation behavior.

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

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

The description clearly specifies the tool retrieves licence requirements for a canonical activity in an African jurisdiction. It distinguishes itself from sibling tools (cross_border_rules, list_licensed, map_license) by focusing on requirements like capital, fees, and obligations, not licenses or cross-border rules.

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 how to use the tool: key by activity (+ optional jurisdiction) or exact category id. It mentions default and full formats. However, it does not explicitly state when not to use it or provide direct comparisons to alternatives, though the context of sibling tools implies differentiation.

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