audit

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

Annotations already declare write (readOnlyHint=false), openWorldHint=true, and destructiveHint=true, so the safety profile is covered. The description adds valuable context the annotations do not: no login, API key, or OAuth is required, and ad-unit creation must be deferred. However, a 'destructive' flag on a lead submission is surprising and goes unexplained (duplicate leads? irreversible submit?), and no idempotency or response behavior is 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?

Two front-loaded sentences with no filler; the core action leads and the workflow constraint follows. The clause about audit tools remaining available is tangential to invoking this tool but brief enough not to be 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?

With no output schema and no annotations covering auth or side effects, the description should say what a successful submission yields (lead id, status, follow-up expectations) and whether repeat submissions create duplicates. It gives the auth picture and a sequencing rule but leaves the observable outcome 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 coverage is 67%: email and domain are documented, including the useful note that the signup backend accepts root publisher domains, while outputFormat is unexplained in both places. The description adds nothing about any parameter, so the schema carries the semantics and the baseline of 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?

A specific verb (submit) plus a concrete resource (an unauthenticated Sulvo account application lead) delivered through the current signup API. It is clear what the tool does, but it offers no differentiation from the crowded signup siblings (create_sulvo_signup_account, start_sulvo_signup, submit_sulvo_signup_documents), which an agent must disambiguate on its own.

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 this applies (unauthenticated lead capture, before approval) and adds one useful sequencing rule: ad-unit generation should wait for approval. It never states when to choose this over create_sulvo_signup_account or start_sulvo_signup, nor when not to use it, so relevance must be inferred.

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 and readOnlyHint=false, so the safety profile is covered. The description adds nothing about what is overwritten when an artifact is attached, how expectedVersion conflicts are surfaced, or whether the prior artifact is retained — all critical for a destructive mutation.

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 action front-loaded and the input requirement immediately after; no filler. The brevity is efficient, though it borders on under-specification rather than tightness.

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 destructive, version-guarded mutation with a free-form nested `input` object and no output schema, the description leaves out conflict behavior, reversibility, and where the required field values come from. An agent could invoke it but could not predict or recover from the likely failure modes.

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 75%, but the visible schema exposes only workspaceId, outputFormat, idempotencyKey and an untyped `input` bag with additionalProperties:{}. The description is therefore the sole source naming expectedVersion and auditArtifactId, which is genuinely valuable — but it does not explain that expectedVersion is an optimistic-concurrency token or how auditArtifactId is obtained, so the added meaning is shallow.

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 verb+resource pairing ("Attach ... revenue audit artifact") is identifiable, but "attach" is ambiguous — it does not say whether this links an existing artifact to a workspace, uploads it, or replaces a prior one. It also offers no differentiation from adjacent siblings such as run_publisher_revenue_audit or get_publisher_revenue_audit_checklist, so the agent must guess at scope.

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 statement of when this should be used, what precondition must hold (e.g., an audit having been run first), or which sibling to use instead. The only guidance is a restatement of required input fields, which is 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?

Annotations already establish readOnlyHint, openWorldHint and non-destructive behavior, so the description is free to add interpretation guidance: robots.txt Disallow and Amazon Crawl-delay are treated as hard fails while a WAF 403 against the scanner is a soft warn requiring verification. That severity model is genuine value beyond the annotations, though it omits auth/rate-limit or scope details.

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, front-loaded with what is checked, then the verdict semantics. Nothing is redundant and each sentence adds decision-relevant 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?

There is no output schema, so the description carries responsibility for return values; it explains the fail/warn confidence classification but not the result structure, what checks are enumerated, or what outputFormat changes. Enough to call it, not enough to fully anticipate the response.

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 only 50% (domain is documented, outputFormat has no description) and the description does not compensate by explaining either parameter. The undocumented parameter is a trivial enum with a default, so baseline 3 is appropriate rather than a penalty.

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 (Check) and resource (robots.txt / live probe blocking), and names the exact crawlers being tested (AmazonAdBot, Google ad crawlers), which is more concrete than the tool name alone. It does not explicitly contrast itself with related siblings like run_agentic_readiness_audit or check_https_certificate, so it stops short of full 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?

Usage is implied by the confidence-tier framing (high-confidence fails, medium-confidence warn needing verification), which tells the agent how to act on results but not when to choose this tool over the readiness audit or certificate check. No prerequisites or exclusions are 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?

Annotations already declare readOnly and non-destructive, so the description focuses on behavior the annotations can't express: the 14-day expiry threshold, the six specific defect classes, and the notable rule that no finding is written when both HTTP and HTTPS are unreachable. That last detail is genuinely non-obvious side-effect information an agent would otherwise have to discover by trial.

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 detected defect classes, followed by a single exception clause. Nothing is repeated and the caveat is placed after the main scope where it belongs.

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 conveys what kinds of results are produced (findings about cert/HTTPS state) and one condition under which no finding is written. What remains unstated is the shape of a returned finding (severity, message fields, per-protocol granularity), which is a modest gap for a diagnostic tool.

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

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

Schema coverage is 50%: the domain parameter is documented in the schema itself while outputFormat is only an enum with a default. The description adds no meaning to either parameter — no note on whether wildcards, ports, or subdomains are accepted in the domain string. Baseline 3 applies given the schema does the visible work.

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 definition opens with a specific verb and resource ("Check a publisher domain for HTTPS and certificate issues") and enumerates the exact failure modes it detects, so the scope is unmistakable. It doesn't explicitly name a sibling to distinguish itself from, but the subject matter (TLS/HTTPS) is clearly separate from the crawl/ads.txt/account tools listed.

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 phrase "publisher domain" — there is no statement of when to prefer this over, say, check_crawler_blocks or run_agentic_readiness_audit. The closing sentence describes a result condition, not a reason to choose or avoid the 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?

