All Quiet MCP by usefulapi

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

Annotations only carry destructiveHint=true with no explanation; the description supplies the reason (live-account creation that may trigger paging/alerting), plus the non-obvious behavioral trait that status and severity are free-form strings server-side validated against account configuration. It does not cover error behavior, idempotency, or permissions, so it is not a 5.

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?

Purpose and the live-account warning are front-loaded, and the closing endpoint reference is compact. It is slightly redundant, repeating the status/severity free-form explanation that the schema already carries, but overall it earns its length.

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 mutation tool with no output schema and minimal annotations, the description conveys the essential context: live-account side effects, the validation caveat on the two free-form required fields, and the underlying endpoint. Notably absent is any mention of what the response returns or failure modes, but the core calling information is present.

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 eight parameters thoroughly. The description largely restates the status/severity semantics already present in the schema, adding no format or syntax beyond it; the baseline 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 states a specific verb and resource ('Creates a new incident') and adds critical scope detail ('on the LIVE account'), immediately distinguishing it from the read-oriented siblings like allquiet_get_incident and allquiet_list_incidents. The endpoint reference (POST /v1/incident) further pins down the 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?

It gives clear context for use — this targets the live account and may trigger alerting/paging — which is exactly the condition an agent needs to weigh before calling it. It also advises confirming valid status/severity values before calling. It stops short of naming sibling alternatives (e.g. update_incident for modifying an existing incident), so it is not 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?

The annotation surface is thin (destructiveHint=true only), and the description corroborates the mutation and adds account scoping plus a warning that `type` is free-form and account-specific. However, it does not disclose permission requirements, whether the override expires automatically or must be removed, or how it interacts with existing overrides — meaningful gaps for a state-changing 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?

Front-loaded with the action and its effect, followed by the two caveats an agent actually needs before calling. The trailing API endpoint reference is mildly redundant but compact, so nothing meaningfully dilutes the definition.

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 7-parameter mutation tool with no output schema and near-empty annotations, the description covers the core action and the trickiest parameter caveat, which is adequate. It stops short of describing the return payload or the lifecycle of an override, leaving some uncertainty an agent must resolve by trial or by reading the schema.

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 every parameter including userId, teamId, escalationTier, and replacementUserIds is already documented in the schema. The description restates the semantics of `type` and `start`/`end` but adds no syntax or validation detail beyond what structured data supplies, so baseline 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?

States a specific verb (creates) and resource (on-call override) and clarifies the effect in parentheses ('temporarily changes who is on call'), which cleanly separates it from the read-oriented sibling allquiet_list_on_call_overrides. It also scopes the operation to the LIVE account, so an agent can place it immediately.

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 is only implied by the purpose statement; there is no explicit when-to-use vs when-not guidance, no named alternative for inspecting or removing overrides, and no stated prerequisites beyond confirming the `type` values. An agent can infer intent but gets no routing help.

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?

readOnlyHint=true already establishes the safe-read profile, so the description only needs to add context. It contributes the backing endpoint (GET /v1/incident/search/{incidentId}), but says nothing about not-found behavior, response shape, or whether the id is an internal or external identifier.

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 short sentences with the core action front-loaded and no filler. The trailing endpoint reference is slightly redundant for an agent that only needs selection and invocation cues, but it costs little.

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 read tool whose readOnlyHint covers the safety profile and which has no output schema, the description is sufficient to select and invoke it. Only the lack of routing guidance against the markdown/get-list siblings keeps it from being 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 description coverage is 100%, so the single incidentId parameter is already documented in the schema; the baseline of 3 applies. The phrase 'by its id' adds no meaning beyond what the schema states.

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 ('Get a single incident by its id'), which clearly separates it from the list-style sibling and identifies the id-keyed lookup. It does not explicitly name the nearest sibling (allquiet_get_incident_markdown), so it falls short of full sibling differentiation.

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 only usage signal is the implied 'by its id' precondition; there is no statement of when to prefer this over allquiet_get_incident_markdown or allquiet_list_incidents. No exclusions or alternatives are offered.

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?

readOnlyHint=true already tells the agent this is a safe read. The description usefully adds that the output is a markdown rendering rather than structured JSON, but discloses nothing about error behavior for invalid ids, permissions, or size limits.

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 tight sentence plus the backing API route, with the core purpose front-loaded. The endpoint string is marginally useful for traceability but is the only slightly non-earning element.

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 trivial one-parameter read endpoint with no output schema, the description conveys both input and output shape (markdown by incident id), which is sufficient to call it correctly. Only the sibling-routing detail is missing.

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 a single, self-explanatory parameter. The description's 'by its id' adds no syntax or format detail beyond the schema's own 'The incident id (required).' Baseline 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?

