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

With no annotations, the description carries the burden of behavioral disclosure. It usefully explains that the operation is asynchronous and returns a pipe-delimited string per account type via callback. However, it misses other behavioral aspects such as required permissions, error handling, or the role of the resultUrl parameter, so transparency 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?

The description is two sentences, each adding value: the first states the core purpose, the second explains the asynchronous callback behavior. There is no wasted wording, and it is front-loaded with the main 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?

No output schema exists, so the description must explain the return result. It mentions the pipe-delimited string per account type, which is helpful, but it lacks parameter semantics and detail about how the callback is delivered or correlated. For a query tool, this is adequate but leaves clear gaps.

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 0% description coverage, and the description does little to clarify the three parameters (remarks, resultUrl, shortCode). It implicitly hints at resultUrl through the asynchronous callback, but it never explicitly explains what each parameter does or how they relate to the balance query.

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 queries the balance of a M-Pesa business account, using a specific verb ('Query') and a precise resource. This distinguishes it from sibling tools like transaction_status or query_org_info, which target different data.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contexts where this tool is preferred. The only hint is that it queries balance, but no explicit usage direction is 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?

No annotations are present, so the description must carry full behavioral burden. It only states the action and target types; it does not disclose that this is a mutating financial operation, any authorization or prerequisite requirements, callback behavior, or error semantics. This is a significant gap for a payment 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, front-loaded sentence with no filler. It is concise and well-structured, though it omits necessary details for a complex tool. The brevity is appropriate for a summary, but not for a complete specification.

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 8 parameters, no output schema, and no annotations, the description is severely under-specified. It provides only a high-level purpose without addressing parameter interactions, callback results, or operational caveats. This is insufficient for an agent to safely and correctly execute the 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 63%, and the description adds minimal value beyond the schema. It restates the target enum values but does not clarify ambiguous parameters like shortCode, resultUrl, or remarks, nor does it explain relationships such as accountReference being required only for paybill. The description fails to compensate for the undocumented parameters.

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 'Pay another business' followed by three specific target types (PayBill, Buy Goods till, B2C working account top-up). This distinguishes the tool from sibling payment tools like b2c_payment (pay a customer) and c2b_simulate (customer-to-business), making the purpose unmistakable.

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 defines the tool's scope but does not explicitly state when to use it versus alternatives like b2c_payment or business_to_pochi. The three target types give some context, but no exclusions or comparative guidance are provided.

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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses the key asynchronous nature and callback result delivery, which is important. However, it omits other behavioral traits such as authentication requirements, idempotency, or the fact that it initiates a real financial transaction (though 'pay money out' implies this). It adds value but is not comprehensive.

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, and each sentence adds value: the first defines the scope, the second explains behavior. No 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 7 parameters, no output schema, and no annotations, the description is too sparse. It does not mention the callback URL parameter (resultUrl), the shortCode, or what the initial response looks like. For an asynchronous payment tool, this leaves the agent without critical operational details, making it incomplete for correct invocation.

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 only 43% description coverage (3 of 7 parameters described). The description does not explicitly mention any parameter names or how to use them. It lists use cases (salaries, winnings) that map to commandId enum values, but this connection is implicit. The description fails to compensate for the low schema coverage, leaving several parameters (remarks, occasion, resultUrl, shortCode) unexplained in both schema and description.

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 ('Pay money out') and identifies the resource ('a customer'), and explicitly lists use cases (refunds, withdrawals, salaries, promotional winnings). It clearly distinguishes from sibling tools like b2b_payment (business-to-business) and b2c_payment_and_wait (synchronous variant) by mentioning asynchronous behavior.

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: it is for paying money out to customers, and it is asynchronous via callback. This implies when to use it over b2c_payment_and_wait, but it does not explicitly name alternatives or exclusions. The guidance is sufficient for typical use cases but lacks an explicit contrast with the synchronous counterpart.

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?

With no annotations, the description carries the full burden of disclosing behavior. It reveals that the operation waits for a callback and returns a receipt number on success, but it does not disclose failure modes, timeout behavior, callback semantics, or any side effects. For a money-moving tool, this is a significant transparency gap.

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 immediately states the action, the waiting behavior, and the success return value. Every word serves a purpose; there is no fluff or 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?

