Relvato

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

Annotations declare it is a non-destructive, idempotent mutation; the description adds substantial behavioral detail beyond that: per-key outcome reporting (added/exists/rejected), rejection reasons (plan, active-check limit, plugin), and default trigger behavior (weekly/daily schedule plus re-runs on site changes). This is rich, non-obvious context.

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

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

Two sentences, front-loaded with the action and the key source, followed by outcome and scheduling behavior. No filler; every clause carries 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?

With no output schema, the description fills the gap by explaining per-key results and rejection reasons, and it covers default scheduling and dependencies. For a two-parameter mutation tool this is complete enough to invoke 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 coverage is 100%, so baseline is 3, but the description adds meaning by specifying that keys come from list_checks and are check keys, guiding correct value sourcing. It does not restate limits like maxItems, but that is already 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?

States a specific verb and resource ('Add checks to a site') and identifies the key source ('from list_checks'), which distinguishes it from siblings like list_checks and update_check. An agent can tell what this does without opening the schema.

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?

Directs the agent to list_checks for valid keys, giving clear context for how to use it, and notes dependencies (WordPress plugin). It does not explicitly state when to prefer an alternative tool or when not to use it, so it falls short of full routing 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?

Annotations already flag idempotentHint=true and destructiveHint=false, and the description usefully explains the dedupe behavior concretely: an existing site on the same domain is returned instead of creating a duplicate. It also discloses the important behavioral constraint that no checks execute until setup completes, which goes beyond the annotations.

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 core purpose, then the return value/precondition, then the dedupe rule. Nothing is padded and each sentence carries distinct 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 3-parameter mutation tool with no output schema, the description compensates by describing the return (site + setup step), the operational precondition, and the idempotent dedupe path. An agent has enough to call it correctly and interpret the result.

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

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

Schema description coverage is 100%, so url, name, and platform are already documented in the schema, including the platform enum semantics. The description's note that domain verification is the only option for non-WordPress sites largely restates the platform field and adds no syntax or format 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 clear verb and resource ('Start monitoring a website') and explains what the call produces (the site plus the required setup step). It gestures at the verification/plugin workflow that sibling tools like verify_site handle but never names those siblings, so differentiation is implicit rather than explicit.

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 conveys the precondition context (no check runs until the owner completes plugin connection or domain verification) but never states when to call this versus add_checks, verify_site, or update_check, nor any exclusion or prerequisite ordering for the agent itself. Usage is implied rather than prescribed.

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 readOnlyHint=true, but the description goes well beyond that: it defines the `on` flag semantics ('alerts actually go out on it'), notes that routing lists only channels that are on, and states a security boundary ('Never includes webhook URLs or secrets'). That is meaningful behavioral context an agent could not infer from 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?

Front-loaded with the core question ('Who is told about what') and every clause carries information. The single sentence is dense with em-dashes and parentheses, making it slightly harder to parse than a short bulleted structure would be, but there is essentially no 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?

No output schema exists, so the description must carry the return-shape burden — and it does, covering frequency, severity, channel enablement/setup/pause state, muted sites, and check-type routing, plus an explicit exclusion of secrets. Nothing an agent needs before calling this 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?

Zero parameters, so there is nothing to disambiguate at the input layer and the baseline is 4. The description instead spends its detail on output semantics, which is the right allocation for a no-arg getter.

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?

Names a specific resource and enumerates exactly what the response contains: digest frequency, minimum severity, per-channel state, muted sites, and channel routing. An agent can distinguish this read-only settings tool from siblings like list_checks or site_overview without opening a schema.

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 closes the loop on the write side — 'Changing them is done by the user in Alert settings' — which tells the agent there is no mutation counterpart to look for. The positive trigger (call this when you need to know who is notified and how) is implied rather than stated, so it stops short of a full 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 readOnlyHint already declared, the description goes further by enumerating the brief's contents (detected stack, check semantics, recent site changes, error/findings, prior-failure status, cause-ruling evidence) and stating the advisory boundary that it does not apply fixes. It adds real behavioral 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?

The condition is front-loaded and a second sentence covers usage, so structure is sound. The middle enumeration is a long comma series, but every listed item is substantive content the agent needs to know is available rather than 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 one-parameter, read-only tool with no output schema, the description compensates by itemizing the returned brief's contents, so an agent knows what to expect. Coverage is strong; only the absence of an explicit sibling alternative keeps it from being fully complete.

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

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

Schema description coverage is 100% for the single runId parameter, so the baseline is 3. The description adds no format, source, or sourcing detail about runId beyond what the schema already 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?

The description names a specific verb (get) and resource (fix brief for a run) and enumerates exactly what the brief contains, so an agent can distinguish it from get_run or site_overview. It is slightly buried in the return-content enumeration rather than stating the action crisply up front, but the purpose 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?

