Server Quality Checklist

Tool Scores

• superops_tickets_createC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it only states the mutation itself. It does not disclose side effects (e.g., notifications to technicians or requester), what the response contains, or what happens on validation failures such as an unknown clientId.

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

  Conciseness4/5

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

  A single sentence with no wasted words, front-loading the verb and object. It loses a point because the brevity veers toward under-specification for a creation tool — more behavioral content could have been added without harming clarity.

  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 7-parameter mutation tool with no output schema and no annotations, this is thin. It omits return-value behavior, side effects, and failure semantics — exactly the context an agent needs to confirm the ticket was created and to handle errors.

  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 all 7 parameters individually described in the input schema. The description 'Create a new ticket' adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

  Purpose4/5

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

  The description opens with a specific verb ('Create') and names a precise resource ('a new ticket') in the SuperOps.ai system, so an agent immediately knows the operation. Among ticket siblings (list, get, update, add_note, log_time), 'create' is the only creation verb, but the description doesn't explicitly contrast itself with alternatives, stopping short of a 5.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus siblings like superops_tickets_update or superops_tickets_add_note, and mentions no prerequisites such as looking up a valid clientId via superops_clients_list. An agent must infer the entire call context from the name alone.

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

• superops_tickets_updateC
  2.9/5.0
  Behavior2/5

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

  Annotations are absent, so the description must carry the transparency burden. It communicates a mutating operation and mentions 'resolution' as an input, but does not disclose whether updates are partial or full replacements, whether resolution is required when status is set to Resolved/Closed, permission requirements, 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?

  A single hyphenated sentence that front-loads the action and then lists categories of fields, with no filler. It is as short as possible while conveying the tool's scope.

  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?

  The schema and the absence of an output schema mean the description is the only source for behavior and return expectations, and it remains skeletal. Missing usage exclusions, partial-update semantics, and outcome/response details make it incomplete for an agent choosing between six ticket tools.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema documents every parameter and the description need not repeat details. The description groups fields semantically ('assignment' for assigneeId/techGroupName) but adds no format/default/enum meaning beyond the schema.

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

  Purpose4/5

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

  The description starts with a specific verb+resource ('Update an existing ticket') and enumerates the editable aspects (status, priority, assignment, resolution), which distinguishes it from create/get/list siblings by scope. It doesn't explicitly name sibling alternatives, but the intent is unmistakable.

  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 choose this over tickets_create, tickets_add_note, or other ticket mutations. The phrase 'existing ticket' implies it is not for creation, but there are no exclusionary or conditional statements.

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

• superops_statusB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool shows status, with no detail on what states are reported, whether this is a live check or cached data, or what the response contains. This is minimal and leaves behavioral expectations vague.

  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 short phrase with no wasteful content. The key resources are presented immediately and clearly for a zero-parameter status tool.

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

  Completeness3/5

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

  The tool is simple and has no parameters, but there is no output schema and no explanation of what 'credentials status' or 'available domains' means in practice. An agent knows roughly what it will see, but not the shape or semantics of the returned data, which limits completeness.

  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 tool has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the description need not compensate for undocumented parameters.

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

  Purpose4/5

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

  The description names a specific operation ('show') and two concrete resources ('credentials status' and 'available domains'). It is clear enough to distinguish this from data-retrieval and mutation siblings, though it doesn't explicitly contrast itself with similar tools like superops_test_connection.

  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 about when to call this tool versus alternatives. The description does not mention typical use cases, prerequisites, or exclusions, so an agent must infer when 'status' is needed.

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

• superops_tickets_log_timeB
  3.2/5.0
  Behavior2/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 of behavioral disclosure. It states that the tool logs time, but does not explain whether this appends to existing time entries, mutates ticket totals, requires permissions, or returns a result. For a state-changing tool, this is a meaningful gap.

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

  Conciseness5/5

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

  The description is a single clear sentence with no filler or repetition. It is appropriately concise for a straightforward action and front-loads the core verb and resource.

  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?

  The schema covers all parameters well and enforces required fields, but the tool has no annotations and no output schema, and the description does not clarify expected behavior, constraints, or return value. An agent could invoke it based on schema alone, but important operational context is missing for a mutation 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 the parameters are already documented with names, types, and descriptions. The tool description adds no extra semantic detail beyond what the schema provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('Log time spent on a ticket') that clearly identifies the operation. It is easily distinguished from siblings like superops_tickets_add_note or superops_tickets_update by its focus on time tracking.

  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 about when to use this tool versus related ticket tools, or about prerequisites such as the ticket needing to exist. The name implies its purpose, but the description does not state exclusions or alternatives.

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

