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

The description adds concrete behavioral context beyond the readOnlyHint and openWorldHint annotations: it says the tool reports enabled modules, missing settings, tool descriptions, and module-specific settings. It does not mention authentication, rate limits, or error behavior, but the read-only annotation makes that less 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 two compact sentences with no wasted words, and it front-loads the main capability before explaining the optional module-specific behavior.

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-only inspection tool with one optional parameter and an output schema, the description covers the essential purpose and parameter behavior. It could be slightly stronger by clarifying the default/no-argument result, but no major information 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?

The schema has 0% description coverage for the single optional 'module' parameter. The description compensates partially by explaining that passing a module name returns its full settings list, but it does not specify valid module names, expected format, or the exact behavior when omitted.

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 that the tool reports which modules are enabled, missing settings, and per-tool descriptions, and that a module name returns its full settings list. It identifies the resource and scope well, though it does not compare itself with any sibling 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 second sentence gives an explicit usage instruction: pass a module name to get its full settings list. However, the description does not state when to use this tool instead of alternatives or clarify the no-argument case beyond implication.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no mention of pagination/completeness (are all domains returned?), auth requirements, or rate limits for what is an external API call.

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 with zero filler; the key attribute (verification status) is stated up front rather than buried.

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 parameters, an output schema, and annotations covering read safety, the description is nearly complete. The one missing piece is whether the listing is paginated or exhaustive, which matters for an open-world API.

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 takes zero parameters, and the description correctly implies a no-argument listing call. Nothing about parameter semantics needs to be, or is, explained.

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 (list sending domains) plus the informative payload (verified status), which cleanly separates it from siblings like resend_send and resend_emails. It stops short of explicitly naming an alternative, but the resource is 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?

No explicit when-to-use or when-not-to-use guidance. The purpose implies the common use case (checking which domains are verified, e.g. before sending), but the agent must infer that routing rather than being told.

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 and openWorldHint=true, so safety is covered; the description still adds real behavioral value by disclosing result ordering ('newest first') and the cursor-paging mechanism. It says nothing about when the listing ends, whether there is a max limit, or what happens with an invalid cursor.

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, zero filler, with the core purpose and the paging instruction both front-loaded. Every clause carries information the agent needs.

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?

An output schema exists, so return values need not be described, and the pagination story is partially told. Still missing are termination behavior at the end of the list and any guidance on the limit parameter, which matter for a cursor-paged listing tool with 0% schema coverage.

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 both parameters are undocumented in the schema and the description must compensate. It explains 'after' well by tying it to the next_after value from the previous page, but 'limit' is never mentioned, leaving half the parameter surface unaddressed.

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 sent emails') and clarifies ordering ('newest first'), which importantly disambiguates the tool from its name, which reads like a re-send action. It never explicitly contrasts with the sibling resend_send, so the agent must infer the split between listing and sending.

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 (read a list of sent emails, page through it) and gives concrete paging mechanics, but offers no when-to-use/when-not guidance and no routing hint relative to resend_send or resend_domains. Adequate but inference-dependent.

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 only declare the generic profile (not read-only, open-world, non-idempotent, non-destructive); the description adds the non-obvious two-phase preview/approval workflow and the human-in-the-loop gate that an agent absolutely must know about. The pre-approved-recipient bypass is a real behavioral detail not derivable from annotations or schema.

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 tight sentences with the default (preview) mode stated first and the escalated (confirm) mode second. Every clause conveys actionable information; nothing is padded.

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 consequential outbound-send tool, the critical questions — does it actually send, and who approves — are answered, and an output schema covers return values. Remaining gaps are the untended body parameters (html vs text) and what the preview contains, which are secondary but not trivial.

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% across six parameters, so the description must carry the burden. It explains only `confirm` meaningfully; `to`, `subject`, `html`, `text`, and `reply_to` get no guidance, and it never says whether html/text are alternatives, whether both are allowed, or what happens if neither is supplied.

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 ('Send an email from the configured sender') so an agent can immediately distinguish this from read-only siblings like resend_emails and resend_domains. It does not explicitly name the sibling it is not, but the write/send semantics make the boundary clear.

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?

