Senegal Payments (Flutterwave — Orange Money / Wave)

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

Annotations indicate destructiveHint=true and idempotentHint=true; the description adds context about the subscription lifecycle (first payment, then query_subscription). This explains the behavioral constraint of needing a subscription_id from a specific source, going beyond 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?

Two short, focused sentences. First sentence states the purpose, second explains the prerequisite. No unnecessary words, front-loaded with the action.

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 parameter and no output schema, the description covers the essential: purpose, parameter prerequisite, and workflow. It does not describe success/failure behavior, but annotations fill idempotency. Nearly complete.

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

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

Schema coverage is 100% with a clear description for subscription_id. The tool description reinforces this and adds workflow context (why it must come from query_subscription). While no new format details, the additional context improves 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 action ('Cancel a subscription') and the result ('so it will not renew'). It also explains the prerequisite for the parameter, distinguishing it from sibling tools like create_subscription_link or query_subscription.

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 specifies when to use this tool (after the first payment is complete and the subscription_id is obtained from query_subscription) and implies when not to use it (without the subscription_id). It names the prerequisite tool, providing clear usage 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?

The description goes beyond annotations by explaining the flow (returns a hosted checkout URL, payment completes automatically, no confirm step), the fund transfer path (buyer→Flutterwave→merchant), and safety notes (test credentials never move real money). This provides rich behavioral context.

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 relatively detailed but each sentence adds value. It front-loads the core purpose and then elaborates on payment methods, return URL, credentials, and flow. Could be slightly tighter but still 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?

Given the complexity of an external payment integration and no output schema, the description explains the return value, payment flow, and credential requirements. It lacks error handling details but covers the essential operational 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?

Schema coverage is 100% and each parameter is described adequately. The description adds no new semantic information beyond what is in the schema, so baseline 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's purpose: creating a payment link in XOF for Senegal via Flutterwave. It specifies the currency, region, and payment methods, and distinguishes itself from sibling tools (query_payment_status, refund_payment) by focusing on creation.

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 context (Senegal, XOF, Flutterwave), but does not explicitly state when not to use or provide alternative tools. It does mention credential requirements, which guides proper use.

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

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

The description discloses that the buyer authorizes payment once and is charged automatically each period, and mentions that owner policy guardrails are respected (per-period amount checked before creation). This adds behavioral context beyond annotations, which only show readOnlyHint=false.

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 with two sentences. The first sentence states the purpose clearly, and the second adds important behavioral details. Every word contributes meaning without 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?

Given no output schema, the description does not mention the return value (likely a checkout URL). It also does not explain how to retrieve subscription ID for later management (e.g., cancellation). The behavioral description is good but incomplete regarding output and follow-up actions.

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% coverage with clear descriptions for each parameter. The description adds little new meaning beyond the schema (e.g., interval default is already in schema). The mention that amount is per billing period is implied by the schema description. Thus, 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 creates a recurring subscription checkout link with specifics (XOF currency, monthly/yearly/weekly billing) via Flutterwave. It distinguishes from sibling create_payment_link by emphasizing the recurring nature and automatic billing.

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 recurring subscriptions and mentions the recurring nature and automatic billing, which suggests when to use it. However, it does not explicitly contrast with alternatives like create_payment_link or state when not to use it.

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?

Discloses direct query to Flutterwave, pull-based, no webhook. States paid=true condition (status PAID). Annotations confirm readOnlyHint, openWorldHint; description adds behavioral detail beyond.

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 concise, front-loaded sentences. No filler, every sentence adds unique 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?

Adequately covers purpose, parameter source, and behavior. Lacks mention of error cases or response format, but acceptable given simplicity and no 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?

Schema describes tx_ref as 'returned by create_payment_link'. Description explicitly mentions origin, linking to sibling. Schema coverage 100% so baseline 3; adds value via context.

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 exact purpose: check whether a Senegal payment (created by create_payment_link) has been paid. Verb 'check' with resource 'payment status' is clear. Sibling tools (create, refund) differentiate by action.

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?

Indicates pull-based polling vs webhook, implying when to use. Could explicitly state not for creating/refunding, but context of siblings makes it 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 indicate readOnlyHint=true and openWorldHint=true. The description reinforces that the tool is a read operation by stating 'Check a subscription.' It also describes status values (ACTIVE vs NOT_SUBSCRIBED_YET) and the resulting subscription_id, adding behavioral context beyond 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 (3-4 sentences), front-loaded with the core purpose, and avoids extraneous information. Every sentence serves a clear function: purpose, parameter guidance, status explanation, and output hint.

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 no output schema, the description adequately covers expected outputs (active flag, subscription_id) and provides next-step guidance ('keep it to cancel later'). It is complete for a read-only tool with moderate complexity.

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 baseline is 3. The description adds value by explaining the purpose of plan_id ('disambiguate when the same email has several plans') and that customer_email is required and tied to create_subscription_link, going beyond the schema's 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's purpose: 'Check a subscription created by create_subscription_link.' It specifies the required parameter (customer_email) and optional plan_id for disambiguation, effectively distinguishing it from sibling tools like cancel_subscription and create_subscription_link.

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 context on when to use the tool (after creating a subscription link) and how to handle disambiguation. It does not explicitly list when not to use it or alternatives, but the sibling names are provided separately, reducing the need.

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 annotations (destructiveHint=true), description discloses that refunds respect owner policy guardrails and that partial refund support varies. 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?

Three sentences with no extraneous words. First sentence states core purpose immediately. Highly 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?

Covers purpose, parameter usage, and behavioral guardrails. Lacks details on errors or return values, but tool is simple (2 params, no output schema). Adequate for expected use.

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 baseline 3. Description reinforces schema by explaining default and 'where supported' nuance, adding moderate value beyond schema definitions.

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 clearly states the verb 'Refund' and resource 'paid payment', and distinguishes from siblings (create_payment_link, query_payment_status). It specifies the default full refund and optional partial refund.

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?

Provides clear guidance on when to use (refunding a paid payment) and how to use parameters (full vs. partial). Mentions guardrails and gateway checks. Lacks explicit exclusion of alternatives, but context with siblings makes it clear.

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