Server Quality Checklist

Tool Scores

• phone_get_account_call_historyC
  2.3/5.0
  Behavior1/5

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

  No annotations are provided (fine), but the description also fails to state behavioral facts: it doesn't mention pagination behavior, result ordering, whether call history is immutable, rate limits, or that it requires admin-level scope beyond just echoing the OAuth scope string. For a read-only data retrieval tool with zero annotation coverage, 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.

  Conciseness4/5

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

  Efficient two-sentence description with zero wasted words. The scope string is useful context. However, brevity here trades off against substance that other dimensions needed.

  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 4 parameters with only 50% schema coverage, no output schema, and no annotations. The description should compensate by describing return structure, pagination, and behavior, but instead it's minimal. Incomplete for a data-retrieval tool with this profile.

  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?

  Schema coverage is only 50% (from/to are documented, page_size and next_page_token are not). The description adds nothing beyond the schema—it doesn't explain what page_size maximums mean or how pagination by next_page_token works. It fails to compensate for the undocumented parameters.

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

  Purpose3/5

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

  The description states the tool gets the account's call history for a date range, with a clear account scope. It distinguishes from siblings like phone_get_user_call_history (which is user-scoped) but not explicitly from phone_get_account_call_logs, which sounds very similar 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 vs phone_get_account_call_logs, which is a close sibling that could easily be confused with this tool. The date-range context is implied but no exclusions or alternatives are given.

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

• phone_get_auto_receptionist_call_handling_settingsC
  2.7/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 is a read-only GET operation, but the description doesn't state what the return format is, whether the autoReceptionistId must exist, what happens on a non-existent ID, or any auth requirements. For a read operation with zero annotation coverage, this is a meaningful gap.

  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 one concise sentence at 11 words, which is appropriately brief for a simple single-parameter GET tool. There is no wasted text or redundancy. It's under-specified but not bloated.

  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?

  Despite being a relatively simple tool (1 param, no output schema, no annotations), the description leaves key gaps: no return value explanation, no description of the autoReceptionistId parameter, and no differentiation from the user-level settings tool. Given that the sibling phone_get_user_call_handling_settings exists, some guidance about scope differences would improve completeness.

  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?

  Schema description coverage is 0%, meaning the description must compensate for the single parameter autoReceptionistId. However, the description never mentions this parameter, doesn't explain where to find the ID, or clarify the expected format. With one parameter and no schema descriptions, the agent must guess what identifier is expected.

  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 verb+resource: 'Get call handling settings for an auto receptionist (IVR).' It identifies the specific resource type (auto receptionist/IVR) and distinguishes it from sibling tools like phone_get_user_call_handling_settings, which targets a different entity (users). The 'IVR' gloss adds useful clarity.

  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. It doesn't mention that phone_get_user_call_handling_settings exists for user-level settings, nor does it explain scenarios where querying an auto receptionist's settings would be appropriate. Context must be inferred entirely from the tool name and siblings.

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

• phone_get_call_elementC
  2.7/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 behavioral disclosure burden. It describes a read/get operation but doesn't state whether this is safe, what happens if the ID is invalid, whether it returns details of all element types, or how it relates to call log retrieval. The examples (hold, transfer, recording marker) provide some context value, but there are significant disclosure gaps for a get operation with zero annotations.

  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?

  Single sentence, efficient, with useful parenthetical examples. Zero waste. However, it could have used the space to add parameter or usage clarity while staying concise.

  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 zero annotations, zero schema description coverage, and no output schema, the description is thin for a tool with 1 required parameter. It lacks guidance on where callElementId comes from, what the returned element looks like, and how this relates to the sibling call-log/call-detail tools. A single sentence is inadequate for a tool with so little structured metadata supporting it.

  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?

  Schema coverage is 0%, so the description must compensate for the single undocumented parameter callElementId. The description does mention 'by ID' which partially clarifies that callElementId is an identifier of the element, but it doesn't specify the ID format, origin (where to obtain it), or constraints. Baseline for zero coverage is low, and description adds only minimal clarification.

  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 verb+resource ('Get a single call element... by ID') and gives helpful examples of what a call element is (hold, transfer, recording marker). It distinguishes from sibling list-type tools (call_history, call_logs, transcripts) by clarifying this retrieves a single element by ID. Could be stronger but is clear and specific.

  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 vs alternatives. The description doesn't say when you'd want a call element versus call logs, history, or transcripts. It implies you'd use this after knowing a callElementId, but doesn't state any prerequisite steps or situations where a sibling is more appropriate. No exclusions or alternatives named.

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

