Server Quality Checklist

Tool Scores

• motion_usersC
  2.3/5.0
  Behavior1/5

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

  No annotations are present, so the description carries the full burden. It says 'manage users,' implying mutations, but the schema's operation enum only allows read-only actions (list and current). This is misleading. No other behavioral traits (permissions, side effects, return format) are disclosed.

  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 sentence, so it is concise, but it is under-specified and vague. It could be just as concise while being more informative (e.g., 'List users or get the current user's details'). The structure is simple and front-loaded, but the content is weak.

  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 tool with 4 parameters and no output schema, the description is too thin. It does not explain how operations map to parameters, what filters are available, or what results to expect. The lack of any return-value or behavior details leaves the agent with significant 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 the parameters are already well-documented. The description does not add any extra meaning about the parameters or their relationships, but it does not need to compensate given the schema's clarity.

  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 identifies the resource (users) and mentions two actions (manage and get current user), but 'manage' is vague and does not specify the actual operations (list and current) that the schema defines. It does distinguish from siblings like motion_tasks or motion_projects, but the purpose lacks specificity.

  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, how to choose between the 'list' and 'current' operations, or any alternatives. The description does not mention prerequisites or context for using parameters like teamId or workspaceId.

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

• motion_commentsC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavior, but it only says 'manage comments'. It does not reveal that create is a mutating operation, whether list is read-only, pagination behavior via cursor, or any side effects or permissions. This is insufficient for a tool that supports both read and write operations.

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

  Conciseness2/5

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

  The description is a single short sentence, but it is under-specified rather than appropriately concise. It omits details about operations and usage, making it minimally informative. Like the calibration example for under-specification, this does not count as effective 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 4 parameters, no output schema, and no annotations, the description is too skeletal to be complete. It fails to explain return values, pagination, operation-specific details, or any behavioral nuances, leaving significant gaps for an agent to safely invoke the 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?

  Schema description coverage is 100%, so all four parameters (cursor, taskId, content, operation) are already documented in the schema. The description adds no additional semantic context beyond the generic term 'manage', so the score is at the baseline of 3.

  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 'Manage comments on tasks' identifies the resource (comments) and broadly indicates management operations, but 'manage' is vague and does not specify the exact operations (list/create) that the schema reveals. It does distinguish from sibling tools by focusing on comments, but lacks a specific verb like 'list' or 'create'.

  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, nor does it explain the difference between the list and create operations. There is no mention of prerequisites or context for use, leaving the agent to infer usage entirely from the schema.

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

• motion_searchC
  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 says 'search' which implies a read-only operation, but it does not disclose behavior such as whether it returns matching tasks/projects, how results are ordered, pagination, or the role of the 'operation' parameter. The description is too thin to provide meaningful transparency.

  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 with no fluff, front-loading the verb and resource. It is appropriately short, though the lack of additional context makes it under-specified rather than efficiently informative. It earns a 4 for being concise, but not a 5 because it could be restructured to include key usage hints.

  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 six parameters, no output schema, and no annotations, the description is far too minimal. It does not mention the ability to scope searches via searchScope, filter by workspace, or the meaning of 'operation'. The description should provide at least a hint about these parameters and the tool's overall behavior to be complete enough for an agent to use correctly.

  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 descriptions cover 100% of parameters, so the bar is lower. However, the tool description adds minimal parameter meaning beyond the schema; 'by query' aligns with the 'query' parameter but does not clarify the 'operation' enum or 'searchScope' options. The schema itself already documents all parameters, so a 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?

  The description clearly states the action (search) and the resources (tasks and projects), using a specific verb+resource structure. However, it does not differentiate from sibling tools like motion_tasks or motion_projects, which could also be used to retrieve tasks/projects, but 'search' implies a distinct query-based access method.

  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 does not mention that it is for searching across both tasks and projects, nor does it indicate when a user should choose this over motion_tasks or motion_projects. No contexts, 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.

• motion_tasksC
  2.9/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only lists operations and gives no insight into side effects, destructive actions, client-side filtering, or other behavioral traits. There is no contradiction with annotations because none exist, but the description is almost entirely opaque.

  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 immediately states the tool's purpose and enumerates its operations. Every word earns its place, with no redundant filler or unnecessary repetition.

  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 complex tool with 19 parameters and 8 operations, yet the description provides only a bare list of operation names. The rich schema compensates for much of the missing detail, but the description lacks a high-level overview of usage, cross-tool references, or warnings. It is minimally viable given the schema richness.

  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% and parameter descriptions are highly detailed (e.g., autoScheduled, includeAllStatuses). The description adds nothing beyond listing operations, so it meets the baseline for schema-provided semantics but does not exceed it.

  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 'Manage Motion tasks' uses a generic verb but lists all supported operations (create, list, get, update, delete, move, unassign, list_all_uncompleted), making it clear this is the main CRUD tool for tasks. It distinguishes from sibling tools by clearly targeting the tasks resource, though 'manage' could be more 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?

  The description provides no guidance on when to use this tool versus alternatives like motion_search (for searching across entities) or motion_schedules (for schedule names). The operation list implies usage but does not state exclusions or when to prefer other tools.

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

• motion_projectsB
  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 burden of disclosing behavioral traits. It only restates the operation enum from the schema without elaborating on side effects, prerequisite permissions, return values, or behavioral differences across operations. This adds minimal value beyond the schema.

  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 is easy to parse and front-loads the tool's purpose. It is appropriately concise, though this brevity comes at the cost of substance.

  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 multi-operation tool with seven parameters and no output schema, yet the description provides only a high-level overview. It fails to explain the purpose of each operation, when to use them, or what the return value looks like, making it incomplete for an agent to select and invoke correctly.

  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 detailed descriptions for each parameter, including operation-specific requirements (e.g., 'required for create'). The description provides no additional parameter semantics, so the baseline score of 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 clearly identifies the tool as managing Motion projects and enumerates the three supported operations (create, list, get). This distinguishes it from sibling tools focused on tasks, users, etc., though the verb 'Manage' is somewhat generic.

  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 'Manage Motion projects' provides an implied usage context, indicating this tool is for project operations. However, there is no explicit when-to-use guidance or mention of alternatives (e.g., motion_tasks for tasks), making it adequate but not explicit.

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

• motion_recurring_tasksB
  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 bears the full burden. It reveals required parameters but does not disclose behavioral traits such as side effects of create/delete, required permissions, reversibility, or response formats. For a tool capable of mutation, this lack of transparency 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?

  The description is a single, front-loaded sentence followed by a compact operation-to-required-params mapping. It conveys the core function and key usage constraints without waste. Every segment serves a purpose, making it highly effective for quick scanning.

  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 the tool's complexity (15 params, nested frequency object, three operations), the description only covers required parameters. It omits behavioral details, return values, and operation-specific outcomes, all of which are important given there is no output schema. The rich parameter schema covers field meanings but not the operational flow, leaving the description insufficient for full autonomous use.

  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 every parameter with 100% coverage, including required-for notes. The description adds a per-operation summary that condenses this information into a single line, offering marginal convenience but no new semantic info 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?

  The description clearly identifies the resource ('recurring tasks') and lists the three operations (list, create, delete) with required parameters. While the verb 'manage' is generic, the operation breakdown makes the tool's purpose clear and distinguishes it from the sibling motion_tasks tool by the recurring-task resource.

  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 provides explicit required parameter mappings for each operation, which is helpful for when to use it. However, it does not explicitly state when to prefer this tool over alternatives like motion_tasks, nor does it mention any exclusions or prerequisites beyond the parameter lists. The usage context is implied but not fully differentiated.

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

• motion_workspacesA
  3.7/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 clarifies that only list and get operations are supported, implying read-only behavior, but it does not disclose return formats, pagination, or potential side effects. The word 'Manage' is slightly misleading but corrected by the operation list.

  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 sentence that directly states the tool's purpose and supported operations. It is concise with no superfluous content.

  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 no output schema or annotations, and the description does not mention return value structure or any behavioral details beyond the operation types. For a simple list/get tool this is acceptable but leaves some gaps, such as expected response shape or error handling.

  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 parameter descriptions already present (operation enum, workspaceId required for get). The tool description adds no additional parameter semantics beyond what the schema provides, so baseline 3 applies.

  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 the tool manages Motion workspaces and explicitly supports list and get operations. This is specific and clearly distinguishes it from sibling tools like motion_tasks or motion_projects.

  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 workspace list and get operations based on the resource name and stated operations, but does not explicitly provide when/when-not guidance or mention alternative tools. It relies on context rather than explicit direction.

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

• motion_custom_fieldsA
  3.8/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 lists required parameters per operation and does not mention side effects (e.g., destructive nature of delete/remove), authorization needs, rate limits, or what the tool returns. The operation names imply behavior, but the description fails to add meaningful transparency beyond what the schema already conveys.

  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 dense sentence but efficiently packs all operation-parameter mappings into a compact form. It is not verbose and contains no filler, though breaking it into a list or bullet points could improve readability. Overall, it 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?

  Given the tool's complexity (7 operations, 12 params, no output schema or annotations), the description provides solid coverage of required parameters but lacks high-level context about what each operation does beyond the verb (e.g., return values, error conditions, or behavioral side effects). It is adequate for invoking the tool correctly but not rich in context.

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

  Parameters4/5

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

  The schema has 100% coverage, so baseline is 3. The description adds value by grouping parameters by operation (e.g., 'create: workspaceId/workspaceName + name + field') and clarifying conditional requirements like 'options[] also required for select/multiSelect'. This cross-cutting mapping is not immediately apparent from individual parameter descriptions and helps the agent understand dependencies.

  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 tool's purpose: 'Manage custom fields for tasks and projects.' This is a specific verb+resource that distinguishes it from sibling tools like motion_tasks and motion_projects. It also enumerates all supported operations, making its scope immediately evident.

  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 provides clear context for when to use the tool (for custom field operations on tasks/projects) and lists operation-specific required parameters, implicitly guiding the agent. However, it does not explicitly mention alternatives or exclusions, though the unique domain makes that less necessary.

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

• motion_statusesA
  3.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 says 'Get' with no mention of safety, permissions, return format, pagination, or rate limits. For a read operation, more context is expected, such as whether the statuses are system-defined or user-defined, or any side effects.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that wastes no words. It immediately states the action and resource, and the optional workspace context is implied. Every word earns its place.

  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?

  The tool is simple with only one optional parameter and no output schema. The description explains the primary purpose, and the schema covers the nuance of workspaceId behavior. It could mention the return type, but for a status lookup tool, the description is sufficiently complete for an agent to understand the operation.

  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% because the only parameter, workspaceId, already has a clear description in the schema ('optional, returns all statuses if not specified'). The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Get') and resource ('task/project statuses') with a scope ('for a workspace'). This distinguishes it from sibling tools like motion_tasks, motion_projects, and motion_custom_fields, which cover other resources.

  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 provides clear context: it's for fetching statuses in the context of a workspace. It does not explicitly mention when not to use it or alternative tools, but the purpose is specific enough that an agent would know when to invoke it. No exclusions or alternatives are stated, which prevents the highest score.

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

• motion_schedulesA
  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. It discloses the behavior of returning all schedules without filtering, and mentions the data included (weekly hours and time zones). However, it doesn't cover pagination, authentication, or other potential behaviors.

  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 sentences long, with the primary action in the first sentence and additional scope clarification in the second. No unnecessary words.

  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?

  The tool is simple with a single optional parameter and no output schema. The description provides essential information about what is returned (all schedules, work hours, time zones) and the lack of filtering. It could be more explicit about potential pagination or additional fields, but overall it is adequate.

  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 single parameter 'operation' is fully described in the schema with an enum of 'list', and schema coverage is 100%. The description doesn't add parameter-specific information, but the schema is sufficient.

  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 identifies the tool as retrieving all schedules, with specific mention of weekly working hours and time zones. It distinguishes the tool from sibling tools that focus on tasks, users, projects, etc.

  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 states that the tool returns all schedules and has no filtering options, implying it is for unfiltered access. While it doesn't explicitly mention alternative tools, it provides clear context for when to use it.

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