"For a run that failed or found a problem" gives a clear triggering condition, and the closing sentence clarifies the intended use (context to explain cause/fixes) and the boundary that applying a fix stays with the user. No sibling is named as an explicit alternative, which is the only gap.

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 declare readOnlyHint=true, so safety is covered. Beyond that the description adds genuinely useful behavior: large metrics are compacted with daily series collapsed to summaries, the trimmed content is enumerated in metricsTrimmed, and findings are never trimmed. That compaction/trimming contract is not derivable from the schema or annotations.

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

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

Two sentences, no filler, with the return contents front-loaded before the compaction caveat. Dense but every clause carries payload information; only the long enumeration slightly tests readability.

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 correctly carries the burden of describing the return shape, and it does so thoroughly including the metricsTrimmed field. The residual gap is minor: it doesn't note that a runId comes from list_runs, which is where the agent would naturally look.

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?

Only one parameter (runId) with 100% schema description coverage, so the schema already documents it fully. The description adds no format, source, or lookup guidance for the id, 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 and resource ('one run in detail') and enumerates the payload (status, errors, steps, comparisons, metrics, dashboard link). This implicitly distinguishes it from list_runs, but it never names that sibling explicitly, so differentiation is left to inference.

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: the agent must infer that this is the detail view reached after list_runs surfaces a runId. There is no explicit when-to-use, no prerequisite (e.g., 'requires a runId from list_runs'), and no stated exclusion for the listing tool.

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 declares this as a safe read. The description adds useful context about what the result conveys (plan eligibility, recommendation, already-added status), which is more than the annotation provides, but it says nothing about auth requirements, pagination, or how 'recommended for this site' is determined.

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 sentence, front-loaded with the resource and its key differentiator. It is a sentence fragment rather than a complete statement, but no words are 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?

With no output schema, describing the returned fields is exactly the right use of the description, and readOnly covers the safety profile. The main gap is the missing action verb and any usage routing, but nothing critical to invoking the tool is absent.

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?

Single siteId parameter with 100% schema description coverage, so the schema already documents it. The description adds no meaning about the identifier's format or scope, which is the expected baseline when the schema carries the burden.

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 names the resource (checks) and scopes it to checks that can be added to a site, which distinguishes it from add_checks/update_check. However it never states the verb explicitly ('list'/'retrieve') and reads more as a return-shape description than an action statement.

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 guidance, no prerequisites, and no mention of alternatives such as add_checks or update_check. The agent must infer that this is the pre-flight lookup before adding checks.

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 readOnlyHint=true, so the description carries the rest and does so usefully: ordering (newest first), optional site scoping, and the per-run payload fields (checkId/journey/checkName, status, trigger, timing, error/warning). It does not discuss volume ceilings or pagination behavior beyond the limit parameter, so it is short of exhaustive.

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 compact sentence front-loads the resource, ordering, and scope, then uses a trailing clause to route to the detail sibling and enumerate the returned fields. There is no filler; every clause adds 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?

With no output schema, the description must convey the return shape, and it does so by enumerating the fields each run carries. Combined with the ordering and annotation-covered safety profile, an agent has what it needs; only pagination/volume behavior is left unstated.

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 parameters (limit with its 1-100/default-25 range, siteId) are already fully documented in the schema. The description only restates site scoping ('optionally for one site') and never mentions limit, 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 states a specific resource (runs) with its ordering (newest first) and optional scope (one site), so the agent knows exactly what comes back. It also differentiates from the closest sibling by noting 'get_run has the detail,' making the list-vs-detail split 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?

It gives clear context for when to use this tool (browsing recent runs, optionally narrowed to a site) and explicitly names the alternative for detail (get_run). There is no explicit 'do not use for X' exclusion beyond that routing, so it stops short of the top score.

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

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

readOnlyHint=true already tells the agent this is a safe read operation, so the description's added value is the disclosure that each site carries a readiness indicator. That is useful given there is no output schema, but pagination, ordering, and result shape are not described.

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 well-formed sentence with no waste, front-loading the verb and resource before the readiness qualifier.

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, parameterless read tool with no output schema, the description covers what is returned at a high level. It is nearly complete, only missing minor detail like result ordering or empty-state behavior.

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 schema has no properties, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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 the websites in this Relvato account') plus a scope qualifier (readiness to run checks). It is clear what the tool does, though it does not explicitly contrast itself with the closest sibling, site_overview.

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 implied by the listing nature of the tool, but there is no explicit statement of when to call it versus site_overview or list_checks, and no preconditions are given.

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 readOnlyHint=true, so the description carries the rest — and it does disclose meaningful behavioral detail: it returns a plain-language verdict, distinguishes real issues from likely false positives, shows latest run and schedule per check, setup state, suggested-but-missing checks, and account run usage. It stops short of stating cost, latency, or scope limits, so 4 rather than 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?

