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

With no annotations provided, the description fully discloses behavior: it makes exactly one minimal audit-log request, reports pass/fail with a plain explanation plus remediation steps, and never echoes secret material (the access key shows only the last 4 characters). This goes well beyond a bare operation statement and gives the agent confidence about side effects and output safety.

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 purpose is front-loaded in the first sentence, and the remaining sentences carry useful information about behavior, triggering, and secret handling. The 'Returns' section slightly overlaps with the provided output schema, but it only lists the key dictionary fields and is not padded. Overall it is tightly written for the information it needs to convey.

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 tool with no parameters and a full output schema, the description covers everything an agent needs: what is checked, when to run it, what side effects occur (one request, no secret disclosure), and what the result looks like. There are no missing pieces that would cause an agent to misuses the 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and the empty input schema leaves nothing ambiguous; the description instead focuses on the output, which is appropriate here.

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 a specific verb and resource: 'Verify the configured API keys can actually read the audit log,' which clearly states what the tool does. It also distinguishes itself from the sibling data-retrieval tools (list_activity_events, summarize_activity, etc.) by positioning this as a diagnostic preflight check rather than an analytics operation.

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 an explicit trigger condition: 'Run this first when another tool returns an authentication or permission error.' This is clear contextual guidance, but it does not mention when not to use it or name alternative tools—though no sibling performs the same diagnostic role, so exclusions are not 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, the description carries full burden and covers side effects (baseline refresh from local SQLite when stale), idempotence (analyzed window not folded into baseline), and output guarantees (evidence, reasoning, severity ordering). This exceeds what schema alone could convey.

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 definition is dense but every sentence adds necessary operational detail; purpose is front-loaded, checks are grouped, and Args/Returns are clearly structured. No filler or repetition.

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 tool with no annotations and moderate input complexity, it explains inputs, output shape, baseline mechanics, staleness handling, and idempotence. An agent has enough to select and call it correctly without further discovery.

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 0%, but the Args section documents all three parameters with semantic meaning: ISO-8601 window bounds and baseline history days. This fully compensates for the absent schema descriptions.

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?

