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

Annotations already declare readOnlyHint=true, so the trailing "Read-only" is pure repetition of structured data. The only added detail is that the account is "configured" (no account id parameter), but nothing is said about network/auth failure modes despite openWorldHint, or about what the balance represents.

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 sentences, front-loaded with the action. The second sentence is wasted words because it restates the readOnlyHint annotation, costing a point.

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 zero-parameter read this is close to sufficient, but with no output schema the description never says what the balance result contains (currency, available vs. current balance) or that an error occurs when credentials are not configured. A sentence on the return shape would close the remaining gap.

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, so there is nothing for the description to compensate for; the baseline for a zero-parameter tool applies.

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

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

States a specific verb and resource ("Read the balance of the configured MoMo account"), which is clearly distinct from siblings like momo_check_account_active or momo_verify_credentials. It does not explicitly differentiate itself from those siblings, but the resource noun does most of that work.

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 statement of when to call this versus momo_check_account_active, momo_verify_credentials, or momo_environment, and no preconditions (e.g., credentials must be configured first). Usage is only implied by the name and the word "configured".

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=true; the description restates read-only and adds one genuinely new trait, that the call is free. It says nothing about the response shape, what an inactive/nonexistent number looks like, or error behavior, so it clears the lowered bar but does not enrich it much.

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 short sentences, purpose first, then the pre-charge recommendation. Every sentence carries distinct information and nothing is padded.

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 read-only check with a fully documented schema, the definition is nearly complete. The only meaningful omission is what the tool returns (e.g. an active/inactive flag) and how an unknown number is surfaced, which the agent would have to discover at call time.

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

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

Schema coverage is 100% and the phoneNumber format (international, digits only, no +) is fully documented in the schema; the description adds no parameter guidance beyond it, 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?

States a specific verb and resource ('Check whether a phone number is a usable MoMo account') and frames it against the charge flow, so it is clearly distinguishable from siblings like momo_request_to_pay and momo_payment_status.

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 an explicit pre-condition ('before trying to charge it', 'before any request to pay'), which is exactly the routing signal an agent needs to sequence this call ahead of momo_request_to_pay.

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 adds meaningful context by saying it reports whether the server moves real money and what limits apply — a behavioral trait the agent needs before transacting. It does not describe the response shape in detail, which keeps it just 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?

One compact sentence with the effect first and the calling instruction second. Every clause carries load: what it reports, why it matters (real money), and when to call 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?

With no parameters and no output schema, the description must convey what comes back, and it does — environment, real-money status, and configured limits. That is everything an agent needs to decide to call it before a payment.

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 disambiguate; the baseline for 0 params applies. The description correctly stays silent on inputs rather than inventing them.

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: reports the target MTN MoMo environment. It further pins down the exact scope (real-money status and configured limits), which clearly separates it from sibling tools like momo_account_balance or momo_request_to_pay.

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 an explicit trigger and ordering rule: 'Call this first, and always before any payment.' The condition that selects it over every payment sibling is stated directly, leaving nothing to inference.

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 status enumeration (PENDING, SUCCESSFUL, FAILED) is genuine added value not present in annotations or any output schema. 'Read-only' merely restates readOnlyHint and the openWorldHint implication (network call to MoMo) is left unmentioned, so it is not a fully rich disclosure.

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 short sentences, front-loaded with the action and the provenance of the input. Nothing is padding.

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 read tool with no output schema, the description supplies the key return information (the three status values) and the source of the input. It omits whether SUCCESSFUL/FAILED are terminal and whether polling is safe, which would help an agent decide its next step.

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% and already says the referenceId is the UUID returned by momo_request_to_pay; the description repeats rather than extends that. No additional format, validation or failure-case guidance is added.

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 ('look up a payment') plus the exact lookup key ('by the referenceId'), and explicitly names the sibling tool that produces that key. An agent can distinguish it from momo_request_to_pay without opening either schema.

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 ties usage to the outcome of momo_request_to_pay, making the intended call sequence clear. It does not state exclusions such as whether polling is expected or how often the status may be re-checked.

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 openWorldHint=true and destructiveHint=false, so the description correctly adds non-obvious behavior: the tool is sandbox-enforced, refuses in production, and returns credentials that must be persisted to specific environment variables. It does not say whether calling it twice mints a new key, which matters given idempotentHint=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?

Three tight sentences, with the most important constraint ('SANDBOX ONLY') front-loaded. The 'three curl commands' rationale earns its place by explaining why the tool exists.

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 saying exactly what comes back (API user and API key) and what the caller must do with it (save to MOMO_API_USER and MOMO_API_KEY). Combined with the production refusal, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single parameter is fully documented there ('Not used in sandbox'), so the schema carries the load. The description adds nothing about providerCallbackHost, though it implies the call needs no meaningful input in sandbox.

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 ('Create an API user and API key in the MoMo sandbox') plus scope ('SANDBOX ONLY'), which no sibling tool covers. An agent can immediately tell this is a credential-bootstrap tool distinct from payment or account operations.

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 scopes usage to the sandbox and states the tool is 'Refused outright in production', which is a clear when-not-to-use signal. It doesn't name an alternative for production, but the description explains why none exists (MTN issues credentials there), which is nearly as good.

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 destructiveHint=true and openWorldHint=true, and the description adds real value on top: it discloses the return value (referenceId), the PENDING-until-approved lifecycle, and the critical safety constraint that production moves real money and the confirmation phrase must never be supplied autonomously. That last point is behavior an agent cannot infer from any structured field.

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, zero waste. The action and its result lead, then the lifecycle and safety constraint follow in priority order.

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, and the description compensates by naming the referenceId return and the PENDING state, plus the polling path. Combined with annotations covering the safety profile, an agent has everything needed to call this correctly and responsibly.

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 parameters are already well documented and the baseline is 3. The description adds meaning beyond the schema for the `confirm` parameter by framing it as a human-authorization gate the agent must not self-supply, which is semantic guidance the schema's 'must be exactly ...' text 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 and resource ('Ask a subscriber to approve a payment on their phone') and immediately distinguishes itself from the sibling momo_payment_status by naming it as the follow-up polling step. An agent knows exactly what this initiates without opening the schema.

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 routes the agent to momo_payment_status for follow-up and states the production precondition (explicit human confirmation). It stops short of naming any alternative initiation path or when-not-to-call condition, but the sequencing and gating guidance is 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 and openWorldHint=true, so the safety profile is covered; the description still adds real context by naming the three credentials consumed and disclosing that it performs a live token-mint call (i.e., it hits the network and will fail on bad credentials). 'Moves no money' is a useful explicit reassurance beyond the annotations, though failure behaviour and whether a token is returned are left unstated.

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 sentences with no filler; the operational claim comes first and the safety caveat second. Every clause carries information the agent needs.

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-param, no-output-schema tool the description covers what is checked and the network/money-safety profile, which is nearly everything. It stops short of saying what a success or failure looks like (token returned vs. thrown error), which would fully close the loop given there is 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate and a 4 is appropriate. The description does usefully explain that the credentials are implicit (environment-configured) rather than arguments.

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?

Specific verb ('Check') and resource (the subscription key / API user / API key trio minting an access token), which clearly separates it from money-moving siblings like momo_request_to_pay and from momo_check_account_active (account status, not credential validity). It never names a sibling explicitly, so the differentiation is inferential rather than stated.

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 explicit when-to-use or when-not-to-use statement and no alternative tool is named. The phrase 'Moves no money' implicitly signals a safe pre-flight/sanity check, which an agent can reasonably read as 'call this before live payment calls', but that is inference rather than guidance.

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