audit

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

Annotations declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the safety profile is already covered; the description usefully adds the auth model (works without login/API key/OAuth). It never explains why this is flagged destructive or what side effect the lead submission produces, which is the gap annotations cannot fill.

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

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

Two sentences, front-loaded with the action and its auth scope, and the second sentence carries the sequencing constraint. Minimal waste, though the audit-tools aside is slightly tangential to invoking this tool.

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

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

For an unauthenticated mutation with no output schema and destructiveHint=true, the description covers auth and downstream sequencing but omits what a successful submission returns, whether it is idempotent, and how to check status afterwards (get_sulvo_signup_status exists but is not referenced). Adequate, with 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 coverage is 67% (moderate, not high enough for the free baseline 3) and the description explains no parameters at all. The undocumented outputFormat enum and the accepted domain format are left entirely to the schema, so the description adds nothing beyond structured 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?

States a specific verb+resource ('submit an unauthenticated Sulvo account application lead') and names the transport ('current signup API'), which is enough to distinguish it from read-only audit siblings. It does not, however, differentiate itself from near-neighbors like create_sulvo_signup_account, start_sulvo_signup, or submit_sulvo_signup_documents, leaving the exact boundary of 'application lead' ambiguous.

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 (unauthenticated, no login/API key/OAuth) and a sequencing rule ('ad-unit generation should wait for Sulvo account approval'), which is real when-to-use guidance. It stops short of naming which sibling to call instead for the account-creation vs. document-submission path.

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 risk is signaled structurally. The description adds the constraint that the artifact must be 'current' and names an expectedVersion field, which hints at optimistic-concurrency behavior, but it does not say what is overwritten, whether the prior attachment is replaced, or what authorization is needed.

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 no filler; the action is front-loaded and the input hint follows. Slightly more could be said about the input bag without bloating it.

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 an opaque nested input object, no output schema, and no usage guidance, the description covers only the minimum. It tells the agent what fields to supply but not the surrounding prerequisites or consequences of a successful attach.

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 schema leaves the nested 'input' bag completely opaque. The description compensates by naming expectedVersion and auditArtifactId, which live inside that undocumented bag, so it adds real information beyond the schema — though it does not explain the semantics of expectedVersion (locking/conflict behavior).

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 ('Attach') and a specific resource ('current public revenue audit artifact'), so an agent knows this mutates state by linking an artifact rather than generating one. It does not, however, distinguish itself from close siblings such as 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?

No indication of when this should be used, what prerequisite state must exist, or which sibling to choose instead. The word 'current' hints that a fresh artifact is required, but that condition is never made explicit.

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/openWorld/non-destructive, but the description adds genuinely new behavior: it performs a live probe against the site, the probe can itself trigger a WAF 403, and results carry confidence tiers requiring verification. That is meaningful context beyond the structured hints, though the probe's request footprint is not quantified.

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, zero filler, with the core check front-loaded and the confidence-tier semantics following immediately. Every sentence earns its place.

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 usefully explains what the result tiers mean (fail vs warn vs needs verification), which is the critical return-value context. The only gap is the undocumented outputFormat parameter, which an agent must guess at from the enum alone.

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 in the schema while the 'outputFormat' enum has no description anywhere. The description adds no parameter-level meaning (no domain format constraints, no mention of output format options), so it does not compensate for the coverage gap.

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

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

States a specific verb (check), resource (robots.txt / live probe crawler blocks) and target actors (AmazonAdBot / Google ad crawlers), which clearly separates it from the Sulvo management siblings. An agent knows exactly what it inspects 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 description implies the scenario (verifying ad-crawler access) and explains how to interpret outcomes (high-confidence fail vs medium-confidence warn), but never states when to run this vs alternatives or prerequisites such as needing a live reachable domain. Usage is inferable rather than explicit.

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 safety is covered. The description adds real behavioral detail beyond that: the 14-day expiry window used for flagging, the specific failure classes detected, and the rule about not writing a finding for fully unreachable hosts.

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 core purpose and detection list, followed by one clarifying exclusion. No filler or repetition of the tool name.

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

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

With no output schema, the description carries the burden of explaining results, and it does describe what findings are produced (and the one case where none is produced). It does not describe output format or result shape, but for a diagnostic check whose annotations confirm a safe read, this is largely sufficient.

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 required 'domain' param is documented in the schema, and the optional 'outputFormat' enum is self-describing via its enum values. The description adds no parameter-level information (formatting behavior, accepted domain forms), so it does not compensate for the remaining coverage gap. Baseline 3 is appropriate.

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

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

The description names a specific verb (check) and resource (publisher domain HTTPS/certificate) and enumerates exactly which conditions it detects: expired/untrusted/hostname-mismatch certs, HTTPS down, non-upgrading HTTP, and certs expiring within 14 days. This makes it clearly distinguishable from sibling checks like check_crawler_blocks.

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 operational scope, including an explicit negative condition ('Does not write a finding when both HTTP and HTTPS are unreachable'), which tells the agent when the tool returns nothing. However, it names no alternative tool or the broader workflow context in which a domain check belongs.

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, openWorldHint=false, so safety is covered. The description adds the required provider value but does not explain what returning the URL accomplishes (does it initiate OAuth, persist a connection, expire?), leaving behavioral intent thin for a non-read-only 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 crisp, front-loaded sentences with no filler. It is lean but arguably terse for the tool's complexity, which slightly caps it below 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?

There is no output schema, so return-format explanation isn't required, but the returned URL is the entire payload and the description never clarifies its purpose or lifecycle. Combined with the undocumented nested input, the definition is adequate but leaves meaningful 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 undocumented (additionalProperties only). The description compensates by telling the agent to set 'provider' to gam or adsense inside that object, adding real meaning 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 ('Return the GAM or AdSense authorization URL'), so the agent knows this yields an auth URL for a backup provider. It does not, however, distinguish this from adjacent siblings like map_sulvo_placement_backup or import_sulvo_backup_units.

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 scopes the tool to GAM/AdSense backup-provider connection via the required 'provider' value, which implies when to use it. It gives no explicit when-not guidance or alternatives among the many sibling tools.

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 the mutation/no-open-world/non-destructive profile, and the description usefully layers on auth requirements (SULVO_API_KEY with inventory:write scope, never an argument), how the key is minted, and a hard precondition that the account must be approved or the backend rejects the call. This is meaningful behavioral context beyond the annotations, though it says nothing about idempotency or duplicate-creation 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?

