Server Quality Checklist

Tool Scores

• upload_profilesC
  2.4/5.0
  Behavior2/5

  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. 'Upload or update' implies a mutation, but it does not disclose whether updates merge or replace, whether authentication is required, rate limits, idempotency, or what the response looks like. This is a significant gap for a write operation.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no redundancy. It communicates the core action and resource in a compact manner, which is appropriately sized for a simple tool, though it sacrifices substance for brevity.

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

  Completeness1/5

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

  With no output schema, no annotations, and a schema with 0% descriptions, the description must provide comprehensive context to enable correct invocation. It does not. The agent has no idea how to structure the profiles array, what fields are required beyond the schema's minimal requirements, or what the response will be. For a mutation tool with one complex parameter, this is seriously incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0% (no descriptions in the schema properties), and the tool description adds no meaning beyond the field names. The single 'profiles' parameter accepts an array of complex objects, but the description does not explain the structure, required fields (like 'type' and 'identity'), or how to format profileData. The description fails to compensate for the schema’s lack of detail.

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

  Purpose4/5

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

  The description states a clear verb ('Upload or update') and resource ('user profiles in CleverTap'), which distinguishes it from event-related siblings like upload_events. However, it does not elaborate on the scope of 'profiles' (e.g., user identity vs. objectId), so it leaves some ambiguity but the core purpose is clear.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention conditions like 'use this for profile creation/modification, use upload_events for events,' nor any prerequisite knowledge. The description does not help an agent decide between this and sibling tools beyond the resource name.

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

• get_profile_countC
  2.7/5.0
  Behavior2/5

  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 only states that it returns a count of user profiles, without clarifying whether this is a distinct count, an approximation, or real-time data. It also does not mention any rate limits, permissions, or the exact output format (e.g., a plain number vs. an object). This lack of transparency could lead to incorrect assumptions.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the primary action ('Get count'). There is no redundant phrasing or unnecessary detail. For a simple count tool, this level of brevity is acceptable, though a short example or note on expected output could be added without sacrificing conciseness.

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

  Completeness2/5

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

  Given the tool has three required parameters and no output schema, the description is insufficient. It does not explain what the return value looks like (e.g., a number, an object with a count field), whether the count is distinct profiles or total events, or any dependencies (e.g., events must have been uploaded via upload_events). The lack of these details could lead to misapplication or confusion, especially in the context of many sibling tools.

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

  Parameters2/5

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

  The schema covers 67% of parameters (from and to have descriptions, event_name does not). The description adds almost no semantic value beyond the schema: it just repeats 'specific event' without explaining what event_name should be or providing format details. It does not compensate for the missing schema description of event_name, and it does not clarify the date format beyond what is already in the schema.

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

  Purpose4/5

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

  The description clearly states the action (get count) and the resource (user profiles that performed a specific event). It implies uniqueness of profiles rather than events, which differentiates it from sibling tools like get_event_count. However, it does not explicitly mention the time range or how it differs from similar count tools, so it's clear but not fully distinguishing on its own.

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

  Usage Guidelines2/5

  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 its many siblings, such as get_event_count, get_events, or get_profiles. There is no mention of alternatives, prerequisites, or conditions under which this tool is preferred. For a tool with a large sibling set, this is a significant gap.

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