Opens with a specific verb-resource pair ('Compare a window against each actor's stored baseline') and an enumerated list of anomaly checks that distinguishes this from sibling event-listing/summary tools. The resource and behavior are unmistakable.

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 investigation scenario is clear: detect baseline deviations in a date window using prior history. It does not explicitly name alternatives or when-not-to-use, but the detailed scope leaves little ambiguity about when this tool applies.

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 available, the description carries the behavioral burden and does so well. It discloses that data combines a fresh audit-log fetch with persisted local state, explains best-effort role resolution, and notes when role data is omitted. This is substantive behavioral context beyond a simple summary.

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 well structured with a one-sentence summary, a clear behavioral explanation, and separate Args/Returns sections. It is appropriately detailed for the tool's complexity without padding, and each sentence adds useful 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?

Given the tool's moderate complexity, zero annotation coverage, and 0% schema description coverage, the description supplies everything needed: what the profile contains, how data is combined, parameter semantics, and return structure. The output schema also exists, but the description goes beyond it by explaining the lifetime/recent_activity distinction.

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 0%, so the description fully compensates. actor_id is explained as the actor UUID as seen in actor.id, and lookback_days is defined as how far back to fetch fresh events. Both parameters receive meaningful semantic detail not present in 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 opens with 'Full historical view of one actor: roles, actions, access types, IPs', which names a specific resource and scope. It clearly distinguishes this from siblings like list_activity_events or summarize_activity by emphasizing the per-actor, history-combining nature.

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?

Usage context is implied rather than explicit: the tool is for obtaining a comprehensive actor profile that merges fresh data with persisted state. It does not explicitly state when to prefer this over sibling tools or provide exclusions, so an agent must infer the right selection.

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 explaining behavior, and it does so well: it discloses the classification method (audit access/auth-method with user-agent fallback), that results are pre-aggregated, and what per-actor fields are returned. It does not mention permissions or rate limits, but 'Report' and 'Returns' strongly imply a safe, 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 front-loaded with a clear one-sentence summary, followed by a concise classification note and clearly labeled Args and Returns sections. Every sentence adds useful information and there is no filler or redundant restating of the tool name.

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 report tool with three optional parameters and an output schema, the description covers the core behavior, defaults, and return shape sufficiently. Minor gaps remain, such as date-boundary inclusivity and explicit guidance about which sibling tools to use instead, but nothing essential is missing for invoking 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?

Schema description coverage is 0%, so the description must compensate, and it does. All three parameters are explained with semantics beyond the bare schema: actor_id is an optional UUID, date_from defaults to 30 days ago, and date_to defaults to now, with ISO-8601 format specified.

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: 'Report API-key-driven activity per actor' and explicitly excludes UI/session activity. It further clarifies the output (per-actor action breakdown, distinct source IPs, first/last seen timestamps), which distinguishes this tool from the sibling activity tools even without naming them.

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 is clear: this tool is for API-key-driven activity reporting, and the description explicitly notes that UI/session activity is excluded. It also explains the effect of omitting actor_id, but it does not explicitly name alternative sibling tools for when 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?

With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It discloses internal pagination with a 20-page/100k-event cap, resume behavior via next_token, normalization of events, access-type tagging, and redaction of credential-looking fields. This is far beyond what a minimal description would provide.

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 information-dense yet well-structured: purpose first, then behavioral caveats, then parameter breakdown, then return structure. Every sentence adds value, and the length is justified by the number of parameters and the pagination/redaction behaviors that need explanation.

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 6-parameter tool with no annotations, the description covers use case, filtering, pagination limits, resume semantics, data normalization, redaction, and return shape. The optional filters and cap behavior are fully explained, leaving no critical gap for an agent attempting to invoke 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 0%, but the description compensates completely by explaining every parameter: date format and inclusivity, optional filters with their eq semantics, the exact action example, limit range, and the opaque next_token cursor. An agent can correctly populate all six arguments without needing extra documentation.

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 begins with a specific verb ('List') and resource ('Tenable audit-log events'), and states the scope ('for a date range') with optional filters. This clearly distinguishes it from sibling tools like summarize_activity and detect_anomalies, so an agent knows exactly what this tool retrieves.

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 makes the core use case clear: retrieve audit-log events within a date range, optionally filtered by actor or action. It does not explicitly name sibling alternatives or provide when-not-to-use guidance, but the event-listing purpose is unambiguous and the filter details help an agent choose appropriately.

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 discloses that counts are pre-computed in Python, that date boundaries are inclusive, and it exposes the exact return structure with summary and pagination blocks. It does not mention permissions, error behavior, or timezone assumptions, but for a read-only aggregation these are not critical.

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 well-organized with a concise purpose line, a usage warning, and clear Args/Returns sections. There is slight redundancy where the prose mention of 'Returns event counts...' is later repeated as a structured returns block, but the text is otherwise efficient and front-loaded.

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 two-parameter aggregation tool with an output schema present, the description covers purpose, parameter semantics, and return keys sufficiently. It lacks an explicit when-to-use-versus-siblings statement and has no annotation safety profile, but the core invocation details are complete enough for an agent to call 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 input schema provides only bare string properties with 0% coverage. The description compensates fully by defining date_from as 'Start of the window, ISO-8601. Inclusive' and date_to as 'End of the window, ISO-8601. Inclusive', adding format, semantic role, and boundary inclusivity to both parameters.

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: 'Summarise all audit-log activity in a window', and enumerates the output dimensions (by actor, action, CRUD, access type, failure and anonymous rates). This clearly frames the tool as an aggregation over raw events and distinguishes it from siblings like list_activity_events or get_actor_profile.

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 a strong usage directive: 'Use these numbers directly; do not re-derive them from raw events.' This tells the agent to rely on pre-computed counts rather than computing from raw event lists, which is clear contextual guidance. It does not explicitly name alternative tools or exclusion conditions, but the implied comparison to raw event access is present.

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