The tool is complex (8 parameters, no output schema, no annotations), but the description only covers the success path. It does not explain what happens on failure, how timeoutSeconds affects behavior, prerequisites like shortCode setup, or the structure of the callback. This is insufficient for an agent to use the tool confidently in varied scenarios.

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 only 38% (3 out of 8 parameters described), and the description adds no parameter-level meaning. It does not mention phoneNumber, amount, commandId, or any of the other parameters. The description is silent on how to use the tool's inputs, leaving the agent without adequate guidance for the 5 undocumented parameters.

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 a specific action: 'Pay money out to a customer' and distinguishes this tool from siblings by explicitly adding 'and wait for the result callback, returning the receipt number on success.' This sets it apart from b2c_payment and b2b_payment, which likely do not wait for a callback.

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 this tool is for use when a synchronous result is needed (waiting for callback), but it does not explicitly state when to prefer this over b2c_payment or provide exclusions. The 'wait' behavior is a clear contextual signal, but no direct comparison or alternative is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't mention whether payment is immediate, requires confirmation, triggers callbacks, or has any side effects. This is a significant gap for a payment 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 with zero wasted words. It is front-loaded with the verb and target, making it immediately scannable. However, it is short to the point of being under-specified, but that is a completeness issue, not a conciseness issue.

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 5 parameters, no annotations, and no output schema, so the description must carry substantial context. It only provides a minimal statement of purpose, omitting crucial details about expected outcomes, callback behavior, or error scenarios. It is far from complete for a payment operation.

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 covers only 2 of 5 parameters (amount and phoneNumber) with descriptions. The tool description adds no additional meaning, leaving remarks, resultUrl, and shortCode entirely undocumented. It fails to compensate for the low 40% 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?

The description clearly states the action (Pay) and the target resource (a Pochi la Biashara number), which aligns with the tool name. It distinguishes from siblings like b2c_payment or stk_push by targeting Pochi la Biashara specifically, though it doesn't explicitly contrast with them.

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 guidance is provided on when to use this tool versus alternatives like stk_push, b2c_payment, or c2b_simulate. The description merely states the action without any context, exclusions, or preconditions.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the registration action and prerequisite, but does not disclose side effects (e.g., whether it overwrites existing URLs), authentication requirements, or error behavior. This is a significant gap for a mutation 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?

Two sentences, front-loaded with the core purpose and followed by a key usage note. 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?

Given the tool's simplicity (4 params, no output schema) and lack of annotations, the description is adequate but not rich. It covers the core action and prerequisite, but leaves out potential details like overwrite semantics, response format, or whether this must be repeated for each shortcode. Still, it is more complete than a typical minimal description.

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 only 25% (only responseType is described in schema). The description adds meaning for validationUrl and confirmationUrl by calling them 'validation and confirmation URLs', and implies shortCode via 'per shortcode'. However, it doesn't explain shortCode explicitly or enhance responseType beyond the schema's existing enum description.

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 a specific verb ('Register') with a specific resource ('validation and confirmation URLs') and the context ('when a customer pays your PayBill or till directly'). It naturally distinguishes from siblings like c2b_simulate or pull_register by focusing on URL registration for C2B.

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: it is a one-time setup step ('Required once per shortcode') and is needed 'before C2B notifications work'. It does not explicitly mention alternatives or exclusions, but the usage scenario is well implied.

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?

With no annotations, the description must carry behavioral disclosure. It discloses a key constraint (sandbox-only) but does not explain what the simulation actually does—e.g., whether it triggers a callback, returns a success response, or has side effects. This is minimal but non-tautological information.

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 conveys the essential purpose without unnecessary words. Every word contributes value, and it is appropriately short for a tool with a clear focus.

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 5 parameters, no output schema, and no annotations, this brief description is insufficient. It does not explain required versus optional parameters, what response to expect, or any post-simulation behavior (e.g., callback triggering). The agent would need additional context to use 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 description coverage is 0%, and the description does not mention any parameter names or semantics. It only implicitly references concepts like 'shortcode', but does not explain the roles of phoneNumber, amount, commandId, shortCode, or billRefNumber, leaving the agent to infer from names alone.

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 with a specific verb ('Simulate') and resource ('a customer paying your shortcode'). It distinguishes itself from sibling payment tools (e.g., b2c_payment, stk_push) by emphasizing simulation, and the 'Sandbox and simulator only' note further clarifies its role.

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 'Sandbox and simulator only' explicitly tells the agent when to use this tool (in testing/sandbox environments) and implies it should not be used for production payments. While no alternative tools are named, the simulation framing naturally contrasts with real payment operations among siblings.

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?

