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

No annotations are provided, so the description carries the behavioral burden. It states the operation is only an existence check, explains that account metadata is returned if present, and explicitly rules out returning secrets. This is strong for a read-only check, though it could also describe the absent-account case.

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 a useful parenthetical clarifying scope and safety. Every clause adds information, and there is no unnecessary 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?

For a simple existence check with full schema coverage, the description covers purpose, return behavior, and a key safety constraint. It lacks explicit behavior for when no account exists, but the tool name and 'existence check only' phrasing make the intent reasonably clear.

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 all parameters already documented, including agentId being required for LOCAL accounts. The description only restates the high-level 'customer + directory type' combination and adds no new parameter-level meaning, matching the baseline for 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 uses a specific verb and resource: 'Check whether a JIT account exists for a customer + directory type.' It clearly frames the tool as an existence check and distinguishes it from account listing or status siblings by adding '(existence check only).'

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 gives clear context for when to use the tool: to check existence for a customer and directory type. It also explicitly warns that this tool never returns a password or OTP code, which helps prevent misuse. It does not name alternative tools, so it stops short of full 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.

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 adds meaningful context by explicitly guaranteeing that passwords and OTP codes are never returned, and by stating that only metadata fields (id, username, type, status) are included. It does not explain pagination behavior, response shape, or ordering, but the security boundary is a strong and useful behavioral disclosure.

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, well-structured sentence that front-loads the core action and resource, then adds the security-relevant caveat and the optional filter. Every clause earns its place; there is no filler or repetition of obvious 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 list tool with 5 parameters, one required, and no output schema, the description explains what is returned (metadata fields) and what is never returned (passwords/OTP). It is missing explicit mention of pagination response behavior and how cursor/page/limit interact, but the input schema covers the parameters. Overall it is reasonably complete for a simple metadata list operation.

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, so the baseline is 3. The description adds no new parameter meaning beyond the schema: accountType is already described as a filter with the same enum values, and page/limit/cursor are already documented. The description's mention of the filter is helpful but redundant with 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 uses a specific verb ('List') with a clear resource ('account METADATA for a customer') and enumerates the returned fields (id, username, type, status). It also draws a clear line against sensitive data ('never returns passwords or OTP codes') and distinguishes itself from the sibling count tool by emphasizing listing metadata rather than counting.

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 the usage context: call this when you need account metadata for a customer, optionally filtered by account type. However, it does not explicitly state when to prefer this over cyberqp_get_customer_accounts_count or other account-related siblings, nor does it mention any conditions where this tool should not be used.

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 states the operation is a read (get counts) but doesn't disclose behavior like whether it returns zero-count entries, whether it requires specific permissions, or how it handles invalid customer IDs. For a simple read tool this is a moderate gap.

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

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

A single sentence that is direct and front-loaded with the action and resource. No wasted 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 read tool with one parameter and no output schema, the description is mostly adequate. However, it doesn't clarify the return shape (e.g., a map of account type to count) or whether counts include only active accounts. The lack of annotations and output schema means the description could have added a bit more 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?

Schema description coverage is 100% (the only parameter 'id' is described as 'Customer ID.'). The description adds no additional parameter semantics beyond what the schema already provides, so baseline 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 tool's function: getting counts of account types for a customer. It specifies the resource (customer) and the output (counts per account type). It doesn't explicitly differentiate from sibling cyberqp_get_customer_accounts, but the word 'counts' distinguishes it from the list-style sibling.

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: when you need aggregate counts rather than detailed account lists. It doesn't explicitly state when to use this over cyberqp_get_customer_accounts, but the sibling name and the word 'counts' provide reasonable implied 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?

With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond the schema by explicitly stating that the tool 'never returns a password or OTP code', which is valuable non-obvious behavior. It also indicates the kind of data returned, though it does not discuss pagination defaults or error behavior.

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 tightly constructed sentences with no filler. The first sentence states the core purpose and scope; the second adds a crucial limitation and redirects the agent toward the correct use case. Every sentence 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?

