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. The verb 'Get' clearly implies a read-only operation, and the description specifies the types of data returned (hardware, OS, network). However, it does not disclose potential error conditions, permission requirements, or response structure, leaving some behavioral gaps.

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

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

The description is a single sentence that front-loads the core purpose and key details. It is concise, free of redundancy, and every segment ('detailed information', 'specific asset', 'hardware, OS, and network details') adds value.

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

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

For a simple get-by-id tool with one required parameter and no output schema, the description sufficiently conveys the tool's function and output scope. The mention of hardware, OS, and network details gives the agent a clear idea of what the response will contain. However, it does not explicitly mention that the response is a single asset object or handle error cases, but this is minor given the tool's simplicity.

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

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

The input schema fully documents the sole parameter 'assetId' with a clear description, so schema coverage is 100%. The tool description does not add extra parameter-level information, but the schema already provides sufficient meaning, matching the baseline for high schema coverage.

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

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

The description clearly identifies the tool as retrieving detailed information for a single asset, and explicitly lists hardware, OS, and network details as the scope. This distinguishes it from sibling tools like assets_list (list), assets_software, and assets_patches by content focus. The verb 'Get' and resource 'asset' are specific and unambiguous.

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

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

The usage context is implied by the description: use this tool when you need detailed information about a specific asset. However, no explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The contrast with sibling asset tools is left to the agent to infer.

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

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

The description states the primary behavior (listing) but omits important behavioral details like pagination (cursor/max parameters) and response structure. Since no annotations are provided, this creates a gap in understanding how the tool behaves beyond a simple list.

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

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

Two sentences, front-loaded with the core action. No redundant words or filler.

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

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

The description covers the core purpose and filter options, but given the lack of an output schema, it doesn't explain what fields the returned assets contain. Pagination behavior is only discoverable from the schema parameters, not the description, making it somewhat incomplete.

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

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

The input schema documents all five parameters with descriptions, including enums for status and platform. The description repeats the filter options (status, platform, client) but adds no extra semantics beyond the schema, so it relies fully on the schema.

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

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

The description clearly states the tool lists assets (endpoints) in SuperOps.ai RMM. It distinguishes from siblings like superops_assets_get (single asset) and superops_assets_software (software listing) by using the verb 'List' and mentions filter options.

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

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

The description implies usage for retrieving asset lists with optional filters, which is distinct from asset-specific siblings. It doesn't explicitly name alternatives or exclusion criteria, but the 'Can filter by' phrasing provides clear context for when this tool is appropriate.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It correctly indicates this is a read operation ('Get') but does not describe the return format, pagination, or any special behavior around 'pending patches' (e.g., whether it includes installed/failed statuses by default). The description is not misleading but adds only minimal context beyond the operation type.

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

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

The description is a single, front-loaded sentence with no fluff. Every word contributes to the tool's purpose, and it is appropriately sized for the tool's simplicity.

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

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

For a relatively simple filtered-listing tool, the description combined with a fully documented schema is sufficient. The tool has no output schema, but the description's mention of 'patch status and pending patches' implies the return type without needing to spell out every field. It could briefly note that it returns a list of patches, but the simplicity keeps this from being a major gap.

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

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

The schema provides 100% coverage with descriptions for all three parameters (assetId, status, severity), so the schema already handles parameter meaning. The description adds no extra context about how these parameters interact with 'patch status' beyond what is already in the schema, which is expected given the baseline of 3.

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

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

The description clearly states a specific verb ('Get') and resource ('patch status and pending patches') scoped to a specific asset. This clearly distinguishes it from sibling tools like superops_assets_get (general asset details) and superops_assets_software (software inventory).

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

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

The intended use case is implicitly clear: to retrieve patch information for a given asset. However, it does not explicitly mention when to prefer this over alternatives like superops_assets_software or exclude other use cases, so it lacks explicit when-to-use/not-to-use guidance.

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

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. The verb 'Get' implies a read-only operation, but the description does not explicitly state that, nor does it mention pagination limits, sorting behavior, or any side effects. Given the lack of annotations, this is insufficient.

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

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