• superops_technicians_listB
  3.3/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full behavioral disclosure burden. It restates the filter options already represented in the schema and does not mention pagination behavior, output shape, or the read-only side-effect profile except by the verb '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?

  Two short, front-loaded sentences with no filler. The core purpose comes first and the optional filter capability is stated compactly.

  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 4-parameter paginated list with no output schema and no annotations, the input schema covers the call mechanics, but the agent is left to infer return shape, pagination details, and how this relates to superops_technicians_get and superops_technicians_groups. That is a moderate gap, not a fatal one.

  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 max, cursor, teamId, and activeOnly are already documented with defaults. The description's 'active status or team' maps to two params but adds no meaning beyond the schema.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'List technicians (agents) in SuperOps.ai'. The parenthetical clarifies domain terminology, and the second sentence adds filtering scope, making it easy to distinguish from the singular superops_technicians_get sibling.

  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 for when to choose this over superops_technicians_get or superops_technicians_groups. The phrase 'Can filter by active status or team' describes capabilities, not decision criteria or exclusions.

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

• superops_tickets_listB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits itself. It only says 'List tickets' and mentions filters; it does not mention pagination/cursor handling, default or maximum result count, result ordering, or whether any side effects occur. This is a safe read-like operation but that is inferred, not disclosed.

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

  Conciseness5/5

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

  The description is one short, front-loaded sentence that states the action first and then lists filter options without padding. Every phrase contributes; no unrelated information is present.

  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 read/list operation with a fully documented parameter schema, this is minimally viable, but there are gaps: no mention of pagination despite cursor/max parameters, no guidance on output/return shape (and no output schema exists), and no alternative tool routing. It is enough for basic calls but not fully self-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?

  Schema description coverage is 100%, so the schema already documents all seven parameters and their allowed filter values. The description's 'status, priority, client, or assignee' phrase merely restates what the schema contains and adds no extra meaning about max, cursor, or unassigned semantics. Baseline 3 applies because the schema carries the load.

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

  Purpose4/5

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

  The description names a concrete verb and resource ('List tickets in SuperOps.ai'), making the core operation clear. It also names filter dimensions, but it does not explicitly contrast with siblings like superops_tickets_get or create, so a weaker agent could still wonder whether it returns a single ticket or a collection, although 'list' implies collection.

  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 filter sentence gives a sense of when the tool is appropriate (when you need multiple tickets by status, priority, client, assignee), but there is no explicit when-to-use or when-not-to-use guidance relative to tickets_get, tickets_create, or the custom query tool. Usage context is implied, not stated.

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

• superops_custom_mutationB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It mentions 'write operations,' which implies mutation, but it does not warn about potential destructiveness, irreversibility, required permissions, or side effects of executing arbitrary GraphQL mutations. This is a significant gap for a tool that can run any mutation.

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

  Conciseness5/5

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

  The description is two short sentences with no redundancy. The core action is front-loaded, and the usage qualification follows efficiently. Every word earns its place.

  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 low-level, open-ended mutation tool with no annotations and no output schema, the description is too thin. It does not explain what the response will look like, warn about the risks of arbitrary mutations, or clarify that variables are optional. An agent receives only the barest sketch of how to use this safely or effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no new meaning about the parameters beyond what the schema already states; it merely labels the action as a mutation. It is adequate but provides no additional semantic value.

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

  Purpose4/5

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

  The description states a clear verb ('Run'), resource ('SuperOps.ai API'), and operation type ('GraphQL mutation'), and specifies it is for advanced write operations. It does not explicitly name the sibling superops_custom_query, but the mutation/query distinction is implicit in the GraphQL terms, giving adequate differentiation from standard tools.

  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 phrase 'For advanced write operations not covered by standard tools' conveys when this tool should be used and implies that standard tools should be the first choice. It does not explicitly enumerate alternatives or state when not to use it, falling slightly short of explicit when/when-not guidance.

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

