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

With no affirmative annotations, the description carries the full disclosure burden and does so well: it warns that the returned nv_ key is issued once, must never be emailed, and that unverified invitees must supply an OTP. This is critical behavioral context beyond the bare accept action.

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 cover the core action, token source, OTP condition, sensitive return value, and billing implication. There is no fluff, and the most important operational facts are front-loaded.

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

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

For a two-parameter tool with no output schema, the description is nearly complete: it explains the return value (nv_ key), its one-time nature, the OTP prerequisite, and the collaboration context. It could go slightly deeper on failure modes or exactly how the returned key should be used, but nothing essential is missing.

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

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

Schema coverage is 100%, so the schema already explains token and otp fully. The description reinforces the OTP requirement and token origin but adds no new parameter-specific meaning beyond what the schema provides, so the baseline score 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?

The description names a specific action and resource: accepting an invite token. It also clarifies the token source and distinguishes this tool from create_project by noting that the caller is not billed, which prevents confusion with project creation.

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 clearly indicates when to use the tool: when accepting an invite, including the local/dev path via invite_project_member. It also gives a useful exclusion by stating create_project still bills the caller, though it does not exhaustively enumerate all alternative tools or explicitly say 'do not use X.'

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

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

The description adds meaningful context beyond annotations: it identifies the external service (Stripe), the portal purpose, and the existing-subscriber precondition. Annotations already signal non-read-only and non-idempotent behavior, so the absence of deeper side-effect detail is acceptable.

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 deliver the core purpose and the exclusionary usage guidance without any filler. The primary function is front-loaded, and the alternative routing follows immediately.

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

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

For a tool with one optional parameter and no output schema, the description provides the essential return type (URL), target audience, and explicit alternatives. There are no missing details that would prevent an agent from selecting and calling it correctly.

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

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

The only parameter, return_url, is already fully described in the schema with 100% coverage. The tool description adds no additional parameter-specific meaning, so the baseline score 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?

The description clearly states that this tool returns a Stripe Customer Portal URL for an existing subscriber and scopes it to manage/cancel actions. It also explicitly distinguishes itself from first-time subscription tools by naming checkout and mpp_upgrade, removing ambiguity.

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

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

It gives an explicit negative usage condition ('Not first-time subscribe') and names the exact alternative tools to use instead. The positive use case, existing subscribers managing or canceling billing, is also clear.

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 (readOnlyHint=false, all hints false) establish this is a mutating operation, and the description meaningfully extends that: no auth required, unverified trial still publishes, OTP/verify_email happens after the live URL, and apiKey returns immediately. These are non-obvious behavioral traits an agent must know to call it correctly.

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 sentences with zero filler: purpose is front-loaded, followed by two high-value behavioral warnings (no auth, unverified publishing, immediate apiKey return). Every sentence earns its place and the critical 'do not wait for OTP' advice is placed last for emphasis.

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

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

For a one-parameter tool with no output schema, the description covers purpose, auth requirements, workflow ordering, and the key return value (apiKey). Minor gaps remain: no mention of error behavior for duplicate/registered emails and no explicit note that this creates a trial account, but these are edge cases for a low-complexity 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 100% and the single email parameter is already documented with its OTP behavior in the schema. The description reiterates that email is the input and mentions OTP delivery but adds minimal new meaning beyond the schema's own description. 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 an account + nv_ API key from an email') and differentiates from siblings by specifying no Bearer key required and framing verify_email as a later step. The distinction from verify_email, create_account, and create_account_session is clear without opening their 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?

Provides clear workflow context: this is the pre-authentication onboarding step, verification comes after the live URL, and the caller should not wait for OTP. It implies when to use it (initial account setup, no auth available) but stops short of explicitly naming alternatives or exclusion conditions like 'use verify_email when confirming OTP'.

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

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

Annotations already mark this as non-read-only and non-idempotent; the description adds the material behavioral context that it returns a checkout URL and requires an nv_ API key plus a verified email. It doesn't explain side effects of repeated calls, but the annotations cover idempotency and the description covers the main auth gate.

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 with no filler: the purpose is front-loaded, followed by prerequisites and an explicit usage boundary. 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?

For a simple tool with no output schema, the description covers what it returns, who can call it, and when it should or should not be used. It could add a fallback for unverified users or state that repeated calls may create new checkout sessions, but these are minor gaps given the annotations and simple return type.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that 'pro' maps to the $29 plan and that 'scale' is the other paid plan, which helps an agent choose between enum values. cancel_url and success_url are already fully described 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?

The description names a specific verb and resource: returning a Stripe Checkout URL for Pro or Scale plans. It also distinguishes itself by naming the required auth precondition and the only plans it serves, so an agent can tell it apart from billing_portal and mpp_upgrade.

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 an explicit trigger condition ('Use after a 2nd project or a 402') and an explicit exclusion ('never after the first live URL'). It also states a prerequisite ('Requires nv_ + verified email'), leaving no doubt about when this tool is appropriate.

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 indicate this is a mutating, non-idempotent operation. The description adds valuable behavioral detail beyond the annotations: it enables both apex and www, defaults to www with redirect, and explains how to switch to apex or disable redirect. This gives the agent a clearer picture of 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?

The description is three short sentences, front-loaded with the core purpose. Every sentence earns its place by clarifying behavior or customization options. There is no redundant wording or filler.

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

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

Given the schema covers parameters and annotations cover mutation behavior, the description is reasonably complete for invoking the tool. However, it lacks guidance on prerequisites (e.g., domain verification), what happens after attaching, and how this relates to domain status checks, so an agent may not have the full operational picture.

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?

Input schema coverage is 100%, so the schema already documents all four parameters and their defaults. The description adds some context around primary and redirect defaults, but it largely restates schema-provided defaults rather than introducing genuinely new parameter 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?

The description opens with a specific action and resource: 'Attach a custom domain.' It goes on to clarify behavior for site domains (apex+www) and default canonical host settings. It does not explicitly name or differentiate sibling tools, but the action and domain-specific scope make the purpose 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?