The description is a single, clear sentence that is appropriately front-loaded with the main purpose. Every word earns its place, and there is no unnecessary fluff.

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

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

Given the tool's low complexity (3 params, no output schema), the description sufficiently conveys the purpose. However, because there is no output schema, it would be beneficial to clarify what 'software inventory' includes (e.g., list of software names/versions), but overall it is complete enough for a simple retrieval tool.

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

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 minimal meaning beyond the schema—it reinforces that assetId identifies the specific asset, but does not clarify max or search semantics beyond what the schema already states. No additional parameter context is provided.

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

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

The description uses a specific verb ('Get') and resource ('software inventory') scoped to a specific asset, clearly distinguishing it from sibling tools like superops_assets_list (lists assets) and superops_assets_get (gets asset details). No ambiguity exists.

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

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

The description indicates a clear context—this tool is for retrieving software inventory for a specific asset, implying the user already has an assetId. However, it does not explicitly state when not to use it or mention alternatives (e.g., use assets_list to find assetId), so it misses a perfect score.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'Get detailed information', which essentially restates the tool's purpose. It does not disclose error handling, idempotency, read-only nature, or any side effects, leaving the agent without deeper behavioral context.

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

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

The description is a single, focused sentence that front-loads the action and resource. It contains no filler or redundant phrasing, efficiently conveying the tool's purpose in just a few words.

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

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

This is a simple, single-parameter tool. The description mentions 'detailed information', which implies the return type sufficiently in the absence of an output schema. It does not need to elaborate on complex behaviors, and the context signals indicate low complexity, so the description is reasonably complete for the task.

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

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

The schema already provides 100% coverage for the single parameter, describing accountId as 'The unique account ID of the client'. The description's phrase 'by their account ID' adds no extra semantic beyond what the schema states. Therefore, the baseline score for good schema coverage applies.

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

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

The description uses a specific verb 'Get' and resource 'client' with the qualifier 'detailed information' and specifies the key 'account ID'. This clearly distinguishes it from sibling tools like list and search, which focus on collections or broader queries.

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

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

The description clearly implies use when you have a specific account ID and need detailed client data, which distinguishes it from list and search operations. However, it does not explicitly state when not to use it or name alternatives, so it falls short of full explicit guidance.

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

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. It states 'List' which implies a read-only operation, but does not explicitly confirm non-destructive behavior, authentication requirements, or what happens with no results. The filter and pagination mentions are already evident from the schema, adding no extra transparency.

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

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

The description is two sentences, front-loaded with the primary action, and contains no redundant or wasteful phrasing. It conveys the core functionality efficiently.

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

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

With no output schema, the description does not explain what fields are returned or the structure of the response. It also omits any context about pagination limits or default behavior beyond parameter names. The tool is simple, but the description is too sparse to be fully complete for an agent.

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

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 with enums and descriptions. The description adds no semantic nuance beyond restating that filtering and pagination are possible, which does not exceed the schema's value.

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

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

The description opens with 'List clients (accounts) in SuperOps.ai', which is a specific verb and resource. It clearly distinguishes from sibling tools like 'clients_get' (single client) and 'clients_search' (search), establishing a unique listing purpose.

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

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

The description implies usage for listing and filtering, but does not explicitly state when to prefer this over 'clients_search' or 'clients_get'. No exclusions or alternatives are mentioned, so 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.

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 only states that it returns 'basic information,' which is vague, and does not mention limitations, case sensitivity, partial matching, or other behaviors.

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

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

The description is two short sentences, front-loaded with the action and criteria, with no unnecessary words. It is appropriately sized.

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

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

With no annotations and no output schema, the description is insufficiently complete. It doesn't describe the return format, pagination, or any caveats, and 'basic information' is left undefined.

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

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

Schema coverage is 100% with both parameters described. The description's 'by name or email domain' adds nothing beyond the query parameter's description, and no extra semantics are provided for the max parameter.

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

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

