Server Quality Checklist

Tool Scores

• tacticalrmm_list_checksB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'This tool is read-only' reinforces that without adding new safety context. The /checks/ endpoint path is mild behavioral context, but no additional details about pagination, filtering, or response structure 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 two short sentences, front-loading the action and resource. There is zero wasted wording, making it highly concise and scannable.

  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 and the schema/annotations provide good coverage, but the description lacks scope clarification (global vs per-agent) and gives no usage context relative to sibling tools. For a tool in a large family of list tools, this leaves the agent uncertain about when to invoke it.

  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%, with each parameter (limit, offset, response_format) already described in the input schema. The description adds no additional parameter information, 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 states the tool lists TacticalRMM checks from the /checks/ endpoint, with a specific verb and resource. However, it does not explicitly distinguish this global list from the sibling tool tacticalrmm_list_agent_checks, which likely lists checks for a specific agent.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention global scope, filtering, or contrast with tacticalrmm_list_agent_checks or tacticalrmm_get_check_history. The description only states what it does, not 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.

• tacticalrmm_list_sitesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the source endpoint and a redundant 'read-only' statement, but does not disclose additional behavioral details like pagination, response format, or relationship to clients. It is consistent with annotations but provides minimal extra context.

  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 and front-loaded, with the core action stated first. The second sentence repeats the annotation hint 'read-only', which is somewhat redundant, but overall the description is appropriately sized and easy to parse.

  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 list tool with optional parameters and no output schema, the description is minimally sufficient. It names the endpoint but does not explain what a 'site' is, how it relates to clients, or what the response contains. Given the rich annotations and schema, this is a bare minimum but not fully complete.

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

  Parameters3/5

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

  The input schema covers 100% of the parameters with clear descriptions for limit, offset, and response_format. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists TacticalRMM sites, with the specific action 'List' and resource 'TacticalRMM sites'. It also provides the source endpoint '/clients/sites/', which distinguishes it from sibling tools like 'tacticalrmm_list_clients' by resource type.

  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 given about when to use this tool versus alternatives such as 'tacticalrmm_list_clients' or other list tools. The description merely states what it does and that it is read-only, but does not mention exclusions, prerequisites, or typical use cases.

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

• tacticalrmm_get_agentA
  3.5/5.0
  Behavior2/5

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

  The description says 'This tool is read-only', which directly duplicates the readOnlyHint annotation. It adds no new behavioral context beyond repeating the annotation and the endpoint path. No information about error handling, return format, or side effects is provided, though annotations already cover the read-only and idempotent nature.

  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, consisting of two short sentences. The first sentence is front-loaded and informative. However, the second sentence ('This tool is read-only.') is redundant with the annotation, so it does not fully 'earn 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?

  For a simple get-by-id operation, the description is adequate. It specifies the required agent_id and the read-only nature. Although there is no output schema and the description does not detail the response structure, the schema's response_format parameter and the straightforward nature of a single-record fetch make this sufficient.

  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 provides descriptions for both parameters (agent_id and response_format) with 100% coverage. The description adds no additional meaning beyond what is in the schema, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Get one TacticalRMM agent record by agent_id', specifying the exact resource and how it is identified. It distinguishes from sibling tacticalrmm_list_agents by using 'one' versus implying a list operation. The endpoint '/agents/<agent_id>/' adds further specificity.

  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 the tool is used when you have a specific agent_id and need that single record, but it does not explicitly mention when not to use it or suggest alternatives for listing all agents. The usage context is clear but not fully elaborated.

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

• tacticalrmm_get_custom_fieldsA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover the safety profile. The description only repeats the read-only nature and adds the endpoint path, which is not a behavioral trait. It does not disclose return format, pagination behavior, or any additional 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.

  Conciseness4/5

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

  The first sentence is concise and front-loaded, clearly stating the action and resource. The second sentence is redundant with the readOnlyHint annotation, adding minor waste, but the overall description remains short and readable.

  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?

  For a simple read-only list tool with no required parameters and an output format option, the description is adequate. It does not explicitly describe the return structure, but the verb 'List' and the schema's response_format parameter provide sufficient context. The lack of an output schema is not a major gap given the tool's simplicity.

  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?

  All three parameters have schema descriptions providing 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents for limit, offset, and response_format.

  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 uses the specific verb 'List' and identifies the resource as TacticalRMM custom fields, including the API endpoint path '/core/customfields/'. This clearly distinguishes it from sibling list tools, which target other resources such as clients, agents, or sites.

  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 does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. However, the resource focus on custom fields implies its use case, but no contrast with sibling tools is provided.

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