Annotations already declare openWorldHint=false, destructiveHint=false and readOnlyHint=false, so the description need only add flow context — but it adds none. Notably, 'Return ... authorization URL' reads like a passive retrieval while the annotations mark it non-read-only and the schema exposes an idempotencyKey for 'the same mutation'; the description never explains what state is created or that the URL must be visited by a human before the connection exists.

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, the return value front-loaded and the input constraint second — no padding or filler. The second sentence is a bit clipped ('Input requires...') but 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 4-parameter journey step with no output schema and a nested free-form `input` object, the definition covers the call shape adequately but not the workflow: it never says what to do with the returned URL (redirect a user, then poll a status/activation tool). An agent could invoke it but would not know the next step.

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 75%, and the description supplies exactly the missing piece: the nested `input` object has no declared properties in the schema, so naming the required `provider` field and its two accepted values (gam, adsense) adds real meaning the schema cannot. The other parameters (workspaceId, idempotencyKey) are already documented in the schema, so no further elaboration is needed.

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 ('Return the GAM or AdSense authorization URL') plus the provider values accepted, so the agent knows exactly what it gets back. It does not clarify its relationship to the sibling backup/import tools (e.g. import_sulvo_backup_units) or to the name's 'connect' framing, so sibling differentiation is left implicit.

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 the prerequisite that 'input requires provider set to gam or adsense', which is a call-shape constraint rather than a when-to-use rule. There is no statement of which step of the activation/backup journey this belongs to, no when-not-to-use, and no pointer to the sibling that continues after the URL is obtained.

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 a non-destructive write, and the description adds real context beyond them: the key comes from the server environment and is never an argument, the scope is inventory:write, and unapproved accounts are rejected by the backend. The return shape (unit id and container root) is also disclosed, though no failure modes beyond approval are 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?

Three tight sentences, front-loaded with the action and then the auth and approval prerequisites, then the return value. Dense but every sentence carries distinct information; no padding or repetition of the title.

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 mutating tool with no output schema, the description covers the three things an agent would otherwise lack: the auth mechanism and where the credential comes from, the account-level gate that causes failure, and what the call returns.

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 86%, so the schema already carries most parameter meaning, establishing a baseline of 3. The description adds nothing about individual parameters — it does not clarify the type enum tradeoffs or how size interacts with interstitial types, which the schema only hints at.

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 ("Create a Sulvo ad unit") plus a precondition (approved publisher), which is more specificity than a bare name restatement. It does not, however, distinguish itself from near siblings like create_sulvo_auto_sticky_units or create_sulvo_interstitial_units, which create ad units in bulk or by category.

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?

Gives a clear precondition (account must be approved, key must be write-scoped) that guides whether a call can succeed at all. It offers no exclusion or alternative-selection guidance — an agent cannot tell from this text when to pick this single-unit tool over the other ad-unit creation siblings.

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 annotations already declare non-destructive, non-open-world mutation semantics, and the description adds genuinely new context: the required SULVO_API_KEY with inventory:write scope and the approved-publisher precondition. It stops short of stating idempotency, behavior on partial failure, or whether one unit is created per adType.

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 followed by the environmental prerequisite. No filler and nothing redundant with the schema.

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 covers the auth and eligibility preconditions but leaves the result shape and the mapping of adTypes to created units unexplained. Acceptable but with clear gaps given the density of sibling creation 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 coverage is 67% — domain and adTypes are documented in the schema, while outputFormat has no description. The description adds nothing about parameters, so the baseline of 3 is appropriate; it neither compensates for the gap nor misleads.

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 ("Create Sulvo auto-sticky ad units") and adds a scope qualifier ("for an approved publisher"). It never distinguishes this from close siblings like create_sulvo_ad_unit or create_sulvo_interstitial_units, so an agent must infer which creation tool applies.

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 an approved publisher" implies a precondition, but the description gives no explicit when-to-use guidance and names no alternative. An agent can guess this is the sticky-format variant, but nothing confirms it against create_sulvo_interstitial_units or create_sulvo_ad_unit.

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 a non-destructive, non-open-world write, so the description's job is additive — and it delivers by naming the required SULVO_API_KEY with the inventory:write scope and the publisher-approval prerequisite. It doesn't cover idempotency or whether re-creating an existing domain/adTypes pair fails, which would be the remaining gap for a write 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?

Two short sentences with zero filler, and the core action is front-loaded ahead of the environment prerequisite. Every clause carries actionable 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 three-parameter mutation with annotations covering side-effect profile and no output schema, the description supplies the two things structured fields cannot: auth scope and publisher-approval gating. A note on duplicate handling or what the units look like on return would close the remaining gap.

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

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

Schema coverage is 67%: domain and adTypes are documented in-schema, while outputFormat has no description anywhere. The description's 'interstitial' wording loosely maps to the adTypes enum values but adds no format, default, or multi-unit behavior guidance 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 — creating Sulvo interstitial ad units — plus the qualifier 'tagless', which separates it from create_sulvo_ad_unit and create_sulvo_auto_sticky_units. It doesn't explicitly name those siblings, so differentiation is inferred from the ad-type rather than directed.

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 an approved publisher' establishes a real precondition an agent must satisfy before calling. However, it never says when to prefer this over create_sulvo_ad_unit or create_sulvo_auto_sticky_units, nor what to do when no interstitial inventory is needed.

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 and openWorldHint=true, so the write/external nature is known. The description adds a genuinely useful behavioral constraint (the backend mandates a password before progression) but says nothing about what state is created externally, whether the call is idempotent, or what side effects the pending account has, which matters for a destructive-hinted 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?

Two short sentences with zero padding; the step number and the action are front-loaded, and the justification for the otherwise surprising password requirement follows immediately.

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, 12 parameters, and a destructive hint, the description should say what a successful call returns (e.g., pending account identifier or status) and what preconditions apply (must start_sulvo_signup run first, domain must match). It gives the workflow position but leaves these gaps.

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 only 25% across 12 parameters, yet the description only reinforces the password field (already documented in the schema). It adds nothing for domain, monthlyPageviews, firstName/lastName, the UTM analytics fields, mixpanelId, phone, or outputFormat, leaving most of the payload undocumented in both places.

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 ("create the pending Sulvo user/account") plus its position in the workflow ("step 2"), which lets an agent place it relative to start_sulvo_signup and the ads.txt/review steps. It stops short of explicitly naming the sibling it differs from (e.g., apply_for_sulvo_account for non-normal flows), so it is clear but not fully differentiated.

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 "Run normal Sulvo signup step 2" and the note that the backend requires a password "before the account can continue to ads.txt and review" supply clear sequencing context: this is the step after signup start and before ads.txt/review. No explicit exclusions or named alternatives are given, keeping it below 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?

Annotations already mark this as destructive and non-read-only. The description adds useful behavioral context beyond annotations, specifically the required SULVO_API_KEY environment variable, the inventory:write scope, and backend-enforced ownership.

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 tightly written and front-loads the core action before prerequisite details. Every sentence adds relevant information without repetition.

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

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

For a single-parameter destructive deletion tool with no output schema, the description covers the action, required credential scope, and ownership constraint. An agent has enough information to invoke it correctly.

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

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