A single sentence, front-loaded with the core concept ('plain-language health verdict for a site') followed by a comma-separated inventory of contents. Every item listed is informative rather than filler, though the tail-end enumeration is dense enough to read as a checklist.

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 bears the burden of explaining returns, and it does so thoroughly — verdict, issues with false-positive framing, per-check run/schedule, setup state, recommendations, and usage. It omits any mention of response size or pagination, which is the only notable gap for a composite overview 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?

There is a single parameter (siteId) with 100% schema coverage, though the schema description itself is just 'The site id'. Per the baseline for high schema coverage, a 3 is appropriate; the description adds no scoping or format detail about the id beyond what the schema already provides.

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

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

The description names a specific deliverable — a "plain-language health verdict for a site" — and enumerates its contents (issues, checks with runs/schedules, setup state, recommended checks, run usage). That is far more precise than a restated title. It does not name siblings like list_checks or list_runs, so the agent must infer the differentiation, which keeps it at 4 rather than 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?

Usage is implied rather than stated: the aggregate nature of the output (health verdict, recommended checks, account run usage) suggests it is the entry-point summary versus per-entity siblings such as list_checks, list_runs, and get_run. There is no explicit 'use this when... / use X instead when...' guidance or prerequisite note.

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 mark this as non-read-only, non-idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot convey: each run consumes the monthly quota and a checkId run can bypass a disabled state.

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 short clauses, front-loaded with the primary action, then the override, then the quota caveat and follow-up hint. No filler sentences.

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

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

No output schema exists, and the description compensates by stating the return value (runIds) and the tool to follow up with (get_run). Combined with the quota disclosure, an agent has everything needed to invoke and continue 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: checkId overrides the 'enabled' filter, which the schema's terse 'Run only this check' does not state.

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 action (run checks now) and the resource (a site's enabled checks), plus the two distinct modes: all enabled checks, or a single check via checkId. Easily distinguished from siblings like list_checks or get_run.

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?

Clearly says what is run by default (enabled checks) and the exception (one check with checkId, even if disabled). It also routes the agent to get_run as the follow-up, but does not name a sibling alternative for the 'don't run, just inspect' case.

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 the mutation/idempotency profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds meaningful context beyond that: PATCH-style partial semantics (only passed fields change) and a plan-tier gating constraint on fast schedules. It doesn't discuss reversibility or error behavior, so it falls short of 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?

Three short sentences, each earning its place: what it does, the partial-update rule, and the plan constraint. The core action is front-loaded with zero 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 6-parameter mutation tool with no output schema and full annotation coverage, the description covers the essential behavioral facts (partial update, plan gating). It omits a required-only-checkId reminder and any confirmation of return behavior, but nothing critical to correct invocation 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 description coverage is 100%, so the schema already documents all six parameters including the enum values and timezone format. The description alludes to the on/off and schedule fields but adds no syntax, defaults, or format detail beyond the schema, so the baseline 3 is correct.

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 ('Turn a check on or off, or change its schedule') and clearly distinguishes itself from siblings like add_checks and list_checks, which create and read rather than modify. An agent can select this without opening the schema.

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 for use via the partial-update rule ('Only the fields you pass change') and a precondition ('Schedules faster than daily need a paid plan'), which tells the agent when the operation will succeed. It stops short of naming explicit alternatives or when-not-to-use cases.

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 declare readOnlyHint=false and idempotentHint=true, and the description is consistent with that: 'Returns the updated setup state' discloses that the call mutates stored setup state rather than being a pure read. It also discloses the probe mechanisms (live plugin connection, DNS lookup, meta tag fetch), which explains the openWorldHint=true behavior. It does not cover auth requirements, rate limits, or what happens when verification fails, so it stops short of 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?

Two sentences, front-loaded with the core question ('is ownership proven') followed by the mechanism and the return value. Every clause earns its place and there is no boilerplate.

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 carries the return-value burden and does so summarily ('the updated setup state'), which is adequate for a state-verification tool. Behavior and parameters are well covered; the only gap is failure semantics (timeout, unverified result) on an open-world network probe.

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

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

Schema coverage is 100%, so the baseline is 3 for siteId and method. The description adds meaning beyond the enum: it clarifies that the plugin-connection probe is a separate path from 'domain verification', which explains why the method enum only accepts dns/meta and why omitting it checks everything ('and/or'). That framing is genuinely useful and pushes past the baseline.

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 (check/verify) and resource (site ownership) and then names the exact mechanisms used: probing the WordPress plugin connection and looking for the DNS TXT record or meta tag. An agent knows precisely what this tool does and how it does it, and no sibling (add_site, add_checks, trigger_scan) overlaps this verification role.

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 implied rather than stated: checking that ownership is proven implies running this after setup or after adding a verification record, but there is no explicit when-to-use, no prerequisite (e.g. a site must already be added), and no exclusion or alternative. Nothing misleading, but nothing that routes the agent either.

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