The phrase 'For site domains' hints at the applicable context, and the description makes it easy to infer this tool is for attaching/activating a custom domain. However, it never explicitly states when to choose this tool over alternatives like get_domain_status or update_project_settings, nor does it offer any 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?

Although annotations already declare idempotentHint=true, the description explains what that means here: re-confirming the same path updates metadata rather than erroring. It also discloses the important side-effect boundary that confirming does not publish the site, which is not in 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 sentences, each carrying distinct information: action, alternative, non-effect, and idempotency. No filler and the main action is front-loaded.

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

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

The description captures the full workflow context: it sits after get_upload_url and before deploy, and disambiguates from confirm_uploads_batch. It could add error behavior for missing staged files, but for a simple confirmation tool with 100% schema coverage this is sufficiently 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?

All three parameters have descriptions in the schema (100% coverage), so the description does not need to repeat them. The description mentions 'path' and the presigned URL flow but adds no parameter details beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Record one staged file' after a PUT to the presigned URL. It explicitly contrasts with confirm_uploads_batch and deploy, making the tool's unique role unmistakable.

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 when to use the batch sibling ('Use confirm_uploads_batch when several files were uploaded') and explicitly says the tool does not deploy, directing the agent to call deploy afterwards. This is explicit when/when-not routing.

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

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

Annotations are minimal (readOnly=false, not destructive), but the description adds meaningful behavioral details: the 200 response shape, errors always being an array, retry-only-failed-paths guidance, and the non-deploy guarantee. This goes well beyond the 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?

Three tight sentences: purpose, response/retry behavior, and sibling distinction. Every sentence carries necessary information, and the most important usage constraint is front-loaded.

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

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

For a two-parameter tool with full schema coverage, the description supplies the missing pieces: the expected workflow step, response shape, error-handling contract, and distinction from both the single-file tool and the deploy tool.

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

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

Schema description coverage is 100%, so the schema already documents project_id and files with clear meanings. The description adds no parameter-specific details beyond the schema, which is acceptable 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?

States a specific verb and resource: 'Confirm many uploads' after the presign/PUT flow, and explicitly distinguishes from confirm_upload for a single file. The workflow context makes the tool's role 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?

Gives explicit when-to-use guidance ('after get_upload_urls_batch PUTs'), names the alternative confirm_upload for single files, and clarifies what the tool does not do ('Does not deploy'), preventing confusion with the deploy sibling.

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

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

The description adds useful behavioral context beyond the annotations: the token is 'short-lived', carries specific scopes, and the security warning 'Never put nv_ keys in HTML' explains a key constraint. It does not fully describe session lifecycle or response shape, but the additions are meaningful.

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

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

The description is two short sentences with no filler. The primary action and resource are front-loaded, and the security warning earns its place as an important operational constraint.

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 tool with no output schema, the description covers the essential facts: what the token is, its lifetime, its scopes, and a critical usage warning. It slightly omits explicit return-value details, but the token itself is implied as the result, so the definition is reasonably 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?

The input schema has zero parameters and the schema description coverage is 100%, so no parameter documentation is needed. The description's statement about the token scopes is the only relevant semantic context, which is appropriate for a parameterless tool.

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

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

The description uses a specific verb ('Mint') and names the exact resource produced ('short-lived mgmt_ token') along with the scopes granted. It clearly distinguishes this tool from sibling tools like get_account_console_kit or billing_portal by specifying the token's purpose and scope list.

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 clearly indicates this is for a 'local HTML console' and specifies the scopes needed, which gives the agent solid context for when to use it. It does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion 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 indicate this is a mutating, non-idempotent operation, and the description adds the useful fact that it returns submit URLs for edge and public API. It does not disclose other behavioral aspects such as whether slug conflicts are handled, default field behavior, or persistence semantics, but the annotation coverage lowers the burden.

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

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

The description is a single, focused sentence that front-loads the core action and outcome. The optional note and return-value information each add value without padding, and nothing is redundant.

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

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

The described return value (submit URLs for edge + public API) partially compensates for the lack of an output schema. Given annotations and full schema coverage, the description is sufficient for an agent to call the tool correctly, though it could mention failure modes or default behaviors for full completeness.

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 parameters are fully documented in the schema. The tool description adds no parameter-specific meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Create') and resource ('a Novence form on a project'), clearly identifying the action and scope. It also distinguishes itself from alternative form services (Formspree/Web3forms) and, via sibling context, from list_forms/update_form.

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 notes that the tool is optional and that sites may use Formspree/Web3forms instead, providing a useful exclusion. However, it does not spell out when to choose this tool over sibling form tools or give explicit conditions for use, so it stops short of full 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 indicate this is not read-only, not idempotent, and not destructive. The description adds valuable behavioral context beyond annotations by disclosing that creation counts against the caller's project quota and is scoped to the caller's account.

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

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

Two sentences with no wasted words. The primary action and quota consequence are front-loaded, and the shared-site alternative is useful guidance rather than filler.

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

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

For a simple create tool with only two well-documented parameters, full annotation coverage, and no output schema, the description provides the essential context: creation scope, side effect, and how to handle shared sites. Nothing critical is missing.

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

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

