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

With no annotations, the description carries full burden. It discloses idempotency (re-adding returns 200) and the effect on send-sms. This goes beyond the schema but lacks details on auth, rate limits, or side effects. Still, it provides key behavioral traits.

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 plus a reference link, with no unnecessary words. Every sentence adds value: purpose, idempotency, limit per request.

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

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

The description covers the core operation, idempotency, and the relationship to send-sms. It lacks output format details (no output schema), but for a simple add operation this is acceptable. The reference link provides additional context.

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

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

The schema provides a description for the 'number' parameter with accepted formats, so the description adds only 'one number per request.' With 0% schema description coverage counted, the tool description compensates partially but does not add significant extra meaning 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 action ('adds one phone number'), the target resource ('to your account's blacklist'), and the effect ('so it is skipped by send-sms'). It distinguishes from sibling tools like delete_blacklist (removal) and get_blacklist (listing).

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 mentions idempotency and 'one number per request,' which are important usage constraints. However, it does not explicitly state when to use this tool versus alternatives (e.g., delete_blacklist, get_blacklist), though the context of blacklist management makes it implicit.

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

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

With no annotations, the description carries full burden. It discloses the cancel window and the error condition (455). However, it does not mention idempotency or side effects like irreversible cancellation.

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 concise sentences plus a reference link. The core action and condition are front-loaded. No redundant 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?

No output schema exists, so description should explain what the tool returns on success. It only mentions the error case (455). Missing description of the success response format.

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%, so description must compensate. The description explains that the order.id comes from a previous send-sms call and must be for a future-scheduled order. This adds context beyond the bare 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 that cancel_order cancels a future-scheduled SMS order created via send-sms before dispatch. It distinguishes this tool from siblings like send_sms by specifying the precondition of a future sendDateTime.

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 tells when to use: only for orders that have not started sending. States that once in the send pipeline, cancellation fails with error 455. Provides a reference link for more details.

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?

Given no annotations, the description discloses non-idempotency and error behavior, and references external docs. It could be more explicit about authentication or rate limits but covers the key behavioral traits.

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, two sentences with a reference, front-loading the purpose and effect without unnecessary 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?

For a simple tool with one parameter and no output schema, the description covers purpose, behavior, error case, and provides an external reference, making it complete enough for correct usage.

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 describes the number parameter with accepted formats. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool removes a phone number from the blacklist and explicitly distinguishes from sibling tools like add_blacklist and get_blacklist by specifying the effect on SMS delivery.

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 when to use (to allow delivery to a number) and mentions non-idempotency and error conditions. However, it does not explicitly contrast with add_blacklist for adding numbers or suggest 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?

The description explicitly states the tool has no side effects and consumes no credits, which is critical behavioral information. With no annotations provided, the description fully carries the burden of transparency, and it does so effectively.

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 concise sentences front-load the core function and then provide usage context. A reference link is included. Every sentence is informative without 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 the tool has no parameters and no output schema, the description fully covers what the tool returns (balance and SMS count) and its side-effect-free behavior. It is complete enough for an agent to understand when to use and what to expect.

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 no parameters, so schema coverage is 100%. The description adds value by explaining what the response contains (balance and SMS count), which goes beyond simply naming the tool. Given the absence of parameters, this explanation is valuable for correct usage.

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 returns TL balance and number of standard SMS messages it can fund. It uses a specific verb ('get') and resource ('balance'). No sibling tools serve a similar purpose, so it is well-differentiated.

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 states the tool is safe for verifying authentication and checking remaining budget before a campaign, giving clear context for when to use. It does not explicitly mention when not to use or alternatives, but no sibling performs a similar function.

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

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

Discloses no side effects and no credit consumption, which is good. However, omits details on pagination and filtering behavior beyond what is in the schema. With no annotations, description carries full burden but could be richer.

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 plus a reference link. Efficient and front-loaded with purpose. Minimal 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?

Missing details on pagination behavior, filter usage, and return format. No output schema provided. For a tool with nested parameters, the description is incomplete.

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?

Input schema has detailed descriptions for all parameters (page, rowCount, filter), so baseline is 3. Description adds no additional parameter meaning 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?

Clearly states it returns the list of blocked phone numbers and explains the effect (skipped during send-sms). Distinguishes from siblings like add_blacklist and delete_blacklist.

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?

Mentions 'no side effects and consumes no credits', which implies safe usage, but does not explicitly state when to use versus alternatives or when not to use. No comparative guidance with 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 disclose behavior. It thoroughly describes the response structure (status, counters, timestamps, sender, price, per-recipient status) and pagination. However, it does not mention authentication requirements or rate limits.

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

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

The description is concise, with two short paragraphs covering response contents and pagination. A reference link is included. Could be slightly more streamlined but effectively communicates necessary info.

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 lack of output schema, the description adequately explains the return values and pagination. It references external docs for completeness. Sibling context is clear. Minor gap: no error scenario coverage.

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 has detailed descriptions for each parameter (id, page, rowCount), so the description adds little beyond confirming pagination. Schema description coverage is effectively high, keeping baseline at 3.

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 returns delivery reports for orders created via send-sms, listing specific fields. This distinguishes it from sibling tools like get_reports and get_balance, which serve different purposes.

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 after a send-sms call but does not explicitly state when not to use it or compare with alternatives like get_reports. Pagination details are mentioned but not prerequisites or error handling.

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 full burden. It clearly indicates this is a read-only retrieval (returns list, no destructive language) and describes the response contents (counters, timestamps, sender). It does not explicitly say 'read-only', but the context implies it. The lack of explicit destructive caveats is acceptable for a 'get' 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 concise (3 sentences), front-loads the main purpose, and uses every sentence to add value (purpose, limitations, use cases, sibling reference). No extraneous 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?

For a list endpoint without output schema, the description sufficiently explains the response (counters, timestamps, sender), pagination (page parameter), and typical usage. It also links to external documentation. The sibling tools are contextually relevant for disambiguation.

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%, so the description must compensate for parameter meanings. However, the description only mentions 'given date range' and does not describe the structure of the filter parameter, the start/end format, the page parameter, or the constraints (e.g., 10-day limit). The schema does provide some parameter descriptions, but the tool description fails to add value beyond what the schema already offers.

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 returns an aggregate summary list of SMS orders within a date range, differentiating it from the per-recipient detail tool (get_report). It identifies the resource (SMS orders), the verb (returns list), and the scope (summary, date-filtered).

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 tells when to use this tool (for aggregated summaries) and when to use an alternative ('For recipient-level details, call get-report'). It provides typical use cases like dashboards and periodic analytics. However, it does not explicitly state when not to use the tool beyond the sibling reference.

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?

States 'no side effects and consumes no credits,' which are critical behavioral traits. With no annotations, this disclosure is sufficient. Could mention rate limits, but not necessary for a simple list endpoint.

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

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

Three concise sentences plus a reference link. Each sentence adds value: purpose, usage context, and behavioral notes. No unnecessary 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?

Completely covers what the tool does, its purpose in relation to send-sms, and its safety profile. No output schema needed since return value is clearly described as a list of sender IDs.

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?

No parameters exist in the schema (0 params, 100% coverage), so description doesn't need to add param info. Baseline 4 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?

Clearly states it returns the list of sender IDs (headers) registered and approved on the account. The verb 'returns' and resource 'sender IDs' are specific. Siblings include unrelated tools like blacklist and balance, so no confusion.

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

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

Explicitly explains that the result is used in send-sms's order.sender field and that non-list values are rejected. Provides clear context for when to use, though no direct alternatives or when-not-to-use 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?

No annotations provided, so the description must disclose behavioral traits. It states no side effects and no credit consumption, but lacks details on rate limits, authentication, or error behavior. Reference to external docs partially compensates.

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, front-loaded with purpose, and every sentence adds value. No wasted words, and the reference link is appropriately placed.

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 nested input schema and no output schema, the description covers basic usage but lacks details on return format, error handling, or comparison with sibling tools. Complete enough for a simple check tool but could be improved.

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% per context, so description must compensate. The description does not explain individual fields (e.g., brandCode, recipientType), only mentions 'recipient' and 'consent status'. This is insufficient for proper 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 ('returns') and resource ('current İYS consent status'), and distinguishes from the sibling tool iys_register by mentioning verification of a submitted record.

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 use cases are provided (verifying processed records, checking consent before sending, audit reports), and it states no side effects, but does not explicitly list when not to use or 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?

Without annotations, the description carries the full burden. It discloses atomicity (one bad record fails the whole batch), the 5000 limit, and the legal requirement. It lacks response details and authentication requirements, but the disclosed traits are valuable.

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 moderately concise, front-loaded with the core purpose, and includes a reference link. It could be slightly more streamlined but is not overly verbose.

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

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

Given the complexity (nested parameters, no output schema, no annotations), the description should discuss response behavior, authentication, and error handling for the endpoint itself. It only mentions downstream rejection errors. Atomicity and limits help, but overall completeness is moderate.

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 adds only minimal parameter insight: the 5000 per request limit and atomicity. It does not explain brandCode, list structure, or consentDate constraints beyond what the schema provides. Since schema description coverage is 0%, the description should compensate but falls short.

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 İYS consent records for the Turkish national registry, with a specific verb ('creates') and resource ('İYS consent records'). It distinguishes from sibling tools like iys_check and send_sms by focusing on registration.

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 strong context: it emphasizes mandatory registration for commercial SMS and warns of rejection codes 468/469/470 if consent is missing. It does not explicitly list when not to use this tool, but the context is clear enough.

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 covers key behaviors: the intentional misspelling of 'receipents' for backward compatibility, APITEST sender restrictions, scheduling nuances, and the automatic appending of B186 operator code. However, it omits rate limits or error handling 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 concise with two sentences and a reference link. It front-loads the main action and provides a reference for details. However, it could be slightly more structured (e.g., bullet points) for better readability.

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

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

Given the complexity with nested objects and no output schema, the description fairly covers the essential behavioral aspects like order handling, sender restrictions, and scheduling. It also includes a reference for additional details, making it reasonably 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 description adds minimal parameter info beyond what the input schema already provides. The schema has detailed descriptions for parameters like iys and sender, so the baseline is 3 due to high schema description coverage. The description does mention the 'receipents' misspelling, which is helpful but not critical.

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 delivers SMS to one or many numbers in a single request and returns an orderId. It distinguishes from sibling tools like get_report or cancel_order by focusing on sending SMS.

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 does not explicitly state when to use this tool vs alternatives, but the purpose is clear. It could mention that for checking delivery reports, use get_report, but overall it's adequate.

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