Purpose is front-loaded in the first sentence, followed by prerequisites and the return value in a logical order with no filler. The dashboard key-minting detail is slightly procedural and human-oriented, keeping it just short of maximally tight.

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

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

For a 7-parameter mutation tool with nested objects and no output schema, the description covers the key missing pieces: auth, the approval precondition, and what is returned (unit id and container root). It is close to complete, with only the sibling-distinction and idempotency gaps remaining.

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 parameter meaning, including the size/type interaction and default outputFormat. The description adds no parameter-level detail beyond that, making the baseline 3 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?

States a specific verb and resource ('Create a Sulvo ad unit') plus a scope qualifier ('for an approved publisher'), so the core action is unambiguous. However, it does not distinguish this generic ad-unit creator from overlapping siblings like create_sulvo_auto_sticky_units and create_sulvo_interstitial_units, leaving the agent to guess when this one 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?

It gives real prerequisites (write-scoped key, approved account), which implies the context in which the tool works, but never says when to prefer this over the specialized sibling creators. There are no explicit exclusions or alternative routing, so usage is only implied.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, identifying this as a non-destructive write operation. The description adds genuinely useful context beyond the annotations by naming the required credential and its scope (SULVO_API_KEY with inventory:write). It does not, however, describe idempotency, error behavior, or what happens to duplicate units.

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 concise sentences, front-loaded with the action and followed by the prerequisite. Every sentence earns its place, though the second sentence could be tightened slightly.

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 write tool with no output schema, the description covers the auth requirement but omits return value expectations, response shape, and the distinction from sibling creation tools. Adequate but with clear gaps an agent would otherwise have to guess at.

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 carry schema descriptions and constraints, while outputFormat has none. The description adds no parameter-level detail, so the schema does the heavy lifting. A baseline 3 is appropriate given the moderate coverage.

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 Sulvo auto-sticky ad units'), which is clear enough on its own. However, it does not distinguish itself from sibling creation tools like create_sulvo_ad_unit or create_sulvo_interstitial_units, so an agent cannot tell from the text alone which creation tool applies to a given request.

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 an approved publisher' implies a precondition (the publisher must already be approved), which is useful context. But it gives no explicit when-to-use guidance or routing against the sibling ad-unit creation tools, leaving the selection logic to inference.

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

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

Annotations already declare this is a non-read-only, non-destructive, closed-world operation. The description adds useful behavioral context by specifying that units are tagless and that SULVO_API_KEY with the inventory:write scope is required in the server environment, though it does not cover return behavior or any post-creation effects.

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 tightly written sentences lead with the core action and immediately follow with the key prerequisite. There is no redundant restatement of the title or annotations, and every clause carries useful information.

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

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

The description covers the critical auth requirement and publisher approval prerequisite, and annotations address the safety profile. However, with no output schema and no description of the outputFormat parameter or the expected return structure, it is only minimally complete for a create operation.

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 67%: domain and adTypes are documented in the schema, but outputFormat has no description in either the schema or the tool description. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 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?

States a specific verb (Create), resource (Sulvo interstitial ad units), and distinguishing qualifier (tagless) for an approved publisher. It differentiates from generic sibling create_sulvo_ad_unit and create_sulvo_auto_sticky_units by naming the exact unit type, though it does not explicitly contrast with those alternatives.

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

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

The description gives the prerequisite context of an approved publisher and the required API key scope, which implies when the tool is applicable. However, it does not explicitly say when to use this tool versus sibling creation tools such as create_sulvo_ad_unit or create_sulvo_auto_sticky_units, leaving alternative selection to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the write/open-world profile is covered. The description adds the useful fact that the account is created in a 'pending' state and that a password is a backend prerequisite, but it does not say whether re-invocation duplicates an account, what happens on failure, or how it affects an existing signup.

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 its position in the flow, with the password caveat placed where it is needed. No filler, though the second sentence is doing parameter work that belongs elsewhere.

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 12-parameter mutating tool with 25% schema coverage and no output schema, the description covers only the action and one required input. It does not describe the resulting account state, identifiers an agent would need downstream, or the meaning of the untracked parameters, leaving substantial 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?

Only 25% of the 12 parameters carry schema descriptions, so the description is expected to compensate, yet it only reinforces the password requirement already stated in the schema and mentions no semantics for domain, email, name fields, monthlyPageviews, or the UTM/mixpanel tracking 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?

States a specific verb and resource ('create the pending Sulvo user/account') and situates it as step 2 of the normal signup flow. This distinguishes it from start_sulvo_signup (step 1) and submit_sulvo_signup_documents without needing the schema, 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?

'Run normal Sulvo signup step 2' implies the position in the flow and notes the account must exist before ads.txt and review steps. However, no alternative is named and no when-not condition (e.g. resuming versus restarting a signup) is given, so routing is inferred 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 destructiveHint=true and readOnlyHint=false, so the description's deletion semantics are partly redundant; however it adds genuinely new operational context — the required SULVO_API_KEY with inventory:write scope and server-side ownership enforcement. It does not explicitly say the deletion is irreversible, which would have earned a 5.

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

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

Three compact sentences, front-loaded with the action and scope, then the auth requirement. No filler 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 single-parameter deletion tool with annotations covering the safety profile and no output schema, the description covers action, ownership semantics, and credential/scope requirements. Nothing an agent needs to invoke it 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 description coverage is 100% and the single adId parameter is fully documented in the schema, so the description's 'by id' adds nothing beyond it. Baseline 3 applies when the schema carries the parameter burden.

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

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

The description names a specific verb and resource ('Delete a Sulvo ad unit by id') and adds a scoping constraint ('for an approved publisher'). This clearly distinguishes it from the sibling create_sulvo_ad_unit and the unrelated delete_sulvo_advanced_report without needing either 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?