• tacticalrmm_list_policiesA
  3.5/5.0
  Behavior2/5

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

  The description redundantly states 'This tool is read-only', which is already declared by annotations (readOnlyHint=true, destructiveHint=false). It adds no new behavioral context beyond annotations, such as pagination behavior, ordering, or what the response contains. The mention of the endpoint is more about purpose than behavior.

  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 very short and front-loaded with the primary action. 'List automation policies from /automation/policies/' is concise and effective. However, the second sentence 'This tool is read-only' is redundant with existing annotations and does not earn its place, so it loses a point.

  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?

  For a simple list tool with well-documented parameters and safety annotations, the description is mostly complete. It states what is listed and the source endpoint. However, it does not describe return format or pagination behavior, although these are partially addressed by parameters. Still, the description is adequate for an AI agent to select and invoke the tool 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 input schema already provides 100% coverage with descriptions for all three parameters (limit, offset, response_format), so the baseline is 3. The description does not add any parameter information or clarify their usage beyond what the schema already specifies.

  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 function with a specific verb 'List' and a specific resource 'automation policies', even specifying the endpoint '/automation/policies/'. This distinguishes it from sibling tools that list other entities like clients, agents, or sites.

  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 tool is read-only, which is a helpful safety cue, but it does not explicitly state when to use this tool over alternatives or provide exclusionary guidance. The intended use is largely implied by the tool name and the fact that it lists policies, but no explicit 'when to use' or 'instead of' instructions are given.

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

• tacticalrmm_get_check_historyA
  3.6/5.0
  Behavior2/5

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

  The description states 'This tool is read-only,' but this is already captured by the readOnlyHint annotation. No additional behavioral traits (e.g., pagination details, rate limits, required permissions) are disclosed. The description adds no context beyond the annotations, so it does not meet the bar for added transparency value.

  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 that directly convey the action and read-only nature. Every word earns its place, with no redundancy or fluff. It is highly concise and front-loaded with the core purpose.

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

  Completeness4/5

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

  Given the simple read-only nature, strong annotations (readOnly, idempotent, non-destructive), and fully documented parameters, the description is adequate for an agent to understand the tool's scope. While there is no output schema, the response_format parameter hints at expected outputs. It does not elaborate on the history data structure, but for a simple retrieval tool this is acceptable.

  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 (limit, offset, check_id, response_format) are already fully documented in the input schema. The description itself adds no parameter-specific information beyond what the schema provides, meeting the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the action ('Read history'), the specific resource ('one TacticalRMM check'), and the endpoint ('/checks/<check_id>/history/'). It distinguishes this tool from sibling history/list tools by focusing on a single check's history, making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for retrieving a single check's history but does not explicitly state when to choose this over alternatives like tacticalrmm_list_agent_history or tacticalrmm_list_checks. No exclusions or alternative recommendations are provided, so the guidance is only implicit.

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

• tacticalrmm_list_agent_historyA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety profile is covered. The description adds the specific API endpoint ('/agents/<agent_id>/history/'), which is useful context, but it does not disclose additional behavioral traits such as pagination behavior, rate limits, or what kind of history is included.

  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 only two sentences, front-loaded with the action, and every word adds value. It does not waste space or repeat obvious details.

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

  Completeness4/5

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

  Given the rich schema and annotations, the description is mostly complete. It does not explicitly describe the return format, but the response_format parameter covers this. It could be slightly more informative about what the history entries represent, but for a list operation this is acceptable.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters (limit, offset, agent_id, response_format). The description does not add any meaning beyond reinforcing the agent_id path parameter. Baseline 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 ('List') and resource ('history for one TacticalRMM agent'), and the endpoint is specified. This distinguishes it from sibling tools like list_agents and list_agent_software, which operate on different resources.

  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 given on when to use this tool versus alternatives. It does not mention exclusions or provide a context such as 'use when you need agent activity logs.' The only usage-related hint is implicit from the resource name, but no explicit guidelines exist.

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

