simplepages

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

Annotations only declare readOnlyHint=false, so the description carries the meaningful burden: the page is saved as a draft, the home page is created in published state, and the site itself is NOT published by this call. It also discloses inheritance behavior (brand, domain, shared header/footer/theme), which the agent cannot infer from annotations.

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

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

Front-loaded with the action and draft state, followed by the sibling routing and the home-page ordering rule. The "index"/home-page concept is explained across two clauses, a mild redundancy, but every sentence otherwise adds information.

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

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

For a mutating tool with an output schema and full schema descriptions, the remaining unknowns an agent needs are side effects and state changes, which are all covered (draft vs published home page, site not published, inheritance). Nothing required 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% and the schema already explains slug, brief, title and siteId in detail, including the "index" home-page rule. The description mostly restates the slug "index" semantics rather than adding new parameter meaning, so baseline 3 applies; ordering context is the only marginal addition.

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 ("Generate a new page inside an existing website and save it as a draft") and immediately distinguishes itself from the sibling create_page by scope (page belongs to a site). An agent can route correctly without opening the schema.

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

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

Explicitly names the alternative ("Use this rather than create_page whenever the page belongs to a site") and gives an ordering rule for new sites: add the home page (slug "index") first because later pages reuse its header/footer/theme. It also points to list_sites for obtaining a siteId.

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 readOnlyHint=false, so the description carries the burden of behavioral disclosure. It fully discloses that the script is injected when the page is next saved or published, not immediately on already-published pages, and notes the unwrapping of a script tag for inline code. This is transparent and goes beyond the annotation.

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

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

The description is two sentences, front-loaded with the primary action and purpose, followed by usage context and a behavioral caveat. Every clause adds meaningful information without redundancy or fluff, making it highly concise and well-structured.

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 has 6 parameters and an output schema (which covers return values), the description sufficiently covers purpose, timing, and rationale. It references other tools in schema (list_pages/list_sites) and provides enough context for an agent to decide when to use it. The description is complete for a mutation tool with this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters with detailed explanations (e.g., character limit, defaults, enum choices). The description adds minimal parameter-specific value; it mentions 'either by URL or as inline code' which aligns with url/code, but does not introduce new semantics. 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 clearly states the tool attaches a third-party script to a page via URL or inline code, with a specific resource (page) and action (add). It also differentiates from editing page HTML by emphasizing the script survives page edits, which distinguishes it from sibling tools like edit_page.

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-to-use guidance: 'Use this for analytics, pixels, chat widgets and similar integrations rather than editing the page HTML' and clarifies that the change takes effect on next save or publish, so it's clear when live. It also implies a contraindication: not for scripts that need immediate effect or are too large, as the code param mentions hosting larger scripts via URL.

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 specify readOnlyHint: falseainer, so the description carries the burden of behavioral disclosure. It clearly explains the test POST on enabling, the conditional activation (only if test succeeds), and the refusal of unsafe URLs. It does not mention side effects like rate limits or data format, but the core behavior is well disclosed.

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

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

The description is two sentences long and front-loads the main purpose, then adds a critical behavioral caveat (test on enable) and a practical alternative. Every word adds value, with no unnecessary repetition or 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?

The description fully covers the tool's purpose, usage context, alternatives, and the critical enable-test behavior. It slots well alongside sibling tools by clarifying what this one does (add webhook) and how it differs from the fetch approach. The output schema exists elsewhere, so no need to detail return values.

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 each parameter is already well-documented in the input schema (e.g., url's test requirement, siteId's choice guidance). The tool description adds minimal extra semantic value beyond the schema, only reiterating the test behavior and the URL constraint already present in schema. Thus, 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 clearly states the tool's purpose: forwarding captured leads to a URL, with specific scope (page or site) and target (Zapier, Make, CRM, or own endpoint). It is specific and distinguishes from sibling tools by focusing on webhook creation rather than pages or redirects.

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 advises 'Use this instead of adding fetch() to the page,' offering a direct alternative. It also provides context on when to use siteId vs pageId, noting 'siteId... Usually the right choice for a CRM or automation that should cover the whole website.' This covers both when to use and how to choose parameters.

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 state that this is not read-only, while the description adds meaningful behavioral context: it creates a real page in the workspace, saves it as a draft, allows opening/publishing later, and returns preview and edit URLs. This goes well beyond the annotation and clearly indicates mutation and draft-state behavior.

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

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