• superops_technicians_groupsB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the burden of disclosing behavior. It states the operation is a 'List,' implying read-only, but does not disclose pagination, ordering, or whether the response is just group names or includes nested members. It does not contradict annotations because none are provided, but the single-sentence description adds only minimal behavioral context beyond the obvious listing action.

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

  Conciseness4/5

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

  The description is a single sentence that is front-loaded with the verb and resource, making it immediately scannable. It contains no wasted words, though it omits optional details that could be added without bloat.

  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 one optional parameter and no output schema, the description is largely adequate. Missing context includes whether groups are paginated, what the response shape contains, or any required authentication specifics, but with no output schema and simple functionality, the description covers the essential invocation. The lack of a connector prefix in the description (e.g., 'SuperOps.ai technician groups') is minor because the tool name and sibling context already anchor 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% because the only parameter 'max' has a description that explains it is the maximum number of results with a default of 50. The description adds no further meaning to this parameter, so a baseline 3 is appropriate since the schema already handles the semantics.

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

  Purpose4/5

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

  The description uses the specific verb 'List' with the resource 'technician groups/teams in SuperOps.ai,' which clearly states the operation and distinguishes it from sibling tools like superops_technicians_list (individual technicians) and superops_technicians_get (single technician). It lacks the 'ALL' scope detail seen in higher-rated examples but it is 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 the tool is for retrieving technician groups rather than individual technicians, which distinguishes it from superops_technicians_list and superops_technicians_get. However, it does not explicitly state when to choose this over alternatives or provide exclusion criteria, leaving the agent to infer the use case from the resource name.

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

• superops_assets_patchesA
  3.5/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. 'Get' clearly signals a read-only operation and 'for a specific asset' scopes the call, but no further behavioral traits are disclosed, such as filter behavior, pagination, or response shape. It is adequate but minimal.

  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 states the verb, the resource, and the scope without filler. It is appropriately sized for a simple read tool, leaving optional filter details to the schema.

  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 3-parameter read tool, the description minimally explains the return concept ('patch status and pending patches'), but without an output schema it does not clarify the response structure, how statuses are represented, or how the status/severity filters affect results. It is sufficient but leaves clear gaps.

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

  Parameters3/5

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

  All three parameters are already described in the input schema, including the status enum and severity list, so schema coverage is 100%. The description adds no parameter-level meaning beyond restating that the operation targets 'a specific asset,' which maps directly to assetId.

  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 ('Get') and identifies the exact resource ('patch status and pending patches') scoped to 'a specific asset.' This is enough to distinguish it from sibling tools like superops_assets_get and superops_assets_software, which target general asset details or installed software.

  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 explicit when-to-use guidance, exclusions, or mention of alternative tools. The only implicit signal is 'for a specific asset,' so an agent must infer when this should be selected among the many asset-related siblings.

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

• superops_clients_searchA
  3.5/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 disclosing behavioral traits. It does not explicitly state this is a read-only operation, does not mention result limits (though max parameter exists), pagination, or error handling. The description only mentions that it returns matching clients with basic information, which is insufficient for a tool that could modify data or have 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, concise sentence that clearly states the action and expected output. It is front-loaded with the primary purpose and contains no irrelevant details or fluff.

  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 search tool with only two parameters and no output schema, the description is reasonably complete in explaining what it does and returns. However, it lacks guidance on when to use it compared to sibling tools, and does not disclose whether it is a read-only operation. Given the absence of annotations, these gaps lower the completeness score.

  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 both parameters, and the description adds no new meaning beyond what the schema already provides. It restates the search criteria ('by name or email domain') which matches the query parameter description, and makes no mention of the max parameter's behavior beyond the default. Since the schema covers all parameters, 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 the verb 'Search', the resource 'clients', and specific search criteria ('by name or email domain'). It differentiates from siblings like superops_clients_list (likely returns all clients) and superops_clients_get (likely a single client) by emphasizing the search action and filter criteria.

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

  Usage Guidelines3/5

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

  The description implies this tool is for finding specific clients via search terms, but it does not explicitly state when to prefer it over clients_list or clients_get, nor does it mention any exclusions or alternatives. The verb 'search' provides an implicit usage context, but no explicit guidance is given.

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