• tacticalrmm_list_agent_notesA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description repeats 'read-only' and adds the endpoint, but does not disclose additional behaviors like pagination behavior or response structure. Since annotations cover the safety profile, a middle score is appropriate.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action and resource. No filler. The read-only note is short and reinforces the annotation without overloading. Every sentence 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?

  For a simple listing tool with good annotations and complete schema, the description is sufficient. It specifies the endpoint and read-only nature, and the response_format parameter covers output expectations. No output schema exists, but the parameters effectively describe the response format. Slight lack of detail on the content of notes, but not critical for such a straightforward 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% for all four parameters, so the schema already documents each parameter. The description adds no extra meaning beyond the endpoint context, which is expected given the full schema coverage. 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?

  Description clearly states 'List notes for one TacticalRMM agent' with a specific verb and resource, including the API path. It distinguishes from siblings like list_all_agents or list_agent_software by specifying 'notes' and 'for one agent'.

  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 retrieving notes for a single agent, but does not explicitly mention alternatives or when-not-to-use. It is implied by the tool name and endpoint, but lacks explicit guidance compared to tools that name alternatives.

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

• tacticalrmm_list_agent_tasksA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds minimal behavioral context beyond repeating read-only and giving the source endpoint; it does not disclose pagination behavior or return format specifics beyond what the schema provides.

  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 focused sentences, front-loaded with the action and scope, with no wasted words. Every sentence adds value.

  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?

  For a simple read-only list tool with comprehensive schema and annotations, the description is nearly complete. It sufficiently explains the resource and endpoint, but lacks explicit comparison to sibling list_tasks, which would improve completeness.

  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 provides 100% parameter coverage with descriptions for all four parameters. The description adds no new semantic meaning beyond referencing agent_id in the endpoint, 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 the action ('List automated tasks') with a specific resource ('assigned to one TacticalRMM agent') and endpoint. It distinguishes from sibling tools like tacticalrmm_list_tasks by focusing on a single agent via agent_id.

  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?

  Usage is implied through the endpoint and agent_id parameter: this tool is for tasks of a specific agent. However, there is no explicit when-to-use vs alternatives, no exclusions, and no mention of tacticalrmm_list_tasks for broader task listing.

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

• tacticalrmm_list_agent_servicesA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description repeats read-only status and adds the endpoint path, which is a minor implementation detail. No additional behavioral traits (pagination, response format specifics) are disclosed 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.

  Conciseness4/5

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

  The core sentence is concise and front-loaded. However, the second sentence 'This tool is read-only' is redundant given the readOnlyHint annotation, so it doesn't fully earn 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?

  For a simple read-only list tool, the description states the resource and endpoint. However, with no output schema, it doesn't describe the response structure (e.g., service fields), which would be helpful. Given the schema and annotations cover parameters and safety, it's reasonably complete but not comprehensive.

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

  Parameters3/5

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

  Schema has 100% description coverage for all 4 parameters, including defaults and constraints. The description doesn't add parameter-specific meaning beyond what's in the schema, so baseline 3.

  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 uses the specific verb 'List' and identifies the exact resource: 'Windows service inventory for an agent' plus the API path '/services/<agent_id>/'. This clearly differentiates it from sibling list tools like list_agent_software or list_agent_checks.

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

  Usage Guidelines4/5

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

  The description implies the use case (listing services for a specific agent) but does not explicitly state when to prefer it over alternatives or mention exclusions. It provides clear context but no alternative guidance, so it falls short of a 5.

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

• tacticalrmm_list_clientsA
  3.9/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the endpoint '/clients/' and the auth-bound visibility ('visible to the API key'), which provides context beyond the structured annotations. No contradiction.

  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 only two sentences, front-loaded with the core purpose. However, the second sentence ('This tool is read-only') is redundant with the readOnlyHint annotation, so it does not fully earn its place. Still, it is concise and well-organized.

  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?

  For a simple read-only list tool with no output schema and only optional parameters, the description is adequate. It mentions the endpoint, scope, and read-only nature. It could explicitly note pagination behavior, but the schema already describes limit/offset, so this is not a major gap.

  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 describes all three parameters (limit, offset, response_format) with full 100% coverage, so the baseline is 3. The description adds no parameter-specific information, so no bonus is warranted.

  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 uses the specific verb 'List' with the resource 'clients' and specifies the source '/clients/'. This clearly differentiates it from sibling tools that list other resources (agents, sites, etc.). The scope 'visible to the TacticalRMM API key' adds important context.

  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 retrieving the client list, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or alternative tools, so usage context is only implicit.

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