The description is concise and front-loaded: the first sentence states the action, subsequent sentences explain output, draft state, and the separate publishing step. Every sentence adds useful information without repetition 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 output schema and full parameter schema coverage, the description is complete enough for an agent to call the tool correctly. It also adds the important context that creation results in a draft rather than a published page, which is not captured by the minimal annotations.

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 all four parameters are already documented in the input schema, including name, outline, description, and workspace_id semantics. The description adds only a high-level reference to generating from a description and does not add parameter-specific detail beyond the schema, 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 uses a specific verb and resource: generate/create a new landing page from a description, and it clarifies that a real workspace page is produced. It does not explicitly differentiate itself from sibling tools such as add_page_to_site or create_site, so it falls short of a 5.

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

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

The description implies the tool is for creating a new landing page and notes that publishing is a separate step, which gives some usage context. However, it does not explicitly say when to use this tool versus add_page_to_site, create_site, or edit_page, leaving alternatives to inference.

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

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

Beyond the readOnlyHint annotation, the description discloses the key behavioral trait that redirects only take effect after the next publish, which is a separate step. This adds important context for the agent. 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?

The description is two concise sentences that are front-loaded with the primary action and then provide usage guidance and a key caveat. 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?

Given the tool's moderate complexity (4 params, output schema present), the description covers purpose, usage, and the deferred publication effect. Parameter details are handled by the schema, and the output schema covers return format. It lacks only explicit mention of potential conflicts or idempotency, which are not essential.

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 detailed parameter descriptions for all fields, including wildcard and status code semantics. The description adds no additional parameter information, so 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?

Clearly states it adds a URL redirect rule to a website, with the specific purpose of handling moved pages or changed URLs. Distinguishes from sibling tools like add_page_to_site or delete_redirect by focusing on redirect 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?

Gives a concrete use case: 'Use this when a page moves or a URL changes, so existing links keep working.' Also notes that redirects take effect on next publish, implying when to expect activation. Does not explicitly list alternatives or exclusions, but the context is 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 are sparse (only readOnlyHint=false), so the description carries the burden. It discloses key behavioral traits: the site starts empty, pages must be added via a sibling tool, and the home page convention (slug 'index') is documented. Could mention persistence/auth/rate-limit side effects of a mutation, but for a create operation the workflow disclosure is strong value-add beyond the structured data.

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, front-loaded with the core verb+object, then two bits of high-value context (workflow next step, alternative tool). Zero waste — every clause adds information an agent couldn't infer from the name or schema alone.

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

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

For a 2-parameter creation tool with an output schema and readOnlyHint=false annotation, the description is complete: purpose, workflow, and alternative tool are covered. The output schema covers return values, so no redundancy is needed there. Nothing material is missing for an agent to invoke this 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%, and the schema itself is unusually rich (name is 'not the domain', workspace_id explains single vs. multi-workspace error behavior). The description text doesn't repeat params, which is correct — with complete rich schema coverage, the baseline of 3 applies and the schema's own quality elevates it to a 4 since the agent gets complete param semantics from the combined picture.

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

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

Specific verb+resource: 'Create a new multi-page website in the workspace.' The description explicitly distinguishes it from siblings by calling out multi-page vs. standalone landing page, naming create_page and add_page_to_site as the alternatives. This is exactly what a purpose statement should do.

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?