• send_smsC
  2.7/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention any side effects, delivery guarantees, rate limits, cost implications, or response format. The description only states the action without any information that would help the agent anticipate consequences, making it severely lacking.

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

  Conciseness4/5

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

  The description is a single, concise sentence that delivers the core action and target. It is not verbose and gets to the point quickly, aligning with the principle of front-loading key information. However, it is so brief that it sacrifices useful context, but this dimension rewards conciseness over completeness, so a 4 is appropriate.

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

  Completeness2/5

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

  Given the tool has nested objects, no output schema, and no annotations, the description should provide substantial context to make up for these gaps. It only covers the basic purpose and leaves out usage scenarios, constraints, and expected behavior. The absence of any additional context makes it incomplete for safe and correct invocation.

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

  Parameters3/5

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

  The schema already describes both parameters (to and content) with examples, giving 100% coverage. Since coverage is high, the baseline is 3. The description adds no additional meaning beyond what the schema provides, so it stays at baseline; it does not compensate for any ambiguity in the schema's cryptic formatting.

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

  Purpose4/5

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

  The description clearly states the action (send), the resource (SMS), and the target (specific users). It is distinct from sibling tools like send_push, send_email, and send_whatsapp based on the channel name. However, it lacks an explicit differentiation from other send tools or a note about the 'direct' aspect, which would have earned a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives, prerequisites (e.g., user identity availability), or any exclusions. The phrase 'directly to specific users' hints at targeting, but it doesn't clearly explain the intended use case or contrast with sibling tools that might be more suitable for bulk or campaign messaging.

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

• get_profilesC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full behavioral burden. It mentions that the tool returns a cursor, which is a behavioral trait, and implies a read operation via 'download'. However, it does not disclose whether the operation is read-only, how pagination works (e.g., need to use get_profiles_page with the cursor), or any limitations such as date range semantics or rate limits. The description is minimal and leaves critical behavioral details unstated.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. The primary purpose is front-loaded in the first sentence, and the return type in the second. Every word earns its place, making it efficient and easy to parse.

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

  Completeness2/5

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

  Given the tool has four parameters, three required, no output schema, and no annotations, the description is insufficiently complete. It does not explain the pagination flow (what a cursor is, how to use it with get_profiles_page), valid event_name values, the meaning of the date range, or the structure of the returned data. An agent would struggle to use this tool correctly without additional external knowledge.

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

  Parameters2/5

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

  The schema covers 50% of parameters (to and from have format descriptions, batch_size has a default but no description, event_name has no description). The description adds meaning only for event_name by stating 'based on an event they performed', but it does not explain the date range (from/to) or batch_size. It does not compensate for the uncovered parameters, leaving the agent with incomplete understanding of all inputs.

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

  Purpose4/5

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

  The description clearly states the tool downloads a list of user profiles filtered by an event, and mentions the return of a cursor. This distinguishes it from singular profile retrieval (get_profile) and count tools, though it does not explicitly differentiate from get_profiles_page. The 'returns a cursor' hint implies a paginated initial call, making the purpose reasonably clear.

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

  Usage Guidelines2/5

  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 get_profiles_page or get_profile_count. There are no prerequisites, exclusions, or conditions for selection. The description only states what the tool does, leaving the agent to infer usage context.

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

• send_emailC
  2.8/5.0
  Behavior2/5

  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 only states the action without explaining side effects, permission requirements, rate limits, or what happens on success/failure. As a send operation, it implies mutation, but the description does not clarify whether the email is queued, sent synchronously, or if there are constraints like max recipients. This is a significant gap for a mutating tool.

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

  Conciseness3/5

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

  The description is a single concise sentence with no waste. However, it is under-specified rather than efficiently complete. It front-loads the core action but lacks any additional structural elements like examples or caveats. It is not verbose, but the brevity compromises informativeness, so a middle score is appropriate.

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

  Completeness2/5

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

  This tool has two nested object parameters, no output schema, and no annotations. The description is minimal and does not explain the expected format of the 'from' object, whether 'to' supports multiple recipients, or what the tool returns (e.g., an email ID). Given the complexity of the schema and the absence of annotations, the description should provide more guidance to be considered complete. It leaves too many details to inference.

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

  Parameters3/5

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

  The input schema provides 100% coverage for both parameters with descriptions of their structure ('to' as recipients with identity/email, 'content' with subject, html, from). The tool description adds no extra semantic meaning beyond what the schema already specifies, so the baseline of 3 applies. The nested object formats are already explained in the schema, so the description does not need to reiterate them.

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

  Purpose4/5

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

  The description clearly states the action (send), the resource (email), and the target (specific users). It distinguishes from sibling messaging tools like send_push, send_sms, and send_whatsapp by naming the medium, though it doesn't explicitly contrast with them. The phrase 'directly to specific users' adds a useful nuance that it is not a bulk campaign, but it could be more specific about scope.

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

  Usage Guidelines2/5

  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. There are many sibling tools (send_push, send_sms, send_whatsapp, create_campaign), but the description does not mention any conditions that would select email over others, nor any exclusions such as 'use create_campaign for bulk sends'. The phrase 'directly to specific users' implies a use case, but it stops short of explicit direction.

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