• superops_technicians_getA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Get' but does not mention potential errors (e.g., not found), authentication or permission requirements, response format, or any rate-limit implications. For a tool with zero annotation support, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler or redundancy. It communicates the action, target, and selection criterion efficiently.

  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 call surface is minimal—one required, fully documented parameter—so an agent can invoke it correctly. However, the description does not explain the return value shape or failure behavior, and there is no output schema to fill that 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 description coverage is 100%, and the parameter technicianId is already documented as 'The unique technician ID'. The description only restates this concept ('by their ID') without adding extra meaning such as format, source, or validation rules, so it does not exceed the schema baseline.

  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 verb ('Get'), the resource ('detailed information for a specific technician'), and the unique identifier criterion ('by their ID'). This distinguishes it from the sibling tool superops_technicians_list, which would be used for fetching multiple technicians.

  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 intended use is implied: you call this when you have a technician ID and want that one technician's details. However, there is no explicit guidance about when to avoid this tool in favor of superops_technicians_list or other siblings, nor any stated prerequisites or exclusions.

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

• superops_test_connectionA
  3.5/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 states that the tool tests the connection using credentials, but it does not disclose whether this is a read-only operation, what happens on success or failure, or whether any side effects or network calls are made beyond the basic implication of a test.

  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 clear sentence with no filler. It immediately communicates the tool's purpose and the prerequisite of configured credentials, making every word valuable.

  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 — no parameters, no output schema, no complex behavior — the description is largely complete for an agent to understand the operation. It could be improved by clarifying the expected result format or relationship to 'superops_status', but the core use case is sufficiently covered.

  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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed because the input schema is empty and fully covered.

  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 a specific action ('Test the connection') and the target resource ('SuperOps.ai API'), making the tool's purpose obvious. It does not explicitly differentiate itself from the sibling tool 'superops_status', which may also involve connectivity checks, so it stops short of a 5.

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

  Usage Guidelines3/5

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

  The phrase 'using configured credentials' implies the tool is meant for verifying API connectivity with existing credentials. However, there is no explicit guidance about when to use this tool versus alternatives like 'superops_status' or when not to use it.

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

• superops_clients_listA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does mention filtering and pagination, which is useful, but it does not explicitly state that this is a read-only operation or describe the response shape. This is adequate for a list tool but leaves minor gaps.

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

  Conciseness5/5

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

  The description is two short sentences with no redundancy. It front-loads the main purpose and then lists the key behaviors efficiently.

  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 zero required parameters and fully self-documenting parameters, the description covers the essential invocation context. It lacks a brief pointer to sibling search/get tools, but no critical details needed to call it correctly are missing.

  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 every parameter (max, stage, cursor, status) is already documented in the schema. The description adds no parameter-specific meaning beyond naming status, stage, and pagination, so it stays at the baseline.

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

  Purpose4/5

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

  The description states the core action clearly: 'List clients (accounts) in SuperOps.ai' and names the relevant filtering options. It does not explicitly contrast with sibling tools like superops_clients_search or superops_clients_get, so differentiation is left to verb and naming.

  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 conveys that the tool is for listing clients and can filter by status, stage, or paginate. However, it does not say when to prefer this tool over superops_clients_search or superops_clients_get, nor does it provide any exclusions.

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

• superops_custom_queryA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure, but it only states the high-level action. It does not disclose whether queries are read-only, what happens on invalid GraphQL, error behavior, rate limits, or authentication requirements. The term 'query' hints at a read operation but is not explicit.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The first sentence front-loads the core action, and the second states the use case. Every sentence contributes meaningful information.

  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 raw GraphQL execution tool with no annotations and no output schema, so the description needs to supply more operational context to be complete. It lacks guidance on response shape, error conditions, query scope limitations, or how it relates to custom_mutation. The current description is adequate for identifying the tool but not for safely invoking it in advanced scenarios.

  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 the schema already explaining 'The GraphQL query string' and 'Variables to pass to the query'. The description adds context about the API and advanced use, but it does not provide additional parameter-level meaning beyond the schema. 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?

  Description states a specific action ('Run a custom GraphQL query') and scope ('against the SuperOps.ai API'). It also differentiates from standard sibling tools by noting it is for advanced use cases not covered by them. The distinction from the sibling custom_mutation is implied by the GraphQL query/mutation vocabulary, which is sufficient.

  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 phrase 'For advanced use cases not covered by standard tools' clearly indicates when to use this tool and implies that standard tools should be preferred for ordinary operations. It does not explicitly mention custom_mutation as the alternative for write operations, so the guidance is good but not exhaustive.

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