Schema coverage is 100%, and the single adId parameter is already described in the schema as the ad unit id to delete. The description reinforces that deletion is by id but adds no format or syntax details 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: deleting a Sulvo ad unit by id. It also scopes the operation to an approved publisher, distinguishing it clearly from sibling tools such as create_sulvo_ad_unit or delete_sulvo_advanced_report.

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 conditions for use: the publisher must be approved and the API key account must own the unit. It does not explicitly name alternatives or exclusions, but the deletion context is unambiguous from the resource and verb.

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 and readOnlyHint=false, and the description adds genuinely new context: the required SULVO_API_KEY environment variable and the reports:write scope. It stops short of confirming permanence/irreversibility or what happens if the id does not exist.

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: the action leads, and the authorization requirement follows. Nothing is redundant or 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 single-parameter destructive mutation with no output schema, the definition covers the essentials: what is deleted, the identifier, the destructive nature (via annotations), and the required credential scope. Missing only failure-mode behavior and confirmation of irreversibility.

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, documented at 100% schema coverage with its own description. The phrase 'by id' adds no meaning beyond the schema, so 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?

States a specific verb (Delete) and resource (saved Sulvo advanced report) scoped by id, which is unambiguous against siblings like save_sulvo_advanced_report and list_sulvo_advanced_reports. It does not explicitly name those siblings as alternatives, so it falls short of full 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?

Usage is implied by the verb — call this to remove an existing report. There is no explicit statement of when to use this versus save_sulvo_advanced_report (to modify) or get_sulvo_report (to read), and no prerequisites or exclusions beyond the auth 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 declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only that these are comparative industry benchmarks returned per vertical; it says nothing about data freshness, source, or scope limits of the benchmark set, which would be the valuable extra context here.

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 no filler; the parenthetical '(AdSense and managed wrappers)' earns its place by clarifying what 'standard stacks' means. Slightly long but efficiently packed.

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 lookup with full schema coverage and no output schema, the description gives enough for correct invocation. Minor gaps (nature/freshness of benchmark data, what the comparison output contains) are tolerable given the tool's simplicity.

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% and the single enum parameter already documents allowed verticals and the 'other' default. The description echoes the vertical dimension but adds no syntax, fallback, or interpretation guidance beyond the schema, 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 ('Get') and resource ('comparative yield and CPM industry benchmarks by publisher vertical'), plus the framing of comparing standard stacks against Sulvo Premium Ad Units. It is clear what the tool returns, though it does not explicitly contrast itself with benchmark-adjacent siblings like run_publisher_revenue_audit or get_publisher_revenue_audit_checklist.

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 stated comparison purpose: call it when you need reference yield/CPM numbers to benchmark against AdSense. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer routing.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds that the content is a 'public' checklist with interpretation notes, implying static, non-user-specific reference material, but says nothing about caching, versioning, or return format. Modest added value over annotations, hence a 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?

A single front-loaded sentence with zero padding. The resource being returned is named immediately and no sentence is wasted on restating the tool name or title.

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

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

For a zero-parameter read-only getter with no output schema, the description should hint at what the checklist actually contains and in what form. 'Checklist and interpretation notes' gives the gist but leaves the structure and scope of the payload undefined, so an agent knows what it gets only vaguely.

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, so the schema has nothing to document and there is no parameter-level ambiguity to resolve. Baseline 4 applies for a parameterless tool; the description correctly implies no input is required.

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 (Return) and resource (public checklist and interpretation notes for the publisher revenue-readiness screen). An agent can distinguish it from run_publisher_revenue_audit, which performs the audit rather than fetching its checklist. It stops short of explicitly naming that sibling, so a 5 is not warranted.

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: an agent infers it should call this to obtain the checklist before or alongside a revenue-readiness screen. There is no explicit when-to-use statement and no named alternative (e.g., run_publisher_revenue_audit) to route against, which is the main 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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description contributes the useful constraint that only the latest attempt is reported (no historical query) and enumerates the three status categories, but says nothing about behavior when no activation attempt exists. Note the idempotencyKey field description mentioning 'mutation' is inconsistent with a read-only tool, though that text lives in the schema, not the description.

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 front-loaded sentence with no filler; the three status facets are packed efficiently. It is tight enough that nothing is wasted, though the terseness leaves little room for the usage context an agent would need.

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?

There is no output schema, so the description should carry more of the return-shape burden; it names the three status categories but not the form of each (pass/fail, counts, remediation items) or the error case for a missing attempt. For a read-only status tool with strong annotations this is adequate but has clear gaps.

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 75%, with workspaceId and idempotencyKey both documented inline, so the baseline of 3 applies. The description adds no parameter-level detail of its own — it never mentions workspaceId or explains that outputFormat toggles markdown vs json.

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?

Specific verb ('Return') plus a clearly scoped resource: active-probe, real-page, and remediation status for the latest activation attempt. The three reported facets make the tool's output domain unambiguous. It does not, however, distinguish itself from nearby status siblings such as get_sulvo_revenue_onboarding_status, get_sulvo_signup_status, or run_sulvo_activation_preflight.

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?

'Latest activation attempt' implies the tool is called after an activation submission, but the description never states that precondition nor names any alternative. An agent must infer from context whether this or run_sulvo_activation_preflight / get_sulvo_revenue_onboarding_status is the right check. Usage is implied, not 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds useful context that the output is instructional content spanning three CDNs plus a WordPress path, but it does not say what form the instructions take or whether they are step-by-step, code snippets, or links.

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 well-built sentences, front-loaded with what the resource is and what it covers. The terminal-avoidance clause about the WordPress plugin is mild flavor but justifies its inclusion by explaining that path.

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 instruction-retrieval tool with one optional enum param fully documented in the schema, the description is nearly complete. A hint about the returned artifact (format/length) would close the last gap, especially with no output 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 coverage is 100% — the single 'cdn' enum parameter is fully documented in the schema, including that omission returns all three options. The description adds no parameter meaning beyond that, so 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 names a specific resource (Sulvo Boost setup instructions) and enumerates its coverage (Cloudflare, AWS, Fastly, WordPress plugin), so an agent knows exactly what it retrieves. It does not, however, distinguish itself from the close sibling get_sulvo_installation_instructions, leaving overlap ambiguity.

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?

Coverage of the CDN options implies when the tool is relevant (setting up Boost), but there is no explicit when-to-use or when-not statement. Critically, it never clarifies its relationship to get_sulvo_installation_instructions, which an agent could easily pick instead.

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 description's read/return framing is fully consistent with readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so there is no contradiction. It adds the useful behavioral detail that results are pinned to the locked revision, which the annotations do not convey. It stops short of describing failure behavior when no revision is locked, or what the returned values look like.

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 the scoping constraint, with no filler. The only cost is that the second sentence is the ambiguous 'Input is empty' rather than a clarifying statement about required arguments.

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 burden of explaining what 'installation values' actually contains, and it does not — the agent has no idea what shape of data comes back. Combined with the unexplained idempotencyKey on a read-only tool and the ambiguity of 'Input is empty', several gaps remain for a 4-parameter tool with a nested object.

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?