• get_campaign_reportC
  2.9/5.0
  Behavior2/5

  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 does not mention that the operation is read-only, and fails to describe the effect of the 'daily' flag, filter behaviors, or any output format. The description simply repeats the action without revealing side effects, data granularity, or other important behavior that an agent would need to anticipate.

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

  Conciseness4/5

  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, and there is no fluff. While it could include more detail, the efficiency and clarity of the sentence justify a high score.

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

  Completeness2/5

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

  Given the lack of an output schema and several optional parameters that materially change the result (daily breakdown, filters), the description is incomplete. An agent cannot know what the report will actually contain, how filters interact, or what the daily flag changes. The description leaves too much to inference; a more complete description would mention the response shape or the significance of these options.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are already fully documented in the input schema. The description adds no new meaning beyond the schema, but it does mention 'within a date range' which maps to the from/to parameters, reinforcing their role. This is adequate given the schema's completeness, earning a baseline score of 3.

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

  Purpose4/5

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

  The description states a clear verb ('Get') and a specific resource ('message delivery reports') scoped to campaigns within a date range. It accurately conveys the tool's core function, though it doesn't explicitly differentiate from siblings like get_realtime_counts, which could also relate to delivery metrics. The purpose is clear enough for an agent to understand what the tool does.

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

  Usage Guidelines2/5

  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. Siblings such as get_realtime_counts or get_profile_count exist, but no exclusions or conditions are mentioned. The only implicit context is that it's campaign-specific, but the agent must infer that from the name and description alone.

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

• get_event_countC
  2.9/5.0
  Behavior2/5

  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 only states 'aggregate count,' which implies a single numeric result, but omits details about output format, handling of optional filters, timezone assumptions, or potential errors. There is no mention of pagination, limits, or how the count is computed (e.g., unique events vs. all occurrences). This is minimal disclosure for a tool with no annotation safety net.

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

  Conciseness4/5

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

  The description is a single, efficiently worded sentence that front-loads the primary action and resource. There is no wasted text, and it conveys the core operation without verbosity. It could include more detail, but as a concise statement it is appropriately sized for a simple count tool.

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

  Completeness3/5

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

  Given the tool's modest complexity (4 parameters, no output schema, no annotations), the description is somewhat complete in stating what it does, but it lacks details on the return value (expected to be a number), the effect of the optional 'where' filter, and any edge cases. For an agent to call it correctly, more context about the filter object and output format would improve completeness, though the description is not grossly inadequate.

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

  Parameters3/5

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

  Schema description coverage is 75% (from, to, where have descriptions; event_name does not). The description adds minimal context by implying event_name is the 'specific event', but it does not explain the syntax of the 'where' object or the YYYYMMDD format beyond what the schema already provides. Overall, it adds slight meaning but relies mostly on the schema for parameter semantics.

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

  Purpose4/5

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

  The description names a clear action ('Get'), a specific resource ('aggregate count of a specific event'), and a time boundary ('within a time period'). This differentiates it from sibling tools like get_profile_count (profiles) and get_realtime_counts (real-time), though it does not explicitly name those alternatives. It is precise but could be more explicit in distinguishing itself.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as get_realtime_counts or get_events. No context is provided about appropriate scenarios, prerequisites, or exclusions. The description simply states the function without any conditional advice, leaving the agent to infer usage from the name alone.

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