States a specific verb+resource+format: 'Get a markdown rendering of a single incident by its id'. The format distinction (rendering vs. raw data) implicitly separates it from allquiet_get_incident, but the sibling is never named, so the agent must infer the difference.

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 parenthetical '(useful for pasting into a doc or chat)' gives an implied use case, which is more than nothing. However it never states when to prefer this over allquiet_get_incident or list_incidents, leaving the choice to inference.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description is not carrying the safety burden. It adds the pagination note and the underlying API mapping (GET /v1/incident/search/list), but says nothing about default limit, maximum page size, or how offset interacts with results.

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 compact, front-loaded sentences: capability first, API mapping second. The filter enumeration is dense but useful. The raw endpoint citation is marginal value and the only slight 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 read-only list tool with 14 fully documented parameters, no output schema, and no nested objects, the description covers purpose, filter surface, and pagination adequately. Missing details are minor (pagination defaults, result shape) and partly outside the description's remit given the rich schema.

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 14 filter parameters with their meanings and defaults. The description only restates the filter categories in prose and adds nothing about value formats, defaults, or combining behavior beyond what the schema provides. Baseline 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?

States a specific verb+resource ('Search/list incidents') and enumerates the filter dimensions (status, severity, team, user, search term, archived/snoozed, date range), which clearly separates it from the singular allquiet_get_incident and the mutation siblings. It does not explicitly name or route against a sibling, so it falls just short of a 5.

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

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

The word 'Search/list ... with filters' implies this is the collection-browsing tool as opposed to get_incident for a single record, but there is no explicit when-to-use statement, no when-not, and no named alternative. Usage is inferable rather than 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying endpoint (GET /v1/on-call-override/search/list), which corroborates the read-only nature and hints the backend is a search rather than a full enumeration, but it says nothing about pagination limits or result ordering.

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 short sentences, with the purpose statement front-loaded and the API reference trailing as secondary detail. Nothing is padded, though the raw endpoint adds little for an agent that only needs to call the tool.

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 three-parameter read tool with full schema coverage and no output schema, the description is serviceable but thin. It never indicates what an override record contains or how many come back by default, which is the main gap given no output schema exists.

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 limit, offset, and userId are fully documented in the schema, making 3 the baseline. The description reinforces the userId scoping ('for a given user') but adds no format, default, or boundary detail beyond 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?

States a specific verb and resource: 'Search/list on-call overrides for a given user.' This clearly distinguishes it from the sibling allquiet_create_on_call_override and from allquiet_list_incidents/teams/users. It stops short of explicitly naming how it differs from near-neighbors like allquiet_who_is_on_call.

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 when-to-use or when-not-to-use guidance is given. The phrase 'for a given user' implies the tool is scoped to a single user's overrides, but with siblings such as allquiet_who_is_on_call and allquiet_on_call_report available, no condition is offered for choosing among them.

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?

readOnlyHint=true already establishes this as a safe read operation, and the description adds little beyond that other than the raw endpoint path. It does not describe pagination behavior (relevant given limit/offset), default result sizes, or return shape.

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 short sentences, front-loaded with the core action and filter, with no filler. The 'Search/list' pairing and the appended endpoint string are slightly redundant but harmless.

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, non-destructive list tool whose annotations cover safety and whose schema is fully documented, the description is adequate. The lack of any note on pagination defaults is a small gap, but no output schema exists so return-value explanation is not required.

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 limit, offset, and displayName are already fully documented in the schema. The description only restates the display-name filter and adds no format or syntax detail beyond 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 states a specific verb and resource ('Search/list teams') and notes the optional filter. It is unambiguous and readable on its own, though it offers no differentiation from siblings (there is no competing team tool, so this is a minor gap).

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 (e.g., allquiet_list_users) or any exclusions/constraints. The filter mention hints at a use case but no when-to-use or when-not context is provided.

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?

