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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new context beyond them: the required account:read scope and the fact that the call consumes no credits. It does not describe failure modes (e.g., what an invalid key returns), but the auth and cost disclosures are substantive.

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 clauses with no filler: action, auth requirement, cost behavior. The core purpose is front-loaded and every clause carries distinct information.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the remaining essentials (scope, credit cost) for a zero-parameter read tool; only failure/error behavior is unaddressed, which is a minor 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the empty schema, and it correctly does not invent 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 specific verb and resource (get the authenticated agent/key status) and even names the endpoint. The resource is distinct from siblings like get_account or get_project, but the description never explicitly distinguishes itself from get_account, which an agent might reasonably consider a near-neighbor.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative sibling is named. The only adjacent signal is 'Does not use credits,' which is a cost property rather than a usage condition, leaving the agent to infer that this is for checking auth/key health.

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 mutation, idempotent, non-destructive, closed-world. Description adds valuable behavioral context: changes live tracking on the user's site, keeps canonical host/site key, and does not use credits. Does not contradict 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?

Front-loaded with verb, resource, and endpoint; each short sentence adds distinct information (targeting, side effects, cost) with 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 2-param mutation with rich annotations and no output schema, the description covers what it does, how it targets, its live-tracking impact, and cost. Missing explicit alternatives and permission details, but adequate overall.

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?

With 0% schema description coverage, description must compensate. It clarifies propertyId is the sole target and hostname is a public collection hostname, but does not explain format or constraints beyond what the schema provides (pattern, integer minimum).

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 'Add' and resource 'public collection hostname' with endpoint PATCH /api/v1/analytics/property. Distinguishes from generic property creation by scoping to hostname addition and targeting propertyId alone.

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 context such as 'target by propertyId alone' and 'keeps the canonical host and site key', but does not explicitly state when to use this versus siblings like analytics_create_property or analytics_verify_property, nor when not to use it.

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

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

Adds substantial context beyond the annotations: the resulting state is 'archived', history is preserved and data is not deleted, idempotency is state-based, and it changes live tracking on the user's site. This concretely explains what destructiveHint=false and idempotentHint=true mean here, plus discloses a real-world side effect and zero credit cost.

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?

Four terse, front-loaded clauses: what it does, what archival means, idempotency, side effect, and cost. No filler, and the most decision-relevant fact (preserves history, does not delete) comes early.

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-required-param mutation with annotations and no output schema, the description covers state outcome, idempotency, side effects, and credit cost. It omits auth/permission requirements and what a success response looks like, which are minor given the annotations already carry the safety profile.

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

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

Schema description coverage is 100%, so goalId/projectId/propertyId/projectUuid are already fully documented in the schema. The description only restates the :goalId path element and adds no new parameter semantics, 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 specific verb (Archive) and resource (analytics goal) and even names the underlying endpoint DELETE /api/v1/analytics/goals/:goalId. An agent can immediately separate this from analytics_create_goal and analytics_list_goals without opening a schema.

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

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

Gives clear context for choosing it: archival preserves history rather than deleting, is idempotent by state, and consumes no credits. It does not explicitly name an alternative tool or state when *not* to use it, so it falls short of a 5.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description goes well beyond them: it warns that the destination must be a path (not absolute URL), that counting is prospective with no history backfill, that it changes live tracking on the user's site, and that it does not use credits. These are critical behavioral traits not covered by 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?

The description is a compact paragraph that is front-loaded with the core action and API endpoint. Every sentence adds value, though it could be slightly more structured with bullet points for error cases.

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 no output schema and high schema coverage, the description covers the key behavioral aspects: endpoint, destination contract, counting semantics, error conditions, and live impact. It is complete enough for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents the parameters. The description adds semantic nuance about destination being a path starting with '/' and absolute URLs being rejected, and mentions the property's own hostname, which goes slightly beyond the schema's parameter descriptions.

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 destination-URL goal') and names the API endpoint. Distinguishes itself from sibling analytics_list_goals and analytics_archive_goal by making the create action and the destination-URL concept 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 description explains what a destination-URL goal is and how counting works, but does not explicitly say when to use this tool vs. alternatives or prerequisites beyond the error codes. The error codes (409 goal_exists, 409 property_not_set_up) do imply usage 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?