Schema coverage is 100% and both parameters already have meaningful descriptions. The tool description does not add further parameter-level detail, so it meets the baseline but does not exceed 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 ('Create') and resource ('hosting project on the caller's account'), and adds the quota side effect, which distinguishes it from other project-related tools. It also implicitly differentiates from editing shared sites via the second sentence.

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 tells the agent when not to use this tool: for editing a shared site, use upload/deploy tools with that project's project_id. This provides clear routing guidance relative to 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?

Beyond the destructiveHint annotation, the description explains the real consequences: the change is irreversible for the staged path, re-uploading is required to restore it, and the live deploy remains unaffected until the next deploy. This is valuable behavioral context.

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

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

Three short sentences with no filler. The core action is front-loaded, followed by the most important behavioral caveat and an explicit routing to an alternative 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 a simple two-parameter destructive file tool, the description covers the key missing context: staging scope, irreversibility, restoration path, and when not to use it. No output schema exists, so no return-value documentation is expected.

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 input schema fully documents both parameters, including path format and project_id source. The description adds no additional parameter-level meaning, 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?

The description states a specific verb and resource: 'Remove one path from staging.' It clearly differentiates this from delete_form_submission by saying form PII should use that sibling instead, and distinguishes the staging scope from live deploys.

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 explicit context: this affects only staging, not the currently live deploy. It also names the alternative tool for form PII, telling the agent exactly when not to use this 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?

The annotations already carry destructiveHint=true and readOnlyHint=false. The description adds that deletion is permanent and irreversible, clarifies the impact on PII, and notes that the form itself remains active. This is useful context beyond the structured annotation.

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

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

Three short sentences with zero fluff. The core action and the most important caveats (irreversibility, form not disabled, alternative) are front-loaded and 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?

For a simple destructive operation with fully documented parameters, the description covers permanence, PII sensitivity, and the alternative to disabling. No output schema exists, but return values are not essential for invoking a delete 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%, with each parameter fully documented (e.g., project_id from create_project/list_projects, submission_id from list_form_submissions). The description adds no parameter-specific detail, 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 (delete), a resource (one form submission), and key characteristics (PII, permanent). Explicitly contrasts with disabling the form via update_form, making it immediately distinguishable from its main sibling 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?

Provides explicit when-not-to-use guidance: 'Does not disable the form — use update_form status=disabled.' This routes the agent to the correct alternative and clearly separates deletion from disabling.

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

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

The description significantly expands on annotations by revealing the asynchronous nature (POST returns quickly, poll separately), the difference in quality checks for verified vs unverified accounts, the checkRuns: 0 behavior, and the retry prohibition during certain statuses. This is valuable context an agent cannot infer from annotations alone.

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 concise sentences deliver high-value information with no filler. The main action is front-loaded, followed by essential edge-case behavior and retry guidance. 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?

Given the tool is asynchronous and has no output schema, the description covers the full flow: response timing, polling destination, terminal states, retry constraints, and behavioral differences based on account verification. An agent has enough to invoke it correctly and interpret results.

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 both parameters have clear descriptions. The description adds no new 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?

Description opens with 'Publish the site', a specific verb and resource, making the core action unmistakable. It also references the related get_deployment_status tool, giving context about the deployment lifecycle, though it doesn't explicitly differentiate itself from sibling tools beyond that.

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

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

Provides clear operational guidance: POST returns quickly, so poll get_deployment_status, and explicitly says not to retry while status is promoting or checking. It also distinguishes verified vs unverified account behavior. It doesn't state alternative tools for deployment, but the primary purpose is unambiguous.

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, and the description reiterates 'Read-only' and adds the 'snapshot' nature. No conflicting or unexpected behaviors are implied, though it doesn't mention additional side effects or data freshness details, which is acceptable given 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 two concise sentences. It front-loads the primary purpose and then provides alternative tool guidance, with no unnecessary details 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?

For a tool with no parameters and no output schema, the description sufficiently explains what data is returned (profile, subscription, quotas, usage, projects) and explicitly differentiates it from sibling tools. It is complete for an agent to decide and invoke correctly.

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

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

The tool has no parameters, and the schema coverage is trivially complete. The baseline for zero-parameter tools is 4, and the description adds no parameter-specific information since none exist.

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

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

The description clearly states the tool's function as a full account snapshot covering profile, subscription, quotas, usage, and projects, and distinguishes it from related tools. It uses specific verbs and identifies the resource (account).

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

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

It explicitly instructs when to use this tool versus alternatives: use get_quotas_and_usage for limits only, and get_account_console_kit for rendering a local HTML console. This provides clear when-to and when-not-to 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 indicate read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond those annotations by specifying what the returned artifact contains and that the operation is read-only. It does not conflict with annotations.

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

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

Three short sentences deliver the purpose, composition, usage context, and key alternatives. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is complete: it states what the kit contains, how to use it locally, where to get the token, and which sibling to use for plain JSON. Nothing essential 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 has zero parameters and the schema coverage is 100%, so the schema already conveys all input requirements. The description appropriately references related session tokens from create_account_session, adding useful context despite no direct parameters being involved.

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

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

The description clearly identifies the tool as providing a 'JSON kit' for writing a local novence-console.html, listing its contents (snapshot, HTML template, session mint instructions). It also differentiates itself from the sibling get_account, which provides JSON without the kit, so an agent can tell them apart.

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 explicit routing guidance: use create_account_session for the mgmt_ token, and use get_account for JSON without the kit. It also states the intended local usage ('Serve on localhost'), leaving no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Read' is consistent with those annotations but adds no new behavioral traits like error conditions, staleness, or permissions. The sibling note implies it does not trigger a run, which is mildly useful but largely restates the read-only nature already captured.

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 sentences with no fluff. Purpose is front-loaded, followed by default behavior and sibling routing. Every clause earns its place and the whole definition is compact and scannable.

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 tool with two well-documented parameters and annotations covering safety, the description is complete. It names the result categories, explains the deployment default, and routes to the correct sibling for triggers and publish state. No output schema exists, but the description sufficiently conveys what the tool returns at a conceptual level.

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 project_id and deployment_id are already fully documented. The description's 'Omit deployment_id for the latest' largely repeats the schema's own 'Omit to use the project's latest deployment,' adding no new semantic information beyond what the schema provides.

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

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

The description opens with a specific verb 'Read' and concrete resource types: 'Lighthouse, a11y, and link results for a deployment.' It clearly differentiates from siblings by naming run_checks and get_deployment_status, so an agent can tell this is a read-only results fetch, not a trigger or deployment status call.

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 tells the agent when to use alternatives: 'Use run_checks to trigger a new cycle; use get_deployment_status for publish/promote state, not scores.' It also states the default behavior for deployment_id, leaving no ambiguity about calling patterns.

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 annotations (readOnlyHint, idempotentHint, non-destructive), the description adds meaningful operational context: the publish lifecycle states, the polling-friendly semantics, and the warning not to retry deployment during active states. This helps an agent understand not just that it is read-only, but how to interact with it safely over time.

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 front-load the tool's purpose, then cover parameter shortcut, sibling routing, and safety guidance. There is no filler or redundant explanation; 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 simple two-parameter polling tool with strong annotations and full schema coverage, the description is complete: it tells the agent when to poll, how to select the latest deployment, what related tools to use instead, and how to avoid unsafe retries. No critical guidance is missing.

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

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

The schema already documents both parameters thoroughly at 100% coverage, including project_id provenance and deployment_id omission semantics. The description reinforces the omission behavior but does not add new parameter meaning beyond what the schema provides, so the 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 opens with a specific verb and resource: 'Poll publish state after deploy' and lists the exact states (queued, checking, promoting, live, failed). It also distinguishes itself from sibling tools by explicitly routing the agent to get_checks_results and get_preview_url for different kinds of information.

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 clearly states when to use the tool ('after deploy'), how to target the latest deployment ('Omit deployment_id for the latest'), and which sibling tools cover related but different needs (checks scores, preview URL). It also gives an explicit negative instruction: 'do not retry deploy while promoting or checking.' This is exemplary 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 readOnlyHint, idempotentHint, and destructiveHint=false, and the description is consistent with them. It adds useful context beyond the annotations: the tool is a post-configuration poll target and returns current hostname and certificate state. It could go further by describing states or failure behavior, but the main behavioral traits are covered.

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-load the verb and resource, then add workflow context and a usage warning. There is no filler; every sentence contributes (including the final 'Read-only' safety cue).

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, read-only getter with no output schema, the description is complete: it names the trigger condition, the return content (hostname and certificate state), and the polling intent. Nothing an agent needs to decide when and how to call it 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 project_id documented as 'Hosting project UUID from create_project or list_projects.' The description adds no new parameter semantics, and the baseline of 3 applies because the schema does the work.

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

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

Description uses specific verb 'Read' and a clear resource: DNS and TLS status for the project's custom hostname. It also positions the tool relative to configure_custom_domain by saying it is used after that step, and explicitly distinguishes it from attaching a domain.

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?

States exactly when to use it ('after configure_custom_domain'), gives an exclusion ('Do not use this to attach a domain'), and provides a polling usage pattern ('Poll until verified'). This is explicit guidance with no reliance on 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, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond annotations by clarifying that the return value is metadata rather than file bytes, and that the path refers to a staged path. This is meaningful for agent expectations.

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, zero filler, with the core purpose and key differentiators front-loaded. Every clause earns its place, and the read-only note reinforces the annotation without 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?

For a two-parameter read-only metadata tool with strong annotations and schema coverage, the description is nearly complete. The only minor gap is that it does not enumerate what metadata fields are returned, which would be more important given there is no output schema. Still, the tool is simple enough that an agent can correctly invoke it.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description does not add additional parameter-level semantics, but the baseline of 3 applies because the schema carries the burden.

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

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

The description uses a specific verb-resource pair ('Return metadata for one staged path') and immediately disambiguates what the tool does not do ('not file bytes'). It is clearly distinct from sibling tools like get_upload_url and list_files.

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 names two alternatives and the conditions for using them: 'Use list_files to discover paths; use get_upload_url to replace content.' This gives an agent direct routing guidance for the most relevant 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 already communicate read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: the returned URL is public and follows the https://{suffix}.novence.ai format, and it points out that liveness must be checked separately. No contradiction with annotations.

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

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

Three short sentences with zero filler. The core behavior is first, usage alternatives follow, and the read-only note is minimal. 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?

For a single-parameter read-only URL retrieval tool, the description fully covers the return value, how to verify liveness, and the custom-domain alternative. Annotations cover safety, and no output schema is needed for such a simple return.

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 input schema covers project_id with full description, so the baseline is 3. The description references 'a project' but does not add new semantic detail about the project_id parameter itself, which is acceptable given the schema's 100% 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 ('Return') and resource (the public https://{suffix}.novence.ai URL for a project). It also explicitly distinguishes itself from get_deployment_status and configure_custom_domain, so an agent can tell them apart without inspecting 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?

Directs the agent to get_deployment_status for checking liveness and to configure_custom_domain for custom hostnames. This is explicit when-to-use and when-not-to-use guidance with named alternatives.

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, and destructiveHint, so the safety profile is already known. The description reinforces 'Read-only; does not mutate' and clarifies that it returns one project, but it does not add substantial behavioral context beyond the annotations, such as error behavior or 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?

The description is short and front-loaded with the core purpose, followed by routing guidance and a safety note. The phrase 'Read-only; does not mutate' is slightly redundant with the provided annotations, but the overall structure is still efficient and scannable.

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 read-only tool with no output schema and many siblings, the description covers the core purpose, the return content, how to get the ID, and which sibling tools to use for related but different needs. Nothing essential for correct selection and invocation is missing.

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

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

Schema description coverage is 100%: the single parameter project_id is described as a hosting project UUID from create_project or list_projects. The description repeats the list_projects discovery hint but adds no new constraints or format details beyond what the schema already provides, 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?

The description states a specific verb and resource: 'Return one hosting project' and enumerates what is included (name, suffix, settings, membership). It clearly distinguishes itself from list_projects and other get_* siblings by emphasizing it returns a single project.

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 guidance is explicit: 'Use list_projects to discover IDs' tells the agent how to obtain the required param, and it names two concrete alternatives for when the agent wants a different result (get_preview_url for public URL, get_project_usage for quotas). This leaves little room for ambiguity.

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

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

The description adds meaningful behavioral details beyond the readOnly and idempotent annotations: it discloses the off-by-default state, the exact setting needed to enable it, and the return behavior when disabled (enabled=false and empty totals). This gives the agent realistic expectations for side effects and conditional responses.

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 compact and highly informative. It front-loads the core purpose, then covers the enablement prerequisite, date defaults, and disabled-state behavior without extraneous 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?

Given the lack of an output schema, the description does a good job summarizing the returned analytics categories and the special disabled-state payload. It could be slightly more explicit about the overall return structure when analytics are enabled, but the information provided is sufficient for correct selection and invocation.

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

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

Schema coverage is 100%, so the schema already documents project_id, from, and to including defaults and inclusive semantics. The description reinforces the date defaults and max 90-day range, but does not add significant new parameter meaning beyond what the schema provides.

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

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

The description clearly identifies the tool as retrieving project analytics, listing specific metrics (pageviews, 404s, top pages, referrers, countries). It also frames the data as 'cookieless edge analytics for a hosted site,' which distinguishes it from broader project or usage tools like get_project_usage.

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 important usage context: analytics are off by default and must be enabled via update_project_settings with analytics_enabled=true. It also states default date ranges and max range, giving the agent clear conditions for invocation. It does not explicitly contrast with related tools, but the use case is well 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds one useful behavioral detail: bandwidth is live from edge-served bytes, but it does not describe return shape, units, time ranges, or other operational behaviors. This is moderate extra context 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 compact and front-loaded: the core purpose appears in the first sentence, followed by a key behavior note and explicit sibling routing. Every sentence earns its place with no filler.

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

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

For a simple one-parameter read-only tool with strong annotations, the description provides sufficient context: scope, a live-data nuance, and alternatives. No output schema exists, but the listed usage categories make the expected return clear enough for this low-complexity 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 100% and the single project_id parameter already has a clear description identifying where to obtain it. The tool description does not add further parameter-level meaning, so a baseline score 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?

The description states a specific verb and resource: per-project usage, and enumerates its scope (storage, deploys, check minutes, bandwidth, forms). It also distinguishes itself from sibling tools by explicitly naming get_quotas_and_usage and get_project_analytics as covering account totals and pageviews respectively.

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 explicit: this tool is for per-project usage, while get_quotas_and_usage is for account totals and get_project_analytics is for pageviews. This gives an agent clear routing guidance without needing to inspect sibling schemas.

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, and destructiveHint, so the safety profile is covered. The description adds meaningful context beyond annotations by clarifying this is a point-in-time snapshot rather than a live meter stream, which is important for agents deciding whether the data is fresh enough.

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 with no filler. The core purpose is front-loaded, the alternatives are given next, and the behavior caveat closes it. 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?

For a zero-parameter read-only tool, the description covers scope, data categories, sibling alternatives, and data-freshness limitations. Annotations cover the safety profile, and no output schema exists, so nothing critical is missing for an agent to invoke it correctly.

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

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

The input schema is empty, so there are no parameters to document. The description correctly communicates what data the tool reports, and no additional parameter guidance is needed. Baseline 4 is appropriate for a zero-parameter tool.

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

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

The description names a specific resource ('Account-level plan limits and current consumption') and a concrete set of data (projects, storage, deploys, bandwidth), and it explicitly distinguishes itself from sibling tools by naming get_project_usage and get_account. A selecting agent can immediately see both the scope and the differentiation.

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

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

It gives direct routing guidance: 'Use get_project_usage for one site; use get_account for profile plus quotas together.' It also adds a usage caveat with 'Read-only snapshot, not a live meter stream,' which tells the agent when this tool is not appropriate (when live streaming data is needed).

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

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

The annotations provide no read-only, idempotent, or destructive hints, so the description carries the burden. It does reveal that the result is a presigned PUT URL, which implies write access, and notes content_type inference, but it omits behaviors such as whether the URL expires or how it should be supplied to the PUT request.

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, with the main verb-claim first and optional detail plus routing second and third. 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?

There is no output schema, so the description's mention of a presigned PUT URL provides the core return-value information. It also names the post-PUT confirm_upload step, giving the agent the workflow context. It leaves out URL expiration and upload-size limits, but those are secondary for selecting and invoking this 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?

Since schema coverage is 100%, the schema already documents path and project_id. The description's statement that content_type is optional (inferred from extension) restates the schema's own note, adding no independent meaning. Overall parameter semantics are adequately covered by structured data.

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 a presigned PUT URL for one site file.' The 'one site file' qualifier immediately distinguishes it from get_upload_urls_batch, so no sibling ambiguity.

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

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

Explicitly names get_upload_urls_batch as the alternative for multi-file sites and instructs calling confirm_upload after the PUT. This gives clear when-to-use and next-step guidance.

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

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

The description discloses workflow behavior such as the 100-item limit and the required confirmation step after PUTs, which is useful. However, with all annotations false, it does not clarify the operation's actual effects on state, URL expiry, or authorization requirements, so the behavioral profile is only partially transparent.

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 three short sentences with no filler. The core purpose and batch constraint are front-loaded, and the sibling-based guidance and follow-up instruction each earn their 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 batch URL-generation tool with a detailed input schema and clear workflow references, the description covers the essential selection and sequencing context. It does not describe the response shape, but that is partially implied by the tool name and the described PUT-then-confirm 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 100%, so the parameters are already well documented in the schema. The description adds only the batch limit and the follow-up workflow, not significant new parameter meaning, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: "Presign many site files at once (max 100)". It clearly establishes this as the batch counterpart to get_upload_url, making the purpose and scope immediately identifiable.

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 explicitly says to prefer this over get_upload_url for multi-file sites, and it also prescribes the correct follow-up call (confirm_uploads_batch, not confirm_upload). This gives an agent concrete selection and sequencing guidance with no inference required.

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 annotations, the description discloses important behavioral constraints: the Pro/Scale requirement, the owner-only admin privilege, and the security caution about the owner's nv_ key. These are useful behavioral/authorization details not present in the structured fields. It does not detail side effects like email delivery or duplicate invite handling, but the annotations already establish this is a non-read, non-idempotent 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?

The description is compact, with the primary action front-loaded and four short sentences covering purpose, prerequisites, alternative routing, and a security note. The sentence about create_project is slightly awkward and could be clearer, but overall there is no wasted content.

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 targeted invitation tool with full schema coverage and no output schema, the description covers the key prerequisites, role restrictions, and a pointer to the alternative creation tool. It could additionally mention how pending invitations are managed by sibling tools like revoke_project_invite or accept_project_invite, but the essential information for invoking the tool correctly is 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?

The input schema already documents all 3 parameters with 100% coverage, including role enum and email format. The description adds minimal semantic value beyond the schema, mostly restating the email-based invite action and the owner/admin constraint already present in the role description. This meets the baseline for full 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 clearly states the action — inviting a collaborator by email — with a specific verb and resource. It also explicitly distinguishes from create_project by directing callers to use that tool for new project creation, which disambiguates the sibling set.

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 concrete usage context: it requires Pro/Scale on the project owner, restricts admin invitations to the owner, and points to create_project as the alternative when creating a new project. It does not explicitly contrast with invitation lifecycle siblings like accept_project_invite or revoke_project_invite, but the core usage conditions are clear.

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 the description adds a specific consequence: 'Revokes your project keys.' It also discloses the ownership restriction, giving meaningful context beyond the annotation.

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

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

Three terse, information-dense sentences. Each sentence carries a distinct purpose: primary action, constraint, and alternative tool routing.

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 one-parameter action, the description covers action, authorization scope, side effect, and alternative path. It is complete enough for an agent to invoke the tool correctly without additional 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?

The schema fully describes project_id as a UUID from create_project or list_projects. Since schema coverage is 100%, the description need not add parameter 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: 'Leave a project you were invited to.' It clearly distinguishes itself from remove_project_member by noting that owners should not use this tool for removing others.

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 states when to use (invited members leaving) and when not to use (owners must transfer or stay). It also names the alternative remove_project_member for owner-led removal, leaving no ambiguity for an agent.

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, and destructiveHint, so the safety profile is covered. The description adds that files are staged and that listing does not deploy, but it does not disclose pagination, limits, or error behavior. This is adequate but not rich beyond the annotations.

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

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

Three sentences with no filler. The primary action and scope are front-loaded, and the alternative-tool routing is compactly placed without unnecessary 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 simple, single-parameter, read-only listing tool, the description is complete: it states what is listed, the output fields, the scope (staged site files), and the relevant sibling alternatives. No output schema exists, but the description covers the return contents well enough.

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 single parameter project_id is already fully documented in the schema with a UUID format and source guidance. The description only says 'for a project,' adding no meaningful semantics beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb ('List'), names the resource ('staged site files for a project'), and enumerates the returned fields (paths, types, sizes). It is clearly distinguishable from sibling tools by explicitly contrasting with get_file and delete_file.

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 direct routing guidance: use get_file for one path's metadata, use delete_file to remove a path, and 'does not deploy' rules out deploy as a side effect. This is explicit when-to-use and when-not-to-use guidance.

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

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

The annotations already declare readOnly, idempotent, and non-destructive, and the description repeats "Read-only" without contradicting them. It adds useful behavioral context by stating the result surface (ids, slugs, status) and narrowing scope to project-level forms, though it does not cover pagination or auth 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?

The description is compact and front-loaded with the core purpose, followed by useful sibling routing in the second sentence. The final "Read-only" is slightly redundant with the annotations, but it does not meaningfully bloat the entry.

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 read-only list operation with rich annotations, the description covers scope, return fields, alternatives, and exclusions. No output schema is present, so listing the returned fields is enough, and nothing needed 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?

The only parameter, project_id, already has 100% schema description coverage, including its format and origin ("Hosting project UUID from create_project or list_projects"). The description adds no additional parameter-level meaning, so the 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 opens with a specific verb and resource — "List Novence forms on a project" — and names the returned fields (ids, slugs, status). It also distinguishes itself from sibling tools by pointing to update_form and list_form_submissions, so an agent can tell this is the read-only form index.

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 explicitly provides routing guidance: use update_form to change a form and list_form_submissions to read leads. The exclusion "Not for third-party widgets" gives a clear when-not case, making the invocation context unambiguous.

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, and non-destructive behavior. The description adds useful context beyond annotations: it is paginated, scoped to one form, and PII removal is delegated to a different tool. This is meaningful behavioral context without contradicting 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 short sentences, each earning its place: purpose, pagination, and routing to alternatives. The core behavior is front-loaded, and there is no redundant fluff.

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 list operation with fully documented parameters and strong annotations, the description covers the essential context: what it lists, pagination, read-only safety, and where to go for destructive or schema-changing actions. The lack of return-value details is a minor gap given no output schema exists, but not a critical one for selecting and invoking this 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?

Input schema coverage is 100%, with each parameter already described in the schema. The description adds only general scoping context ('one form', 'paginated') rather than deeper parameter-specific semantics, 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?

The description names a specific verb (List), a specific resource (visitor submissions for one Novence form), and the pagination behavior. It clearly distinguishes this tool from siblings like delete_form_submission and update_form by scoping the purpose.

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 explicitly tells the agent when to use an alternative: 'Use delete_form_submission to remove PII' and 'Not for update_form schema changes.' This gives clear routing guidance and prevents misuse.

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, idempotentHint=true, and destructiveHint=false, so 'Read-only' adds little. The description does add the behavioral scope that pending invites are included alongside members, but it omits response structure and pagination. With annotations carrying the safety profile, this is acceptable 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 core purpose is front-loaded in the first sentence, followed by two compact sentences covering alternative tools and read-only behavior. There is no filler, and each clause contributes actionable information.

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

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

For a simple, one-parameter read-only tool with annotations covering safety and an input schema that fully contextualizes project_id, the description is complete. It identifies the result categories and adjacent tools, so an agent has enough to select and invoke it correctly.

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

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

The only parameter, project_id, is fully described in the schema with provenance from create_project or list_projects. The description adds no additional meaning about the parameter, so the baseline 3 applies due to 100% 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?

States a specific verb and resource: 'List members and pending invites for a project.' The inclusion of 'pending invites' distinguishes it from pure member-listing tools, and naming the sibling mutation tools makes the boundary 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?

Provides explicit alternatives for the related actions: invite_project_member to add, revoke_project_invite for pending tokens, and remove_project_member for accepted collaborators. This tells an agent exactly when to use this tool instead of a different one.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds useful behavioral context beyond the annotations: the result is limited to caller-owned or invited projects and contains ids, names, and suffixes. It also reinforces the read-only nature, which is redundant with the annotations but still helpful given the existence of create_project.

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 carry all the essential information with zero filler. The primary purpose and scope are front-loaded, and the sibling routing and read-only note follow efficiently.

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 zero parameters, no output schema, and strong annotations, the description is complete: it states what is listed, the result contents, the ownership scope, the sibling alternatives, and the safety profile. There is no missing information an agent would need to call this 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?

The tool takes no parameters and the schema coverage is trivially 100%, so the baseline of 4 applies. The description adds no parameter-specific meaning, but no parameters exist for it to clarify.

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 begins with a specific verb and resource ('List hosting projects') and defines the scope ('the caller owns or is invited to') and returned fields ('ids, names, suffixes'). It also explicitly distinguishes itself from get_project and get_preview_url, so an agent can tell this tool apart from its siblings.

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

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

The description gives explicit routing guidance: 'Use get_project for one project's settings; use get_preview_url for the live URL.' It also adds a clear exclusion ('does not create a project'), helping the agent avoid confusing this list operation with create_project or other mutation 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?

Discloses non-obvious behavior beyond annotations: the first call returns a 402 challenge, the retry needs payment_authorization, and the timing constraint around the first live URL. Annotations provide readOnly=false and idempotent=false, but the description adds the essential payment-challenge rhythm and prerequisites.

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 with no filler. The core purpose is front-loaded, and each subsequent sentence adds a necessary behavioral or usage detail. The description remains compact despite encoding a multi-step payment protocol.

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 complexity of a payment upgrade flow, the description covers prerequisites, challenge/retry, and timing constraints, which is substantial. Minor gaps remain: the description doesn't state what a successful retry returns or how exactly to attach the alternative '_meta' credential, but these are secondary to 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 input schema already describes both parameters with 100% coverage, including 'Omit on the first call' for payment_authorization. The description reinforces this but adds only the alternative '_meta org.paymentauth/credential' and the plan names, which are already in the schema enum. This meets the baseline 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 opens with a specific action and resource: 'Start or complete Pro/Scale via Machine Payments Protocol.' It clearly identifies the tool's function and distinguishes it from payment-adjacent siblings like checkout by tying it to the upgrade flow and the 402 challenge lifecycle.

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 states prerequisites ('Requires nv_ + verified email'), the 402 challenge retry flow, and the exact trigger condition ('Use after a 2nd project or a 402 — never after the first live URL'). This gives the agent unambiguous when-to-use and when-not-to-use guidance.

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

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

The description explicitly warns that prior account-scoped nv_ keys are revoked, which aligns with destructiveHint=true and goes beyond what the annotation states. It also discloses the side effect that email verification may be performed. This is valuable behavioral context for an agent.

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 concise sentences with the purpose stated first and the critical revocation warning placed prominently. There is no filler or redundant restating 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?

For a destructive, non-read-only tool with no output schema, the description covers the purpose, authentication requirement, destructive side effect, and additional verification behavior. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so both email and code are already documented. The description confirms that code is an email OTP and email is the account owner, but it does not add meaningful detail beyond what the schema already provides.

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

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

The description uses a specific verb ('Mint') with a resource ('new account nv_ key') and identifies the required credential source ('from email OTP'). It clearly distinguishes this tool from sibling auth-related tools like verify_email, resend_verification, and create_account_session.

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 clear context: no Bearer key is required, and the operation depends on an email OTP. The schema further references resend_verification as the OTP source. It does not explicitly name alternatives or when-not-to-use scenarios, but the trigger conditions are evident.

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

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

Annotations already mark this as destructive, but the description adds meaningful context: API key revocation, the irreversible nature, and the need to re-invite afterward. This goes beyond the structured 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 short, purposeful sentences. The main action, permission requirement, alternative, and consequence are each stated without redundancy or filler.

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

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

For a destructive, two-parameter mutation tool with full schema coverage and clear annotations, this description covers the essential behavior, prerequisites, alternative route, and irreversibility. Nothing critical 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?

Schema coverage is 100% with clear descriptions for both project_id and account_id. The tool description does not add parameter-specific meaning, but the schema already documents the parameters well, 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 and resource: 'Remove an accepted collaborator and revoke their project API keys.' It clearly differentiates from the sibling revoke_project_invite by specifying 'accepted collaborator' versus 'pending invite.'

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 states the owner-only condition for admins and names the alternative tool, revoke_project_invite, for pending invites. This gives an agent clear routing guidance without ambiguity.

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 all annotations false, the description carries the burden of behavioral disclosure. It does disclose the side effect of emailing a new OTP, the lack of authentication requirement, and a precondition. It does not discuss response behavior, previous-OTP invalidation, or rate limits, but for a simple one-parameter action this is reasonably adequate.

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 compact sentence containing the core action, an alternate-use note, the authentication requirement, and a precondition. Every clause adds useful information with no unnecessary 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 tool with one simple required parameter and no output schema, the description covers the essential context: what it does, authentication expectations, and when it applies. It omits error scenarios and response format, but these are less critical for this straightforward email-sending action.

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 only parameter, email, is already described as the account email to receive a new OTP. The tool description adds no additional meaning about the parameter, so a baseline score 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?

The description identifies the action with a specific verb and resource: 'Email a new OTP.' It also tells the agent the tool works when the account is already verified and mentions a connection to reissue_key. However, it does not explicitly contrast with the sibling verify_email, so some distinction is left to inference.

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

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

The description gives useful usage context: no Bearer key is required and it works when the account is already verified. This implies when to use it, but it does not explicitly say when not to use it or name an alternative such as verify_email.

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

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

Annotations already flag this as destructive and non-idempotent; the description adds that the operation is 'Irreversible for that invite_id' and that it does not affect accepted members. This is valuable context beyond the annotations, though it could have mentioned required permissions or error cases.

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?

Only two sentences, front-loaded with the main purpose, then alternatives and irreversibility. Every sentence earns its place with no filler.

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

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

For a two-parameter destructive tool with no output schema, this description is complete: it states what the tool does, its boundary condition, the correct alternative, and the irreversible consequence. An agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by tying irreversibility to invite_id ('Irreversible for that invite_id') and clarifies the project scope via 'Cancel a pending invite', slightly enriching the parameter 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?

The description states a specific action, 'Cancel a pending invite', and clarifies the exact effect, 'so the token no longer works'. It also distinguishes itself from remove_project_member, which handles already-accepted members, making the purpose unmistakable.

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 gives the alternative: 'use remove_project_member for that' when someone already accepted, and provides the recovery path: 'send a new invite_project_member if needed'. This tells an agent exactly when to use this tool versus its siblings.

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

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

Annotations only indicate non-read-only, non-destructive behavior; the description adds async behavior ('then poll until scores appear') and clarifies that no deployment is published. It could mention what the call returns or whether it can overwrite an in-progress check, but the added context is valuable.

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, purposeful sentences with no fluff. The core action is front-loaded, and each additional sentence provides either a critical exclusion or a precise next-step instruction.

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 triggering tool with no output schema, the description provides all necessary operational context: what starts, what does not happen, how to verify completion, and an edge-case behavior. The agent can act without further research.

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 project_id parameter already has a useful description referencing create_project or list_projects. The tool description adds no further parameter detail, but none is needed at this level of 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?

States a specific verb ('Start') and resource ('a Lighthouse, a11y, and link check cycle') on the latest deployment. It also distinguishes itself from deploy and get_checks_results, so an agent knows exactly what this tool does beyond its 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?

Explicitly names when not to use it ('use deploy for that') and which sibling to poll next ('poll get_checks_results, not get_deployment_status'). It also covers the unverified-account edge case, leaving little room for incorrect tool selection.

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 annotations, the description discloses the partial-update contract ('omitted fields stay unchanged') and explicitly notes that the operation 'does not delete submissions.' This is valuable behavioral context not present in annotations. It does not contradict the annotations, and the remaining gaps (auth requirements, rate limits) are minor for this 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 sentences, no filler. The primary action is front-loaded, the partial-update contract follows immediately, and the routing guidance to sibling tools is packed into a short sentence. 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?

For an 8-parameter update tool with clear schema annotations and explicit sibling routing, the description is sufficient for correct selection and invocation. It does not describe the response format, but with no output schema and a straightforward patch operation, that omission is unlikely to mislead an agent.

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 input schema covers all 8 parameters with 100% descriptive coverage, so the baseline is 3. The description lists the updatable fields and reinforces partial-update behavior, but it does not add meaning beyond what the schema already documents. The shorthand 'active|disabled' maps cleanly to the status enum but adds no new 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?

The description opens with a specific verb and resource: 'Patch an existing Novence form', and lists the updatable attributes. It explicitly contrasts with create_form and implicitly with deletion tools, so an agent can immediately see this is an update operation on an existing 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?

The description gives concrete routing guidance: 'Use create_form for a new form; use list_forms to get form_id.' It also clarifies partial-update semantics and states that submissions are not deleted, which helps avoid confusion with submission-management 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 mark this as non-read-only and non-idempotent. The description adds meaningful behavioral context beyond annotations: only the owner can grant or demote admin, and the operation does not affect pending invites. This clarifies permissions and boundary behavior without contradicting 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 short sentences, each earning its place. The core action is front-loaded, followed by the key permission constraint and then the sibling-tool routing. There is no filler or redundant restating 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 simple three-parameter role-update tool, the description covers the action, the permission boundary, and the exclusions that could otherwise cause misuse. Given the schema already documents parameter meaning and sources, nothing important is missing for an agent to select and invoke this 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%: each parameter already has a clear description, including the role enum and the provenance of account_id and project_id. The description does not need to repeat these details and adds no significant parameter-level 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?

The description opens with a specific verb and resource: 'Change a collaborator's role.' It clearly distinguishes itself from related sibling operations by explicitly naming remove_project_member and revoke_project_invite as the tools for different actions, so an agent can tell them apart immediately.

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 explicit routing guidance: use this tool to change roles, use remove_project_member to revoke access, and use revoke_project_invite for pending invites. It also states the owner-only constraint for admin grants/demotions, which is essential for correct use.

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 provide no readOnly, idempotent, or destructive hints, so the description carries some burden. It does add useful context about analyticsEnabled ('cookieless edge traffic; off by default'), but it does not disclose permissions, side effects, or whether changes are applied partially or fully. This is acceptable but not comprehensive for a mutation 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?

The description is a single efficient sentence that lists the affected fields and includes the key default behavior. Every part contributes to understanding the tool, and there is no redundant or filler content.

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 five parameters, a nested object, and no output schema, the description is reasonably complete when combined with the rich schema documentation. It names all mutable areas and adds default context for analytics. It could be more complete with explicit usage guidance or permission notes, but the schema and description together cover the essential invocation needs.

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 a baseline of 3 applies. The description adds a meaningful semantic detail beyond the schema by noting analyticsEnabled is 'off by default,' which is not stated in the property description. The other parameter references are consistent with the schema, so the added value is modest but real.

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

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

The description uses a specific verb ('Update') with a clear resource ('project settings') and enumerates the exact mutable fields: name, description, check thresholds, and analyticsEnabled. This distinguishes it from sibling tools like update_form or update_project_member, which target different resources.

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 intended use is implied by the title and field list, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions such as 'use update_project_member for member changes.' An agent can infer the use case but is not given explicit 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 provide no read-only or safety hints (all false), so the description adds value by disclosing the 15-minute TTL and the lack of auth requirement. It does not detail what happens on failure or with an expired code, but the primary behavioral constraints are covered.

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 extremely concise: two sentences with no filler. The core purpose is front-loaded, and the sequencing/context follows immediately. Every word 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 simple two-parameter action, the description is complete: it states the operation, the timing, the TTL constraint, and the lack of auth requirements. No output schema exists, but the response semantics of an OTP confirmation are straightforward and don't require elaboration.

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 both parameters ('code' and 'email') are well-described in the schema. The description itself adds no additional parameter-level meaning, 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?

The description states a specific verb and resource: 'Confirm the email OTP'. It clearly distinguishes this from siblings like resend_verification or bootstrap by focusing on the confirmation action and its timing within the flow.

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

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

It gives clear contextual guidance: 'Call after the first live URL, before checkout/mpp_upgrade' and notes that no Bearer key is required. It does not explicitly mention alternatives or when not to use the tool, but the sequencing strongly implies correct usage.

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