Coverage is 75%, so the baseline would be 3, but 'Input is empty' is ambiguous and potentially misleading: it plausibly clarifies that the nested `input` object should be left empty (given the schema's vague 'Fields required by this journey action'), yet it reads as 'this tool takes no arguments' when workspaceId is in fact required. The description never mentions workspaceId, outputFormat, or idempotencyKey, so the agent must fall back entirely on 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 names a verb (return) and a resource (installation values for the locked revision), which is more than a restatement of the name. However, 'installation values' is left undefined, and there is no differentiation from adjacent siblings such as verify_sulvo_placement_installation, get_sulvo_activation_smoke_status, or get_sulvo_boost_setup. An agent can guess the intent but cannot confidently separate it from those tools.

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

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

The phrase 'for the locked revision' implies a precondition (a revision must have been locked first via lock_sulvo_placement_revision), which is a real hint about when to call it. But there is no explicit when-not guidance, no named alternative, and no statement of what happens if no revision is locked. 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the auth requirement and the dashboard path for obtaining the key, which the annotations cannot convey. It stops short of describing response shape, pagination, or rate limits, but for a read-only fetch that is a modest gap.

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

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

Front-loaded with the action and read-only status, then the prerequisite, then the scope list. It is dense but every clause carries information; the trailing enumeration is long but functional.

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 an 8-parameter tool with no output schema, the description never explains what any report type actually returns, so an agent cannot tell 'bot-scores' from 'invalid-activity' in terms of output. Auth and scope are covered, but the per-report content an agent needs to pick correctly 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 88%, so the schema already documents parameters well, including the directBidder requirement and date formats. The description's enumeration of report types restates the enum rather than adding semantics such as what each report returns or which additional params each type needs; 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 ('Fetch a Sulvo report') and immediately names the eight report types it covers, which maps directly onto the reportType enum and separates it from siblings like list_sulvo_advanced_reports or save_sulvo_advanced_report. An agent can tell this is a read-only report retrieval tool 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?

The prerequisite is explicit ('Requires SULVO_API_KEY in the server environment', plus where a publisher generates it), which is genuinely useful onboarding context. However, there is no guidance on when to choose this tool over the report-related siblings (list_sulvo_advanced_reports, get_publisher_monetization_benchmarks) and no statement of exclusions or which report type suits which question.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful signal that the stage is "backend-owned" (i.e., computed authoritatively server-side, not client state) and that the response includes a recommended action, but says nothing about caching, staleness, or the state space.

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 no filler; it lists the three return elements efficiently. It is arguably a touch too short for the amount of unstated context, but nothing in it wastes space.

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 is the only source for return semantics, and it only names three fields without explaining the possible journey stages or what a "readiness dimension" contains. For a status-read tool with two parameters this is adequate but leaves real gaps an agent would want filled.

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 only 50% (workspaceId is documented, outputFormat is undocumented in the schema), and the description mentions neither parameter. It does not clarify that workspaceId is the activation workspace handle or what markdown vs json output implies — the schema alone must carry the load.

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 concrete verb ("Return") and enumerates the payload: journey stage, readiness dimensions, and one next best action, which tells an agent this is a read-only status/projection tool. It does not explicitly say it is the Sulvo revenue onboarding status or distinguish itself from nearby siblings like get_sulvo_activation_smoke_status and get_sulvo_signup_status, so it stops 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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The agent must infer from context that this is the read sibling of start_sulvo_revenue_onboarding / set_sulvo_onboarding_journey, which is left implicit.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the returned lines are for publisher-side ownership verification, which is meaningful context, but says nothing about prerequisites (e.g., must an account exist), error behavior, or whether the lines are idempotent across calls.

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 efficient sentence with the resource stated up front and no filler. The only weak spot is the unexplained 'step 4a' label, which adds jargon rather than information for an agent that cannot see the flow diagram.

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 should clarify what the fetched lines look like or how to consume them; it only paraphrases. It also omits any hint that verification is a separate subsequent tool, leaving the agent to guess the next step in the flow.

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 carries the full burden for the two parameters, yet it mentions neither. 'userId' is undocumented (whose ID? signup session vs. account?) and 'outputFormat' (markdown/json enum) is never referenced, which matters because it changes the shape of what comes back.

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 ('fetch') and resource ('ads.txt lines the publisher must add for site ownership verification'), which is concrete enough to distinguish it from generic signup-status tools. The 'step 4a' framing situates it in a workflow, though that numbering is opaque without the surrounding flow.

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?

Implies usage inside the Sulvo signup flow ('normal signup step 4a'), giving some contextual hook. However, it never distinguishes itself from the very closely related verify_sulvo_signup_ads_txt or verify_sulvo_site_ownership siblings, nor does it say what state the user must be in before calling it.

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 cover the read-only, non-destructive profile. The description does add real context beyond them: the upstream API lacks a public approval-status endpoint, so the response is a limitation report rather than fabricated state — an important disclosure. However, it does not say what the returned payload contains or how an agent should interpret the limitation for its next step.

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 front-loaded sentences with no filler; the caveat follows the purpose statement. Slightly inefficient because the first sentence's phrase 'status capability' must be re-explained by the second.

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 describe the shape of what comes back and what userId means; it does neither. For a tool whose main value is a caveat, the agent is left unsure what it will receive and whether a successful signup can be confirmed at all.

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 carries the full burden and contributes nothing: it never explains what userId identifies (Sulvo account id, email, publisher id) nor when to choose json over the default markdown outputFormat. Both parameters are left entirely to the agent's guesswork.

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 verb+resource (return signup status) is present, but the qualifier 'capability' makes the purpose ambiguous — it reads as if the tool reports on the API's abilities rather than the user's signup state. The second sentence clarifies that it returns a limitation notice instead of approval state, which is honest but further blurs what the tool actually does versus the sibling tools like get_sulvo_revenue_onboarding_status or run_sulvo_activation_preflight.

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 condition is given for when to call this versus the many signup siblings (start_sulvo_signup, apply_for_sulvo_account, submit_sulvo_signup_documents, verify_sulvo_signup_ads_txt). The only implicit guidance is negative — that it should not be used to obtain approval state — with no alternative named for that need.

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 destructive and not read-only, but the description adds no behavioral detail beyond annotations. It does not say what existing data may be overwritten, what happens on version mismatch, or what side effects importing connected provider units has.

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 short sentences, front-loads the operation, and has no wasted wording. It is appropriately sized for a terse tool 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 destructive import with a nested freeform input object and no output schema, the description is too sparse. It names two required input fields but omits prerequisites, overwrite behavior, and the effect of expectedVersion, leaving important invocation context 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 75%, so the baseline is 3. The description usefully adds that the freeform input object requires provider and expectedVersion, which is not visible in the schema properties, but it gives no format or semantic detail for those fields.

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

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

The description uses a clear verb+resource phrase, 'Import connected provider units,' so the agent can infer the basic operation. However, it does not distinguish this tool from nearby siblings such as connect_sulvo_backup_provider or map_sulvo_placement_backup.

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 what input is required but gives no guidance on when to use this tool versus connect_sulvo_backup_provider, map_sulvo_placement_backup, or rollback_sulvo_activation. There are no prerequisites, exclusions, or workflow context.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new operational context: a server-side SULVO_API_KEY with the reports:read scope is required, which an agent cannot learn 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 short sentences with zero filler, and the resource identification comes before the prerequisite. Efficient and front-loaded.

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

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

For a read-only list with one optional param, the description covers purpose and auth but omits what a report entry looks like, whether results are paginated or ordered, and how outputFormat affects the response — and with no output schema, that burden falls on the description.

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% — the single outputFormat parameter is documented only by its enum (markdown/json/csv) and default. The description says nothing about it, but the enum values are largely self-explanatory for a low-risk optional parameter, so the gap is minor.

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?

Specific verb + resource + scope: 'List the saved Sulvo advanced reports for the account'. This distinguishes it from get_sulvo_report (single report), save_sulvo_advanced_report and delete_sulvo_advanced_report without needing the schemas, though no sibling is named explicitly.

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?

Enumeration is implied by 'list', but there is no explicit when-to-use statement and no reference to the obvious alternatives (get_sulvo_report for one report, save_sulvo_advanced_report for creating one). The agent must infer the selection rule.

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 and readOnlyHint=false, so the safety profile is carried by structured data. The description adds nothing about what locking actually does—whether it is reversible, whether an unlock path exists (no unlock sibling is listed), or what happens to in-flight edits. For a destructive, one-way-looking mutation this is a real gap.

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

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

Two short sentences, front-loaded with the action, with no filler. It is efficient but arguably over-compressed given the missing behavioral 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?

A destructive mutation with a free-form nested input object and no output schema demands more: what lock semantics mean, reversibility, failure modes when expectedVersion is stale, and the shape of the result are all absent. The description covers only the action name and two nested field names.

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 75%, so baseline is 3, but the critical 'input' property is a free-form object whose schema description is purely generic ('Fields required by this journey action'). The description rescues this by naming expectedVersion and revisionId, which is genuine added value; however it gives no types, formats, or whether those are the only permitted keys.

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 ('Lock the exact mapped revision') with a scope qualifier that distinguishes it from planning/mapping siblings like save_sulvo_placement_plan and map_sulvo_placement_backup. It never names an alternative tool explicitly, so sibling differentiation is only implicit.

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, when-not, prerequisites, or alternatives are given. An agent must infer from the 'lock' verb and the surrounding activation journey that this is a post-mapping, pre-verification step.

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 a non-read-only, destructive mutation, but the description adds no behavioral context about what gets changed, whether the operation is reversible, how version conflicts are handled, or what happens to existing placements. For a destructive mapping operation, the description should disclose far more than it does.

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 short sentences with no wasted text, and it front-loads the resource being operated on. However, the brevity leaves out critical usage and behavioral details.

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 destructive mutation with a nested input object and no output schema, the description is materially incomplete. It does not explain the mapping operation, the role of expectedVersion, or the consequences of the destructive write.

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 75%, so the baseline is 3. The description adds useful information by naming nested input fields expectedVersion, stablePlacementId, provider, and providerId, which are not described in the schema's free-form input object, but it does not explain their meaning or constraints.

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 largely restates the tool name: 'Map a display placement backup' does not explain what mapping means operationally. It does not distinguish this mutation from nearby siblings like import_sulvo_backup_units, connect_sulvo_backup_provider, or lock_sulvo_placement_revision.

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, when not to use it, prerequisites, or which sibling tool handles related backup operations. The only usage-like statement is a list of required input fields, not a selection criterion.

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=false and destructiveHint=true, and the description adds nothing about what a decision overwrites, whether decisions can be revised after saving, or how the destructive effect is scoped. The expectedVersion mention hints at optimistic concurrency but the semantics (stale-version rejection) are never explained.

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 action front-loaded and the input requirement second; nothing is wasted. It is on the edge of under-specification for a destructive mutation, but that is a completeness issue rather than 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?

For a destructive, non-idempotent-by-default mutation with no output schema and a nested free-form input, the description should say what comes back and what the edit/reject decisions actually do. Only the minimum required field names are provided, so an agent cannot predict the outcome of the call.

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's 'input' is an opaque free-form object (additionalProperties: {}), so the description's statement that it requires expectedVersion and decisions supplies information the schema genuinely lacks. It still does not explain what values 'decisions' takes or how expectedVersion should be sourced.

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 concrete verb ('Save') and enumerates the three decision types (accept, edit, reject), so an agent knows this records review outcomes rather than creating plan data. The target resource is only inferable from the tool name, and nothing distinguishes it from the close sibling save_sulvo_placement_plan.

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 is given, and no alternatives are named despite several adjacent placement tools (save_sulvo_placement_plan, lock_sulvo_placement_revision, verify_sulvo_placement_installation). The agent has to guess whether this runs before or after the plan is saved and locked.

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 and readOnlyHint=false, so the safety profile is covered. The description adds the useful outcome detail that the domain ends up in backup-only serving, but it omits whether the rollback is reversible, what happens to existing placement mappings or ad units, and whether it requires confirmation or specific permissions — significant gaps for a destructive mutation.

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 no filler. It is efficiently written, though efficiency here shades into under-specification rather than deliberate brevity, which keeps it from a 5.

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

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

This is a destructive, state-changing operation with a nested free-form `input` object, an idempotency key, and no output schema. One sentence cannot cover preconditions, blast radius (which units/placements are affected), or how to verify success afterwards, so an agent has little basis for calling it safely.

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 75%, with workspaceId and idempotencyKey documented inline, so the schema carries most of the load. The description adds nothing about the nested `input` object or the outputFormat enum, so it neither compensates for the remaining gap nor misleads. 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 state transition for a specific resource (the workspace domain goes back to publisher-owned backup-only serving), which pairs with the verb 'rollback' in the name. But 'publisher-owned backup-only serving' is internal jargon and the description never says plainly that it undoes a Sulvo activation, nor does it distinguish itself from siblings like submit_sulvo_activation_workspace or get_sulvo_activation_smoke_status.

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

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

There is no when-to-use guidance, no stated preconditions (e.g. an activation must currently be live), and no reference to any alternative tool. The agent must infer entirely from the name that this is the undo path for an activation.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the scan is free (cost disclosure) and it reports negative findings ('what it cannot'), which tells the agent the output includes gaps, not just successes. It omits latency, rate limits, and failure behavior for unreachable domains.

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 zero waste. The value proposition and scope come first, the concrete checks are listed next, and the return semantics close it out — properly front-loaded.

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

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

For a two-parameter read-only scan with no output schema, the description tells the agent what is inspected and qualitatively what comes back. What remains thin is how results are shaped and how outputFormat changes them, but that is minor at this complexity.

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 50%: 'domain' is documented in the schema, while 'outputFormat' carries only an enum plus a markdown default. The description adds no parameter-level meaning at all, but the enum and default make outputFormat largely self-explanatory, so the baseline 3 applies rather than a penalty.

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 ('scan' the publisher's agentic readiness) and enumerates the four concrete things inspected: adagents.json, taxonomy tagging, audience segments, and product/deals catalog. The 'buyer agent' framing is distinctive, but it never explicitly contrasts with the nearby run_publisher_revenue_audit or check_crawler_blocks siblings, so an agent must infer the boundary.

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?

'Free top-of-funnel scan' implies this is an early, low-cost triage step rather than a deep audit, which gives implied usage context. However there is no explicit when-to-use/when-not statement, no mention of the closest alternative (run_publisher_revenue_audit), and no stated prerequisites such as the domain needing to be live.

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, destructiveHint=false, and openWorldHint=true, so the safety and external-network profile is covered. The description adds that the evidence is 'public' and directional, which usefully signals it is an unauthenticated outside-in assessment, but says nothing about runtime cost, rate limits, or how long the collection (with optional Playwright/PageSpeed passes) takes.

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 action, no filler. The second sentence is a dense enumeration that runs long, but every item maps to an actual audit dimension the tool performs, so it earns its space.

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

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

For a tool with three nested option objects, browser/PageSpeed toggles, artifact writing, and no output schema, the description is thin on what the caller gets back — no mention of report shape, artifact generation, or that output format is selectable. It is adequate given 100% schema coverage but leaves real gaps for a heavyweight audit 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% with rich nested descriptions for domain, metrics, options, and vertical, so the schema carries the parameter burden. The description adds no parameter-level meaning beyond loosely implying PageSpeed and premium-unit dimensions exist; 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 — running a public publisher revenue-readiness screen — and enumerates the concrete dimensions audited (ad stacks, ads.txt hygiene, consent, PageSpeed, premium ad unit opportunities). That distinguishes it from adjacent siblings like get_publisher_revenue_audit_checklist or get_publisher_monetization_benchmarks, though it never names those alternatives explicitly.

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: an agent can infer it should call this when it has a publisher domain and wants a full revenue screen rather than a checklist or benchmark lookup. There is no explicit when-to-use/when-not, no prerequisites, and no routing to sibling tools such as attach_sulvo_revenue_audit or run_agentic_readiness_audit.

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, destructiveHint=false, so this is a state-touching but non-destructive call; the description adds nothing about what state it writes, what the preflight validates, whether a failure blocks activation, or how partial results are reported. The presence of an idempotencyKey parameter strongly implies mutation/retry semantics that the description never explains. With nominally rich annotations the bar is lower, but the key behavioral facts are still missing.

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 with no filler, which is good, but the compression comes at the cost of meaning — 'complete bounded' carries no informational weight for the agent.

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 non-read-only journey tool with no output schema and an opaque nested input object, the description should say what checks run, what a pass/fail looks like, and what to do on failure. None of that is present, leaving an agent unable to predict the result or recover from errors.

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 75% (just under the high-coverage baseline), and workspaceId, idempotencyKey, and outputFormat are documented inline. The description contributes nothing about these, and the nested free-form 'input' object ('Fields required by this journey action') is left entirely unexplained in both places.

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 verb ('Run') and resource ('activation preflight') are present, but the qualifiers 'complete bounded' and 'locked workspace revision' are undefined jargon that don't tell an agent what the preflight actually checks. It does not distinguish itself from siblings like get_sulvo_activation_smoke_status, submit_sulvo_activation_workspace, or rollback_sulvo_activation.

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, prerequisites, or when-not guidance. 'For the locked workspace revision' only indirectly implies it runs after lock_sulvo_placement_revision, but the agent must infer that ordering itself. No alternative tools are named.

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=false, destructiveHint=true and openWorldHint=true, so the description only needs to add context. It does so meaningfully: it discloses the required API key scope and, crucially, that output is emailed rather than returned inline — a behavioral trait an agent cannot infer from the schema. It does not explain what an update overwrites on an existing report, which is the main gap given destructiveHint=true.

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 action, then the prerequisite, then the delivery caveat. Nothing is redundant and every sentence 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?

With no output schema, the description correctly closes the biggest gap by stating that reports are emailed and not returned inline. However, for a 15-parameter, destructive, open-world mutation, it does not explain per-reportType field requirements or what an update to an existing reportId replaces, leaving real ambiguity.

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 47% across 15 parameters, so the description must compensate, but it mostly restates what the schema already says (reportType values, immediateRun vs. frequency). Parameters such as adRoots, domains, start/end, utms, timeZone, outputFormat and utmHourlyBreakdown receive no clarification, and the description does not indicate which fields are required or meaningful per reportType.

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 verb pair (create/update) and resource (Sulvo advanced report) and enumerates the three report subtypes (adUnit, dimensions, customData), which helps distinguish it from list_sulvo_advanced_reports and delete_sulvo_advanced_report. It stops short of explicitly routing the agent away from get_sulvo_report, so it is clear but not fully differentiated.

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 conveys two usage modes (run now vs. scheduled) and a prerequisite (SULVO_API_KEY with reports:write scope), which is useful context. It never states when to prefer this tool over get_sulvo_report or list_sulvo_advanced_reports, nor when an agent should update an existing report vs. create a new one.

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 annotations already state readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds little behavioral context beyond 'save': it does not explain optimistic version conflicts, idempotency behavior, why consent/runtime declarations must be true, or what happens to existing revisions.

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 short sentences with the action front-loaded and no filler. The second sentence largely points back to schema requirements, but the overall structure is efficient.

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

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

This is a complex nested mutation with no output schema and several workflow-sensitive siblings. The description omits prerequisite steps, conflict handling, idempotency guidance, and why the attestations matter, leaving it materially incomplete 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 coverage is 75%, so the schema already documents most parameters. The description repeats that expectedVersion and payload are required, but does not add meaning such as expectedVersion being a concurrency token or explain workspaceId, idempotencyKey, outputFormat, or payload constraints.

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: 'Save a placement revision.' It is clear what the tool does, but it does not distinguish this tool from nearby siblings such as lock_sulvo_placement_revision or run_sulvo_activation_preflight.

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 only a bare input requirement ('expectedVersion and payload') and does not say when to use this mutation versus preflight, locking, review, or rollback tools. There are no explicit exclusions, prerequisites, or workflow 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 declare a destructive mutation with readOnlyHint=false and destructiveHint=true. The description adds useful context that expectedVersion is required, implying optimistic concurrency, but it does not explain destructive consequences or return 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?

The description is two tight sentences with no filler, and the required input constraints are front-loaded for quick parsing.

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 destructive mutation with a nested input object and no output schema, the description covers key input requirements but says nothing about return values or the effect of changing intake answers. It is minimally adequate but leaves gaps.

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 75%, but the nested input object is largely undocumented in the schema. The description compensates by naming expectedVersion and the at-least-one-of fields mode, goal, and retagTiming, which is meaningfully beyond the structured 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 action and resource: setting or changing journey intake answers on a workspace. It is clear what the tool does, though it does not explicitly distinguish itself from related onboarding/status siblings.

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 by saying it sets or changes intake answers and gives input prerequisites. However, it does not say when to choose this over related tools such as starting onboarding or checking status.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description is consistent with that ('create or resume' is a non-destructive mutation) but adds little beyond it — nothing about idempotent resume semantics, permissions, or side effects on an existing workspace.

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 action and its qualifying precondition. Nothing redundant and nothing 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 six-parameter mutation with no output schema, the description leaves the agent under-informed: it does not say what the workspace contains, what happens on resume versus first creation, which optional parameters matter, or what the caller gets back. The 50% schema coverage gap is not compensated.

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?

Six parameters with only 50% schema description coverage; 'domain', 'outputFormat', and 'auditArtifactId' are undocumented in both places. The description's mention of the 'public audit' weakly hints that auditArtifactId ties to a prior audit, but it never explains domain, outputFormat, or how the resume behavior interacts with the required domain key.

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 concrete verb pair and object: 'Create or resume a verified-account activation workspace'. That is specific enough to distinguish a start/resume action from siblings like submit_sulvo_activation_workspace or get_sulvo_revenue_onboarding_status, though it never names those siblings explicitly.

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 clause 'after the public audit and signup steps' establishes a clear prerequisite ordering, which is real usage context an agent needs. It stops short of exclusions or naming an alternative when a workspace already exists in a later state.

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 description adds useful context beyond the annotations by saying the lead is unauthenticated and that domain verification occurs. However, it does not explain what verification entails, what side effects or failure modes exist, or why the operation is marked destructive, so it only partially enriches the annotation-provided safety profile.

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

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

The description is a single front-loaded sentence that identifies the step and the two core actions without filler. It is appropriately compact and wastes no words.

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

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

For a state-changing, open-world tool in a crowded family of signup and onboarding siblings, the description omits prerequisites, expected outputs, next steps, and how it differs from similar entry points. The annotations cover safety signals, but the description does not provide enough workflow context for an agent navigating this multi-step domain.

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 75%, with descriptions for domain, email, and monthlyPageviews; only outputFormat lacks a schema description but is a self-explanatory enum. The tool description adds no parameter-level meaning beyond what the schema already provides, so a 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 verb and resource: it verifies the publisher domain and creates an unauthenticated signup lead as step 1 of signup. This distinguishes it from later-stage siblings like create_sulvo_signup_account or submit_sulvo_signup_documents, though it does not explicitly separate it from apply_for_sulvo_account.

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 'Run normal Sulvo signup step 1' implies it should be used at the beginning of the standard signup flow, but there are no explicit conditions for when not to use it or how it relates to similar siblings such as apply_for_sulvo_account or start_sulvo_revenue_onboarding.

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 and readOnlyHint=false, so the safety profile is known. The description adds no behavioral context about what submitting actually changes, whether it is reversible, or what happens on success or failure, leaving it largely redundant with 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 short sentences, front-loaded with the action. There is little waste, though the description is terse to the point of under-specifying the operation.

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

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

This is a destructive mutation with no output schema and a nested free-form input object, yet the description never explains what a "proven revision" is, what the operation does to the workspace, or how it fits with preflight and rollback siblings. The annotations carry the safety signal, but the workflow context is substantially 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 75%, and the nested input object has no defined properties, so naming expectedVersion and revisionId in the description is genuinely useful beyond the schema. It still omits their value types and formats, but it supplies the required nested keys an agent must provide.

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 object ("Submit the proven revision"), but "proven revision" is undefined and it never mentions the activation workspace from the tool name. It does not distinguish this from siblings like lock_sulvo_placement_revision or rollback_sulvo_activation.

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 that the input requires expectedVersion and revisionId. It does not say when to call this versus preflight, lock, or rollback tools, nor does it state prerequisites or when not to use it.

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, openWorldHint=false, destructiveHint=false, and the description reinforces this by stating the connector has no access to the user's local files. That added constraint is useful behavioral context beyond the annotations, though no further detail on the explanation's contents is given.

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, front-loaded with the tool's real function and immediately following with the alternative location for submission. No waste.

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

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

For a zero-parameter, no-output informational tool, the description covers what it does and where the real submission flow lives. It could say a bit more about what the explanation covers, but nothing essential is missing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete (100% coverage). Baseline 4 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 purpose: it explains how to complete Sulvo signup document review, and clarifies what the tool is not (a submission mechanism). This distinguishes it from the many Sulvo signup siblings. The only friction is that the name 'submit_sulvo_signup_documents' implies an action the description explicitly disclaims, so the stated purpose is clear but at odds with the name.

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 tells the agent where the real action happens ('upload monthly earnings proof or connect an AdSense account' in Sulvo onboarding) and that this connector is not the path, effectively routing the agent away from misuse. It does not spell out the positive trigger ('call this to get instructions'), but the context is clear enough.

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 and readOnlyHint=false, so the mutation profile is known; the description does not contradict that. It adds useful scope context (submits a bare site with no tags, approval limited to ads.txt ownership) but says nothing about side effects of submission, reversibility, or what approval changes on the account.

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 compact sentence with the core action front-loaded and no filler. Slightly dense jargon ('Retag-after-approval journeys') costs a bit of readability but nothing is redundant.

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 destructive, nested-input mutation with no output schema, the definition covers the action and the key required input field but leaves the approval workflow, side effects, and expected outcomes unexplained. Adequate but with clear gaps for an agent deciding whether/how to invoke it.

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 75%, but the critical nested 'input' object has no documented properties (additionalProperties: {}), so the description's note that 'Input requires expectedVersion' supplies information the schema omits entirely. workspaceId, outputFormat, and idempotencyKey are already covered by 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 ('submit the bare site for Google approval') and adds a scope qualifier ('ads.txt ownership only, no tags'). The 'Retag-after-approval journeys' prefix is jargon that presumes context the agent may not have, and it does not distinguish itself from siblings like submit_sulvo_activation_workspace or verify_sulvo_site_ownership.

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?

'Retag-after-approval journeys' and 'ads.txt ownership only, no tags' imply a narrow use case, giving some context about when this applies. However, no alternative or exclusion is named, so the agent must infer when to pick this versus the several other submit_* siblings.

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=false and destructiveHint=true, but the description does not explain what is destructive, whether existing company data is overwritten, or what permissions/state are required. It adds only that the information is optional and tied to a pending signup, leaving the most important behavioral trait unexplained.

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

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

The definition is a single front-loaded sentence with no filler. It is efficient, though slightly jargon-heavy with "normal Sulvo signup step 3" and thin on operational detail.

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

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

This is a mutation tool with destructiveHint=true, 10 undocumented parameters, and no output schema, yet the description does not clarify what is saved, what may be overwritten, or what the result contains. It is materially incomplete for an agent to invoke safely.

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

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

Schema coverage is 0% across 10 parameters, so the description must compensate. It hints that the fields are "optional company information" but does not explain the required userId or distinguish fields like website, employeeCount, monthlyAdRevenue, or outputFormat.

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

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

The description uses a specific verb ("save") and resource ("optional company information") and scopes it to "pending Sulvo signup" step 3. That distinguishes it from siblings like submit_sulvo_signup_documents or create_sulvo_signup_account, though it does not explicitly contrast itself with them.

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

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

"Run normal Sulvo signup step 3" implies the context in which this tool is used, but it does not name alternatives, prerequisites beyond a pending signup, or what to do if the agent wants to skip optional company information. Usage is suggested rather than explicitly bounded.

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, destructiveHint=false, openWorldHint=false, but the description adds no context about what state verification writes, what happens when containers fail, or whether the operation is repeatable. 'Verify' conventionally reads as a safe check, so the omission of any mutation behavior leaves the agent with a misleading mental model, even though it is not a strict contradiction of 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?

A single sentence, front-loaded with the verb, with no filler. It is appropriately short but so compressed in domain jargon that brevity comes at the cost of comprehension.

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 should explain what a verification result looks like (pass/fail per container? a status code?) and which tool produces the 'locked revision' it verifies -- neither is covered. Given the opaque nested 'input' parameter and the non-read-only annotation, the definition is too thin for an agent to call it reliably.

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 75%, and the one parameter that matters most -- the nested 'input' object with additionalProperties {} -- is undocumented in both schema and description. The description never mentions workspaceId, outputFormat, idempotencyKey, or what fields belong in 'input', so it does not compensate for the coverage gap on a nested-object 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?

The verb 'Verify' and its objects ('stable placement container', 'inert loader', 'locked revision') are stated, so it is more than a tautology. But the nouns are opaque internal jargon, and the tool is not distinguished from the several sibling verifiers (verify_sulvo_site_ownership, verify_sulvo_signup_ads_txt, get_sulvo_activation_smoke_status), so an agent cannot tell what verification actually produces or where it fits in the sequence.

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, no prerequisite (e.g., 'after lock_sulvo_placement_revision'), and no alternative named. The phrase 'for the locked revision' hints at a preconditions but never states that the revision must already be locked or what to do otherwise.

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 destructiveHint=false, so the description's 'verify' framing sits in mild tension with a non-read-only operation — running a signup step evidently records progress, which is never explained. With no output schema, the description should say what a failed verification returns (missing lines, remediation hints) and where the result is stored, but it says nothing.

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 the workflow step and the verification target front-loaded. No filler, though it is arguably too terse given the transparency gaps.

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 verification tool with no output schema and zero parameter documentation, the description omits the essentials: what a pass/fail looks like, what happens when the ads.txt lines are absent, and how userId maps to the domain being checked. Annotations cover only the safety profile, leaving the rest unanswered.

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 carries the full burden, yet it explains neither userId nor outputFormat. Worse, it refers to 'the submitted publisher domain' although no domain parameter exists — the only input is userId — which can mislead an agent about what it must supply.

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?

Specific verb (verify) plus specific resource (required Sulvo ads.txt lines for the submitted publisher domain) and a workflow anchor ('signup step 4b'). It is reasonably distinct from get_sulvo_signup_ads_txt, though it never names that sibling to sharpen the boundary between 'verify' and 'get'.

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 'normal Sulvo signup step 4b' implies when in the onboarding sequence this belongs, but there is no explicit when-not guidance and no mention of the obvious alternative get_sulvo_signup_ads_txt or sibling verify tools like verify_sulvo_site_ownership. Usage is implied 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?

Annotations declare readOnlyHint=false, so this 'verify' call actually mutates state, and the description never explains what it writes or whether a failed verification persists anything. The idempotencyKey parameter hints at retryable mutation, but the description offers no failure semantics, no permission requirements, and no indication of what evidence must already be in place.

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 tight sentence with no filler and the verb front-loaded. It is efficient, though the brevity borders on cryptic given the unexplained 'inert' terminology.

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 state-mutating verification tool with a nested untyped input object and no output schema, the description should explain what gets checked, what happens on partial evidence, and what a success looks like. None of that is present, leaving significant gaps.

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 workspaceId is documented in the schema, but the nested 'input' object is a free-form bag described only as 'Fields required by this journey action' at 75% coverage. The description does not name a single expected input field, so an agent cannot construct a valid call without trial and error.

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 verb 'Verify' and the resources 'ads.txt and Sulvo head-tag ownership evidence' are named, so the general intent is discernible. However, the phrase 'inert Sulvo head-tag' is unexplained jargon and the description never states whose ownership (publisher site vs. signup record) is being proven, leaving it weakly separated from siblings such as verify_sulvo_signup_ads_txt and verify_sulvo_placement_installation.

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 statement of when this tool should be called, no prerequisites (e.g., must a workspace be submitted first?), and no mention of the near-identical sibling verify_sulvo_signup_ads_txt as an alternative. The agent must infer the workflow position entirely from the name.

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