• tacticalrmm_list_pending_actionsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description's 'read-only' is redundant. It adds the global scope and source endpoint but does not disclose other behavior such as pagination, response contents, or how global filtering works, leaving room for more context.

  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 with no wasted words. The description is front-loaded with the action and resource, followed by a clear read-only note, making it highly concise and scannable.

  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?

  While the description names the global pending actions and source, it does not explain what pending actions are, what the response looks like, or how to interpret the output. With no output schema and no return-value guidance, the description is adequate but leaves the agent to infer important 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?

  Schema description coverage is 100%, with each parameter (limit, offset, response_format) having a clear description. The tool description adds no parameter-specific meaning, so the baseline score of 3 applies given the schema does the heavy lifting.

  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 'List global pending actions' with a specific verb, resource, and scope. The word 'global' distinguishes it from the sibling tool tacticalrmm_list_agent_pending_actions, and the source endpoint adds specificity.

  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 term 'global' implies use for system-wide pending actions rather than agent-specific ones, providing clear context. However, it does not explicitly mention the alternative sibling for per-agent pending actions or state when not to use this tool, so it misses the explicit exclusion criterion for a 5.

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

• tacticalrmm_list_scriptsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces this by saying 'This tool is read-only and does not run scripts', adding the explicit constraint that no script execution occurs. However, it doesn't detail return format or pagination, which is a minor gap.

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

  Conciseness5/5

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

  Two concise sentences, no filler. The first sentence states the action and resource; the second clarifies safety, both earning their place.

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

  Completeness5/5

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

  The tool is a simple read-only listing with 3 documented optional parameters and rich annotations. The description covers purpose and safety; combined with the schema, it gives an agent enough to select and invoke correctly. No output schema needed.

  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%; all three parameters (limit, offset, response_format) have descriptions in the schema. The tool description does not add additional parameter semantics beyond what the schema provides, so 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?

  Description uses specific verb 'List' and resource 'scripts from the TacticalRMM script library at /scripts/', providing clear scope. It explicitly distinguishes itself by stating it is read-only and does not run scripts, setting it apart from potential script execution 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?

  No explicit guidance on when to use this tool over alternatives is provided. While it clarifies the tool's read-only nature, it doesn't mention related list tools (e.g., list_agents, list_tasks) or exclude cases. This leaves the selection criteria implicit.

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

• tacticalrmm_list_agent_checksA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is well-covered. The description adds the endpoint path but otherwise restates 'read-only', which is redundant. No additional behavioral details like pagination or rate limits are disclosed, so a 3 is appropriate.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action and scope, and no wasted words. 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?

  For a simple list tool with complete schema and strong annotations, the description is sufficient. It mentions the per-agent scope and endpoint, and the response_format parameter handles output variety. Could mention return structure, but not required given 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 coverage is 100%, with every parameter described clearly. The description does not add extra parameter semantics beyond what the schema provides, matching the baseline for fully documented schemas.

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

  Purpose5/5

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

  The description clearly states the action ('List checks') and the resource scope ('assigned to one TacticalRMM agent'), with the specific endpoint path (/agents/<agent_id>/checks/). This distinguishes it from sibling tools like list_checks, which likely cover all checks.

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

  Usage Guidelines4/5

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

  The description implies use for a single agent, which helps distinguish from list_checks. But it does not explicitly mention alternatives or exclusion criteria, such as 'for all checks use list_checks'. The 'one agent' wording provides clear context, earning a 4.

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

• tacticalrmm_list_tasksA
  4/5.0
  Behavior4/5

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

  The description reinforces the readOnlyHint by explicitly stating 'read-only' and adds the important behavioral detail that it 'does not run tasks,' which is not covered by annotations. The '/tasks/' source also provides endpoint context. No contradictions with annotations.

  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 concise, consisting of two sentences, front-loaded with the main action, and contains no unnecessary words. It is well-structured for quick comprehension.

  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 a simple list operation with a well-documented schema and strong annotations. The description adequately covers the purpose and safety behavior, though it could mention the return format or explicitly differentiate from list_agent_tasks. Given the low complexity, it is sufficiently complete.

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

  Parameters3/5

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

  All three parameters (limit, offset, response_format) are fully described in the input schema with clear descriptions, so the description adds no additional parameter semantics. Baseline 3 is appropriate given 100% schema coverage.

  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 uses the specific verb 'List' and identifies the resource as 'TacticalRMM automated tasks' with the source endpoint '/tasks/'. This clearly distinguishes it from siblings like list_agent_tasks, which are agent-scoped, and from task-execution 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 states the tool is read-only and does not run tasks, giving context for safe use. However, it does not explicitly mention when to use this tool over alternatives such as tacticalrmm_list_agent_tasks, nor does it provide exclusions or prerequisites.

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