It states the conditions for use: the publisher must be approved and the API key's account must own the unit. There is no explicit 'when not to use' or named alternative, but the preconditions are concrete enough that an agent knows when invocation will fail.

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 genuine value the annotations don't carry: the required SULVO_API_KEY with reports:write scope. It does not explicitly state irreversibility, but destructiveHint already signals that.

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 operation front-loaded and the auth requirement second. No wasted 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 destructive single-parameter tool with no output schema, it covers purpose, target, and the auth prerequisite. A brief note on irreversibility would make it fully complete, but nothing essential for correct invocation is missing.

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

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

Only one parameter (reportId) with 100% schema description coverage, so the schema fully documents it. The description adds no format or id-source detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb ('Delete') and resource ('saved Sulvo advanced report'), scoped by id. This cleanly distinguishes it from save_sulvo_advanced_report and list_sulvo_advanced_reports without needing to name them.

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

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

The description implies when to use it (removing a saved report) but offers no explicit when/when-not guidance or alternatives. The prerequisite (API key/scope) is stated, which helps, but routing guidance against siblings is absent.

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 this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds the nature of the returned content (yield and CPM benchmarks), but discloses nothing further about data sourcing, freshness, or coverage. With annotations covering safety, a 3 is appropriate.

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 resource and comparison target front-loaded. No filler or redundancy, though it is not quite maximally tight given the parenthetical stack list.

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, but the description names what is returned (comparative yield and CPM benchmarks) and the unit of comparison (vertical, standard stacks vs. Premium Ad Units). This is sufficient for a one-parameter read-only lookup, leaving only minor gaps about return shape.

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 is fully documented, including its default. The description reinforces 'by publisher vertical' but adds no format or behavioral detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (Get) and resource (comparative yield and CPM industry benchmarks) and scopes it by publisher vertical. It clearly conveys the comparative intent against standard stacks. It does not need to differentiate from siblings since none of them provide benchmark data.

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 purpose clause 'to compare standard stacks (AdSense and managed wrappers) against Sulvo Premium Ad Units' implies when an agent would reach for this tool, but there is no explicit when/when-not guidance and no named alternative. Usage is inferable rather than stated.

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

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

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, and openWorldHint=false, so the safety profile is covered. The description adds the useful constraint that results pertain only to the 'latest' activation attempt (not historical runs), but says nothing about freshness, polling cadence, or what a 'remediation' status implies is actionable.

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 resource scope front-loaded and zero filler. Slightly dense with undefined jargon ('active-probe', 'real-page'), but no wasted 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?

With no output schema, the description carries the burden of describing what is returned, and it only gestures at three status categories without indicating shape, granularity, or how to interpret failure/remediation values. Combined with the missing usage guidance, this leaves meaningful gaps for a journey-status 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 75%: workspaceId and idempotencyKey are both documented in the schema, and outputFormat is a self-evident enum. The description adds no parameter-level meaning beyond that, which is acceptable given the high coverage, 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?

The description states a specific verb ('Return') and enumerates the resource content: active-probe, real-page, and remediation status for the latest activation attempt. This is far more specific than a tautology, though it does not explicitly differentiate itself from siblings like run_sulvo_activation_preflight 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?

There is no statement of when to call this tool versus alternatives, no prerequisites, and no mention of the preflight/rollback/submit siblings that occupy adjacent workflow positions. The agent must infer that this is a post-activation polling step purely from the name.

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, destructiveHint=false, so the safety profile is covered. The description adds that it covers multiple CDNs and a WordPress plugin, which is useful context, but does not detail output format or how the instructions are delivered.

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-crafted sentences, front-loaded with the purpose and followed by the scope, with zero filler. Every clause earns its place.

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

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

For a zero-required-parameter, single-enum-parameter read-only retrieval tool, the description is adequate but leaves gaps: it doesn't clarify how instructions are returned (text, links, steps), and doesn't differentiate from the sibling get_sulvo_installation_instructions. Given no output schema, more detail on the return format would help.

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

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

Schema coverage is 100%, so the single parameter (cdn) and its enum are fully documented in the schema. The description adds marginal value by noting the CDN options and the WordPress alternative, but doesn't expand on parameter behavior beyond what's already in the schema.

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

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