• phone_update_auto_receptionist_call_handling_settingC
  2.7/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 flags the operation as a WRITE that 'modifies live call routing configuration', which signals it has real-world impact. However, it doesn't disclose whether this is reversible, requires specific permissions, affects active calls, or what the response format looks like. For a live-routing mutation, this is a meaningful disclosure gap.

  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 short sentences, no wasted words. The WRITE OPERATION warning is front-and-center and immediately signals the mutation risk. It's appropriately concise for a 3-parameter tool.

  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?

  For a mutation tool with no annotations, no output schema, and a nested 'settings' object with unspecified internal structure, the description is under-specified. The 'settings' parameter is the most complex and least explained — the agent gets no guidance on the shape of the payload, enums within it, or validation rules. The purpose is clear but the operational details needed to invoke confidently are missing.

  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?

  Schema coverage is 67% (hourType has a description and enum, settings has a description, but autoReceptionistId has no description). The description itself adds no parameter-level semantics — it doesn't explain how hourType maps to the three enum values, what structure the settings payload should follow beyond 'matching the Zoom Phone API schema', or what the autoReceptionistId should reference. The 'settings' description is notably vague, deferring to an external schema the agent may not see.

  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 verb ('update'), the resource ('auto receptionist'), and the specific field ('call handling setting for a specific hour type'). It distinguishes itself from the sibling 'phone_update_user_call_handling_setting' by targeting the auto receptionist rather than a user, though it doesn't explicitly name that sibling. The explicit WRITE OPERATION warning adds helpful emphasis.

  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 when-to-use or when-not-to-use guidance is provided. While the WRITE OPERATION warning implies this is a mutating action, the description doesn't explain when a user would choose this over the sibling auto-receptionist GET endpoint (phone_get_auto_receptionist_call_handling_settings) or how it differs from the user-level update tool. The distinct auto-receptionist vs user context is clear but not explicit.

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

• va_get_articlesC
  2.7/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 behavioral disclosure burden. It states only that this lists articles - no mention of pagination, response limits, sorting, whether a specific kbId is required to be pre-created, or what happens if the kbId is invalid. For a listing operation, return format and limits are notable gaps.

  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?

  Single sentence, no wasted words. It is front-loaded with the action verb. However, it is so terse that it misses opportunities to add value, though conciseness itself 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?

  With no output schema, no annotations, 0% schema coverage for the only parameter, and 18 sibling tools varying between get/create/update operations, the description is too thin. It should clarify the listing behavior, the relationship to va_get_article (singular), and possibly the return structure or result count, especially given the tool's role in a knowledge base management workflow.

  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?

  Schema description coverage is 0%, so the description bears full responsibility for explaining the kbId parameter. The description mentions 'a Zoom Virtual Agent knowledge base' contextually but does not explicitly explain what kbId is or how to obtain it. The description does not add semantic meaning to the single parameter.

  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 'List knowledge base articles for a Zoom Virtual Agent knowledge base' - clear verb ('list'), resource ('knowledge base articles'), and context (Zoom Virtual Agent). It doesn't explicitly distinguish from sibling va_get_article (singular), but the plural 'articles' vs 'article' differentiates them implicitly.

  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 vs alternatives. It doesn't mention that va_get_article retrieves a single article, or how this differs from va_get_sync_status or va_get_engagements. The agent must infer usage from sibling names alone.

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

• va_get_articleC
  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. As a read operation, it doesn't state whether the article is returned fully, whether metadata is included, what happens for missing/expired article IDs, or whether authentication is required. Minimal disclosure beyond stating it fetches a single article.

  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?

  A single efficient sentence with zero waste. It's appropriately front-loaded with the core purpose stated in the first few words. However, it could arguably be longer to cover the gaps in param/behavior explanation given it's a simple one-liner.

  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 fetch tool with no output schema, the description is minimal but the tool itself is low complexity. The main gap is the undocumented kbId parameter and lack of usage guidance relative to the sibling va_get_articles. Given the low complexity, this is adequate but not comprehensive.

  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?

  Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' for the article (mapping to articleId) but does not explain kbId at all or clarify that both are required identifiers. The description adds minimal meaning beyond what the schema property names imply.

  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 uses a specific verb+resource ('Get a single knowledge base article by ID'), clearly stating what it does. It distinguishes from siblings like va_get_articles (plural list) and va_create_article/va_update_article by the 'single... by ID' 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?

  No guidance on when to use this tool versus alternatives. It doesn't mention when to use va_get_articles instead, nor any prerequisites like needing a valid articleId from a prior list operation. The use case is implied but not stated.

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