The description uses a specific verb ('Search') and resource ('clients') with explicit criteria ('by name or email domain'), clearly distinguishing it from sibling tools like list and get, which have different purposes.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention when to prefer search over list or get, nor any exclusions or prerequisites.

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

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

No annotations exist, so the description must carry the full burden. It only states it runs a mutation and is for write operations, but does not disclose potential side effects, authentication needs, rate limits, or error behaviors. This is a significant gap for a tool that can execute arbitrary write operations.

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

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

Two sentences, direct and to the point. No extraneous information. Every word serves a purpose.

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

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

Given the tool's complexity as a raw GraphQL mutation runner, the description is minimal. It covers purpose and use case but lacks details on return format, error handling, or validation. Considering the param richness (2 params, nested objects) and no output schema, additional guidance would be beneficial.

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

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 both parameters. The description adds no new meaning beyond 'Run a custom GraphQL mutation', which is redundant. It does not explain expected format for the mutation string or how variables map, so it meets the baseline but does not enhance understanding.

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

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

Description clearly states it runs a custom GraphQL mutation for write operations. It distinguishes from the sibling superops_custom_query (reads) and other specific write tools, indicating it is for advanced cases not covered.

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

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

Description says 'For advanced write operations not covered by standard tools,' providing context for when to use it. It implicitly contrasts with specific write tools and the custom query tool, though it doesn't explicitly list alternatives or exclusions.

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

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 does not mention potential side effects, required permissions, or that this is intended strictly as a read-only operation. It also lacks information about error handling or response format, leaving the agent with insufficient awareness of risks.

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

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

The description consists of two concise sentences that front-load the primary action ('Run a custom GraphQL query') and add the context of advanced use cases. Every word earns its place, with no redundancy or fluff.

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

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

This tool has no output schema and no annotations, yet the description does not explain what the response looks like, how errors are handled, or any limitations of the custom query. For a flexible and potentially powerful tool, this level of context is inadequate for an agent to invoke it correctly and interpret results.

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

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

The input schema already provides clear descriptions for both parameters ('query' as a GraphQL query string and 'variables' as variables to pass), giving 100% schema coverage. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool runs a custom GraphQL query against the SuperOps.ai API, with a specific verb and resource. It also distinguishes itself from standard tools by noting it covers advanced use cases, and from the sibling mutation tool by being a 'query' rather than a mutation.

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

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' gives general context for when to use the tool, implying it should be used only when standard tools are insufficient. However, it does not explicitly name alternatives or state when not to use it, such as preferring standard tools for common operations or using the custom mutation tool for writes.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does state the output ('Returns tool names and descriptions') and positions the tool as a 'help/discovery aid,' which implies no side effects. However, it does not explicitly state that the tool is read-only or has no mutating effects, which is important when no annotations are present. This is adequate but not rich.

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

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

The description is two concise sentences that front-load the core purpose ('Discover available SuperOps.ai tools by domain') followed by a clarifier about the tool's non-prerequisite nature. Every word earns its place; no redundant or vague content.

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

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

For a simple tool with one parameter, the description fully covers what the tool does, what it returns, and its optional status. With no output schema, the description appropriately states the return format ('tool names and descriptions'). It is complete for the tool's complexity, though it could specify the exact structure of the returned data (e.g., list vs. object), but this is minor.

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

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

Schema description coverage is 100%: the single 'domain' parameter includes a detailed enum with descriptions for each option (clients, tickets, assets, technicians, custom). The tool description merely says 'by domain,' which adds no additional meaning beyond the schema. Baseline for high coverage is 3.

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

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

The description clearly states the tool's function: 'Discover available SuperOps.ai tools by domain' and specifies the return value ('Returns tool names and descriptions for the selected domain'). It uses a specific verb ('Discover') and resource ('SuperOps.ai tools'), and distinguishes itself from siblings by positioning as a discovery aid rather than an operational tool.

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

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

The description explicitly states the tool is a 'help/discovery aid' and clarifies that 'All tools are callable at any time — this is a help/discovery aid, not a prerequisite.' This effectively tells the agent when to use it (to discover tools) and when not to (it is not a required precursor to other calls). It does not name alternative tools, but given its discovery purpose, the context is clear.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure, but it merely states 'Show credentials status and available domains' without indicating read-only behavior, response format, or any side effects. The minimal text adds little beyond what the tool name implies.

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

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