No annotations are provided, so the description must carry the burden. It discloses the primary behavior (returning the registration date) and adds an interpretive note about fraud risk, but it does not mention return format, error handling, or what happens for unregistered numbers. The fraud risk note adds context, but the disclosure is not comprehensive.

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: the first states the exact purpose, and the second adds a risk-related note. There is no fluff or redundant information, making it efficient 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 simple one-parameter lookup with no output schema, the description adequately explains the return value and includes a useful risk insight. However, it omits details such as date format, behavior for invalid or unregistered numbers, and precise thresholds for 'very new,' so it is not fully 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 schema covers 100% of the parameter descriptions, including 'Number to check.' The tool description does not add any additional parameter semantics beyond what the schema already provides, so 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's function: 'Return the date a number was first registered on the Safaricom network.' This is a specific verb and resource, and it distinguishes the tool from siblings like check_sim_swap, which checks a different aspect.

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 fraud risk assessment with the note 'Very new lines carry elevated fraud risk,' but it does not explicitly state when to use this tool over alternatives or provide exclusions. No alternative tools 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output (a date) and the rationale (fraud signal), but it does not disclose behavior for invalid or unknown numbers, potential errors, or whether this is a read-only operation. For a simple lookup, this is adequate but not detailed.

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 purpose, and contains no filler. The second sentence adds practical usage context without bloat, making it an example of efficient writing.

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 lookup tool with no output schema, the description gives the core purpose and a use case, but it does not describe the return value's structure or edge cases (e.g., no swap ever, invalid number). This is minimally viable but leaves the agent to guess response details.

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 covers 100% of the parameter (phoneNumber) with 'Number to check.' The description does not add any extra meaning or format guidance (e.g., E.164 format), so it relies entirely on the schema. This meets the baseline but does not enrich 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 uses a specific verb ('Return') and a clear resource ('the date a number was last SIM-swapped'), and it distinguishes itself from sibling tools like check_age_on_network by focusing on SIM swap events. It also adds the fraud-signal context, making the purpose unmistakable.

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 provides explicit when-to-use guidance: 'check this before disbursing to an unfamiliar number.' This gives a clear operational context. However, it does not mention alternatives or when not to use the tool, keeping it just below the highest bar.

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?

No annotations are provided, so the description alone must disclose behavioral traits. It only states that it generates a QR code; it does not mention return format, side effects, authentication requirements, or whether it is a read-only operation. This leaves significant behavioral uncertainty.

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 concise sentence with no filler, front-loading the key action and object. It is appropriately sized 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?

The tool has no output schema, so the description should explain what is returned (e.g., an image URL or data). It does not. Additionally, no annotations are present, leaving the agent without information about side effects or safety. The schema is rich, but the description remains incomplete for operational 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?

The input schema covers all parameters with detailed descriptions (100% coverage), so the description needs to add little. It does mention 'till or paybill' and 'specific amount,' but the schema already documents these, and the description omits the phone number option for cpi, so it adds no new value beyond 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?

The description clearly states the tool's function: generating a dynamic M-Pesa QR code for a specific amount and till/paybill. It uses a specific verb ('generate') and resource ('QR code'), and no sibling tools appear to serve the same purpose, making it unambiguous.

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 no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It merely states what the tool does, leaving the agent to infer usage from the name and description.

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?