• get_top_property_valuesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits itself. It implies a read-only operation ('Get') but does not state safety, rate limits, output format, or any side effects. The lack of detail leaves significant ambiguity about what happens when the tool is invoked.

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

  Conciseness5/5

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

  The description is a single, concise sentence with no filler. It conveys the core action and object in minimal words, fitting the 'appropriately sized' criterion well.

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

  Completeness2/5

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

  Given the lack of an output schema and annotations, the description is insufficiently complete. It does not explain what 'values' means (e.g., counts, users, sessions), how results are ordered, or what a typical response looks like. For a tool with five parameters (four required), this minimal description leaves too much unsaid for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 80%, so the baseline is 3. The description reiterates 'top N' and 'event property', which loosely map to 'top_n' and 'property', but adds no new meaning beyond the schema entries. It does not clarify the format of 'from' and 'to' (YYYYMMDD is in schema) or the meaning of 'event_name' beyond what the parameter name implies.

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

  Purpose4/5

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

  The description states a clear verb ('Get') and a specific resource ('top N values for an event property over a date range'), which is more than a tautology. However, it does not explicitly differentiate this from sibling tools like 'get_trends' or 'get_events', though the phrase 'top property values' implies a ranking use case that is distinct.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. No mention of scenarios, exclusions, or related tools. The description only states the action without any contextual direction, leaving the agent to infer usage from the name alone.

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

• upload_eventsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It discloses the 1000-events-per-call cap, which is useful, but omits side effects (e.g., idempotency, overwrite vs append), error behavior, authentication requirements, or response format. For a data-write 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.

  Conciseness5/5

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

  Two concise sentences with the action first and the limit second. No filler, every word earns its place. Perfectly front-loaded.

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

  Completeness2/5

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

  Lacks crucial behavioral context for an ingestion tool: no idempotency, error handling, rate limits (beyond per-call cap), or relation to sibling tools. Since there's no output schema or annotations, the description should cover side effects and post-conditions, but it doesn't.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the events array structure and field requirements. The description adds the 1000-event limit, which is extra value, but doesn't elaborate on individual field semantics beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose4/5

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

  States a specific verb (upload) and resource (user events) with context about the source (external system to CleverTap). It implies an ingestion action, distinguishable from sibling read tools like get_events and profile uploads like upload_profiles, though it doesn't explicitly name alternatives.

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

  Usage Guidelines2/5

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

  No explicit when-to-use vs alternatives. The description hints at external ingestion but doesn't contrast with get_events or upload_profiles, nor does it mention scenarios where this tool should be avoided (e.g., large batches exceeding 1000 events).

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

• get_realtime_countsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'real-time' and 'live data', but does not reveal potential rate limits, caching behavior, latency, or whether the call is expensive. It is a simple read operation, but the sparse description lacks transparency about any non-obvious traits.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the key information (real-time counts) and avoids unnecessary verbosity. It is concise and immediately understandable.

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

  Completeness3/5

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

  For a tool with one simple parameter and no output schema, the description provides the core purpose but omits several contextual details. It does not explain the return format, whether the count is an integer, or any specifics about event name conventions. It also lacks usage guidance that would help an agent decide when to invoke it. Given the low complexity, it is adequate but not fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single parameter 'event', which has its own clear description. The tool description adds no additional semantic information beyond what the schema provides. With full schema coverage, a baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool retrieves real-time counts of users performing an event, using specific verb 'Get' and resource 'real-time counts'. It implicitly distinguishes from get_event_count via the 'real-time' and 'live' wording, but does not explicitly differentiate. Overall a clear purpose, but could be more explicit about what makes it different from similar count tools.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like get_event_count or get_trends. It does not state that this is for live data and historical counts should use another tool. The description gives no context on selection criteria or prerequisites, leaving the agent to guess.

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