• superops_tickets_add_noteA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavioral traits. It states 'Add a note' which implies a mutating operation, but it does not disclose potential side effects, permissions, or whether the note is appended to existing notes. For a simple note addition, this is adequate but not rich; more explicit disclosure of mutation safety or prerequisites would improve it.

  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, clear sentence with no filler. It communicates the primary action and a key parameter option ('internal or public') in a compact, front-loaded manner. Every word serves a 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?

  For a simple mutation tool with only 3 parameters and no output schema, the description covers the essential purpose and the main variation (visibility). It does not discuss response behavior or error handling, but given the simplicity and absence of an output schema, it is reasonably complete for an agent to call 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 provides full descriptions for all 3 parameters (100% coverage), so the schema already conveys their meaning. The description's mention of 'internal or public' adds a slight semantic layer to isPublic, but it largely repeats what the schema already states. This matches the baseline of 3 for full schema coverage.

  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 ('add a note') and the target resource ('ticket'), and it distinguishes from sibling tools like create/update which operate on the ticket itself. However, it does not explicitly name any sibling or mention what it is not, so it lacks the explicit differentiation of a 5.

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

  Usage Guidelines3/5

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

  The description provides context that notes can be internal or public, which hints at the isPublic parameter usage. However, it does not explicitly compare against alternatives like send a message, log time, or custom_mutation, nor does it specify when to use this tool over others. The guidance is implied rather than explicit.

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

• superops_assets_listA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure; 'List' conveys a read-only operation and the filter sentence describes query behavior. However, it does not mention pagination/cursor behavior, result shape, or any operational details beyond the verb, leaving noticeable gaps.

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

  Conciseness5/5

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

  Two compact sentences with the primary action front-loaded and no filler. The filter list is expressed efficiently and adds immediate value without repeating schema details.

  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?

  Without an output schema or annotations, an agent must infer the return shape from 'List assets' and the pagination parameters in the schema. The description does not explicitly mention pagination, result limits, or how filters combine, so it is adequate but not fully complete for a list tool with cursor-based pagination.

  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 echoes the filter parameters (status, platform, client) using friendly labels, but it adds no new semantic detail about max or cursor beyond what the schema already provides.

  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 opens with a specific verb 'List' and names the resource 'assets (endpoints)' in SuperOps.ai RMM. It clearly identifies this as the collection/list operation and distinguishes it from sibling tools like superops_assets_get, superops_assets_software, and superops_assets_patches.

  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 should be used to enumerate assets and shows what filters are available, but it does not explicitly state when to prefer this over sibling tools such as superops_assets_get or superops_assets_software. No exclusions or alternative routing are provided; usage context is inferred rather than spelled out.

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

• superops_assets_softwareA
  3.7/5.0
  Behavior3/5

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

  The description makes the read-only retrieval nature clear with 'Get' and identifies the returned concept as 'software inventory.' With no annotations present, it carries the behavioral disclosure burden alone, but it does not mention result format, pagination behavior, or any operational constraints beyond what the schema already documents.

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

  Conciseness5/5

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

  A single sentence with no filler, front-loads the action and resource, and is appropriately minimal for a straightforward read tool. Every word earns its place.

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

  Completeness3/5

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

  For a simple read tool with fully documented parameters, the description is mostly adequate. However, there is no output schema and the description does not clarify return structure, potential pagination, or how this tool relates to the sibling software/patch tools. An agent could invoke it correctly, but selection among close siblings would benefit from more 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?

  The input schema documents all three parameters and their purposes, so the baseline is 3. The description adds only the conceptual context that the result is software inventory; it does not add meaningful parameter-level semantics beyond the schema.

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

  Purpose5/5

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

  States a specific action ('Get') and resource ('software inventory for a specific asset'), making it clearly distinct from siblings such as superops_assets_get, superops_assets_patches, and superops_assets_list. An agent can identify exactly what this tool returns.

  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 'for a specific asset' implies the tool is scoped to one asset, which provides basic usage context. However, it gives no explicit guidance about when to prefer this over related tools like superops_assets_patches or how to obtain the required assetId. Usage is implied rather than stated.

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