For a status-read tool with no output schema and no annotations, the description provides the essential context: what is returned, the customer-level scope, and a critical guarantee about credentials. It is slightly less complete because it does not mention the optional pagination/filtering behavior or differentiate from cyberqp_check_jit_account_exists, but the schema covers the parameter mechanics.

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 four parameters. The description adds little parameter-level meaning beyond reinforcing that customerId identifies the specific customer. The optional pagination and search parameters are adequately handled by the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('Get'), the resource ('JIT account status'), and the target scope ('for a specific customer'). It also lists what the status includes (existence, enabled/disabled state, metadata), distinguishing it from tenant-level siblings like cyberqp_get_tenant_jit_status.

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 when to use the tool: 'use this to check the current state of JIT accounts'. It also provides a clear when-not: 'not to retrieve credentials'. However, it does not name alternative tools for credential retrieval or for simple existence checks, so the guidance stops short of full sibling differentiation.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It adds a useful security-relevant trait: 'Never returns account passwords or OTP codes.' But it does not disclose pagination behavior, response shape, ordering, or explicitly state that this is a read-only 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 two sentences with no filler. The first sentence front-loads the resource and capabilities, and the second provides a concise, relevant safety caveat.

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 broad query tool with 9 optional parameters, no annotations, and no output schema. The description explains what the log contains but leaves important operational details unaddressed, such as pagination behavior (page/limit vs cursor), defaults, ordering, and what fields appear in the response. That is a significant gap for selecting and invoking the tool confidently.

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 every parameter already has a meaningful description. The tool description restates filter categories but does not add meaningful semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Get the tenant's event log', and adds concrete examples of the contents (self-serve resets, admin actions). It is unambiguous and distinct from sibling tools like cyberqp_get_customer_accounts or cyberqp_get_tenant_company_data.

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 gives a clear subject area and filterable dimensions, which implies when it would be used. However, it does not explicitly state when to prefer this tool over siblings, nor does it mention exclusions or alternatives. The connection to cyberqp_get_event_types only appears inside the schema, not in the description.

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 carries the full burden. The verb 'Get' implies a read-only operation and 'full set' suggests completeness, but the description does not disclose the return format, potential caching behavior, or whether the set is dynamic. The minimal risk profile lowers the severity, but the lack of any explicit behavioral detail keeps this at the minimum viable score.

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?

One single sentence conveys the resource, the action, and the relationship to another tool with no filler or repetition. The key usage detail is front-loaded and every word 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 zero-parameter tool with no output schema, the description covers the essential purpose and connects it to the consumer tool. The only minor gap is that it doesn't explicitly describe the return structure (e.g., array of strings), but the agent can confidently infer the output from 'full set of event-type values'.

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 schema provides no information to add to. The description adds practical semantics by explaining that the returned event-type values are intended to be used as the eventType filter in cyberqp_get_events, which is the most relevant meaning an agent needs.

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 states a specific verb and resource: 'Get the full set of event-type values'. It also defines the exact scope by tying these values to 'cyberqp_get_events' eventType filter', which clearly separates it from sibling tool cyberqp_get_events that fetches events themselves rather than metadata about event types.

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 indicates the context in which the tool is useful: when an agent needs valid values for the eventType filter of cyberqp_get_events. It does not explicitly list exclusions or alternatives, but for this zero-parameter metadata lookup no alternatives are necessary.

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 adds a valuable guarantee: 'Policy configuration only - never returns credential material,' which prevents an agent from expecting secrets. However, it doesn't mention permissions, reversibility, or error behavior. For a read-only getter this is adequate but not comprehensive.

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 with zero waste. The action and scope are front-loaded, and the credential-material warning adds meaningful value in the second sentence. It is efficient, though it could use structure to clarify alternatives; as conciseness, it's effective.

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 two-parameter getter with no output schema, the description covers the core purpose. However, the sibling confusion risk is significant: multiple JIT tools exist in the same family, and the description doesn't clarify how policy retrieval differs from status checks or existence checks. That gap leaves an agent without enough context to reliably choose this 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 coverage is 100%: both customerId and accountType have descriptions, and accountType has an enum limiting values. The description echoes 'customer + account type' but adds no extra syntax, format, or default details beyond the schema. Baseline 3 is appropriate when the schema documents both parameters well.

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 states a clear action and resource: 'Get the configured JIT policy (approval requirements, max session duration) for a customer + account type.' The parenthetical adds specificity about what the policy contains. It doesn't explicitly distinguish from siblings like cyberqp_get_customer_jit_status, but the resource detail is specific enough to convey the tool's 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?