The description is a single, concise sentence that immediately states the tool's function without any filler or extraneous detail. Every word contributes to understanding the tool's purpose.

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

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

The tool is simple with no parameters, but the description only names the two outputs without specifying response format, potential errors, or prerequisite conditions. Since no output schema exists, the description should carry more weight, and a slightly richer explanation would improve completeness.

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

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

The tool has zero parameters, so the input schema is empty. The description does not need to elaborate on parameters, and the baseline for zero-param tools is a 4. No parameter-related ambiguity exists.

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

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

The description uses the specific verb 'Show' and clearly identifies the resource: 'credentials status and available domains.' It stands out from sibling tools, none of which focus on status or domain information, 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.

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

The description provides no guidance on when to use this tool versus alternatives, such as using superops_test_connection for validating connectivity. It neither states typical usage context nor excludes alternative tools, leaving the agent without decision support.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation ('Get') but does not disclose error behavior, permissions, rate limits, or the exact structure of the returned information. This is a minimal disclosure for a non-trivial API operation.

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

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it immediately clear what the tool does.

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

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

For a simple get-by-ID tool with one parameter and no output schema, the description is adequate. It clearly communicates the core purpose. However, 'detailed information' is vague without annotations or an output schema, leaving some ambiguity about return fields.

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

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

The input schema already provides a 100% description coverage for technicianId ('The unique technician ID'), so the description adds no extra meaning. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the action ('Get') and the resource ('detailed information for a specific technician by their ID'), which differentiates it from sibling tools like list or groups. The phrasing is specific and unambiguous.

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

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

The phrase 'by their ID' implies that this tool should be used when a technician ID is available, but it does not explicitly mention when not to use it or compare it to alternatives like superops_technicians_list. Usage 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.

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 states 'List', which implies a read-only operation, but it does not disclose return format, pagination, authorization requirements, or any side effects. It adds some behavioral context but is not rich enough given the lack of structured metadata.

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

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

The description is a single sentence that is concise, front-loaded with the verb, and contains no filler. It effectively communicates the core purpose without wasting words.

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

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 minimally sufficient: it names the resource and action. However, it does not describe the shape of the returned data or differentiate from similar list tools, leaving some gaps for the agent relying solely on this description.

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

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

The input schema has 100% description coverage for the only parameter 'max', including its default value. The description adds no parameter-specific meaning, but since the schema fully documents it, the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'technician groups/teams in SuperOps.ai', making the tool's purpose obvious. However, it does not explicitly distinguish itself from sibling tools like 'superops_technicians_list', which lists individual technicians, so it lacks sibling differentiation that would make it a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as 'superops_technicians_list' or other list tools. The context is implied by the resource name, but no explicit exclusions or alternatives are provided, so the agent has to infer usage independently.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and filter capability, omitting important behaviors like pagination (though 'cursor' is in the schema) and the default 'activeOnly=true' behavior. This could lead an agent to assume unfiltered results when the default is active-only.

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

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

The description is a single, concise sentence with no filler words. It front-loads the core purpose and adds the filter capability in a second short sentence. Every word earns its place.

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

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

The description covers the core purpose but is incomplete given the absence of an output schema and annotations. It does not mention pagination behavior, default values, or return format. While the schema documents parameters, the description fails to provide context about the results (e.g., that it returns a list of technician objects) and how to handle pagination.

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

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 semantics beyond what the schema already provides; it merely paraphrases the activeOnly and teamId filters. It does not clarify parameter formats or relationships, but this is acceptable given full schema coverage.

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

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

The description clearly states the tool's function: 'List technicians (agents) in SuperOps.ai.' It uses a specific verb ('List') and resource ('technicians'), and distinguishes from sibling tools like superops_technicians_get (single fetch) and superops_technicians_groups (groups). The mention of filtering by active status or team further clarifies scope.

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

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