With no annotations provided, the description carries the burden of conveying behavioral traits. The verb 'Fetch' implies a read-only operation, and 'full callback payload' suggests complete data retrieval, but no details are given about error behavior, prerequisites, or response characteristics. It adds some context but falls short of full 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 a single, concise sentence that front-loads the core action and resource. Every word earns its place, 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 retrieval tool with no output schema and no annotations, the description is largely sufficient. It indicates what the tool does and the return type ('full callback payload'). A tiny gap exists in not mentioning what happens if the correlation id is invalid or not found, but given the low complexity, this is acceptable.

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 provides a 100% descriptive coverage for the parameter, including specific examples (CheckoutRequestID, ConversationID, or Ratiba correlationId). The tool description adds no new meaning beyond what the schema states, so the 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 a specific action ('Fetch') and resource ('full callback payload') for a correlation id, making its intent unambiguous. It implicitly differentiates from sibling tools like list_callbacks by focusing on retrieving a single payload rather than listing callbacks.

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 no guidance on when to use this tool over alternatives or when not to use it. It simply states the action without any contextual cues, exclusions, or references to sibling tools.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states this is a list operation (read-only) and adds ordering ('newest first') and scope ('this server has received') beyond the tool name. It does not mention pagination or response details, but for a simple list operation this is reasonably transparent.

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 with no wasted words. It conveys the core purpose and ordering in six words, making it 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?

Given the low complexity (two optional params, no output schema, no nested objects), the description is generally complete. It explains what the tool lists and the ordering, though it could optionally mention that results can be filtered by kind or limited, but these are partially covered by the 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 description coverage is only 50%, so the description needs to compensate for the undocumented limit parameter. However, the description does not mention either the 'kind' filter or the 'limit' parameter. The only parameter meaning comes from the schema's partial description, so the description adds no value here.

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 and resource: 'List callbacks' clearly indicates the action and object. It further distinguishes the tool by scoping to 'this server' and specifying ordering as 'newest first', which differentiates it from sibling tools like get_callback and pull_transactions.

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 use when you want to view callbacks received by the server, but it does not explicitly state when to use this over alternatives like get_callback (which fetches a single callback) or pull_transactions (which retrieves transactions). No exclusions or alternative guidance is provided.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'register,' which implies a mutation, but it does not explain side effects (e.g., overwriting existing registrations), prerequisites, or the outcome of registration. This is insufficient for a config 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 core purpose. Every word earns its place, with no unnecessary filler 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?

The tool has 3 parameters, no output schema, and no annotations, so the description needs to provide sufficient context for correct invocation. While it explains the purpose, it does not cover return values, error conditions, or parameter usage details, leaving significant gaps for an agent.

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 only 33% (one of three parameters is described). The tool description mentions 'shortcode' but does not explain the meaning or expected format of shortCode, callbackUrl, or nominatedNumber beyond what the schema already provides. It fails to compensate for the low 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?

The description clearly states the action ('Register a shortcode') and the specific resource ('Pull Transactions API'). It also provides context ('fetch missed C2B transactions after an outage') that differentiates it from sibling tools like pull_transactions or c2b_register_urls.

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 gives clear context for when to use this tool (after an outage to enable fetching missed C2B transactions), but it does not explicitly state exclusions or alternatives. The context is useful but not as explicit as naming 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?

No annotations are provided, so the description must fully disclose behavior. It states the tool fetches transactions, but does not mention whether it is read-only, how pagination behaves, whether shortCode is required/optional, or what the response looks like. This leaves significant behavioral assumptions unaddressed.

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 scope, the second provides a practical use case. Every word adds value, and the structure 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?

For a 4-parameter tool with no output schema and no annotations, the description gives a clear purpose and usage context. However, it omits behavior around pagination, shortCode semantics, and return format, which are needed for fully confident invocation. It is adequate but not comprehensive.

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 documents startDate, endDate, and offsetValue well. The description reinforces the time-window semantics. However, shortCode has no schema description and the description does not clarify its purpose, leaving an ambiguity that the schema and description together fail to resolve.

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 ('Fetch') and resource ('C2B transactions') with a clear scope ('for a time window'). It distinguishes pull_transactions from siblings like list_callbacks and transaction_status by focusing on C2B transaction retrieval.

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 explicitly states a use case: 'Useful for reconciliation when callbacks were missed.' This gives clear context for when to use the tool. It does not mention exclusions or alternatives, but the primary usage scenario is well covered.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Look up' which implies a read-only operation, but it does not explicitly state the operation is non-mutating, does not initiate a payment, or describe any side effects, error handling, or authentication requirements. This lack of explicit behavioral context is a significant gap.

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 and well-structured, with two sentences. The first sentence front-loads the core purpose, and the second adds the usage context. Every word adds value, and there is 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?