Adds substantial context beyond the annotations: the siteKey is disclosed exactly once, it cannot be re-read, and the recovery path is named. It also resolves a cost question ('Does not use credits') and documents the 409 collision behavior. Annotations only give the generic non-idempotent/non-destructive profile, so this description carries real additional weight.

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 dense sentences, zero filler. The irreversible one-time-siteKey warning is front-loaded right after the action statement, which is exactly where an agent's attention should land.

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 creation tool with no output schema, the description covers the outcome (siteKey returned once), the collision error, cost, and recovery. Nothing an agent needs in order to call it correctly and handle the response 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%, with hostname, projectId, and projectUuid all documented in the schema itself (including the alternative-to-projectId relationship). The description adds no parameter-level syntax or constraints beyond implying the hostname feeds the tracking snippet, so the baseline 3 applies.

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

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

States a specific verb+resource ('Create the analytics property for a project'), names the exact endpoint, and describes the key artifact returned (the site key for the tracking snippet). This distinguishes it cleanly from siblings like analytics_get_property and analytics_rotate_key.

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 the triggering condition (project needs a property), the failure case a caller must handle (409 property_exists with propertyId), and the recovery alternative (analytics_rotate_key mints a fresh key). It stops short of an explicit 'do not call this if a property already exists' routing statement, but the error semantics effectively convey it.

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

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

Annotations already cover read-only/idempotent/non-destructive, yet the description adds genuinely non-obvious behavioral semantics: `totals: null` means no reporting basis rather than zero, `goals.configured: false` differs from a configured goal with zero completions, and collector state/freshness must be checked. It also discloses the no-credit cost, none of which is derivable from structured fields.

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

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

Front-loaded with the core action and URL, then a compact honest-null caveat and a cost note. Dense but each clause carries information; the run-on list of returned artifacts ('instrumentation card, six-state collector + freshness') is slightly jargon-heavy but not wasteful.

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

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

With no output schema, the description carries the burden of describing returns and does so at a good level of detail, including the important null-state semantics. It stops short of describing the response envelope or pagination, but for an aggregate overview endpoint that gap is minor.

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

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

Schema description coverage is 100%, so the schema already documents date range, tz, and the projectId/propertyId/projectUuid targeting rules in detail. The description adds nothing about parameters (e.g. it never reinforces the 'propertyId alone, do not combine' constraint), so baseline 3 is correct.

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

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

States a specific verb+resource ('Get the GA Overview via GET /api/v1/analytics/overview') and enumerates the payload (visits/AI visits/goal completions chain, top engines and landing pages, goals summary, collector state). This is far more specific than a tautology, though it never names a sibling (e.g. analytics_get_traffic) to disambiguate from the other analytics_get_* 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?

Usage is only implied: an agent can infer 'overview' is the broad summary versus analytics_get_traffic's narrower data, but there is no explicit when-to-use, when-not-to-use, or alternative routing. The 'does not use credits' note is a cost hint rather than selection 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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses meaningful traits: the site key is never returned (security), a specific 409 ambiguity error, and that the call does not consume credits (billing). It stops short of describing pagination/auth or latency behavior, so it is strong 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?

Front-loaded with the action and endpoint, then the returned fields, then the error and billing note. No filler sentences; every clause carries distinct information.

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

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

With no output schema, the description compensates by enumerating the return fields and the full six-state collector enum, and it covers the principal failure mode. An agent has everything needed to call and interpret the result correctly.

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

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

Schema description coverage is 100%, so projectId/propertyId/projectUuid semantics and the mutual-exclusion rule are already documented in the schema. The description echoes the ambiguity consequence but adds no new syntax or format meaning, so the baseline 3 applies.

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

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