The description implies usage for listing technicians but does not explicitly state when to use it over alternatives. It lacks 'when to use' or 'when not to use' guidance, and does not name sibling tools. The filter note hints at use cases but does not exclude scenarios where other tools are more appropriate.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It states the action (test connection) and mentions credentials, but does not disclose what happens on success/failure, whether it is a read-only operation, makes network calls, or any side effects. 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.

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

The description is a single sentence, highly concise, and front-loaded with the purpose. It contains no redundant words and is easy to parse.

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

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

For a simple tool with no output schema, the description is adequate but incomplete. It explains the function and credential usage but does not describe the expected return value or success/failure behavior, which would be useful for an agent to interpret the result.

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

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

The tool has zero parameters, and the description adds value by explaining that credentials are already configured, which justifies the absence of parameters. This helps the agent understand why no arguments are needed, exceeding the baseline for 0-parameter tools.

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

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

The description clearly states the tool's function: to test the connection to the SuperOps.ai API. The verb 'Test' and resource 'connection' are specific, and the tool distinction from siblings is clear (others perform CRUD or navigation, this one verifies connectivity).

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

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

The description implies usage context—test the connection when you want to verify API access with configured credentials—but it does not explicitly mention when to use this over alternatives like 'superops_status' nor provide exclusion criteria. It 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.

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

With no annotations provided, the description must bear the full burden of behavioral disclosure. It only states the internal/public visibility distinction, which is already present in the schema's isPublic parameter description. It lacks details about side effects (e.g., client notifications, permissions, ticket state constraints) or confirmation that the note is appended to existing ticket history.

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

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

The description is concise, consisting of two sentences that front-load the verb and object, and explain the key public/internal option without unnecessary detail. Every word earns its place.

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

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

Given the tool's simplicity—3 parameters, no output schema, no annotations—the description covers the essential operation. However, it omits usage context (e.g., selecting between this and log_time) and any operational implications of adding a public note. It is minimally sufficient but leaves gaps for robust agent decision-making.

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

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

Schema description coverage is 100% for all three parameters, so the schema fully documents ticketId, content, and isPublic. The description's 'internal or public (visible to client)' reiterates the isPublic description without adding new semantic information, 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.

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 resource ('a ticket'), conveying a specific purpose. It distinguishes itself from sibling tools like tickets_update or tickets_log_time by naming the unique operation, though it doesn't explicitly call out those alternatives.

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

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 sibling tools such as superops_tickets_log_time or superops_tickets_update. It does not specify scenarios for adding internal vs public notes or any prerequisites, leaving the agent to infer usage from the operation name.

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

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 only states that it creates a ticket, which implies a mutating operation, but it does not disclose permissions, side effects, or resulting behavior beyond creation. This is a minimal disclosure with significant gaps.

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

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

The description is a single declarative sentence with no wasted words, clearly front-loading the core function. It is appropriately concise for a simple create operation, though it could have included more context without becoming verbose.

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

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

Given that the tool has 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return value, error behavior, or any additional context that would help an agent understand the full scope of the operation. The schema covers parameters, but the description lacks operational context.

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

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

The input schema provides descriptions for all 7 parameters (100% coverage), so the description does not need to add parameter details. The description itself adds no additional meaning to parameters, but the baseline for high schema coverage is 3.

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

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

The description uses the specific verb 'create' and identifies the resource as a 'new ticket' in SuperOps.ai, making the primary function unambiguous. However, it does not explicitly differentiate from sibling tools like tickets_add_note, which could also involve creation, though the 'new ticket' phrasing provides sufficient distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as superops_tickets_update or superops_tickets_add_note. There is no mention of prerequisites, recommended scenarios, or exclusions. This leaves the agent without decision support.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get detailed information,' implying a read-only operation, but does not disclose any edge cases, error behavior, required permissions, or what exactly constitutes 'detailed information.' This is sparse for a tool with no annotation safety net.

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

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