Explicit when/when-not/alternatives guidance: 'use add_page_to_site to build its pages' explains the forward workflow, and 'To make a single standalone landing page instead, use create_page' gives a direct alternative with reasoning. No ambiguity about which tool to pick.

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 readOnlyHint=false, so the description carries the burden of disclosing effects. It clearly states that the old path stops redirecting and may 404, and that changes apply on next publish—valuable behavioral context beyond the schema.

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

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

The description is two sentences, front-loaded with purpose, and includes only necessary details about consequences and timing. No wasted words.

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

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

For a simple delete operation with two well-documented parameters, the description covers purpose, prerequisite, effect, and timing. It lacks potential edge cases (e.g., non-existent redirect) but the output schema likely addresses that. Overall sufficient.

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

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

Schema coverage is 100% and both parameters already have descriptions including source (id from list_sites, redirectId from list_redirects). The description repeats 'Get the redirectId from list_redirects' without adding new semantic information, so it meets the baseline without exceeding it.

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

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

The description states 'Delete a redirect rule from a website' with a specific verb and resource, and distinguishes from siblings like create_redirect and list_redirects. It also clarifies that the redirectId comes from list_redirects.

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 provides a prerequisite ('Get the redirectId from list_redirects') and explains the consequence (404 unless a page exists) and timing (takes effect on next publish). This gives clear context for when to use the tool, though it doesn't explicitly mention 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?

The description goes beyond the readOnlyHint annotation by explaining edits happen in place, results go to a draft, the change is not published until separately published, and existing style/layout/images are preserved. This is meaningful behavioral context not derivable 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?

Four focused sentences lead from purpose to examples to behavior to prerequisites. Each sentence adds distinct information, and there is no repetition 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 only two parameters, existing annotations, and an output schema, the description fully covers what tool does, what happens to the draft, publish semantics, page types supported, and how to locate the required pageId. It is sufficiently complete for an agent to invoke correctly.

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

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

The schema already covers both parameters thoroughly (100% coverage), so the baseline is 3. The tool description adds value with plain-language instruction examples for the instructions parameter and extends page ID lookup guidance to list_sites, raising it slightly above baseline.

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

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

The description states the tool's exact function: changing an existing landing page using plain-language instructions, with concrete examples. It clearly distinguishes from sibling create_page by emphasizing 'existing' and 'change in place'.

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 editing existing pages, explains that changes are saved to draft and not published, and tells users to find the page id via get_page/list_pages/list_sites. However, it does not explicitly name create_page as the alternative for new pages, so it stops short of an explicit when-not-to-use statement.

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 readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description adds the returned field set, but since an output schema exists that information is largely duplicated rather than adding new behavioral context such as not-found handling or pagination/rate considerations.

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 waste, with the core action and lookup key front-loaded and the return payload summarized after. Nothing redundant or padded.

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

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

For a single-record read with a fully documented one-parameter schema, readOnlyHint, and an output schema, the description covers everything needed to invoke it correctly. Minor gap: no note on behavior when the UUID is unknown or belongs to a different workspace.

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

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

Only one parameter and schema coverage is 100%, with the schema already describing pageId as 'the page UUID (id from list_pages / list_sites)'. The description's mention of 'page UUID' reinforces but does not extend the schema, 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 — 'Get details for a single landing page or site page by its id' — and names what comes back (name, status, edit URL, live URL). It implicitly contrasts with list_pages by emphasizing 'single ... by its id', but never names a sibling explicitly.

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

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

Usage is only implied: fetch one record when you already hold a UUID. There is no statement of when to prefer this over list_pages, get_page_analytics, or edit_page, and no prerequisites or failure conditions are mentioned.

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 readOnlyHint=true, so the safe read-only nature is known. The description adds detail about the returned data, but does not disclose additional behavioral context such as date-range defaults, pagination, or permission requirements. It is accurate and does not contradict the annotation.

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

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