States a precise verb+resource ('Get the analytics property for a project') and even the underlying endpoint, then enumerates exactly what is returned (hostname, property state, collector state, latest verification run). This lets an agent separate it from analytics_get_overview or analytics_get_verification without opening schemas.

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 the key operational condition — the project-scoped lookup resolving only when the project has exactly one property, otherwise 409 property_scope_ambiguous — plus the note that no credits are consumed. It does not name alternative tools for the multi-property case, so the routing guidance is clear but not fully 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for adding real behavioral context: `totals: null` means the collector has no basis to report rather than zero traffic, only healthy_zero/healthy_data states carry real numbers, modeled influence is excluded, and the call consumes no credits. This null-vs-zero disclosure is exactly the kind of non-obvious behavior an agent needs.

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

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

Front-loaded with the endpoint and returned data, followed by a clearly labelled HONESTY block; every sentence carries information. The honesty sentence is dense with backticked jargon, which slightly hurts scannability but not substance.

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 compensates by enumerating the returned sections and explaining the null semantics and sampling/evidence flags, which is strong for a read-only report tool. What remains thin is guidance on how the returned data relates to the sibling overview report.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters including the propertyId-alone constraint and the 409 property_scope_ambiguous failure. The description adds no syntax or semantics beyond what the schema carries (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 verb and resource ('Get the AI-referral Traffic report via GET /api/v1/analytics/traffic') and enumerates the payload it returns (totals, per-engine series, landing pages, channel split, evidence provenance, sampling flags). It is clearly distinct from get_overview/get_property in subject matter, though it never names a sibling to route against.

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 context is implied rather than stated: it notes the call 'does not use credits' (a cost consideration) and tells the agent how to interpret results, but never says when to reach for this report versus analytics_get_overview or analytics_get_property, and gives no prerequisites or exclusions.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description still adds material context: that it never initiates or retries runs, the full status enum (queued/running/succeeded/failed/expired), what the checks validate (script load and collector endpoint), and that it consumes no credits. That is substantive, non-obvious behavior an agent cannot infer from the annotations.

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

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

Three dense sentences, zero filler, with the core action and endpoint front-loaded and the behavioral caveats following. Every clause carries information the agent can act on.

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, but the description supplies the status vocabulary and what the verification checks cover, giving the agent enough to interpret results. With annotations covering safety and the schema covering parameter exclusivity, nothing material 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 schema itself spells out the projectId/propertyId/projectUuid exclusivity rules and the 409 property_scope_ambiguous case. The description adds no parameter-level information beyond what the schema documents, so the baseline 3 applies.

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

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

States a specific verb and resource ('poll the latest snippet verification run for a project's analytics property') and pins the exact endpoint. It also separates itself from the sibling analytics_verify_property by declaring it never starts or retries a run, so an agent can pick the read-only variant 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 'never starts or retries a run' clause gives clear context that this is the observation-only companion to a verification-start tool, and the mention of polling implies repeated calls. It stops short of explicitly naming the alternative tool or stating when a run must be started first, so it is clear but not fully routed.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world traits, but the description adds genuinely non-redundant behavior: the attribution model (within-visit, one completion per goal per visit, prospective counting from creation), the caveat that goal names are user-authored data, and the notable 'does not use credits' cost disclosure. It stops short of describing pagination or result-size 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?

Front-loads the verb, resource, and endpoint, then adds the return-shape and caveats. Dense but largely waste-free; the parenthetical attribution clause is long but carries real information.

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

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

With no output schema, the description helpfully sketches what is returned (completions and per-source split) and flags the attribution semantics. For a 7-param read tool whose defaults and exclusivity rules live in a fully-covered schema, this is close to complete; only pagination/volume behavior is unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents all 7 params including the projectId/propertyId exclusivity and range defaults. The description adds no parameter syntax or format detail, so baseline 3 applies.

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

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

States a specific verb ('List') and resource ('destination-URL goals'), plus the endpoint and the shape of the returned data (per-goal completions, per-source split). This is enough to distinguish it from the goal-mutating siblings like analytics_create_goal and analytics_archive_goal.

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 advises using the stable numeric id rather than the customer-authored name when acting on a goal, which is useful context, but it never says when to prefer this tool over siblings or what preconditions apply. Usage is only implied by the read/list nature of the tool.

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

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing that the new siteKey is shown exactly once, that the old key keeps working through overlapExpiresAt, and that the operation is never auto-retried but a manual retry performs a safe fresh rotation. It also notes no credits are consumed — all behaviorally load-bearing facts absent from structured fields.

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

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

Front-loads the core action and endpoint, then layers targeting modes, error codes, and retry semantics in tight clauses. Dense but every sentence carries operative information — no filler or restatement 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?

With no output schema, the description supplies the return-value essentials (new siteKey shown once, overlapExpiresAt) plus the non-idempotency and retry behavior. Nothing an agent needs to call this mutation correctly and interpret its result is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and baseline is 3. The description adds real value on top: it emphasizes propertyId must be passed alone and surfaces the 409 property_scope_ambiguous condition for the project-reference path, clarifying mutual exclusivity semantics.

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 — "Rotate a property's ingest site key" — and pins it to an explicit endpoint (POST /api/v1/analytics/property/key/rotate). No sibling in the list rotates keys, so an agent can identify this tool unambiguously from the name and first clause.

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 clear conditional targeting rules: propertyId ALONE as primary, or a project reference plus expectedPropertyId, with the 409 analytics_property_changed failure mode named. It covers invocation conditions well but does not state prerequisites such as permission/auth requirements or when rotation is appropriate versus unnecessary.

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-idempotent, open-world, non-destructive operation. The description adds value beyond that: async execution, 202 acceptance, rate-limit behavior (429 retryAt), absence of credit consumption, and the anti-fabrication instruction. Only return-value detail is absent, which is acceptable for a fire-and-poll starter.

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

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

Front-loaded with the action and endpoint, then behavior, then the polling instruction. Slightly redundant — 'This starts an async live-site check' restates the opening sentence and could be cut.

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 async starter tool with no output schema, the description covers the trigger, the async/polling contract, rate limiting, and credit cost — everything an agent needs to invoke and follow up correctly. Minor gaps only in what the accepted run returns.

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

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

Schema description coverage is 100%, and the schema itself already documents the projectId/propertyId mutual exclusivity and the 409 property_scope_ambiguous case. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (Start), resource (live verification run for a project's analytics property), and the exact endpoint. It is clearly distinguishable from sibling analytics_get_verification, which it explicitly designates as the polling counterpart.

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

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

Explicitly instructs the agent to poll analytics_get_verification for the outcome, giving a clear follow-up path, and warns about 429 with retryAt. It does not state when this tool should NOT be used (e.g., when a verification is already in flight), so it stops short of full when/when-not coverage.

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

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

Annotations already declare the non-read-only, non-idempotent, open-world profile, but the description adds material context they cannot convey: this kicks off recurring metered runs and consumes credits, defaults are injected by a shared client, and target providerKeys are validated against a filtered catalog. It does not say what happens on partial failure or how runs are later stopped, keeping it out of 5 territory.

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?

Four tight sentences with no filler, and the core action plus endpoint are front-loaded before the constraints. The parenthetical about the shared client is slightly compressed but still earns its place by explaining where defaults originate.

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 11-parameter, nested-object, mutating tool with no output schema and 45% schema coverage, the description covers the project scoping, defaults, and provider validation well but says nothing about cadence semantics, promptInstructions, or the free-form settings object. It is adequate but leaves notable holes an agent would 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 only 45%, so the description must compensate, and it does explain the projectSlug/projectId either-or, the type/language/country defaults, and the providerKey constraint. However, three of the four required parameters (name, cadenceMinutes, promptInstructions) and the nested settings object get no explanation in either place, leaving a real 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 and resource ("Create a PromptEden monitor") plus the backing endpoint POST /api/v1/monitors, so an agent can tell it apart from list_monitors and create_project. It stops short of explicitly naming a sibling it must not be confused with, so it lands at clear-but-undifferentiated rather than 5.

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

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

Gives real prerequisites: projectSlug or projectId must be supplied, and provider keys must come from the filtered list_providers catalog, which implicitly routes the agent to list_providers first. There is no explicit when-not-to-use or comparison against create_project, so it is clear context without exclusions.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuine behavioral fact not present in the annotations — that the call consumes no credits — but omits auth requirements, response shape, and side 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 short sentences, front-loaded with the core action and with zero filler. The terseness is a byproduct of under-specification rather than wasteful structure, so it is efficient but leaves obvious room to add value.

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

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

For a mutation tool with no output schema and 0% parameter coverage, the description should explain at least the key inputs and any auth/permission requirements. It covers neither, leaving an agent able to infer only the operation and its credit cost.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the parameter burden, and it does not name or explain any of name, country, language, or websiteUrl. A caller learns nothing about which inputs are required or what they mean.

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 project') and even names the underlying endpoint (POST /api/v1/projects). This is unambiguous and lets an agent distinguish it from the read siblings get_project/list_projects, though it stops short of explicitly contrasting 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?

There is no when-to-use or when-not-to-use guidance and no alternatives are named. The only usage-relevant hint is 'Does not use credits,' which speaks to cost rather than to selection between 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely new context in 'Does not use credits,' a billing-side-effect disclosure not available from any structured field, though it omits auth/permission requirements.

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

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

Two short sentences, zero waste, with the resource and endpoint front-loaded and the cost constraint following. Every clause carries 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?

An output schema exists so return values need no explanation, parameters are empty, and annotations cover the safety profile; the description only needs to carry purpose and cost behavior, which it does. A note on authentication would have made it fully complete.

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

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

Zero parameters, so per the rubric the baseline is 4. Nothing needs to be compensated for at the parameter level and the description appropriately stays silent on inputs.

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

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

Specific verb (Get) plus resource (account) and even enumerates what the resource covers (team, plan, usage details), plus the underlying endpoint. No sibling tool overlaps with account retrieval, so no differentiation is needed, but the description names no alternative to position against, keeping it at 4 rather than 5.

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

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

Usage is only implied: an agent can infer this is the tool for account/plan/usage lookups, and 'Does not use credits' gives a light cost-based signal for calling it. There is no explicit when-to-use, when-not-to-use, or alternative routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so safety is covered. The description adds a genuinely non-structured behavioral fact — 'Does not use credits' — which tells the agent this call has no billing cost, useful context that annotations do not carry.

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

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

Two short sentences, zero filler, and the core identification (what it fetches and by what keys) is front-loaded ahead of the secondary credit note.

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 single-resource read with one documented required parameter and no output schema, the description supplies everything needed to invoke it correctly. It omits return-shape detail, but with no output schema and trivial parameters that is a minor gap rather than an obstacle.

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 description's 'id, UUID, or slug' merely restates the schema's own text. Baseline 3 applies because the schema fully documents the single parameter and the description adds no format or constraint detail beyond it.

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

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

States a specific verb (get) and resource (a single project) and names the three accepted lookup keys (id, UUID, slug). The word 'single' plus the singular resource clearly separates it from the sibling list_projects without opening 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?

Usage is only implied: an agent can infer this is the singular counterpart to list_projects from the phrasing and the required projectId. There is no explicit when-to-use/when-not statement or named alternative, so it stays at the minimum-viable 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that with the billing behavior ('Does not use credits') and the underlying HTTP method, which helps an agent reason about cost and semantics. It omits pagination/rate-limit behavior, so it is not a 5.

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

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

Two short sentences, front-loaded with the core action and the lookup key, with the endpoint and the cost note appended. No filler or redundancy.

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

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

There is no output schema, so the description should carry more about what 'results' actually are (check results, incidents, metrics?) and how paging works with limit/offset. It covers the identity and cost aspects adequately but leaves the return shape and pagination to inference.

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%, above the high-coverage baseline, and the schema itself documents monitorId, limit (200 cap) and since. The description only restates that results are looked up by monitor UUID, adding no syntax or semantics beyond the schema, and the undescribed offset parameter gets no help.

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

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

States a specific verb (get) and resource (monitor results) keyed by monitor UUID, and even names the underlying endpoint GET /api/v1/monitors/:monitorId/results. It is clearly distinct from siblings like list_monitors and create_monitor, though it never explicitly contrasts itself with them.

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

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

Usage is only implied: fetch results for a given monitor. There is no guidance on when to prefer this over list_monitors or other monitoring siblings, and no mention of the since/limit/offset filters for narrowing results. The 'Does not use credits' note is the one genuinely usage-relevant hint (cost-free call).

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, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds a genuinely useful behavioral fact not present in the annotations: 'Does not use credits,' which informs the agent about billing/cost side 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 short sentences, front-loaded with the core purpose and scope, with the credit note appended as a secondary fact. No filler or redundancy.

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 an output schema present, the description need not explain return values, and the annotations cover the safety profile. Scope ('for the authenticated team') and cost are stated; the definition is complete enough for a zero-parameter list 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema is empty with full coverage trivially satisfied.

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 ('List PromptEden monitors for the authenticated team'), leaving no ambiguity about what the tool does. It does not explicitly contrast itself with siblings like create_monitor or get_results, but the read-only list semantics are self-evident.

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

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

Usage is implied rather than stated: the agent can infer this is the way to enumerate monitors for the current team. There is no explicit when-to-use vs. when-not, and no mention of alternatives such as get_results for retrieving monitor output.

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, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds one genuinely new behavioral fact — that the call consumes no credits — which is useful cost context, but it says nothing about pagination, result size, or rate limits.

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

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

Two short, front-loaded sentences with no filler; the operation and the endpoint come first, followed by the cost note. Nothing is redundant or padded.

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

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

With no output schema and no parameters, the description would ideally say what the list returns (fields, ordering, whether it is paginated). The credit note is helpful, but return shape is left entirely undisclosed, leaving a modest gap for a listing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The endpoint path gives a mild hint about the resource being addressed.

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 ('List projects') and even cites the backing endpoint (GET /api/v1/projects), so the agent knows exactly what the tool does. It does not explicitly differentiate itself from the sibling get_project, though the plural/singular naming makes the scope inferable.

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 get_project or the other list_* siblings, and no prerequisites or constraints are stated. The only sentence beyond the purpose line ('Does not use credits') is a cost note, not usage direction.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds two traits annotations cannot express: the billing behavior ('Does not use credits') and a filtering scope ('Coding-agent providers are omitted'), both of which materially affect agent decisions.

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 purpose, followed by the actionable usage hint and the cost/scope caveats. No filler or restated title text.

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 zero-parameter read tool with a full output schema and rich annotations needs little more than scope and billing context, both of which are supplied. Nothing required 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?

The tool takes zero parameters, so the baseline is 4. The description's field list describes outputs rather than inputs, which is mildly redundant with the output schema but adds no param-level confusion.

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

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

States a specific verb and resource ('List the answer engines available for monitors') and enumerates the returned fields (key, name, category, costTier). This distinguishes it clearly from siblings like list_monitors and create_monitor, which operate on monitor instances rather than the provider catalog.

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 concrete downstream use case ('Use a returned key when creating a monitor target') and a scope exclusion ('Coding-agent providers are omitted'). It stops short of naming an alternative or stating when-not-to-use, so it is clear context rather than full routing guidance.

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