• tacticalrmm_list_agent_pending_actionsA
  4.1/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description's read-only note adds no new behavioral information. No additional traits like pagination or error behavior are disclosed beyond what the annotations provide.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the action and resource. It has no unnecessary elaboration, making it efficient and easy to parse.

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

  Completeness5/5

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

  This is a straightforward list operation with comprehensive schema coverage and strong safety annotations. The description is complete for an agent to understand the tool's purpose and scope without needing further detail.

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

  Parameters3/5

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

  The input schema covers all four parameters with detailed descriptions, so the baseline is 3. The description's endpoint notation only reiterates the agent_id parameter without adding meaningful semantic value.

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

  Purpose5/5

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

  The description clearly states the tool lists pending actions for one TacticalRMM agent and specifies the endpoint. It distinguishes itself from sibling tools like the general pending actions list by explicitly scoping to a single agent.

  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 gives clear context that this tool operates on a single agent, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the top score.

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

• tacticalrmm_list_agent_softwareA
  4.1/5.0
  Behavior3/5

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

  The description states 'This tool is read-only,' which is redundant given the annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. It adds the endpoint path but no further behavioral context such as authentication, rate limits, or return values. With strong annotation coverage, the description adds minimal extra value beyond what annotations already provide.

  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, front-loaded with the core purpose. It contains no filler or redundant details, and every word serves a purpose. Very concise and well-structured.

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

  Completeness5/5

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

  For a simple list tool with only two parameters, strong annotations, and no output schema, the description adequately conveys what the tool does and how it is scoped. It is complete for its intended use, similar to the calibration example of get_calls.

  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%, meaning both parameters are fully described in the input schema. The description does not add any parameter-level detail beyond the schema. The baseline of 3 applies because the schema does the heavy lifting and description doesn't need to compensate.

  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 uses a specific verb ('List') and resource ('software inventory for a TacticalRMM agent'), and includes the endpoint path /software/<agent_id>/ which adds clarity. It clearly distinguishes this tool from sibling tools like 'list_agent_services' or 'list_win_updates' by focusing on software inventory.

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

  Usage Guidelines4/5

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

  The description clearly indicates this tool is for listing software inventory of a specific agent, which implies the appropriate context. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusions. The context is clear enough for an agent to choose it appropriately among many list tools.

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