• send_whatsappB
  3.1/5.0
  Behavior2/5

  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 does not mention whether sending is synchronous, requires pre-approved templates, has rate limits, or what happens on success/failure. The agent has no indication of side effects beyond the generic 'send' action.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the core action. It is efficient and free of fluff, though it could benefit from a brief usage note. The brevity is appropriate but leaves out important context, so it is not a perfect score.

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

  Completeness2/5

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

  Given no output schema, no annotations, and nested parameters, the description is minimal. It does not explain when to use WhatsApp instead of other channels, what constitutes valid content, or any operational constraints. The presence of multiple sibling send tools makes this incompleteness more consequential.

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

  Parameters3/5

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

  The input schema describes all three parameters with 100% coverage, so the baseline is 3. The description adds no additional detail about parameter formats, defaults, or relationships; it merely restates the overall purpose without enriching the schema information.

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

  Purpose5/5

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

  The description clearly states the action (send), the resource (WhatsApp message), and the target (specific users via CleverTap). It distinguishes itself from sibling send tools like send_email and send_sms by explicitly naming WhatsApp, so an agent can identify the correct tool without ambiguity.

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

  Usage Guidelines2/5

  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 such as send_email or send_sms. There is no mention of prerequisites, message templates, or context in which WhatsApp is preferred. The agent must infer usage solely from the tool name.

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

• stop_campaignB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It states that it stops a campaign, implying a mutating operation, but does not mention whether the action is reversible, what happens to in-flight sends, or any permission requirements. The behavioral impact is barely disclosed.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no waste. It leads with the verb, specifies the target, and mentions the required input. Highly scannable and efficient.

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

  Completeness3/5

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

  For a simple tool with one parameter and no output schema, the description covers the core purpose and required input. However, it omits error conditions, reversibility, side effects, and response details. Given the lack of annotations, these gaps leave room for improvement, though the low complexity keeps it at a baseline level.

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

  Parameters3/5

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

  The schema already documents the campaign_id parameter with a description ('CleverTap campaign ID'), giving 100% coverage. The description's phrase 'by its ID' adds no additional meaning about format, validation, or usage. Since the schema does the heavy lifting, this is a baseline score.

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

  Purpose4/5

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

  The description clearly states the action ('Stop') and the target ('scheduled or running CleverTap campaign') with its identifier. It is unambiguous and distinguishes from sibling tools that send or create campaigns, though it doesn't explicitly name them. The verb+resource is specific and informative.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or conditions, and no exclusions. An agent is left to infer that it's for stopping campaigns, but nothing indicates scenarios where this tool would be inappropriate or where another tool should be used instead.

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

• get_eventsB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It adds genuine value by disclosing cursor-based pagination, and 'download' hints the operation is a read. However, it doesn't disclose error behavior, rate limits, or data-volume implications, which are useful for a retrieval endpoint.

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

  Conciseness4/5

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

  Two sentences with zero filler, and the primary purpose is front-loaded before the pagination detail. Compact and scannable; a brief sibling mention could be added without bloating it.

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

  Completeness3/5

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

  With no output schema or annotations, the description should explain the return value in more detail. It covers the pagination cursor but not what the returned event payload contains or how the include_profile flag alters results. Adequate for a moderate-complexity 5-parameter tool, but with clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all five parameters (to, from, batch_size, event_name, include_profile) are already documented in the input schema. The description's pagination mention adds slight context around batch_size's role in the cursor flow, but doesn't meaningfully go beyond the schema. Baseline 3 applies.

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

  Purpose4/5

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

  The description states a specific action ('Download') on a clear resource ('user events from CleverTap') scoped to a date range. It's unambiguous about what the tool does, but it doesn't differentiate from the similar sibling get_events_page, which is a gap given how close that tool is in purpose.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus get_events_page for paginated retrieval, get_event_count for counting, or upload_events for writing. An agent gets no decision criteria for choosing among these siblings, so selection is left to inference.

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