Given the tool's simplicity (2 params, no output schema), the description is adequate: it states what the tool returns (registered name and tariff) and when to use it. It could be slightly richer by explaining the structure of the response or edge cases, but for a simple lookup tool, 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?

Schema description coverage is 100% (both shortCode and identifierType have descriptions), so the schema already provides parameter meaning. The tool description does not add any additional parameter details beyond what the schema states, thus 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's action ('Look up') and resource ('registered name and tariff of a PayBill or till'), using specific terminology. It also provides context ('confirm you are paying the business you intend to before sending money') that differentiates it from payment initiation siblings, effectively conveying its role as a pre-transaction verification tool.

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 gives a clear usage scenario: 'Use this to confirm you are paying the business you intend to before sending money.' This explicitly indicates when to use the tool but does not mention when not to use it or name alternative sibling tools, 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?

With no annotations, the description carries the full transparency burden. It discloses important behaviors: the customer approval via M-Pesa prompt and the unique standing order name requirement. However, it omits other relevant behavioral traits such as synchronous/asynchronous behavior, error handling, or return value details, leaving gaps.

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, consisting of two sentences that front-load the primary purpose and use cases. There is no redundant fluff, and every sentence provides useful information.

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 (11 parameters, no annotations, no output schema), the description covers the core purpose and a couple of constraints but lacks key operational details such as what happens after creation, whether it is asynchronous, and what the response format is. It is sufficient for basic selection but not fully 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 description coverage is 64%, and most parameter descriptions are present. The description adds some context (e.g., standing order name uniqueness is repeated from schema), but it does not compensate for the undocumented parameters like callbackUrl, shortCode, transactionDesc, and accountReference. The added value is marginal beyond 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?

The description clearly states the tool creates an M-Pesa Ratiba standing order for recurring collection, with specific use cases. It uses a clear verb and resource, but does not distinguish from the sibling tool ratiba_create_and_wait, so it lacks explicit sibling differentiation.

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 on when to use the tool (recurring collections like subscriptions, loan repayments), but does not explicitly state alternatives or when not to use it. The sibling ratiba_create_and_wait is not mentioned, so usage guidance is helpful but not exhaustive.

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?

With no annotations, the description must disclose behavior itself. It does state that the tool waits for approval and returns the settled outcome, which is useful. However, it omits important behavioral details such as timeout behavior (timeoutSeconds parameter), what happens if approval fails, and any side effects.

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 verb and resource, and every word adds value. 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?