• tacticalrmm_get_audit_logsA
  4.2/5.0
  Behavior4/5

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

  The annotations already mark it as readOnlyHint=true, and the description reinforces this by calling it 'read-only.' The added note about TacticalRMM examples using a PATCH request body for filters provides useful behavioral context about the underlying API's quirk, going beyond the structured annotations.

  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, front-loaded with the purpose, and includes only relevant technical detail. No wasted words; every part contributes to understanding the tool's function.

  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?

  With 7 parameters fully documented in the schema and no output schema, the description adds the endpoint and a relevant API caveat. It doesn't describe the structure of the returned audit log entries, but given the response_format parameter covers output, the overall guidance is fairly complete for a query tool.

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

  Parameters3/5

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

  The input schema provides complete descriptions for all 7 parameters (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics, but the schema already covers pagination, filters, sorting, and output format.

  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 queries TacticalRMM audit logs from a specific endpoint (/logs/audit/), using a precise verb and resource. It is distinct from sibling tools which all target other data types, so no ambiguity remains.

  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?

  It clearly indicates the tool is for querying audit logs, giving immediate context for when to use it. However, it does not explicitly mention exclusions or alternatives, though the unique resource (audit logs) makes the usage scope obvious relative to the listed siblings.

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

• tacticalrmm_list_agentsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about API key visibility scoping and the source endpoint /agents/, which is beyond the annotations. It does not detail pagination behavior, but the existing annotations and description provide adequate transparency.

  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 immediately states the action and resource, then lists optional filters. There is no waste, and it avoids repeating schema details.

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

  Completeness4/5

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

  Given the tool's relative simplicity and 100% schema coverage, the description is sufficient for an agent to understand what the tool does. However, with no output schema, it would be slightly more complete to mention that the 'detail' flag changes the response from summaries to detailed records, but the schema already covers this, so the description 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?

  Schema description coverage is 100%, so the baseline is 3. The description lists some filter names (client, site, monitoring_type, detail) but does not add meaning beyond what the schema already provides, such as types, defaults, or the effect of 'detail' on response shape. The schema carries the heavy lifting, so no extra credit is warranted.

  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 'List agents visible to the TacticalRMM API key from /agents/' with a specific resource (agents), a specific source endpoint, and optional filters (client, site, monitoring_type, detail). This distinguishes it from sibling tools like get_agent (singular) and other list tools by explicitly naming the resource and filtering options.

  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 that this tool is for listing agents, scoped by API key visibility, with optional filters. It does not explicitly mention alternatives or exclusions, but the phrasing implies usage when you need a filtered list of agents, which is sufficient for a straightforward listing tool.

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

• tacticalrmm_list_alertsA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover read-only and safety. The description adds the behavioral note about TacticalRMM expecting a PATCH query for filters, which explains the tool's parameter limitations. This goes beyond annotations, though it doesn't detail pagination or response structure.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action, and no unnecessary words. The endpoint reference is precise and adds value.

  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?

  For a simple list tool with 3 optional parameters, clear schema, and strong annotations, the description is adequate. It gives the endpoint and read-only nature, plus a note on filter behavior. However, it doesn't explicitly state what output to expect, though the response_format parameter covers that.

  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 a baseline of 3 is appropriate. The description doesn't add parameter-specific meaning beyond mentioning the endpoint; the schema descriptions are already self-explanatory for limit, offset, and response_format.

  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 'List TacticalRMM alerts from /alerts/', specifying the verb, resource, and endpoint. This distinguishes it from sibling tools since no other sibling lists alerts.

  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?

  It explicitly says 'This tool is read-only' and mentions that TacticalRMM expects a PATCH query for alert filters, suggesting this GET-style tool doesn't handle filters. This gives clear context, but no explicit alternative or when-not-to-use guidance is provided.

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

• tacticalrmm_list_win_updatesA
  4.2/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating 'does not scan or install updates', which goes beyond the generic read-only annotation and clarifies that this is purely an inventory listing operation. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two concise sentences that are front-loaded with the core action and endpoint. Every sentence earns its place, and there is zero waste or redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (list operation, 4 parameters, no output schema), the description is sufficient. It communicates the purpose, endpoint, and the fact that it's non-intrusive. However, a brief note on the return structure (e.g., fields like update title, date) would improve completeness since there is 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?

  The input schema has 100% description coverage for all four parameters, including defaults and enums. The description does not add any additional parameter-specific meaning beyond what the schema already 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 the tool's purpose: 'List Windows Update inventory for an agent' with a specific API endpoint. This verb+resource combination distinguishes it from sibling list tools like list_agent_software or list_agent_services, which focus on other aspects of agent inventory.

  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 is read-only and does not scan or install updates, which implies when it should and should not be used. However, it does not explicitly name an alternative tool for scanning or installing updates, or provide explicit 'when to use' scenarios beyond the read-only note.

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

• tacticalrmm_get_server_infoA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by naming the exact API endpoints (/core/version/ and /core/dashinfo/), giving the agent more context about what data is returned. It does not fully detail the dashboard info fields, but given the strong annotation coverage, this is acceptable.

  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 front-loads the action ('Read') and resource, then specifies the endpoints. Zero wasted words and highly scannable.

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

  Completeness5/5

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

  For a simple, read-only, server-info tool with one optional param and no output schema, the description plus the schema fully cover what an agent needs: purpose, endpoints, and response format choice. No 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?

  The input schema has 100% coverage for the single parameter response_format, including its enum values and default. The description does not add any additional parameter semantics beyond what the schema already provides. The baseline of 3 applies because the schema carries the full burden.

  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 reads TacticalRMM server version and dashboard information from specific endpoints. The verb 'Read' plus the resource and endpoint paths make the purpose unambiguous, and it is distinct from all sibling tools that focus on clients, agents, sites, 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 implies when to use this tool: when server-level version or dashboard info is needed. It does not explicitly state alternatives or exclusions, but the sibling tools are clearly scoped to other resources (clients, agents, tasks, etc.), so the context is clear enough. No misleading guidance.

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