The description is a single clear sentence, lists the main content types in a readable serialized format, and includes no filler. It is front-loaded with the tool's action and scope.

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 analytics tool with a full schema and output schema, the description is largely complete: it names the object and the metrics. It could be slightly stronger by clarifying the time window or any default behavior, but no major information gap exists.

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 fully describes pageId as 'The page UUID to fetch analytics for', with 100% schema description coverage. The tool description adds only the general idea of 'one page', so its parameter-level contribution is minimal; the schema carries the weight.

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 specifies a clear verb and resource: 'Get analytics for one page'. It enumerates the exact metric categories (visitors, views, traffic sources, devices, countries, leads, revenue, blocked spam submissions), making its scope unambiguous and distinguishing it from sibling analytics tools.

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

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

The phrase 'for one page' clearly signals page-level scope, which naturally separates it from the sibling tools get_site_analytics and get_workspace_analytics. It does not explicitly state when not to use it or name alternatives, but the scope language is enough to guide correct 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?

Annotations already declare readOnlyHint=true, establishing this is a safe read operation. The description adds behavioral context by detailing the analytics dimensions returned, which helps the agent anticipate the tool's output and scope. It does not cover potential rate limits or aggregation delays, but those are not critical given the annotation and output schema.

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

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

The description is two sentences, front-loaded with the core purpose and scope, followed by a useful sibling alternative. Every clause earns its place with no redundancy or 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?

The output schema already covers return values, so the description need not enumerate them. The provided description adequately conveys scope, the distinction from a sibling tool, and the key data categories, making it complete enough for a tool with only two parameters and a read-only annotation.

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 both parameters thoroughly documented: siteId references list_sites, and source explains 'Direct', example values, and where to get valid values (trafficSources). The description itself adds little parameter-level meaning beyond what the schema already 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 uses a specific verb and resource ('Get analytics for one website') and enumerates the returned metrics: visitors, views, traffic sources, per-page breakdown, leads, and revenue. It also distinguishes itself from sibling tools by noting the website-level scope and directing page-level needs to get_page_analytics.

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 gives an alternative for a different use case: 'For a single standalone page use get_page_analytics instead.' The 'one website' scope also implicitly distinguishes it from get_workspace_analytics, making it clear when this tool is the right choice.

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, so the read-only nature is covered. The description adds context on the scope (workspace-wide) and the type of metrics returned, but provides no further behavioral details such as time ranges or aggregation methods. This adds moderate value beyond annotations.

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

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

The description is a single, well-structured sentence that front-loads the action and scope, then lists the specific analytics components. No wasted words or redundant 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?

Given the tool's simplicity (one optional parameter, output schema exists), the description adequately states what the tool returns. It lists key metrics but doesn't mention potential limitations like time frame or granularity; however, these are likely covered by the output schema. Overall, it is complete enough for its purpose.

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 workspace_id parameter is already fully described in the schema with guidance on omitting vs passing different IDs. The description itself adds no parameter-related information, so it meets the baseline for high coverage.

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

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

The description clearly states the tool's function: 'Get a workspace-wide analytics overview' and lists specific metrics (total visitors and views, top traffic sources, per-page ranking). This distinguishes it from sibling get_page_analytics, which focuses on individual pages.

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

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

The description implies the tool is for workspace-wide analytics by using 'workspace-wide' and listing aggregated metrics. It does not explicitly mention alternatives or when not to use it, but the context and contrast with get_page_analytics are clear enough.

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

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

The annotation readOnlyHint=true already indicates safe read operation. The description adds value by clarifying that spam is excluded by default, results are ordered newest first, and that the return includes contact details, page source, and submitted fields. It does not contradict annotations; it complements them nicely.

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 one focused paragraph, efficiently conveying the use, scoping options, return content, and spam filter. Every sentence adds value, and the whole description is easy to scan using plain language.

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

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