The tool is complex (12 parameters, no annotations, no output schema), but the description only covers the basic purpose and result. It misses essential context like timeout handling, failure modes, and guidance on when to use this vs. ratiba_create, making it incomplete for reliable agent invocation.

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 covers only 58% of parameters, leaving several (shortCode, callbackUrl, transactionDesc, accountReference) without descriptions. The tool description adds no parameter semantics beyond what the schema already provides, so it fails to compensate for the coverage gap.

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 ('Create an M-Pesa Ratiba standing order') and the unique blocking behavior ('wait for the customer to approve it'). This differentiates it from sibling tools like ratiba_create, which likely does not wait.

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 used when you need to wait for customer approval and receive the settled outcome. However, it does not explicitly mention alternatives (e.g., 'use ratiba_create if you don't need to wait') or provide 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?

No annotations are present, so the description must carry the burden of disclosing behavioral traits. It only says 'reverse' without explaining whether the operation is irreversible, asynchronous, requires special permissions, or what errors may occur (e.g., already reversed transactions). This is minimal behavioral detail for a financial mutation 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 sentence, front-loaded with the action and object, with zero filler words. It is appropriately concise for the limited content it conveys.

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 5 parameters, no output schema, and no annotations, yet the description only provides a one-line summary. It omits important context such as expected callback/result behavior, reversibility limits, and whether the reversal is immediate or queued. This is incomplete for an agent to invoke the tool reliably.

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 60% (amount, transactionId, receiverShortCode documented). The description itself adds no parameter-level meaning beyond saying 'your shortcode', which loosely maps to receiverShortCode. Parameters like resultUrl and remarks remain unexplained, and the description does not compensate for the coverage gap.

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 ('Reverse') and resource ('a transaction that was paid into your shortcode'), clearly distinguishing this from transaction lookup tools like transaction_status. It precisely identifies the target operation and scope (inbound shortcode payments).

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: reversing an inbound payment to a shortcode. However, it does not explicitly state when not to use it or mention alternatives such as transaction_status for checking a transaction before reversal. The guidance 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?

With no annotations provided, the description carries full burden. It accurately discloses what is reported and is consistent with a read-only health check, but it does not explicitly state that the operation is non-mutating, safe, or free of side effects. Adequate but not deep.

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 exactly two sentences with no redundant phrases. It front-loads the tool's report contents and then gives a clear usage directive. Every word earns its place.

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 (0 params, no output schema), the description covers the essential context: what information is reported and when to use it. It doesn't describe the output format in detail, but the listed report items suffice for a diagnostic 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?

The tool has zero parameters, so the schema is empty and coverage is 100%. There are no parameter semantics to explain, and the description appropriately adds nothing. Baseline of 4 for zero-parameter tools 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 the specific verb 'Report' and lists three concrete data categories (current mode, configured credentials, callback receiver status), making the tool's purpose unmistakable. This distinguishes it clearly from the sibling transaction and business operation 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 phrase 'Start here when something is not working' provides explicit when-to-use guidance, positioning this as the first diagnostic step. It does not name alternative tools or exclusions, but the directive is clear and actionable.

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?

No annotations are provided, so the description bears full responsibility for disclosing behavior. It clearly warns that the tool does NOT confirm payment and returns an acknowledgement immediately, covering the most critical behavioral nuance for an async payment prompt.

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 with high information density: first states the action, second clarifies the asynchronous behavior and directs alternatives. Every clause earns its place with zero 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?

Given 7 parameters, no output schema, and no annotations, the description covers the core selection criteria—what it does, what it returns, and when to choose a sibling. It doesn't detail error states or callback mechanics, but the acknowledgement/confirmation distinction is the most important missing context for an agent.

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 describes all 7 parameters with full coverage, and the description does not add additional field-level meaning beyond referring to the 'customer' and 'payment prompt'. This meets the baseline for schema-covered tools but adds no extra parameter 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?

The description explicitly names the action ('Send'), the resource ('M-Pesa payment prompt (STK push)'), and the target ('to a customer'), making the primary function unmistakable. It also distinguishes itself from the sibling tool stk_push_and_wait by clarifying it does not confirm payment.

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 context that this tool returns immediately without payment confirmation, and explicitly directs users to stk_push_and_wait when the outcome is needed. This effectively tells when to use this tool versus the key alternative.

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?

With no annotations, the description carries the burden. It discloses blocking behavior (wait for customer), and that it returns a settled outcome with receipt number. It doesn't mention timeout or failure modes, but the schema covers timeout details.

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 three concise sentences, front-loaded with the action and outcome, with no fluff or 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 tool with 8 parameters and no output schema, the description covers core behavior, return value, and when to use it. It could mention timeout or related tools, but the schema ably covers parameter details.

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 covers 100% of parameters with rich descriptions, so baseline 3 applies. The description itself does not add parameter-level detail, but it isn't needed given full 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?

The description clearly states it sends an M-Pesa payment prompt and waits for accept/decline, returning the settled outcome. This distinguishes it from siblings like stk_push (which likely only sends) and stk_query (which queries 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?

The description explicitly says 'Use this when you need to know whether the payment actually completed,' giving a clear use case. It doesn't name alternative tools but implies a contrast with non-waiting push tools.

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?

With no annotations, the description carries the full burden. It only states it queries status, implying a read operation, but does not disclose expected response format, error conditions, authentication needs, or whether it may poll. Minimal behavioral context is provided beyond the core action.

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 sentence that is direct and free of redundancy. It conveys the essential action and the key parameter without unnecessary words, making it highly concise and easily 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?

The tool lacks an output schema, so the description should clarify what the query returns, but it does not. It also leaves shortCode unexplained and provides no information about error cases or response structure. For a two-parameter tool with no annotations, this is insufficient.

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 only 50% (checkoutRequestId has a description, but shortCode has none). The description reinforces checkoutRequestId's meaning but adds nothing about shortCode. Since the description does not compensate for the missing shortCode semantics, the parameter guidance is incomplete.

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 queries the status of a previous STK push using a CheckoutRequestID. It uses a specific verb ('Query') and resource ('status of a previous STK push'), distinguishing it from related tools like stk_push (which initiates) and transaction_status (which is more generic).

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: after a previous STK push, to check its status. However, it does not explicitly compare with alternatives or provide when-not-to-use guidance. For example, it does not clarify whether to use this instead of transaction_status for STK payments.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remit tax' implies a financial mutation with side effects, but the description does not disclose whether the operation is asynchronous (despite a resultUrl parameter), what callbacks are expected, how funds are deducted, or any reversal/cancellation behavior. For a money-movement tool, this is a significant gap.

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 single sentence is concise, front-loaded, and contains no fluff. However, it is extremely terse for a five-parameter financial tool, and could include additional needed context without sacrificing 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 financial nature, five parameters, no annotations, and no output schema, the description is severely under-developed. It lacks behavioral details, error semantics, callback information, and parameter explanations, making it insufficient for confident invocation.

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 only 40%, with descriptions for amount and paymentRegistrationNumber only. The tool description merely mentions the PRN, duplicating the schema without adding meaning for parameters like resultUrl, shortCode, or remarks. The agent is left without guidance for three of five parameters.

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 the specific verb 'Remit' and names the resource 'tax to the Kenya Revenue Authority', with the mechanism 'using a Payment Registration Number' clearly distinguishing it from generic payment tools like b2c_payment or stk_push. This is a specific verb+resource+scope formulation.

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 KRA tax remittance, but it does not explicitly state when to use it versus siblings (e.g., b2c_payment, b2b_payment) or provide exclusions or prerequisites. The context is clear but alternative guidance is absent.

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?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It implies a read-only operation through 'Check,' and gives a safety-related use case, but it does not explicitly state that it is non-mutating or idempotent. This is adequate but leaves room for more explicit assurance.

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, front-loaded with the primary purpose, and includes actionable usage guidance. No filler or repetition of schema details. Every word contributes 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?

The tool has five parameters, three of which are not explained, and there is no output schema. The description does not explain what the status response contains or how to interpret it, which is crucial for an agent to act on the result. Missing return-value semantics is a significant gap for a status-checking 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?

The description explains the two primary identifier parameters (transactionId and originalConversationId) and adds context about the timeout scenario, but it leaves three other parameters (remarks, resultUrl, shortCode) completely unexplained. With schema coverage at 40% and no descriptions for these fields in the schema, the description fails to compensate for the gap.

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: 'Check the status of any past transaction by receipt number, or by conversation id when the original request timed out.' It uses a specific verb ('Check') and resource ('status of any past transaction'), and distinguishes itself from siblings by covering any past transaction, not just specific payment types.

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?

Explicit guidance is given: 'Use this before retrying a payment you are unsure about.' It also specifies a particular scenario (timeout) when to use conversation id instead of receipt number, helping the agent decide when to call this tool versus alternatives like stk_query or reversal.

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?

There are no annotations, and the description only states the check operation without disclosing return format, error behavior, or potential side effects. Since 'check' implies a read-only operation, the agent may infer safety, but the tool does not specify whether it returns a boolean, status object, or what happens on invalid input.

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 sentence that states the core purpose without extraneous detail. It is front-loaded with the action and resource, making it quick to parse.

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 lacks an output schema and annotations, and the description does not specify what the response looks like or any usage constraints. While it is a simple validation check, the absence of return semantics and edge-case behavior leaves the description incomplete for an agent to invoke with confidence.

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 provides 100% coverage with descriptions for both required parameters (phoneNumber and idNumber), and the tool description clarifies the relationship between them. The description adds no extra syntax or format details beyond 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 uses a specific verb 'Check' and clearly defines the resource: whether a phone number is registered against a national ID number. This distinguishes validate_identity from sibling tools focused on payments/transactions, making the tool's purpose unambiguous.

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 identity verification but provides no explicit guidance on when to prefer it over alternatives, nor any exclusions or prerequisites. No sibling tool is mentioned, leaving the agent to infer usage context from the tool name alone.

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