simplepages

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

The description discloses behavioral traits beyond the readOnlyHint annotation: it states the page is saved as a draft and inherits the site's brand and domain. This gives meaningful context about side effects and state. It does not contradict annotations; readOnlyHint=false aligns with the write operation. The main description adds value 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 exactly three sentences, front-loaded with the core action, then usage guidance and a practical note. Every sentence serves a purpose with no redundancy. It is appropriately sized 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's complexity (4 params, 3 required), the schema covers essentials, and an output schema exists (though not shown). The description explains the core action, when to use it, and a key behavior (draft status). It does not cover error cases or edge scenarios, but that is not necessary given the rich schema. It is sufficiently complete for an agent to use 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 already provides detailed descriptions for all four parameters (100% coverage), so the baseline is 3. The main description does not add new parameter-specific meaning; it merely reiterates the pointer to list_sites for siteId, which the schema already mentions. No additional semantic clarification is offered 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 clearly states the tool's function: 'Generate a new page inside an existing website and save it as a draft.' It names the specific resource (page within a site) and differentiates from the sibling tool create_page by noting when this one should be used instead. The verb and object are 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?

The description explicitly guides when to use this tool: 'Use this rather than create_page whenever the page belongs to a site.' It also provides a practical pointer for obtaining a required parameter: 'Find site ids with list_sites.' This offers clear context on selection and prerequisite.

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 indicate readOnlyHint=false, and the description goes well beyond that by disclosing that a real page is created in the workspace, saved as a draft, can be opened/published later, and returns specific URLs. This gives the agent a strong sense of side effects and result shape.

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, front-loaded sentences: first states the core action, second explains what gets created and its draft state, third lists returned values and the publishing workflow. No filler or redundant restatement of the title.

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

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

Given the rich input schema and presence of an output schema, the description supplies the remaining workflow context: draft status, editor availability, and the separation of publishing. This is complete for a creation tool and needs no further 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%, so the schema already documents all four parameters thoroughly. The description reinforces the centrality of the 'description' parameter but adds no parameter-level details beyond what the schema provides, matching 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?

Description uses specific verbs 'Generate' and 'Creates' with the resource 'landing page' and clearly differentiates from siblings by emphasizing creation of a new page as a draft, with publishing as a separate step. It also states concrete outputs (page id, preview URL, edit URL), making the tool's 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?

Clear context is provided: use this to create a landing page from a description, and publishing is explicitly called out as a separate step. However, it does not explicitly name alternatives like edit_page for modifications or get_page for retrieval, so it stops short of full when-not guidance.

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

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

Beyond the 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 annotations already declare readOnlyHint=true, so the read-only nature is covered. The description additionally states that it returns specific fields (name, status, edit URL, live URL), which is useful. However, it does not disclose whether it might return other fields or any potential errors (e.g., if the page is not found). Since annotations cover the safety profile, this is adequate 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 a single sentence, conveying the key information efficiently without waste. It is front-loaded with the verb and object. The only minor redundancy is 'by its id' and 'the page UUID' appearing in quick succession, but it remains concise.

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

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

The tool is simple (one parameter), has an output schema, and has appropriate annotations. The description covers the purpose, parameter semantics (though schema does), and key return fields. There is no need to explain the output schema since it exists. The description is sufficient for a straightforward read-only retrieval tool, though it could be argued that it doesn't mention potential error cases, but that is not critical for completeness given the simplicity.

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

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

The schema provides 100% coverage for the parameter 'pageId' with a description: 'The page UUID (id from list_pages / list_sites).' The tool description also mentions 'by its id (the page UUID).' This overlaps with the schema, adding no additional meaning. Baseline 3 is appropriate because the schema fully describes the parameter.

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

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

The description clearly states the tool's purpose: 'Get details for a single landing page or site page by its id (the page UUID).' It specifies the resource (page) and the action (get details). While it doesn't explicitly differentiate from siblings, the phrase 'single... by its id' distinguishes it from listing tools, and the list of returned fields (name, status, edit URL, live URL) adds specificity.

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

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

The description implies when to use this tool: when you need details for one page, as opposed to listing all pages (list_pages) or getting analytics (get_page_analytics). It provides clear context ('by its id') and indicates the prerequisite of having the page UUID. However, it does not explicitly state when not to use it or mention alternatives by name.

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

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

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?

Annotations provide readOnlyHint: true, and the description adds valuable behavioral context by clarifying the scope ('standalone landing pages') and the exact fields returned (publish status, edit URL, live custom domain if connected). The 'if connected' caveat adds nuance about optional fields. This goes beyond simply echoing the read-only nature, though it doesn't discuss errors, rate limits, or ordering. With annotation coverage high, this is sufficient credit.

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, grammatically complete sentence of 22 words. It front-loads the verb, clearly states the object and scope, and lists the key output attributes without any wasted words. Every word earns its place, making it a model of conciseness and effective structure.

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 zero required parameters and an existing output schema, the description covers the essential elements: what is listed, the scope, and the included fields. It leverages the annotations (readOnlyHint) and schema for additional details. The only minor omission is clarity on multi-workspace behavior, but that is already addressed thoroughly in the schema's description of workspace_id. Thus, the description is effectively complete for its 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 input schema already provides detailed descriptions for both 'limit' and 'workspace_id', achieving 100% coverage. The tool description adds no additional parameter meaning beyond what the schema offers. Therefore, a baseline score of 3 is appropriate, as the schema does the heavy lifting and no compensation is needed.

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

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

The description uses a specific verb ('List') with a clear resource ('standalone landing pages') and scope ('in the workspace'), and even enumerates returned fields (publish status, edit URL, custom domain). This distinguishes it from sibling tools like create_page/edit_page and get_page, though it does not explicitly name alternatives. This is clear but lacks explicit sibling differentiation, fitting a 4 rather than a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_page or list_sites. It doesn't mention use cases, prerequisites, or contrasts with other tools. The only implicit hint is the verb 'List', which is not enough to guide an agent in choosing among siblings. There is no 'when to use' or 'instead of' language.

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.