readOnlyHint=true already tells the agent this is a safe read, so the safety burden is covered. The description adds the upstream endpoint (GET /v1/user/search/list), which is marginal context, but says nothing about return shape, ordering, pagination defaults, or result-size behavior. With annotations carrying the safety profile, this is an adequate-but-thin 3.

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 short sentences, front-loaded with the action and scoping. The trailing endpoint reference is harmless but is filler that does not help an agent decide or invoke. Overall tight.

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-required-parameter read tool with full schema coverage and annotations that declare read-only behavior, the description covers what is needed to call it. No output schema exists, so return values need not be explained, though a note on pagination semantics would have completed the picture.

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 all four parameters (email, limit, offset, displayName) are already documented in the schema. The description restates the two filter fields but adds no format, matching, or default-value detail beyond what the structured data provides. Baseline 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 gives a specific verb and resource ('Search/list users') and names the two filterable fields. It is clearly distinguishable from all siblings, which cover incidents, teams, and on-call data rather than users. The only minor ambiguity is the dual 'Search/list' framing, which leaves it slightly unclear whether the call is a keyword search or a plain enumeration.

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?

It states that filtering by email or display name is optional, which implies the no-argument case returns everything. However, it never says when to reach for this versus a related lookup, nor any exclusion or prerequisite. Usage is implied rather than explained.

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 already declare readOnlyHint=true, so the safety profile is covered. The description adds only that the value reported is 'summed' duration over a window plus the backing endpoint, but says nothing about aggregation granularity, grouping of results, or rate limits — modest added context beyond the annotation.

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 short sentences with the core purpose front-loaded ahead of the filters. The trailing 'All Quiet: GET /v1/on-call-report/sum.' restates the operation as an endpoint reference, a minor redundancy, but the text is otherwise free of padding.

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 should ideally indicate what the report returns (e.g., summed duration grouped by user/team/tier) and the window/format expectations beyond the schema's ISO8601 notes. It leaves the return shape entirely unspecified, which is the main remaining gap for a read-only report 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 both required (start/end) and optional (teamId, userId, maxTier) parameters are already documented in the schema. The description's mention of user/team/escalation-tier filtering mirrors the schema without adding format or syntax detail beyond it.

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: 'Get a summed on-call duration report over a time window.' The scope (time window, optional user/team/tier filters) is explicit, and it is plainly distinguishable from siblings like allquiet_who_is_on_call and allquiet_list_on_call_overrides, which serve 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?

The description implies when the tool applies (reporting on summed on-call duration within a window) and notes the optional filtering dimensions, but gives no explicit when-to-use vs. when-not-to-use guidance and never names an alternative tool for related questions.

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 already declare destructiveHint=true, lowering the burden. The description adds context beyond that: it operates only on a LIVE incident, uses PATCH, and frames intents as status transitions. It still does not explain consequences of resolve/snooze or reversibility, but the added scoping is meaningful.

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?

Three tight sentences, front-loaded with the operation and ending with the endpoint. Slight redundancy in restating 'status transition' already present in the schema, but nothing wasteful.

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 4-parameter mutation with no output schema, the description covers purpose, scope (LIVE), the required-field constraint, and the endpoint. Return values needn't be explained without an output schema; only error or side-effect detail is missing.

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 baseline is 3. The description genuinely adds beyond the schema by stating the cross-field constraint 'at least one of changeSeverity or appendIntent is required', which is absent from the schema's required list (only incidentId), and clarifies the semantic of appendIntent.

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 (applies/updates via PATCH) and resource (an existing LIVE incident), plus the two mutating operations (changeSeverity, appendIntent). The 'existing LIVE incident' scoping and the PATCH endpoint make it clearly distinct from create_incident, get_incident, and list_incidents.

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 'LIVE incident' qualifier and the named lifecycle actions (acknowledge/resolve/reopen/snooze) imply when the tool applies, and the 'at least one required' rule constrains invocation. However, there is no explicit statement of when to choose this over alternatives (e.g. create_incident) or any preconditions, so guidance is only implied.

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 already declare readOnlyHint=true, so safety is covered. The description adds a useful behavioral detail — that the query can be scoped to now or to an arbitrary timestamp — but says nothing about nesting/override precedence in on-call resolution or return shape.

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 front-loaded sentence carries the meaning with no filler. The trailing 'All Quiet: GET /v1/on-call.' endpoint reference is minor padding that earns little for an agent-selection context.

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 and full schema coverage, the description is nearly sufficient; the only real gap is sibling differentiation against allquiet_on_call_report and the other on-call override tools.

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 all three parameters (teamIds, userIds, timestamp) are already documented, including the 'defaults to now' semantics. The description only restates the team/user filtering and point-in-time idea, adding no new syntax or format detail.

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 (get) and resource (who is on call) with scope detail about point-in-time queries and optional filters. However, it never distinguishes itself from the similar sibling allquiet_on_call_report, so an agent must open both to choose.

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 'optionally filtered by team/user' and the parenthetical about a given point in time imply when the tool applies, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the alternative allquiet_on_call_report.

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