Clear verb+resource: retrieves setup instructions for Sulvo Boost, with a specific definition of the feature (first-party serving from publisher's own CDN that recovers ad-blocked impressions). The distinction from the sibling get_sulvo_installation_instructions is implied by naming this feature, though not explicit.

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

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

Usage is implied by the description – you call it when you need setup instructions for Sulvo Boost. However, it does not state when to use this vs get_sulvo_installation_instructions or other setup-related siblings, which is a notable gap given many similar tools in the environment.

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 closed-world, so the safety profile is covered. The description adds only the 'locked revision' precondition, which is useful, but omits what is returned, whether the lock must exist first, and any auth/rate-limit behavior; 'Input is empty' also conflicts with the required workspaceId parameter.

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 primary action front-loaded and no padding. The second sentence is terse but its ambiguity with respect to the required workspaceId slightly weakens it.

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' look like, and it does not. For a tool whose output is the whole point, an agent cannot anticipate the return shape or how to use it alongside the lock/verify siblings.

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 workspaceId, outputFormat and idempotencyKey already documented in the schema, so the baseline is 3. The description's 'Input is empty' may intend to clarify that the nested input object takes no fields, but it adds no syntax or format detail and reads as misleading about the required parameter.

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 ('Return') and resource ('installation values'), and the name anchors it as installation instructions. The qualifier 'for the locked revision' signals a state dependency that helps distinguish it from the verify_* and status siblings, though it never names an alternative 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?

No when-to-use guidance and no routing versus siblings such as verify_sulvo_placement_installation or get_sulvo_activation_smoke_status. 'Input is empty' is the only usage hint, and it is ambiguous because the schema actually requires workspaceId.

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; the description corroborates this and adds material context the annotations do not carry — the required environment credential and where a publisher obtains it. It stops short of describing rate limits, pagination, or returned shape, so it is good but not exhaustive.

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

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

Two sentences, front-loaded with the verb, read-only nature, and credential requirement before the report-type list. The trailing enumeration is dense but earns its place by signalling coverage; no filler sentences.

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

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

For an 8-parameter read-only report tool with no output schema, the description supplies auth prerequisites, read-only confirmation, and full report-type coverage. The only meaningful gap is that the default outputFormat of markdown (and the available return formats) is never mentioned.

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 88%, so nearly every parameter is already documented in the schema, including the directBidder requirement and date formats. The description's reportType enumeration and bidder note largely restate the enum, adding minimal meaning beyond structured fields. Baseline 3 applies for high coverage.

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

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

States a specific verb+resource ("Fetch a Sulvo report") and immediately scopes it as read-only, then enumerates the eight report types it covers. This separates it from write-oriented siblings like save_sulvo_advanced_report and list_sulvo_advanced_reports, though it never names a sibling 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?

Gives a prerequisite (SULVO_API_KEY, with where to generate it) and notes that directBidder is required for direct-bidder-analysis, which is useful usage context. However it never states when to pick this tool over siblings such as list_sulvo_advanced_reports or get_sulvo_revenue_onboarding_status, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context with 'backend-owned', signaling the stage is server-computed and not client-writable, but says nothing about return format, volatility, or auth expectations. Moderate added value against an already-documented 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?

A single tight sentence with the returned content front-loaded and zero filler. It is appropriately sized, though the extreme brevity is what leaves the other dimensions thin.

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's enumeration of the three returned components (stage, readiness dimensions, next best action) carries the return-value burden and does so adequately. However, with no usage guidance and half the parameters undocumented, an agent still lacks enough to invoke this confidently in context.

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 50%: workspaceId is documented (including that it comes from the start or status tool), but outputFormat has no description beyond its enum and default. The description supplies no parameter meaning at all, so it fails to compensate for the uncovered half. The self-explanatory enum/default on outputFormat is the only thing keeping this above a 1.

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 pairs a clear verb ('Return') with a specific resource set: the journey stage, readiness dimensions, and next best action for the revenue onboarding flow. An agent can distinguish this read-status tool from start_sulvo_revenue_onboarding and set_sulvo_onboarding_journey. It stops short of naming any sibling explicitly, so it earns a 4 rather than 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 statement of when to call this versus alternatives such as get_sulvo_activation_smoke_status or set_sulvo_onboarding_journey, and no preconditions are given. Usage must be inferred from the name alone. This is the definition's weakest area.

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 structurally. The description adds that the returned lines are what the publisher must add for ownership verification, but says nothing about return format, whether the value is cached, or if it changes between signup steps.

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 the action stated first and no filler. It is efficient, though the 'step 4a' fragment is unhelpful internal jargon that consumes space without informing the caller.

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 must carry return-value semantics; it only vaguely says it fetches ads.txt lines. Combined with 0% parameter coverage and no stated prerequisites or failure modes, an agent lacks enough to call this correctly in the signup 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% and the description never mentions userId or outputFormat. With two undocumented parameters — including a required userId and an enum with a default — the description fails to compensate for the coverage gap, so an agent gets no added meaning about which user identifier to pass.

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) and frames it as the fetch half of the signup verification flow, which distinguishes it from verify_sulvo_signup_ads_txt. The 'step 4a' internal reference is opaque and adds no external meaning, but the core action is unambiguous.

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

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

Placing it as 'normal Sulvo signup step 4a' implies it is used during the signup flow, which is useful context. However, it never states when to call it versus verify_sulvo_signup_ads_txt or verify_sulvo_site_ownership, nor any prerequisites such as having started a signup.

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/openWorldHint, so the safety profile is covered. The description adds genuine value beyond them by disclosing a functional limitation: there is no public approval-status endpoint, so it reports the limitation rather than fabricating approval state. That is meaningful expectation-setting, though it does not cover response shape or failure behavior.

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

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

Two sentences, front-loaded with the purpose and immediately clarifying the limitation. No filler or redundancy. Slightly awkward phrasing ('signup status capability') 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?

For a simple read-only status check whose annotations cover safety, the description conveys the essential caveat about missing approval data. But with 0% parameter coverage and no output schema, it leaves the agent without any sense of the return shape or the role of outputFormat, so it is only minimally complete.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. It never mentions the required userId or the outputFormat enum, so it fails to compensate for the documentation gap. A read-only status tool with two undocumented parameters warrants a low score here.

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

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

The description states a specific verb and resource ('Return the current signup status capability') and, unusually, discloses that the tool cannot actually resolve approval state. That is clear enough to understand what the tool does. It does not, however, distinguish itself from the many signup-domain siblings (e.g. get_sulvo_revenue_onboarding_status, verify_sulvo_signup_ads_txt), preventing 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?

Usage is only implied: the tool exists to check signup status capability, and the note about the missing endpoint warns the agent not to expect approval state. No explicit 'use when' or routing to an alternative sibling is given, so this sits at the implied-usage level.

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 write/destructive nature is conveyed structurally. The description adds no behavioral context: it does not say what data is overwritten, whether the operation is reversible, how the idempotencyKey should be used, or what happens to existing units.

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, front-loaded sentences with no padding; the action and the input requirement are stated up front. It is efficient, though arguably under-specified rather than concise.

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 a nested, free-form input object and no output schema, yet the description omits what the import does to existing state, preconditions, and result behavior. It is not complete enough to safely drive the operation.

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 most parameters are documented. The description adds that the opaque 'input' object requires provider and expectedVersion, which the schema does not specify (its 'input' is a free-form object). This is useful but marginally conflicts with the schema, which marks only workspaceId 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 verb ('Import') and a resource ('connected provider units'), but the resource naming diverges from the tool name (backup units) and it does not differentiate from siblings like connect_sulvo_backup_provider or map_sulvo_placement_backup. An agent can infer the general action but not how it differs from related import/connect/backup 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?

There is no guidance on when to use this tool versus the many sibling backup/connect tools, and no prerequisites or sequencing are given. Only the mention that input requires provider and expectedVersion hints at a precondition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the environment/auth requirement (API key with reports:read scope), which is genuinely useful beyond annotations, but says nothing about pagination, result limits, or ordering for a listing operation.

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

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