• phone_get_user_call_historyC
  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 the full burden of behavioral disclosure. It mentions the required scope (phone:read:call_history) which is useful, but does not disclose pagination behavior, whether results are sorted, what data elements are returned, or whether the date range is inclusive/exclusive. For a read operation with no annotations, this is a moderate gap.

  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 concise with two sentences—one for purpose/scope and one for auth. It's front-loaded and efficient with zero fluff. Could arguably mention sibling alternatives in a second sentence, but the brevity is a strength.

  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 5 parameters with 40% undocumented, no annotations, no output schema, and a close sibling (phone_get_user_call_logs) creating ambiguity, the description is under-specified. It should explain the history vs logs distinction, clarify pagination via next_page_token, and describe what data the response contains. The description does not fully enable an agent to use the tool effectively.

  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 60%, covering userId, from, and to meaningfully. The description adds the scope requirement and confirms the date-range concept. However, page_size and next_page_token are undocumented in both the schema and description, leaving a gap. The description adds some value over the schema but doesn't fully compensate for the uncovered parameters.

  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 verb (get), the resource (Zoom Phone user's call history), and the scope (specific user, date range). It distinguishes from siblings like phone_get_account_call_history (account-level vs user-level) and phone_get_user_call_logs (history vs logs). However, it doesn't explicitly differentiate from the close sibling phone_get_user_call_logs, which sounds nearly identical.

  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. With siblings like phone_get_user_call_logs and phone_get_call_log_details, the agent would struggle to choose between call history, call logs, and call log details. No exclusions or alternative tool names are mentioned.

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

• va_get_transcriptsC
  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 the full burden of behavioral disclosure. The description does not mention pagination, result limits, rate limits, authentication requirements, or how the transcripts are returned. For a data retrieval tool with transaction-like behavior, this leaves significant behavioral unknowns.

  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?

  One efficient sentence stating purpose. No redundancy or waste. It is concise but at the cost of omitting useful behavioral and usage context.

  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 2 simple parameters with 100% schema coverage and no output schema, the tool is relatively simple. However, with no annotations and no behavioral detail (pagination, limits, return format), the description leaves gaps for a date-range retrieval tool. The absence of any usage alternatives or exclusions makes it incomplete for agent decision-making.

  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%, with both parameters ('from' and 'to') having descriptions including format (YYYY-MM-DD). The description says 'for a date range' which loosely maps to the from/to parameters. However, it doesn't clarify range constraints (e.g., maximum span allowed, whether to is inclusive) beyond the schema's format information, so it adds marginal value.

  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 the verb ('Get'), resource ('Zoom Virtual Agent conversation transcripts'), and scope ('for a date range'). This is clear and specific. It doesn't explicitly distinguish from siblings like va_get_engagements or va_get_query_details, but the resource is named distinctly enough that some differentiation is implicit.

  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 va_get_engagements or va_get_query_details, nor any exclusions or context about limitations (e.g., date range constraints, maximum span). The description implies usage for retrieving transcripts but provides no comparison to sibling tools.

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

• va_update_articleC
  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 the full burden of behavioral disclosure. 'WRITE OPERATION' conveys mutation intent, but the description doesn't note whether updates are partial or full replacements, whether all article fields get overwritten, any auth/permission requirements, or behavior on non-existent article IDs. For a mutation tool with zero annotation coverage, 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.

  Conciseness4/5

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

  Extremely concise at one sentence. The 'WRITE OPERATION' marker is somewhat redundant with the verb 'Update', but the overall structure is efficient and front-loaded with the core action.

  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?

  For a mutation tool with no output schema, no annotations, and a nested 'article' object parameter, this description is under-specified. It doesn't explain update semantics (partial vs. full replacement), response/return values, or what happens with the nested 'article' object. The nested object and write nature demand more explanation than provided.

  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 only 33% (only 'article' has a description). The description itself provides no parameter details beyond the tool name. However, the 'article' parameter's description ('Fields to update, matching the Zoom KM API schema') is at least somewhat helpful, and kbId/articleId are self-evident identifiers. The description adds no additional parameter context, keeping this at the baseline without improvement.

  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 verb+resource ('Update an existing knowledge base article'), which clearly identifies what the tool does. It distinguishes itself from siblings like va_create_article and va_get_article through the 'Update' verb. However, the 'WRITE OPERATION' phrase is redundant with the verb and adds little value.

  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 alternatives. It doesn't mention that create should be used for new articles or that get/va_get_articles are for reading. With many sibling VA tools (va_get_article, va_create_article, va_get_articles, va_sync_knowledge_base), explicit when/when-not guidance would help the agent disambiguate.

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

• phone_get_call_log_detailsB
  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 carries the full burden of behavioral disclosure. The description states it's a read operation ('Get details'), but gives no information about error behavior for invalid/nonexistent IDs, whether the result is null or throws, rate limits, or any permission/auth requirements. For a retrieval tool with zero annotation coverage, this is a meaningful 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?

  A single, clean sentence that conveys the core purpose without wasted words. There is no padding or redundancy.

  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 one parameter, no output schema, and no annotations, the tool is relatively simple, but a description nearly identical to other sibling tools (e.g., 'Get details for a single call log by ID' vs future equivalents for elements/users) leaves the agent without enough to disambiguate or anticipate failure modes. Adequate but minimal for the context.

  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?

  There is only one parameter (callLogId) at 0% schema description coverage. The description implies the parameter is the identifier used to fetch the log, but adds no detail about format, provenance (how to obtain a valid ID), or constraints. The baseline should be 4 for a single-parameter tool with no description coverage, but the description's 'by ID' hint does partially map the semantics, so a 3 is fair.

  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 uses a clear verb+resource pattern: 'Get details for a single call log by ID.' It clearly states it fetches details for one call log identified by an ID. It's distinguished from siblings like phone_get_account_call_logs and phone_get_user_call_logs by the 'single... by ID' qualifier, though it doesn't explicitly differentiate from phone_get_call_element which is similar.

  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 sibling tools like phone_get_call_element or the call history/log listing tools. There's no mention of prerequisites (e.g., needing an ID first obtained from a listing tool) or when one might prefer this over alternatives.

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

• va_get_sync_statusB
  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 carries the full burden of behavioral disclosure. It doesn't disclose what a 'running', 'completed', or 'failed' status looks like, whether this is a read-only polling operation, whether it blocks, or what happens if the syncId is invalid or stale. For a status-checking tool, describing the return format would be valuable.

  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 zero waste. It conveys the core purpose immediately and is well front-loaded. It's appropriately brief for a status-checking tool, though it could add a bit more behavioral detail 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?

  For a status-check tool with no annotations, no output schema, and 0% schema description coverage, the description is thin. It doesn't explain the possible status values, response format, timeout/retry expectations, or relationship to the sync-starting sibling tool. More context is needed for an agent to use this effectively in an async workflow.

  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 0%, so the description must compensate, but it only mentions 'sync job' conceptually. It doesn't clarify that kbId identifies the knowledge base and syncId identifies the specific job, though these are somewhat inferable from tool context. Both parameters are required and their names are reasonably self-explanatory despite being undocumented.

  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 uses a specific verb ('check the status of') applied to a resource ('knowledge-base sync job'), and correctly notes this applies to a 'previously started' sync job, distinguishing it from the sibling va_sync_knowledge_base which initiates syncs. It clearly states what the tool does, though it doesn't explicitly contrast with the sibling that starts syncs.

  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 'previously started' implies this is meant to be called after va_sync_knowledge_base, providing implicit usage context. However, there's no explicit when-to-use vs when-not-to-use guidance, no mention of alternatives, and no indication of polling behavior or whether it should be called repeatedly.

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

• phone_get_user_call_logsB
  3.2/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. It states the operation (getting call logs) but doesn't disclose pagination behavior (though page_size and next_page_token params imply it), rate limits, permission requirements, or what happens if the date range is invalid. For an unannotated tool, this is a minimal disclosure gap.

  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?

  Single concise sentence, front-loaded with the action. No wasted words. It's appropriately brief for what it communicates, though it could use the sparse format to add a bit more differentiation 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 paginated list tool with 5 params, missing output schema, and no annotations, the description is somewhat thin. Given sibling ambiguity (multiple similar phone call log/history tools), more differentiation would help. However, it's a functionally simple read operation and the required params guide usage. Adequate but could be richer.

  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 60% — three params (userId, from, to) are described but page_size and next_page_token have no descriptions in the schema or the tool description. The description doesn't add anything beyond what's already in the schema. With 60% coverage, the description's value-add is limited, though the covered params are clear.

  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?

  Description is clear: 'Get a specific Zoom Phone user's call logs for a date range' with specific verb+resource+scope. It distinguishes the target user ('specific Zoom Phone user') which helps differentiate it from siblings like phone_get_account_call_logs (account-level) and phone_get_user_call_history. However, it doesn't explicitly contrast with the sibling call_history and call_log detail tools.

  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 this is for a specific user's call logs within a date range, which signals the main usage context. However, there's no explicit when-to-use vs alternatives, no mention of how it differs from phone_get_user_call_history or phone_get_call_log_details, and the relationship to phone_get_account_call_history is unstated.

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

• va_create_articleB
  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 disclosure burden. It does explicitly call out that this is a WRITE OPERATION which mutates and adds bot-answerable content — useful transparency. However, it doesn't disclose effects like whether existing duplicates are created, indexing time, or whether changes require a sync to take effect, leaving meaningful behavioral gaps.

  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 short sentences with zero wasted words. The WRITE OPERATION emphasis is front-loaded and the purpose-relevant context ('adds content the bot can answer from') is concise and informative. Appropriate length for a create tool.

  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 is a write/create tool with no annotations and no output schema, so it carries a heavy disclosure burden. With 2 required params (one a loosely-typed object), the description should explain the creation flow, confirmation of success, and any sync implications. With no annotations or output schema, two sentences fall notably short of what an agent needs to invoke it reliably.

  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 50% — kbId has no description while article has a partial one. The description doesn't individually explain parameters; however it notes the article is an 'Article payload matching the Zoom KM API schema (title, content, etc)', which gives some structure. kbId's semantics remain undocumented in both schema and description, leaving a partial gap given the moderate coverage rate.

  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 verb+resource ('Create a new knowledge base article') which clearly distinguishes the write intent from sibling results tools (va_get_articles, va_get_article, va_update_article). The WRITE OPERATION emphasis and 'adds content the bot can answer from' adds purpose context. Minor gap: doesn't explicitly contrast with va_update_article or note relationship to va_sync_knowledge_base.

  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 explicit guidance on when to use this vs alternatives. It doesn't clarify when to create vs update (va_update_article), whether synchronization is required afterward, or any prerequisites like syncing with va_sync_knowledge_base. The WRITE OPERATION flag implies creation use-case but offers no when/when-not guidance.

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

• va_get_query_detailsB
  3.2/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 behavioral burden. It's a read/fetch operation, but the description fails to disclose return format, pagination behavior, data volume expectations, or any rate limits. It doesn't describe what the response structure looks like or whether results are aggregated or per-query rows.

  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?

  A single sentence that conveys the core purpose efficiently. No wasted words, and the parenthetical explanation adds value. It doesn't overload with unnecessary detail for a simple two-parameter 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?

  For a simple 2-param, high-schema-coverage tool with no output schema, the description is mostly adequate. However, given the sibling tools (va_get_transcripts, va_get_engagements) that may return overlapping data, the description could clarify what 'query-level detail' returns and why you'd choose this over alternatives. The lack of output format description is a minor gap since there's no output schema.

  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%, with both 'from' and 'to' documented as date strings (YYYY-MM-DD) in the schema. The description adds context that these define the date range for query details, but it's minimal. With full schema coverage, baseline 3 is appropriate since the description doesn't notably extend schema 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?

  Clear verb+resource: 'Get Zoom Virtual Agent query-level detail'. The description specifies what the data contains ('what users asked, whether it was answered') and the date-range scoping. It distinguishes somewhat from siblings like va_get_transcripts and va_get_engagements by naming 'query-level detail', though it doesn't explicitly reference alternatives.

  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 it's for query-level analytics (date range, what was asked, answered status), but there's no explicit when-to-use guidance or exclusions. With siblings like va_get_engagements and va_get_transcripts that could overlap, the description doesn't clarify which is best for which scenario.

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

• va_sync_knowledge_baseB
  3.3/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 burden. It explicitly flags itself as a WRITE OPERATION and notes it starts an async sync, which is genuinely useful behavioral disclosure. However, it doesn't mention what the sync job does with the KB, any rate limits, or what to do after triggering (e.g., poll with va_get_sync_status). The explicit WRITE OPERATION and async disclosure earn a middle score.

  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 short sentences, zero wasted words. The key behavioral facts (write operation, async) are front-loaded. This is appropriately concise for a tool with a single parameter.

  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?

  The tool is simple (1 param, no output schema, no nested objects), so the complexity is low. But it's an async write operation with no companion guidance — the description doesn't tell the agent what response to expect or that va_get_sync_status exists to check progress. Notable that the sibling list includes va_get_sync_status, which the description never references. For such a simple tool this is adequate but could easily add one line about polling.

  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 0% and there is a single parameter kbId. The description mentions the tool operates on a KB but never mentions or explains kbId — the agent must infer that kbId identifies which KB to sync. While the parameter name is fairly self-explanatory (kb ID), the description adds nothing beyond the schema, and at 0% coverage it should compensate more.

  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 it runs an external knowledge-base sync job for a Zoom Virtual Agent KB. 'Kick off' is a reasonable verb indicating async initiation, and it notes it's a WRITE OPERATION that starts an async sync. While it doesn't explicitly name sibling alternatives, the distinction is reasonably clear given the va_* namespace.

  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 when-to-use guidance is provided. It states this starts an async sync and is a write operation, but doesn't explain when to choose this vs. va_get_sync_status (which would be the polling companion) or when sync is needed. The description doesn't mention prerequisites or context for when to invoke this tool.

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

• phone_update_user_call_handling_settingB
  3.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 behavioral disclosure burden. It does flag 'WRITE OPERATION' and 'modifies live call routing configuration,' which conveys this is a side-effecting, production-impacting call. However, it doesn't disclose details like whether changes are reversible, authorization requirements, or what happens to existing settings not in the payload.

  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 one tight sentence plus a brief WRITE OPERATION warning. Every element serves a purpose: what it does, the three valid hour types, and the side-effect warning. Slightly stronger than a bare minimal description but not wasteful.

  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?

  The tool has 3 parameters with 100% schema coverage and a nested 'settings' object with additionalProperties: {} (open schema). No output schema and no annotations. The description covers the purpose and side-effect profile but doesn't compensate for the lack of annotations around mutation safety, rollback, or the open-ended settings structure. Adequate but leaves the agent without guidance on validation or failure modes.

  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 three parameters (userId, hourType, settings) with descriptions. The description restates the hourType enum values but adds marginal value by framing the 'settings' as 'a payload matching the Zoom Phone API schema.' It doesn't introduce meaning beyond the schema; the baseline of 3 is appropriate since the schema already does the heavy lifting.

  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 uses a specific verb+resource structure: 'Update a user's call handling setting for a specific hour type.' It clearly identifies the target resource (user's call handling setting) and the three valid hour types. It distinguishes from sibling tools by specifying 'user' (vs auto_receptionist) and 'update' (vs get). However, it doesn't explicitly name the sibling alternative, and 'WRITE OPERATION' is the kind of mutation signal that might normally come from annotations.

  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 notes the three hour-type values explicitly and states this modifies live call routing configuration, giving a sense of when it's appropriate. However, it doesn't provide explicit when-to-use or when-not-to-use guidance relative to the sibling getter (phone_get_user_call_handling_settings) or the auto_receptionist update. No exclusions or alternatives are named.

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