With an output schema present and the description covering read-only behavior, scoping, sorting, and return fields, the description is quite complete. It could mention pagination limits but the schema covers limit/offset. It adequately compensates for the tool's complexity and sibling context, hence a 4.

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 each parameter is well-documented. The description reinforces the meaning of pageId, siteId, and the omission of both, adding contextual explanation (e.g., siteId's precedence over pageId). It also adds insight into includeBlocked usage, which the schema notes but the description clarifies. Since the description adds beyond the schema, a 4 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 the tool lists people who submitted a form (i.e., leads), and specifies the ordering (newest activity first) and the optional scoping (page, site, or all). This distinguishes it from sibling list tools by focusing on lead capture, not pages, scripts, or redirects.

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 states how to scope the query: use pageId for one page, siteId for a whole website, or omit both for all workspace leads. It also mentions the default exclusion of spam and suggests turning on includeBlocked only when reviewing blocked items. This provides clear context for when to use this tool and what parameters to choose.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description usefully adds what each result carries (publish status, edit URL, live custom domain). It does not cover ordering, pagination beyond the schema's limit, or what 'standalone' excludes, so the added behavioral value is moderate.

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

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

A single front-loaded sentence with the resource and scope first and the return payload second — no filler or redundancy.

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

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

With an output schema, readOnly annotations, and fully documented params, the description covers what an agent needs to call it. The only gap is the undefined scope of 'standalone' (whether site-attached pages are excluded), which could affect result expectations.

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%, including the workspace_id fallback behavior, so the description need not restate parameters. It adds nothing beyond the schema, which is the expected baseline when structured fields are complete.

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

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

The description names a specific verb and resource ('List the standalone landing pages in the workspace') and enumerates the returned fields, which lets an agent separate it from get_page or list_sites. It stops short of explicitly stating the boundary with sibling listing tools, so it lands at a strong 4 rather than a 5.

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

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

Usage is only implied: an agent can infer this is the discovery call before get_page/edit_page, but nothing states when to prefer it over list_sites or get_page. No exclusions or prerequisites are given beyond the workspace_id note that lives in the schema.

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 detail about the ordering (source-path order) and redirect types (301 vs 302), which goes beyond the readOnlyHint annotation. It also clarifies the scope per site, adding useful 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?

Two sentences that are concise and front-loaded with the main purpose. No wasted words.

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

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

Given the simple tool (1 param, read-only, has output schema), the description is sufficient. It explains the ordering and redirect types, but could mention that no pagination or filtering is supported, though unlikely needed.

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 siteId is fully described in the schema (coverage 100%). The description adds minimal extra meaning but doesn't need to compensate. 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 clearly states the tool's purpose: listing URL redirect rules on a website, sorted by source-path order. It distinguishes itself from create_redirect and delete_redirect by focusing on listing.

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

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

The description implies the tool is for viewing redirects, but it doesn't explicitly mention when to use it versus alternatives like list_sites or create_redirect. Context is clear but no exclusions or alternative 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 readOnlyHint annotation already signals a safe read operation, and the description adds meaningful behavior: inline code is summarized by length rather than returned in full. This helps the agent set expectations about response content beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the main purpose, and uses examples efficiently. No wasted words or repetition of schema information.

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

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

The tool is simple with one parameter, a read-only annotation, and an output schema. The description covers the core scope and the notable inline-code behavior, making it complete 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?

The schema already documents pageId with full coverage, including a helpful reference to list_pages / list_sites. The description does not add 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?

The description clearly states the tool lists third-party scripts attached to a page, with concrete examples (analytics, chat widgets, pixels). It distinguishes itself from siblings like list_webhooks and add_script by focusing specifically on scripts and the list action.

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 for when to use the tool: when you need to see third-party scripts on a page. It does not explicitly name alternatives or exclusions, but the scope is evident from the examples and the sibling tool set.

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 readOnlyHint annotation already communicates that this is a safe read operation. The description adds some value by noting the output includes pages and custom domain, but it does not disclose additional behavioral details such as pagination, permissions, or listing order.

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

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

The description is a single, front-loaded sentence with no redundancy. It communicates the tool's function and key output details 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 read-only, single-parameter listing tool with an output schema, the description is complete. It states what is listed and the relevant output fields, while the schema covers the workspace_id behavior.

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

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

Schema description coverage is 100%, so the parameter is already well-documented. The tool description adds no additional parameter-level meaning beyond the existing schema, making the baseline 3 appropriate.

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

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

The description uses a specific verb ('List') with a clear resource ('multi-page websites in the workspace') and specifies the output ('each site's pages and live custom domain'). This clearly distinguishes it from sibling tools like list_pages.

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 of what the tool returns, and the schema adds useful guidance on when to omit or provide workspace_id. It does not explicitly mention alternatives or when-not-to-use cases, so it falls short of a 5.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful behavioral detail: only enabled webhooks receive deliveries, and page-scoped queries include inherited site-level webhooks. This goes beyond the annotation without contradicting it.

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, all purposeful. The first sentence states the core operation and scope; the second adds an important delivery condition; the third explains inherited behavior and a likely use case. No filler or repetition of schema fields.

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 a read-only annotation, a full output schema, and 100% schema coverage for both parameters, the description completes the picture by explaining scope options, inheritance, and enabled-webhook behavior. Nothing essential is missing for an agent to correctly select and invoke 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?

The input schema already documents pageId and siteId with full descriptions, so the baseline is 3. The description adds extra semantic meaning by explaining the inheritance behavior for pageId queries and clarifying that siteId is the broader coverage choice, which enriches the schema's 'Give this or siteId' guidance.

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') and identifies the exact resource ('webhook URLs that captured leads are forwarded to'). It clearly distinguishes the tool from sibling mutators like add_webhook and remove_webhook by focusing on listing existing webhooks with page/site scoping.

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?

Clear guidance is given for choosing between pageId and siteId, including that siteId is 'usually the right choice for a CRM or automation'. The description also adds practical context about inherited site-level webhooks and why someone would ask this ('why are my leads going there'). No explicit exclusions or alternative tool names are mentioned, but the usage context is strong.

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 reveals a non-obvious behavior: "Scripts are injected when the page is next saved in the editor or published; the change is not live on an already-published page until then." This deferred effect is critical for the agent to know, and since annotations only provide readOnlyHint: false, this addition is valuable and non-redundant.

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, all essential, with the core action up front and zero fluff. The information about list_scripts and the injection timing are both high-value additions.

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

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

For a 2-parameter tool with a clear output schema, the description covers the key context: how to get the ID, and the behavioral timing. No critical gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces that scriptId should come from list_scripts, which aligns with the schema information but adds no substantial new semantics beyond what's already in the schema.

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

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

The description starts with a specific verb+resource: "Detach a third-party script from a page." This action is distinct from sibling tools like remove_webhook, and the title reinforces the operation clearly.

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 a clear usage hint by directing the user to obtain scriptId from list_scripts. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to remove a webhook instead), though the context is 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?

Beyond the readOnlyHint annotation (false), the description explains side effects (leads remain captured) and the inheritance constraint, giving the agent a full understanding of what happens during removal.

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 cover purpose, side effects, and usage guidance without redundancy. The main action is stated first, and all additional info is relevant and compact.

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 optional parameters and subtle inheritance rule, the description is complete. It covers the action, the scope options, the side effect on leads, and the special case for inherited webhooks. No gaps remain.

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?

While the schema already describes each parameter, the description adds critical nuance: the distinction between page-level and site-level removal and the rule that inherited webhooks require siteId. This goes beyond basic schema descriptions.

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

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

Description clearly states the action (remove a webhook) and the target (page or website) with specific parameters. It distinguishes from sibling tools like add_webhook and list_webhooks by focusing on removal.

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 guidance on when to use pageId vs siteId, including the important rule that inherited webhooks must be removed via siteId. It also clarifies that removal does not delete leads, which helps set expectations.

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