Two short sentences, purpose front-loaded and the auth requirement second. No filler or repetition.

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

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

With no output schema and a single optional param, the definition covers purpose and auth prerequisites adequately, but omits anything about how results are paginated, limited, or formatted, which matters for a list tool whose only knob is outputFormat.

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

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

There is one optional parameter (outputFormat with an enum of markdown/json/csv and a default), and schema description coverage is 0%. The description never mentions the output format control, so the schema is left to carry it entirely and the description adds nothing here.

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

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

States a specific verb (List) and resource (saved Sulvo advanced reports) scoped to the account. This cleanly separates it from save_sulvo_advanced_report and delete_sulvo_advanced_report, though it does not explicitly contrast with get_sulvo_report or get_sulvo_advanced_report if one exists.

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

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

Provides a prerequisite (SULVO_API_KEY with reports:read scope) which is useful context, but gives no when-to-use guidance and names no alternative sibling such as get_sulvo_report for retrieving a single report.

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 partly covered by structured data. The description adds nothing about what locking actually does, whether it is reversible, whether it blocks other writers, or what happens on version mismatch despite naming expectedVersion — a meaningful gap for a destructive operation.

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

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

Two short, front-loaded sentences with no filler, and the core action leads. It is slightly under-specified rather than padded, so brevity costs it little here.

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 and 4 parameters, the description omits the nested input contract, the effect of locking, and any failure/version-conflict behavior. An agent can identify the tool but cannot confidently construct the nested payload or predict the outcome.

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 workspaceId plus idempotencyKey are well documented in the schema. The description's real contribution is naming expectedVersion and revisionId, which are required but invisible in the schema because they live inside the undocumented nested 'input' object with additionalProperties {}. That is useful added meaning, but no format or semantics for those fields are given, so it lands at the baseline.

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

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