• get_trendsB
  3.3/5.0
  Behavior2/5

  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 explains the output type (day-by-day counts) but omits critical details such as response format, how trends are computed (e.g., unique users vs raw events), timezone handling, pagination, or any limits. This is a significant gap for a tool that an agent may invoke blindly.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core functionality and the optional grouping, though it could have included a bit more usage context without becoming verbose.

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

  Completeness2/5

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

  Given the tool's simplicity and lack of annotations or output schema, the description is incomplete. It does not specify the response structure, how grouped results are returned, error cases, or any assumptions about the data. An agent would need to infer these details or make assumptions, which is risky for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 75%, so most parameters have descriptions in the schema. The description adds meaning by clarifying that from/to define a date range and that group_by is an optional property for segmentation, which aligns with the schema. However, it does not explain event_name beyond what the schema provides, and the description does not fully compensate for the missing description on that parameter.

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

  Purpose5/5

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

  The description states a specific verb 'get' and resource 'event trends', clarifying it provides day-by-day counts over a date range with optional grouping. This clearly distinguishes it from siblings like get_event_count (which likely provides total counts) and get_realtime_counts (realtime data), so an agent can tell them apart.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool (for time-series trends) but does not explicitly contrast it with alternatives or state when not to use it. There is no mention of choosing get_trends over get_event_count or other sibling tools, leaving the agent to infer the appropriate context from the semantics alone.

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

• send_pushB
  3.4/5.0
  Behavior2/5

  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 reveals the recipient modes (identity/objectId) but does not mention delivery behavior, permissions, failure handling, rate limits, or whether the send is immediate or scheduled.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's core action and targeting mechanism.

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

  Completeness2/5

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

  Given the nested object parameters, lack of output schema, and absence of annotations, the description is too thin. It does not explain the relationship between identity and objectId, expected behavior for invalid recipients, or how this differs operationally from the sibling send tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description's 'by identity or objectId' adds a concise high-level summary of the 'to' parameter, but it does not add significant meaning beyond the schema's own parameter descriptions.

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

  Purpose5/5

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

  The description states a specific verb ('Send'), a clear resource ('a push notification'), and a specific targeting mode ('directly to specific users by identity or objectId'). This clearly distinguishes it from sibling send tools like send_email, send_sms, and send_whatsapp.

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

  Usage Guidelines3/5

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

  The phrase 'directly to specific users' implies a targeted, direct push use case, contrasting with campaign-based sends. However, the description does not explicitly state when to prefer this over send_email, send_sms, send_whatsapp, or create_campaign, nor does it mention any exclusions or prerequisites.

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

• create_campaignA
  3.5/5.0
  Behavior2/5

  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 reveals that estimate_only=true previews reach without sending, but it does not disclose what happens on success (e.g., campaign ID, scheduling behavior, whether it sends immediately) or state any side effects beyond creation. This is a significant gap for a tool that creates a real campaign.

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

  Conciseness5/5

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

  Two sentences with zero fluff. The purpose is front-loaded, and the most important option (estimate_only) is mentioned clearly. Every sentence earns its place.

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

  Completeness3/5

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

  For a tool with 7 parameters, nested objects, no output schema, and complex behavior (scheduling, multiple channels), the description is fairly minimal. It does not address the return format, how 'when' scheduling works, or how to construct content for each channel beyond the schema examples. However, the schema is thorough, so the description is not inadequate, but it lacks useful guidance on the tool's broader behavior and alternatives.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all seven parameters with descriptions and examples for content. The description adds the channel list and estimate_only context, but these repeat the enum and the schema description. Since coverage is high, the baseline 3 applies; the description does not meaningfully enhance parameter understanding beyond the schema.

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

  Purpose5/5

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

  States a specific verb and resource ('Create a CleverTap campaign') and lists the supported channels. Clearly differentiates from sibling tools like send_push and send_email by centering on campaign creation rather than one-off sends, and adds the estimate_only preview option.

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

  Usage Guidelines3/5

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

  The description implies a general campaign-creation use case and mentions estimate_only for preview, but it does not explicitly state when to use this tool versus the sibling send_* tools (e.g., immediate sends vs. scheduled campaigns). No exclusions or alternative routing are given, leaving the agent to infer the distinction.

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