• superops_tickets_getA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry behavioral disclosure. It communicates a read/get operation but adds no detail on response structure, error behavior (e.g., unknown ticket ID), permissions, or what 'detailed information' includes.

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

  Conciseness5/5

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

  A single concise sentence with no filler; key information is front-loaded and every word contributes.

  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 one-parameter get-by-ID tool, the description and schema are enough for selection and invocation. However, with no output schema and no annotations, the phrase 'detailed information' is vague about what the agent will receive, which leaves some uncertainty.

  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%: ticketId is described as 'The unique ticket ID'. The description's 'by its ID' reinforces this but adds no new semantic detail, so it meets the baseline.

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

  Purpose5/5

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

  States a specific verb ('get'), a resource ('ticket'), and the selection criterion ('by its ID'). This clearly distinguishes it from list-oriented siblings like superops_tickets_list.

  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 'by its ID' phrasing establishes when to use the tool: when the caller has a known ticket ID and wants details. It does not explicitly name alternatives or exclude list/search flows, but the context is sufficient for most agents.

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

• superops_clients_getA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. 'Get' implies a read-only operation, and 'detailed information' suggests the return is a rich client object. However, it does not disclose what happens for an invalid/unknown accountId, rate limits, or the exact fields returned.

  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 one short, front-loaded sentence with no filler. Every word adds clarity about the target and lookup key.

  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 single-required-parameter read tool with full schema coverage, the description is nearly complete: the agent can correctly call it with accountId. The only gap is that 'detailed information' does not enumerate the returned fields, and there is no output schema to fill that 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?

  The input schema covers 100% of the parameter with 'The unique account ID of the client,' so the baseline is 3. The description only restates the accountId parameter ('by their account ID') without adding format, source, or validation details.

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

  Purpose4/5

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

  The description uses a clear verb and resource: 'Get detailed information for a specific client.' The qualifier 'specific client' and 'by their account ID' help separate it from collection-style siblings like clients_list and clients_search, though it does not name those alternatives explicitly.

  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 states a definite context: use this when you have a client's account ID and need detailed information for that one client. It does not mention exclusion criteria or the list/search siblings, but the precondition is clear from the phrase 'by their account ID.'

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

• superops_assets_getA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. 'Get' clearly signals a read-only operation, and the enumerated content areas outline the response scope. It does not mention error conditions or permissions, but for a simple get-by-ID operation the description is sufficiently transparent.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler or redundant wording. Every part contributes meaning: the action, the target resource, and the expected detail areas.

  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 one-parameter read operation with no output schema, the description gives enough information to invoke the tool correctly and understand the general return content. It could be stronger by explicitly differentiating from sibling asset tools, but this is not critical given the simple interface and clear request.

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

  Parameters3/5

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

  The schema already documents the only parameter, assetId, with a clear description at 100% coverage. The description's 'specific asset' adds only a small amount of context about the resource identity, meeting the baseline for high schema coverage without needing 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 the specific verb 'Get' and identifies the resource as 'a specific asset,' making the tool's function clear. It also names expected content areas (hardware, OS, network details), which distinguishes it from sibling tools like superops_assets_list, superops_assets_software, and superops_assets_patches.

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

  Usage Guidelines3/5

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

  The description implies a single-asset lookup by asset ID, which is distinct from listing assets or retrieving software/patch details. However, it does not explicitly name alternatives or state when not to use this tool, so the usage 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.

• superops_navigateA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It explains that the tool returns tool names and descriptions, and it clarifies the non-gating nature ('All tools are callable at any time — this is a help/discovery aid, not a prerequisite'). This is meaningful behavioral context 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 sentences, each earning its place: the first states purpose and output, the second removes a common misconception about prerequisite behavior. It is front-loaded and contains no filler.

  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 single-parameter discovery tool with no output schema, the description covers purpose, return content, and a key behavioral caveat. It does not detail the exact response structure, but that is not necessary for an agent to invoke and interpret a help/discovery 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 coverage is 100% and the single domain parameter has detailed descriptions for each enum value, so the schema fully explains parameter semantics. The tool description itself adds no additional parameter meaning, which is appropriate given the rich schema.

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

  Purpose5/5

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

  The description states a specific verb ('Discover'), a resource ('available SuperOps.ai tools'), and a scope ('by domain'). It also explicitly states what is returned ('tool names and descriptions'), making it clearly distinct from the operational sibling tools like superops_tickets_get or superops_clients_list.

  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 positions this as a help/discovery aid, making its intended use clear. It also explicitly states it is not a prerequisite for other tools, which prevents an agent from incorrectly treating navigation as a required step. It does not explicitly list alternatives, but the siblings are operationally different.

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