There is no guidance on when to use this tool versus alternatives. The sibling list includes several JIT-related tools (cyberqp_get_customer_jit_status, cyberqp_get_tenant_jit_status, cyberqp_check_jit_account_exists), but the description never mentions them or states when to prefer this one. An agent could easily confuse this with a status or existence check.

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 the behavioral burden itself. 'Get' clearly signals a read-only operation, and 'authenticated tenant's own' discloses that the operation is scoped by the caller's authentication context. For a simple zero-parameter read, this is adequate and unlikely to mislead.

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?

A single sentence that is front-loaded with the verb and resource, followed by a brief parenthetical of the returned fields. Every word earns its place; there is no repetition 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?

For a simple, zero-parameter getter with no annotations and no output schema, the description is complete: it states the resource, the scoping identity, and the returned fields. An agent has everything needed to invoke it 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?

The tool has zero parameters, so the schema provides no semantic content and the baseline is 4. The description adds value by listing the profile fields that the call returns, even though it does not need to explain any parameter behavior.

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 starts with a specific verb ('Get') and names a clearly bounded resource: the authenticated tenant's own company profile. Listing the fields (name, address, timezone, contact phone) removes ambiguity, and 'own' distinguishes this tool from sibling customer/account/event tools.

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 'authenticated tenant's own' gives a clear scope, implying this is the tool for the current tenant's profile rather than customer or account data. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations, the description carries the transparency burden, and it adds a meaningful guarantee: the response never contains a password or OTP code. It also discloses the kinds of status data returned. It does not discuss permissions or error behavior, but for a read-oriented status tool the key output-safety constraint is clearly stated.

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 with no filler. The first sentence front-loads the resource, scope, and return contents, while the second adds a concise and important safety caveat about passwords and OTP codes.

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 optional-parameter read tool with no output schema, the description provides the key information an agent needs: what status data is returned, the tenant-wide scope, and what will never be returned. It is slightly light on exact response shape and pagination behavior, but the complete parameter schema and low complexity prevent 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?

All three parameters (page, limit, searchText) are already fully described in the input schema, so schema description coverage is 100%. The description itself adds no parameter-specific meaning, which is appropriate given the baseline for complete 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 states a specific verb ('Get'), a precise resource ('JIT account status'), and the scope ('across the entire tenant'), while also listing the returned dimensions: existence, enabled/disabled state, and metadata. This clearly distinguishes it from the customer-scoped sibling cyberqp_get_customer_jit_status.

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 'across the entire tenant' implies this is the tenant-wide tool, and the reader can infer the difference from cyberqp_get_customer_jit_status. However, the description never explicitly names alternatives or states when to prefer this over a simpler existence check such as cyberqp_check_jit_account_exists.

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?

Annotations are absent, so the description carries the behavioral disclosure burden. It makes the read-only nature explicit with 'List' and adds meaningful boundaries: metadata only, and never returns account passwords or OTP codes. It does not mention pagination behavior, but the schema covers pagination parameters.

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 concise sentences with no wasted words. The core action and scope are front-loaded, followed by a useful sensitive-data exclusion. Every sentence 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?

For a low-complexity list tool with 100% schema coverage, the description is largely complete: it identifies scope, filters, and return content boundaries. Minor gaps include no explicit mention of pagination output format, but the page/limit parameters in the schema mitigate this.

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 reinforces that 'name' and 'directoryType' are filters but adds little beyond the schema. Pagination parameters are fully documented in the schema and need no additional explanation.

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?

States a specific verb and resource ('List customers visible to the authenticated CyberQP technician account') and clarifies the scope via metadata-only return. The description distinguishes this tool from account-focused siblings by emphasizing customer-level metadata and exclusion of passwords/OTP codes.

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?

Provides clear context: use for listing customers visible to the authenticated account, with filtering by directory type and name. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent can infer when to select this tool over account/event/policy siblings.

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