• get_profileA
  3.5/5.0
  Behavior2/5

  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 indicates a read operation implicitly but does not mention error behavior, authentication, rate limits, or what happens when no profile is found. Minimal additional context beyond the action itself.

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

  Conciseness5/5

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

  A single, front-loaded sentence that states the purpose and key lookup options with no filler. Every word adds value, and the structure is ideal for quick scanning by an agent.

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

  Completeness3/5

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

  For a simple two-parameter read tool with no output schema, the description is adequate but minimal. It does not explain return format, edge cases, or relationship to sibling tools, and with many siblings, a bit more context would help. Still, the core functionality is clear.

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

  Parameters3/5

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

  Schema coverage is 100% and both parameters (value and lookup_type) are already described in the schema. The description does not add any extra semantic detail beyond what the schema provides, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Get a single user profile') and specifies the lookup mechanisms (email, custom identity, objectId). It distinguishes from siblings like get_profiles and get_profiles_page by emphasizing 'single', making the target resource unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for fetching one profile but does not explicitly state when to choose this over get_profiles/get_profiles_page or provide exclusions. There is no mention of alternative tools or conditions, leaving some ambiguity for the agent.

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

• get_profiles_pageA
  3.7/5.0
  Behavior2/5

  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 only states that it 'fetches' data, implying a read operation, but provides no details about edge cases (e.g., invalid cursor, end-of-list behavior), rate limits, or side effects. The description is minimal and offers no additional behavioral context beyond the action itself.

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

  Conciseness5/5

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

  The description is a single, efficiently structured sentence. It front-loads the primary purpose ('Fetch the next page of profiles') and immediately clarifies the cursor source, with no redundant words or filler. Every word adds value.

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

  Completeness3/5

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

  For a tool with one parameter and no output schema, the description covers the essential invocation context (what it does and where the cursor comes from). However, it omits any description of the return payload (e.g., a list of profiles and a new cursor for subsequent pages), which would be valuable given the lack of an output schema. 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.

  Parameters3/5

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

  The schema alone defines cursor as a string with no additional semantics. The description adds the crucial context that the cursor originates from get_profiles, which clarifies it is an opaque token from a prior call rather than a user-supplied identifier. However, it does not specify the format, validation, or behavior with an expired/invalid cursor, so its contribution is limited.

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

  Purpose5/5

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

  The description clearly states the verb 'fetch', the resource 'profiles', and the pagination mechanism ('next page' via a cursor). It explicitly references the source of the cursor (get_profiles), distinguishing it from the initial fetch and other profile-related tools. This is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description implies the usage context: it must be called with a cursor obtained from get_profiles, indicating a sequential workflow. It clearly states the dependency on a prior tool call. However, it does not explicitly mention when not to use it or compare it to alternatives like get_events_page, so it falls short of full exclusion criteria.

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

• get_events_pageA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It labels the operation as 'fetch', implying a read-only, non-mutating action, but it does not explicitly confirm safety (e.g., no side effects), nor does it disclose behavior like invalid cursor handling, rate limits, or return structure beyond 'page of events'. The lack of detail is a gap, but the implied read-only nature is reasonable.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the core purpose and mechanism. There is no wasted text and no redundancy.

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

  Completeness4/5

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

  Given the low complexity (one parameter, no nested objects, no output schema), the description adequately covers what the tool does and how to use it. It mentions the return of 'page of events', which is sufficient for an agent to understand the output. However, it could benefit from noting how to determine the end of pagination or error behavior, but these are not critical for a simple pagination tool.

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

  Parameters3/5

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

  The schema already provides 100% coverage of the 'cursor' parameter, describing it as a string from a previous get_events or get_events_page call. The description adds a slight clarification by specifying 'returned by get_events', but this is largely redundant with the schema. The baseline of 3 applies since the schema handles the parameter documentation well; the description adds marginal value.

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

  Purpose5/5

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

  The description clearly states a specific action ('Fetch the next page of events') and the resource (events) with a distinguishing mechanism (cursor). It explicitly differentiates from the sibling tool 'get_events' by indicating this tool fetches subsequent pages using a cursor returned by get_events, which is a distinct purpose.

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

  Usage Guidelines4/5

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

  The description clearly communicates when to use this tool: after obtaining a cursor from get_events. It implies that get_events is for the initial page and this tool for subsequent pages, though it does not explicitly state exclusions or alternative conditions. The context is clear enough for an agent to know when to invoke it.

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