• va_get_engagementsB
  3.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 burden of behavioral disclosure. The description identifies this as engagement/report data (implying a read operation), which is useful. However, it doesn't disclose response format, pagination behavior, rate limits, or whether the report is aggregate or raw session data. For a read-only report tool the absence of annotations is partially compensated by the 'report data' phrasing, but richer behavioral details would help.

  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 that communicates the purpose with no filler. It front-loads the key information (what, what kind, scope). One could argue for slightly more detail given no annotations exist, but as written it's concise and free of waste.

  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?

  This is a relatively simple date-range report tool with just 2 fully documented parameters and no output schema. For tools in the VA family, there are siblings like va_get_transcripts and va_get_query_details that could overlap, and the description doesn't clarify the distinction. It's adequate but could note relationship to sibling reports or mention whether data is near-real-time or batched.

  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% — both 'from' (Start date) and 'to' (End date) are documented in the schema. The description mentions 'for a date range' which aligns with the from/to parameters but adds no format or constraint details beyond what the schema provides. Baseline 3 is appropriate since the schema already documents both parameters fully.

  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 'Get Zoom Virtual Agent engagement report data (bot conversation sessions) for a date range.' It names a specific verb (Get), resource (Zoom Virtual Agent engagement report data), and scoping (date range). It's distinguishable from siblings that handle articles, transcripts, phone call history, and sync, though it doesn't explicitly name an alternative tool to contrast against.

  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 this is used when retrieving bot conversation session engagement data for a date range, but gives no explicit when-to-use vs alternatives guidance. It doesn't mention exclusions or differentiate from va_get_transcripts or va_get_query_details, which could be related. Some context is clear from the phrasing, but no explicit guidance on when NOT to use it.

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