States a specific verb ('Lock') and resource ('mapped revision'), which distinguishes it from read-only siblings like verify_sulvo_placement_installation. But 'exact mapped revision' is jargon that leaves the scope and effect of locking ambiguous, and it never names the nearby siblings it differs from (map_sulvo_placement_backup, 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 at all: nothing says at what journey stage a caller should lock a revision, what prerequisite state must exist, or what alternative to use instead. The only usage-like content is a restatement of required inputs.

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 destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating, destructive operation. The description adds nothing beyond that: it never warns what gets overwritten, whether the mapping is reversible, or what authorization it needs, despite being a destructive write.

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, and the parameter requirement is front-loaded right after the purpose. Nothing is wasted, though the brevity is partly achieved by omitting needed context.

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

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

For a destructive, idempotency-key-bearing mutation with no output schema, the description omits the destructive consequence, the role of workspaceId/idempotencyKey/outputFormat, and any relationship to the backup import/connect siblings. It is well short of what an agent needs to call this 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?

The schema's 'input' object is opaque (additionalProperties with no declared fields), and the description names the four fields it requires (expectedVersion, stablePlacementId, provider, providerId), which is real information the schema does not supply. Remaining schema fields are documented at 75% coverage, so the description meaningfully compensates for the opaque nested object.

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 'map' plus the resource 'display placement backup' gives a rough sense of the operation, but 'map' is ambiguous (import? associate to a provider? transform?) and the description does not distinguish this from close siblings like import_sulvo_backup_units or connect_sulvo_backup_provider. It states a resource but the purpose remains only partially clear.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of the alternatives among the many sulvo_* siblings. The agent is left to infer usage entirely.

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, so the write/destructive nature is known. The description adds little beyond 'Save' and two required input names that are not defined in the schema; it does not explain what gets destroyed, whether decisions are reversible, or what happens after each decision type.

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 no filler. The action is front-loaded, though the second sentence is a terse input note that could be clearer.

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 far too sparse. It omits what the recommendations are, what the decisions do, and any consequence or return context.

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 baseline is 3. The description adds names of two nested input fields (expectedVersion, decisions) that are absent from the schema, which is helpful, but it does not explain them or cover workspaceId, outputFormat, or idempotencyKey.

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?

It states a specific action ('Save accept, edit, or reject decisions') but does not identify the resource or scope (placement recommendations) or distinguish itself from the many Sulvo siblings. The purpose is only vaguely implied by the tool name, not clarified in the description.

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 context, prerequisites, or alternatives are provided. The only clause beyond the action is 'Input requires expectedVersion and decisions,' which is an input requirement, 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the useful end-state ('publisher-owned backup-only serving'), clarifying what is destroyed. It does not state whether the rollback is reversible, what prior state is required, or whether in-flight work is cancelled.

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 sized, though its brevity relies on opaque domain jargon rather than clarifying structure, which slightly limits its usefulness.

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, no-output-schema mutation with a nested input object, the description gives the outcome but omits prerequisites, reversibility, and what the response reports. It is minimally adequate but leaves notable gaps for a high-impact operation.

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 well documented in the schema itself, so the schema carries the load. The description adds no parameter detail, and the nested 'input' object has no documented fields, but the baseline 3 applies given the high coverage.

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 ('Return ... to') and target ('workspace domain'), and the end state ('publisher-owned backup-only serving') makes clear this is a reversal. However the phrasing is jargon-dense and never uses the plain terms 'rollback' or 'activation', so an agent must map 'backup-only serving' back to the activation journey. No sibling performs a rollback, so differentiation is not strictly needed.

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 prerequisites (e.g. an in-flight or completed activation), and no mention of alternatives such as submit_sulvo_activation_workspace. The agent must infer the trigger condition 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description earns credit by disclosing what the scan actually inspects and, notably, that it returns both 'what a buyer agent would see and what it cannot,' which is meaningful behavioral context beyond the annotations.

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

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

Two tightly written sentences with zero filler. The core purpose and the list of checks are front-loaded, and the return behavior is stated last, so the agent gets the essential framing 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?

For a two-parameter, read-only scan with no output schema, the definition covers purpose, inspected artifacts, and rough return content. Safety is handled by annotations, and the only real gap is that the outputFormat parameter and the exact shape of results are not elaborated.

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 with an example, while 'outputFormat' relies only on its enum values with no description. The description adds no parameter-level detail at all, so it neither compensates for the gap nor goes beyond the schema; the self-explanatory enum keeps this at a baseline 3.

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

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

States a specific action (scan) on a specific resource (agentic readiness) and enumerates exactly what is checked: adagents.json, taxonomy tagging, audience segments, and a product/deals catalog. It is clearly scoped as a 'buyer agent' discoverability check, which conceptually separates it from the sibling run_publisher_revenue_audit, but it never names or contrasts with that sibling 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?

'Free top-of-funnel scan' implies this is the low-cost entry-point check to run first, which is useful contextual guidance. However, there is no explicit when-to-use/when-not instruction and no routing to alternatives such as the revenue audit, leaving the agent to infer the relationship between the two audit tools.

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=true, and destructiveHint=false, so safety is known. The description adds that the evidence is 'public' and 'directional', and that the screen is non-invasive; this is useful but minimal. It does not disclose whether the audit has rate limits, execution time, or how optional browser/PageSpeed collection affects 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 compact sentences that front-load the purpose and list the audited areas. It is efficient, though the parenthetical '(such as Sulvo)' is slightly promotional and could be tightened.

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

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

Given the tool's complexity (4 top-level params, nested objects, many options), no output schema, and a read-only annotation profile, the description is adequate but leaves out important context: what the output looks like (format/artifact options are schema-documented), the non-destructive nature, and how it differs from the parallel agentic readiness audit. It is minimally viable rather than complete.

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

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

Schema coverage is 100%, so parameters are already documented in the schema, including the nested metrics and options objects. The description adds no parameter semantics beyond what the schema provides, making the baseline of 3 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 clear verb and resource: 'Run a public publisher revenue-readiness screen using directional public evidence.' It enumerates the concrete dimensions audited (ad stacks, ads.txt hygiene, consent readiness, PageSpeed, premium ad unit opportunities). It doesn't distinguish itself from the other audit sibling run_agentic_readiness_audit, so it falls short of a 5.

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

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

There is no explicit guidance on when to use this tool versus alternatives like run_agentic_readiness_audit or get_publisher_revenue_audit_checklist. The description implies it is a revenue audit, but context for choosing it among 38 siblings is absent.

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 establish that this is a non-destructive, closed-world mutation, which does much of the safety work. The description adds only 'bounded' and 'locked revision' as scoping context and leaves unexplained why a preflight operation carries readOnlyHint=false, what state it mutates, or how the idempotencyKey affects retries.

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 or restatement of the title. It is efficiently written, though its brevity contributes to the under-specification seen in other dimensions.

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

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

This is a mutation tool with a nested input object and no output schema, yet the description does not say what the preflight validates, what happens on pass versus failure, or what the caller should do with the result. For an operation gating activation, that is a meaningful completeness 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 description coverage is 75%, with workspaceId and idempotencyKey well documented in the schema itself. The description contributes no additional parameter meaning and says nothing about the nested 'input' object or the markdown/json outputFormat choice, so 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?

States a verb (Run) and a resource (activation preflight) with the scoping qualifier 'for the locked workspace revision', so the general action is inferable. However, 'complete bounded preflight' is jargon that leaves the concrete effect ambiguous, and it does not distinguish itself from siblings like get_sulvo_activation_smoke_status 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?

There is no explicit when-to-use guidance, no statement of prerequisites beyond the embedded hint that the revision must already be 'locked', and no named alternatives. An agent must infer sequencing (lock, then preflight, then submit) from the sibling list alone.

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 flag destructiveHint=true and openWorldHint=true, and the description adds value beyond them by disclosing the credential requirement (SULVO_API_KEY with reports:write scope) and the out-of-band email delivery model. It does not say whether overwriting an existing report (via reportId) is reversible or what gets replaced, a gap for a destructive 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?

Three short sentences, front-loaded with the core action, followed by the credential requirement and a critical delivery note. Every sentence carries information an 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?

No output schema, but the description compensates by explaining delivery is by email (no inline return). For a 15-parameter destructive-ish tool with only 47% schema coverage, more parameter detail would help, but the operational essentials (auth, mode, delivery) are present.

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

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

Schema description coverage is 47%, so roughly half the 15 parameters (name, start/end, adRoots, domains, outputFormat, utmHourlyBreakdown, etc.) are undocumented in both schema and description. The description names key axes (report type, immediate vs scheduled) but does not compensate for the undocumented parameters.

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

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

States a precise verb (Create/update) plus the resource (Sulvo advanced report) and enumerates the three report kinds (adUnit, dimensions, customData), which maps directly to the reportType enum. Clearly distinguishable from siblings like delete_sulvo_advanced_report and get_sulvo_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?

Explains the two operating modes (run immediately/emailed vs recurring schedule) and notes delivery is by email rather than inline, which tells the agent what to expect. It does not explicitly name an alternative sibling or state when not to use this tool, but the context is clear enough to choose correctly.

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 adds the optimistic-concurrency signal 'expectedVersion', which is genuinely useful context for a mutation. However, it omits that preflight attestations must be true and does not describe the 1-50 placement constraint or idempotent-retry behavior.

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

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

Two short sentences, front-loaded with the core action before the input note. Nothing is padded, though the brevity comes at the cost of useful detail rather than being elegantly economical.

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

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

For a mutation tool with nested objects, four parameters, no output schema, and preflight gating, the description is very thin. It omits the required top-level workspaceId, the 1-50 placement bound, the mandatory attestations, and any relation to the preflight/lock/verify siblings, leaving the agent to reconstruct the workflow from sibling 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 description coverage is 75%, so the schema already documents workspaceId, idempotencyKey, the attestation flags, and the nested input object, making a baseline of 3 appropriate. The description's claim that input 'requires expectedVersion and payload' is actually incomplete, since the top-level workspaceId is also required and goes unmentioned.

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 (Save) and resource (placement revision), but the tool is named save_sulvo_placement_plan while the description talks about a 'placement revision,' creating slight ambiguity about what exactly is being persisted. It also does not distinguish itself from the nearby sibling lock_sulvo_placement_revision, which an agent could easily confuse with this tool.

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 prerequisites, and no alternatives named. Given siblings like lock_sulvo_placement_revision, run_sulvo_activation_preflight, and verify_sulvo_placement_installation, an agent is left to infer the ordering of these steps on its own.

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 destructiveHint=true, indicating mutation. The description says 'Set or change' which aligns with that. It adds some context by mentioning required inputs, but it does not disclose the consequences of the mutation (e.g., what gets overwritten), permission requirements, or idempotency behavior. With annotations covering safety, this is moderately transparent but not rich.

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 sentences: one stating the action, the second stating input requirements. It is front-loaded and every sentence earns its place. 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 mutation tool with no output schema, the description should ideally explain return values or side effects. It mentions required inputs but does not cover what happens on success/failure, nor potential side effects. Given the complexity (nested input, destructive annotation), it is adequate but incomplete.

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 schema already documents most parameters. The description adds meaning by specifying that expectedVersion is required and that at least one of mode, goal, or retagTiming must be provided. These parameters are not described in the schema's visible fields (they are inside the nested 'input' object with additionalProperties true), so the description compensates well.

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: 'Set or change the journey intake answers on the workspace.' This is clear enough for an agent to understand what the tool does. However, it does not differentiate from siblings like start_sulvo_revenue_onboarding or get_sulvo_revenue_onboarding_status, so it misses the top score.

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 provides usage constraints by stating required input: 'Input requires expectedVersion plus at least one of mode, goal, retagTiming.' This implies when the tool can be used, but there is no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites beyond those input constraints.

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 tell the agent this is a non-destructive, non-read-only mutation. The description adds virtually nothing beyond confirming it creates/resumes a workspace. With annotations covering only the safety profile, the description should disclose whether previous workspace state is overwritten, whether it requires the audit artifact, etc.

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 no filler, front-loaded around the create/resume verb. It is short enough that there's no wasted prose, though the brevity comes at the cost of 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?

For a mutation tool with 6 params, no output schema, and only 50% schema coverage, the one-line description is far too thin. It neither explains return values nor ties the auditArtifactId/domain parameters to the workflow it references.

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%, so half the parameters are documented inline (goal, retagTiming, idempotencyKey). The description mentions none of them, however, leaving the undocumented parameters (domain, outputFormat, auditArtifactId) and their interactions unclarified.

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 action ('Create or resume ... workspace') and references 'verified-account activation', but 'sulvo_revenue_onboarding' is jargon that doesn't clearly map to the sibling set. An agent scanning siblings like get_sulvo_revenue_onboarding_status or set_sulvo_onboarding_journey can't easily tell how this 'start' workflow differs from those.

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 mentions sequencing ('after the public audit and signup steps') but doesn't give explicit when-to-use guidance or point to alternatives. It never names siblings like start_sulvo_signup or get_sulvo_revenue_onboarding_status, so an agent has no routing signal.

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 destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the agent knows this is a destructive, open-world write operation. The description adds almost no behavioral context beyond the annotations — it doesn't explain what gets destroyed, what permissions are needed, whether this is idempotent, or what the lead creation entails.

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 states the core action and outcome with zero waste. It's appropriately sized for the tool's complexity.

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?

The tool has 4 parameters (2 required), no output schema, and annotations that flag it as destructive and open-world. The description doesn't explain what happens on success or failure, whether the domain verification is synchronous, or what the unauthenticated lead means for subsequent steps. For a signup initiation tool, this leaves 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?

Schema description coverage is 75%, so most parameters are documented in the schema (email, domain, monthlyPageviews). The description doesn't add any parameter details beyond what the schema provides, leaving the baseline score of 3 for high schema coverage.

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 (verify domain, create lead) and resource (Sulvo signup step 1), clearly indicating it's the initial step of the signup flow. It's distinguishable from siblings like create_sulvo_signup_account or apply_for_sulvo_account, though it doesn't explicitly contrast 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?

The phrase 'normal Sulvo signup step 1' implies this is the starting point of the signup process, but there's no explicit when-to-use guidance, no mention of alternatives like apply_for_sulvo_account, and no prerequisites such as needing the domain or email to be valid.

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 bar is therefore lower. The description nonetheless adds nothing about what the submission mutates, whether it is irreversible, or what a "proven" state requires — the one behavioral detail an agent would need for a destructive call.

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

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

Two short sentences are front-loaded and waste no words, which is good structure. However, the brevity is closer to under-specification than disciplined conciseness for a destructive mutation tool, so it only earns a middling score.

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, zero-annotation-explained mutation with a nested free-form input object and no output schema. The description omits where expectedVersion/revisionId originate, what a successful submission produces, and what happens to prior state, leaving substantial gaps for a 4-parameter 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 75% and the top-level workspaceId, outputFormat, and idempotencyKey are documented in the schema. The description's real contribution is naming expectedVersion and revisionId, which live inside the free-form "input" object (additionalProperties: {}) that the schema leaves opaque — genuinely useful, though it omits any format guidance for those 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?

"Submit the proven revision" has a verb and an object, but "proven revision" is unexplained jargon that does not clearly map to the activation-workspace concept implied by the tool name. It does not distinguish this tool from siblings like lock_sulvo_placement_revision, submit_sulvo_site_for_approval, or rollback_sulvo_activation, so an agent cannot confidently tell what makes this submission unique.

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

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

The second sentence only states required inputs ("expectedVersion and revisionId"), not when to use this tool versus the many adjacent revision/signup/activation tools. There is no when-to-use condition, no prerequisites, and no named alternative, leaving selection to inference.

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

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

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 write (readOnlyHint=false), closed-world, and destructive behavior, so the safety profile is covered. The description usefully adds that the submission is ownership-only and carries no tags, but says nothing about reversibility, downstream Google-side processing, or failure modes 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 tight sentence with the core purpose front-loaded and the scoping constraint immediately after. No filler, though the 'Retag-after-approval journeys' label is jargon that costs a little clarity.

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 return expectations need not be explained. However, for a destructive external-approval action the description omits prerequisites (e.g., prior ownership verification, active activation workspace) and never reconciles the 'expectedVersion' claim with a schema that only requires workspaceId.

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 most parameters are documented structurally, warranting the baseline 3. The description adds the undocumented requirement of 'expectedVersion,' which is not present in the schema's required list — useful but also potentially confusing, and it leaves workspaceId/outputFormat/idempotencyKey entirely to 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 (submit) and resource (site for Google approval) with a scope qualifier: 'ads.txt ownership only, no tags.' Distinguishable from most siblings, though it doesn't explicitly contrast with the nearest relative, submit_sulvo_activation_workspace. The 'Retag-after-approval journeys' prefix adds context rather than noise.

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 'Retag-after-approval journeys' framing implies when this tool fits, but no explicit when-not condition or named alternative is given. An agent must infer that this is not the path for tag-bearing submissions or first-time activation. Adequate but leaves routing to inference.

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

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

With annotations declaring destructiveHint=true and readOnlyHint=false, the description should disclose what gets destroyed or modified. Instead, it only says 'save optional company information,' which could be interpreted as an upsert or overwrite. It doesn't clarify whether existing data is replaced, what happens if fields are omitted, or error conditions. The annotations are not contradicted, but the description adds little behavioral context beyond them.

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 with no wasted words. It efficiently conveys the core action and 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?

Given 10 parameters, 0% schema description coverage, no output schema, and a destructive annotation, the description is incomplete. It doesn't explain parameter meanings, behavioral implications of destructiveness, or return values. For a mutation tool with many inputs, this is inadequate.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions 'company information' and none of the 10 parameters. It doesn't explain what 'userId' is, what format 'employeeCount' takes, or how 'outputFormat' affects the response. With so many parameters and no schema descriptions, the description fails to add meaning beyond the parameter names.

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 optional company information for a pending Sulvo signup.' It's clear what the tool does and it's identifiable as part of the signup flow. However, it doesn't explicitly differentiate itself from siblings like 'submit_sulvo_signup_documents' or 'create_sulvo_signup_account', which are also signup-related.

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 context ('step 3' of signup, 'pending Sulvo signup') but doesn't explicitly state when to use this tool versus alternatives, nor does it list prerequisites such as needing an existing pending signup. It gives some guidance but leaves the agent to infer the exact conditions.

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 (implying state change) and destructiveHint=false, but the description's word 'verify' suggests a passive check, leaving a tension the description never resolves. It says nothing about what gets written, required permissions, or whether the verification result is persisted.

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?

It is a single front-loaded sentence with no filler, which is structurally good, but the sentence is so jargon-dense that its brevity comes at the cost of comprehension rather than from precision.

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 state-changing tool with no output schema, a nested open 'input' object, and an unexplained verification concept is not adequately described. The agent cannot tell what 'verify' returns or what 'locked revision' refers to.

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 important parameters (workspaceId, idempotencyKey, outputFormat) are self-documented in the schema. The free-form nested 'input' object gets no explanation in either place, but the description adds nothing beyond the schema baseline.

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

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

The verb 'verify' and the resource 'placement installation' are identifiable, but the description leans on undefined jargon ('stable placement container', 'inert loader') that an agent cannot map to a concrete operation. It is distinguishable from siblings like lock_sulvo_placement_revision only by the word 'verify', not by any explained 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 verification should be run, what precondition it depends on (presumably a locked revision), or how it relates to siblings such as lock_sulvo_placement_revision, rollback_sulvo_activation, or run_sulvo_activation_preflight. The agent must guess the position of this tool in the workflow.

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, openWorldHint=false, destructiveHint=false, so the agent already knows this is non-destructive but may advance state. The description's framing as a signup-flow step is consistent with that. It still doesn't say what happens on failure, whether the check is recorded against the signup, or that the domain was 'submitted' meaning it is externally owned, so credit stops at 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 no filler. The 'step 4b' jargon consumes space without adding meaning for an agent that has no signup step map, but the sentence is still lean and well-ordered.

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, yet the description never describes what a verification result looks like (pass/fail, which lines are missing, remediation). For a tool whose entire value is a verdict, plus an undocumented outputFormat parameter, this leaves the agent guessing about the return shape.

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

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

Schema description coverage is 0% and neither of the two parameters (userId, outputFormat) is mentioned in the description. The phrase 'submitted publisher domain' faintly gestures at the subject under test, but the agent gets no hint that userId is required or that outputFormat selects 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?

States a specific action and resource: verify whether the submitted publisher domain carries the required Sulvo ads.txt lines, anchored to 'signup step 4b'. This is distinguishable from the read-oriented sibling get_sulvo_signup_ads_txt, though the description never names that sibling to make the contrast explicit.

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

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

The phrase 'Run normal Sulvo signup step 4b' implies this is invoked at a particular point in the signup sequence, which is useful ordering context. However, it gives no when-not guidance, no prerequisites (e.g., documents must already be submitted), and does not reference the obvious alternative get_sulvo_signup_ads_txt.

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, covering the safety profile. The description adds almost nothing behavioral: it does not say whether records verification state, what failure looks like, or that it depends on prior deployment of the evidence. The only extra fact is the two evidence types being checked.

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 efficient, though the phrase 'inert Sulvo head-tag ownership evidence' could be tighter.

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, nested-parameter verification tool with no output schema, the definition omits what happens on success/failure and how it relates to the surrounding activation journey. The safety annotations and schema carry most of the load, leaving the description only minimally adequate.

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% and the description adds no parameter-level detail (no workspaceId, input, outputFormat, or idempotencyKey semantics). Per the rubric, with high schema coverage the baseline is 3, and the description does not raise it.

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

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

The description names a specific verb (Verify) and two concrete evidence types (ads.txt and Sulvo head-tag), which distinguishes it from siblings like verify_sulvo_signup_ads_txt (ads.txt only) and verify_sulvo_placement_installation. It is clear what the tool acts upon, though the awkward phrase 'inert Sulvo head-tag ownership evidence' slightly muddies the exact resource.

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 indication of when to use this versus the many adjacent verification tools (verify_sulvo_signup_ads_txt, verify_sulvo_placement_installation, run_sulvo_activation_preflight), nor any prerequisites such as the ads.txt needing to be deployed first. The agent is left to infer the entire selection context.

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