The description is a single, focused sentence that communicates purpose without filler. It is appropriately sized for the tool's simplicity and front-loads the key information.

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

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 with no output schema or annotations, the description adequately covers what the tool does and the parameter it requires. It could mention return format or error handling, but the simplicity of the tool makes this minor gap acceptable. The description is complete enough for an agent to use the tool correctly.

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

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

Schema description coverage is 100% and the only parameter 'ticketId' is fully described as 'The unique ticket ID.' The tool description adds no additional meaning beyond 'by its ID,' so it does not improve on the schema. Baseline 3 is appropriate since the schema already documents the parameter completely.

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

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

The description clearly states the action ('Get'), the resource ('detailed information for a specific ticket'), and the scope ('by its ID'). This distinguishes it from sibling tools like superops_tickets_list and superops_tickets_create, which handle multiple tickets or mutations.

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

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

The purpose implies this tool should be used when a single ticket ID is known and full details are needed, but the description does not explicitly mention alternatives or exclusions (e.g., 'Use superops_tickets_list for multiple tickets'). It provides implied usage guidance but lacks clear differentiation from siblings.

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

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

No annotations are provided, so the description carries full burden. It only lists filter options and does not disclose pagination behavior, return format, or any side effects. This is a significant gap for a list tool.

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

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

The description is two short sentences, front-loaded with the core purpose. Every word earns its place with no redundancy.

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

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

With no output schema and no annotations, the description should explain pagination, result structure, and all available filters (including 'unassigned'). It only mentions a subset of filters and lacks return-value details, making it incomplete for agent decision-making.

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

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

Schema coverage is 100%, so the description adds minimal value beyond the schema. It summarizes the main filter dimensions but does not explain each parameter's meaning beyond what the schema already provides.

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

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

The description clearly states 'List tickets in SuperOps.ai', with a specific verb and resource. It also mentions key filter dimensions, distinguishing it from sibling tools like get, create, update, and add_note.

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

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

The tool name and description imply a list/query operation, making it clear when to use it versus get (single ticket) or create/update. However, it does not explicitly state when not to use it or mention alternatives.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only says 'Log time spent' which implies a write operation, but fails to mention side effects (e.g., creating a time entry), permissions required, or whether it modifies existing time entries. Minimal transparency.

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

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

The description is a single, clear sentence that is front-loaded and easy to parse. It has no fluff or redundant text, making it appropriately concise for the tool's simplicity. However, it misses opportunities to add context without becoming verbose.

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

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

Given the absence of annotations and output schema, the description is too sparse to be fully useful. It doesn't explain return values, prerequisites (e.g., ticket existence), or behavior on errors. For a mutation tool with multiple parameters, more context is needed to guide correct invocation.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description adds no additional semantic value beyond the schema, meeting the baseline of 3. No param details are repeated or enhanced.

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

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

The description 'Log time spent on a ticket.' uses a specific verb ('log') and resource ('time spent on a ticket'), clearly distinguishing it from sibling tools like superops_tickets_add_note or superops_tickets_update. It states exactly what the tool does without ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions, prerequisites, or when to prefer other ticket-related tools. The intended use is implied but not explicitly stated.

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

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

No annotations are provided, so the description carries the transparency burden. It states 'update' which implies mutation, but does not disclose side effects, reversibility, authentication needs, or partial update behavior. Could provide more behavioral context.

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

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

Single sentence, front-loaded with the action, no redundant words. Every part earns its place.

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

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

No output schema exists, so the description could clarify return values (e.g., updated ticket object). For a mutation tool of moderate complexity, it is functional but not fully complete.

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

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

Schema coverage is 100%, but the description adds value by grouping parameters into meaningful categories (status, priority, assignment, resolution) that summarize the schema. This helps agents understand high-level capabilities beyond the raw schema fields.

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

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

The description uses a specific verb ('Update') and resource ('existing ticket'), and lists the updatable fields (status, priority, assignment, resolution). It clearly distinguishes from sibling tools like create, add_note, log_time by focusing on modification of existing tickets.

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

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

The description implies usage when a ticket needs updating, but lacks explicit guidance on when not to use (e.g., use add_note for notes or log_time for time entries). No alternatives or prerequisites are mentioned.

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