Explicitly describes both operating modes: without confirm=true it returns a preview only; with confirm=true a human approval step is triggered. It also names the exception (pre-approved recipients) and an important constraint (the assistant cannot approve on the user's behalf), which is exactly the routing knowledge an agent needs before calling.

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 and openWorldHint=true, so safety is covered. The one genuine behavioral addition is the ordering guarantee ('highest count first'), which is useful. Nothing is said about the time window (how `days` interacts with `start`/`end`), how `search` filters, or pagination 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 compact sentences with zero filler; the ordering behavior is front-loaded before the long enumeration. The type list is dense but each token is load-bearing as an allowed 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?

An output schema exists, so return shape need not be explained. However, for an 8-parameter analytics query the description never states the date-range semantics (default 7 days vs explicit start/end precedence) or what `search` does, leaving real gaps for 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 0% across 8 parameters, so the description carries the full burden. It does the single most valuable thing: enumerates the allowed `type` values, which the schema leaves as a bare string with a 'path' default. The remaining parameters (days, limit, offset, search, start, end, website_id) are undocumented but largely self-describing by name.

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 conveys that results are a ranked breakdown of some metric dimension, and the enumerated `type` values (top pages, referrer, country, browser, ...) strongly imply website analytics. But there is no verb and no mention of the resource being a website's metrics, and nothing distinguishes it from siblings like umami_stats or umami_pageviews.

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 explicit when-to-use guidance and no named alternative. An agent must infer from the type list that this is the tool for per-dimension breakdowns rather than aggregate stats, and must guess how umami_stats differs.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing about default time window behavior, how 'days' interacts with 'start'/'end', timezone handling, or aggregation granularity—context that matters for a time-series query.

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 and zero filler. It is efficient, though the brevity comes at the cost of substance covered under other dimensions.

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?

An output schema exists so return values need not be described, but with 6 parameters at 0% schema coverage and only 'unit' documented, an agent cannot confidently supply time ranges, timezone, or the required website_id from the description alone. Significant gaps remain.

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% and there are 6 parameters, so the description carries the full burden. It documents only the 'unit' values, leaving website_id (required), days, start, end, and timezone entirely unexplained, and it never clarifies the precedence between 'days' and start/end.

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 resource (pageviews and sessions) and the temporal dimension ('over time'), so an agent knows this is a time-series retrieval tool. It does not distinguish itself from siblings like umami_stats or umami_metrics, so it falls 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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as umami_stats or umami_metrics. The second sentence about units is parameter detail, not usage 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?

The readOnlyHint annotation already covers the safety profile, and the description adds only the date-range window, which is mostly schema-level information. It says nothing about auth requirements, rate limits, or whether totals are scoped to a single site vs all sites beyond the vague "one website", so little behavior is disclosed beyond structured fields.

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 resource and followed by the range rule; nothing wasted. Brevity is appropriate, though it is terse to the point of under-specification rather than sloppiness.

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 tool with an output schema, return-value detail is not required, so the main gap is which aggregate is returned and how it relates to the sibling metric tools. Enough to invoke (website_id required, range modes given) but not enough to pick it with confidence among the umami family.

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%, and the description does clarify that `days` and `start`/`end` are alternative range modes (ISO 8601 for explicit dates) — valuable for two of the four parameters. It leaves `website_id` and the interaction rules (does `days` override `start`/`end`?) unstated, so it only partially compensates for the coverage gap.

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?

"Totals for one website" restates the tool name (stats = totals) without naming which aggregate is returned (visitors, pageviews, bounce rate?) or how it differs from the sibling umami_metrics. A verb-like framing exists but the resource is left ambiguous, so an agent cannot confidently pick this over umami_metrics or umami_pageviews.

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 guidance is about date-range modes (days vs start/end), which is invocation mechanics rather than when-to-use. Nothing tells the agent in which situation this tool should be chosen over umami_metrics, umami_pageviews, or umami_websites.

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, giving the safety profile. The description adds useful behavioral detail that page is 1-based and page_size caps at 100, which the schema does not state. It doesn't mention total counts or truncation behavior, but the annotations carry the main burden.

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 that are front-loaded with the purpose and immediately follow with the two parameter constraints. Nothing is wasted.

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 read tool with an output schema already describing return values, the description covers purpose and the non-obvious paging constraints. The only gap is routing guidance among the many Umami siblings, which is a minor omission given the unambiguous resource.

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 partially does: it clarifies 1-based paging and the page_size ceiling of 100. However, it doesn't explain defaults (page 1, page_size 20) or what happens when page exceeds the result set, leaving some semantics unstated.

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 websites tracked in Umami.' It's clear what the tool returns, but it doesn't distinguish itself from siblings like umami_stats or umami_pageviews beyond the nouns in their names.

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 offers no when-to-use guidance or alternatives. It doesn't say to call this first to obtain a website ID for other Umami tools, which is the natural usage pattern implied by the sibling set.

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