• phone_get_account_call_logsA
  3.6/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 burden for behavioral disclosure. It explicitly states the required scope 'phone:read:call_log:admin' and clarifies these are 'legacy-style logs' complementing call_history. However, it doesn't describe pagination/response structure, rate limits, or the difference between account-level vs user-level logs beyond the scope mention.

  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, tightly packed with purpose (get call logs), scope filter, and sibling differentiation. Slightly could expand on output but is efficient and front-loaded.

  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?

  The tool has 4 params, no output schema, and 50% schema description coverage. The description mentions the date range but doesn't elaborate on page_size or next_page_token semantics. It distinguishes from call_history but doesn't fully position it relative to phone_get_user_call_logs or phone_get_call_log_details. No output schema means return format is undocumented.

  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 50% with 'from' and 'to' described. The description reinforces the date-range semantics ('for a date range'). However, page_size and next_page_token (the other 50%) have no descriptions in the schema and the description doesn't compensate by explaining pagination behavior.

  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?

  Clear verb+resource: 'Get the Zoom Phone account's call logs for a date range'. Specifically scoped to account-level, explicitly distinguished from 'call_history' as complementary legacy-style logs. Strongly differentiates from sibling tools like user call logs.

  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 mention that it 'complements call_history' and the scope scope 'phone:read:call_log:admin' implies account-admin usage context. However, there's no explicit when-to-use vs alternatives guidance (e.g., when to use this vs phone_get_user_call_logs or phone_get_call_log_details), no exclusions or prerequisites beyond the scope token.

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

• phone_get_user_call_handling_settingsA
  3.6/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 burden. It does disclose the required OAuth scopes (phone:read:call_handling_setting or ...:admin), which is useful behavioral context. However, it doesn't disclose what the return format looks like, whether settings may be absent/defaulted, or behavior when no settings exist. No readOnlyHint means the agent can't infer safety profile from annotations.

  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, efficient and front-loaded with the purpose. The scope note adds necessary auth context. Could be slightly more economical but there's zero waste in the text.

  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 single-parameter read tool with no output schema, this is decent but not complete. The scope info is valuable. However, without annotations and without describing the return value shape or error/empty behaviors, it leaves the agent guessing about what it will actually receive. Adequate but with room to improve on output expectations.

  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% — the userId parameter is described as 'Zoom user ID or email' in the schema. The description adds no additional parameter detail beyond what the schema already provides. Baseline 3 is appropriate since the schema fully documents the single 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?

  Clear verb+resource: 'Get call handling settings' for a Zoom Phone user. The description specifies what's included (business hours / closed hours / holiday routing) and includes the scoping note about required OAuth scopes. Distinguished from sibling read tools like phone_get_user_call_logs by targeting call handling settings specifically.

  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 states what data is returned but doesn't explicitly say when to use this tool vs alternatives. The scope note implies it's for reading (not updating) settings, which distinguishes it from phone_update_user_call_handling_setting, but the guidance is implicit rather than explicit. No exclusions or when-not-to-use guidance provided.

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