Anole AI Visibility

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false), so the description's job is to add context, and it does: crawling is asynchronous unless crawl_site is invoked. It omits what happens if the domain already exists, which matters given idempotentHint=false — duplicate handling is left unexplained.

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

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

Two tight sentences with the core action first and the crawl timing second; every clause carries information an agent needs.

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

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

Covers creation and crawl timing but, with no output schema, says nothing about what is returned (site ID? confirmation?) or how duplicate domains are handled. For a non-idempotent creation tool those are meaningful gaps.

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

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

Schema coverage is 75%: domain, sitemap_url and llms_txt_url are documented inline, and language has an enum plus a default. The description adds no meaning for language, sitemap_url or llms_txt_url beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource ('Adds a website (domain) to the Anole account') and scopes it to account-level site creation. It also names the sibling it pairs with (crawl_site), so an agent can tell it apart from crawl_site without opening either schema.

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

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

Explains the follow-on behavior: the site is crawled automatically in the next background cycle, or immediately if the agent calls crawl_site. That gives a clear decision point for the crawl step, though it doesn't address when to use add_site versus checking list_sites first for an existing domain.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the agent knows this is a safe, repeatable read operation. The description reinforces non-mutation with 'Does not save anything' and mentions the return shape, but it adds little new behavioral context such as authentication needs, rate limits, or URL-fetching 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 three short sentences with no wasted wording. It front-loads the core purpose, then states the return values, then notes that nothing is saved.

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

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

Given the lack of an output schema, the description usefully explains that the tool returns a 0-100 score, a traffic light, and per-check results. Annotations cover the safety profile, and the accepted input formats are stated, though the relationships among the six optional parameters could be clearer.

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

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

Schema description coverage is 50%, and the description adds meaning by indicating that the analyzer accepts Markdown, HTML, or a page URL, which maps to the markdown, html, and url parameters. It does not clarify that these inputs are likely alternatives, nor does it explain the roles of lang, keyphrase, or the optional site parameter beyond the schema's own notes.

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

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

The description states a specific action and resource: it runs an SEO, readability and GEO analyzer on Markdown, HTML or a page URL. This is clear enough for an agent to understand the core purpose, but it does not explicitly differentiate this tool from siblings like get_url_audit or compare_with_top_results.

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

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

The description implies usage by naming the accepted input types (Markdown, HTML, or a page URL), which gives context for when the tool applies. However, it provides no explicit guidance on when to choose this tool over alternatives such as get_url_audit, crawl_site, or compare_with_top_results.

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

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

Beyond the annotations (readOnlyHint/openWorldHint loaded), the description discloses two traits an agent could not infer: analysed pages consume plan quota and the fallback SERP fetch depends on the search API being configured for the account. It does not state what happens when neither competitor_urls nor a configured search API is available, so the failure path remains undocumented.

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?

Everything sits in a single front-loaded paragraph: purpose and compared dimensions first, then the return shape, then the competitor-source rules, then the quota caveat. It is dense and somewhat long, but each sentence carries information not duplicated elsewhere.

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

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

There is no output schema, and the description compensates by describing the return payload (client values, medians, impact-ordered gaps, uncovered heading topics). Combined with the quota note, the get_account and list_sites cross-references, and the competitor-source rules, an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds genuine semantics by explaining that competitor_urls drives the comparison source when supplied and is otherwise substituted by a live Google top-10 lookup. That conditional behavior of an optional parameter is not captured in the schema itself.

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

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

The description opens with a specific verb and resource ('Compares a page of the site with the pages ranking in the top 10 for a search phrase') and then enumerates the compared facets (title, meta, H1-H3, word count, links, images, dates, structured data). This clearly separates it from siblings like analyze_content and get_url_audit, which operate on a single page rather than a SERP gap comparison.

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 explains the conditional data source: 'Uses competitor_urls when given...; otherwise Anole fetches the current Google top 10 when its search API is configured', which tells the agent when the optional parameter matters and what the prerequisite is. It stops short of explicitly naming when to prefer analyze_content or get_url_audit instead, so no exclusions are stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false. The description adds genuinely new behavior: the crawl is asynchronous, it returns immediately rather than with data, and results surface through get_site_overview. It hints at audit replacement with 'refreshes the audit' but never states what prior audit data is lost, which is the one gap left given destructiveHint=true.

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, each earning its place: the first defines the action, the second the async return contract and the follow-up tool. The most important fact (returns immediately) is not buried.

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

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

There is no output schema, and the description correctly covers the return contract by saying it returns immediately and redirecting to get_site_overview. What is missing is the destructive side: with destructiveHint=true, an agent would benefit from knowing the existing audit is overwritten and whether a crawl already in flight matters.

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 description coverage is 100%: the schema already explains the domain format and the optional-when-single-site rule. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb and resource: starts a background crawl of the site sitemap and refreshes the audit. It is clearly separable from siblings like get_site_overview (which it names) and get_url_audit, so an agent can pick it without opening any schema.

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

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

Gives clear context for the call: it kicks off work and returns immediately, then results are read via get_site_overview. There are no explicit exclusions or comparison to alternatives such as get_url_audit, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds real value beyond that: it discloses that the output is a non-public draft and that content can originate from an external page fetch, which explains the open-world hint in practical terms. It stops short of noting permissions or what happens on repeated calls with the same slug.

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

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

Two sentences, front-loaded with the action and scope, then the draft state constraint. No filler or restatement of the title.

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

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

With no output schema, the description should say what a successful call returns (e.g. a draft identifier) so an agent can chain into publish_document or update_document. It also leaves the markdown/source_url requirement implicit for a tool where nothing is marked required.

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 71%, so most parameters are already documented. The description adds one genuinely useful semantic the schema lacks: source_url is an alternative to markdown ('instead of markdown'). But it says nothing about title, description, site, or lang, nor that all 7 parameters are optional while at least one content source is presumably 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?

States a specific verb and resource (creates a draft Markdown document in Content Studio) plus the two input modes: raw Markdown text or conversion from source_url. The draft-versus-published state is made explicit against publish_document, though it does not differentiate itself from siblings like generate_document or update_document.

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 line 'Drafts are not public until publish_document' implies the create-then-publish workflow, which is useful context. However, there is no explicit guidance on when to choose this over generate_document or update_document, and no statement of prerequisites (site resolution, auth, one-of markdown/source_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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the return is 'full content' (as opposed to a search snippet), and says nothing about failure behavior for bad ids or content size/format.

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?

One sentence, front-loaded with the verb and resource, with the id-format hint in parentheses. Nothing is wasted.

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

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

For a single-parameter read tool with annotations covering safety and no output schema, the definition covers purpose and id format adequately. It stops short of describing what 'full content' looks like (markdown, raw HTML, truncation), which would help an agent decide between this and get_document.

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 0% and the single `id` parameter has no schema description, so the description carries the burden. It does this well by giving concrete id shapes ('doc:123 or url:456'), which is exactly the format information the schema lacks.

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: 'Returns the full content of a search result', and clarifies it takes a result id rather than an arbitrary document. It does not differentiate itself from the similarly-scoped sibling get_document, so an agent could hesitate between the two.

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 'search result' implies this is a follow-up call to the `search` sibling, but the description never says so explicitly and names no alternatives or exclusions. Usage is inferable rather than stated.

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

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

Annotations cover the safety profile (non-read-only, open-world, non-idempotent), and the description adds genuinely new behavior: it consumes AI credits, free only on an Own Key plan, writes into Content Studio, and stays private until publish_document. The cost/credits disclosure is exactly the kind of context annotations cannot express, though it omits whether repeat calls duplicate drafts.

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

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

Three short sentences, front-loaded with the action and resource; the credit cost and publish-gating constraints each earn their place. No filler or restatement of the name.

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

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

For a generating, state-changing tool with no output schema, the description should hint at what comes back (a document identifier or reference usable with publish_document). It covers persistence and lifecycle well but leaves the agent guessing how to chain into publish_document or retrieve the draft.

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

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

Schema coverage is 50%: lang and site are documented in the schema, and the description's reference to 'a topic' and 'Markdown document' loosely frames the required topic and title params. Title and topic remain unexplained in both places, so the description neither fully compensates nor adds syntax detail.

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

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

The description pairs a specific verb and resource ('Writes a draft Markdown document on a topic') with the producing engine ('Anole AI writer') and destination ('Content Studio'), so the agent knows this is AI generation, not manual creation. It does not, however, distinguish itself from the sibling create_document, leaving that boundary to inference.

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

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

It implies the generation-then-publish workflow by noting 'Not public until publish_document', which implicitly routes to a follow-up tool. But there is no explicit when-to-use versus create_document or update_document, and no prerequisites beyond the site/plan note.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description's added value is listing the returned data fields, which matters since no output schema exists, but it says nothing about freshness, caching, or whether these are nullable/proration-adjusted values.

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?

One sentence, front-loaded with the verb and the field list, with zero filler. Every clause names a distinct piece of returned data.

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

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

For a zero-parameter, annotation-covered, no-output-schema tool, the description is essentially complete: it fills the return-value gap in place of an output schema. A brief note on scope (account-wide vs per-site) or data recency would make it fully self-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?

The tool takes zero parameters, so there is nothing the description could clarify beyond what an empty schema already conveys. Baseline 4 applies.

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

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

States a specific verb (Returns) and resource (the account), then enumerates exactly what comes back: plan, plan limits, AI credit balance, site usage. It is clearly distinguishable from the site/document/crawl siblings, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent infers it should call this when it needs account-level plan or quota context. There is no explicit when-to-use statement, no exclusion, and no mention of the closest sibling get_site_overview, which also returns usage-style data.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral content by stating the payload is the full Markdown body plus metadata, which matters since there is no output schema. Missing only edge behavior such as what happens for an unknown slug.

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 sentence that front-loads the return payload and the resource. Nothing redundant and nothing vague enough to waste tokens.

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

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

For a one-required-parameter read tool with full annotations, the description covers the essential unknown: what comes back (Markdown body and metadata) in the absence of an output schema. It could add not-found behavior but is otherwise 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 description coverage is 100%, and each parameter (slug, site, lang) is already documented in the schema with examples and cross-references. The description adds no parameter detail beyond that, so the baseline 3 applies.

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

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

Names a specific verb and resource: returns the full Markdown body plus metadata for a single Content Studio document. It implicitly contrasts with list_documents by specifying 'one' document, but it never names a sibling or scope boundary 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: the schema's 'see list_documents' and 'see list_sites' hints suggest how to obtain inputs, but the description itself never says when to call this versus list_documents, search, or fetch, nor any 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that the response includes the public URL of the file, but it does not say what happens when a site has no llms.txt (error vs. empty result), which is the main behavioral unknown for this call.

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

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

A single short clause with no filler, and the resource is front-loaded before the incidental detail about the public URL. It is terse to the point of being slightly clipped, but every word earns its place.

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

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

For a simple, annotated, single-optional-param read with no output schema, the description is adequate but thin: it never states whether llms.txt is generated on demand or read as-is, nor what the caller gets when the file does not exist. Those are the remaining gaps an agent would want closed.

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

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

Schema coverage is 100% and the single `site` parameter is fully documented in the schema, including the example domain and the "optional when the account has one site" rule. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

"The llms.txt file Anole serves for a site, with its public URL" names a specific, unambiguous resource that no sibling tool touches, so there is no risk of confusion with fetch, crawl_site, or analyze_content. The only shortfall is that it is a noun phrase with an implied verb ("get") rather than an explicit one, which the tool name supplies.

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

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

The description gives no when-to-use context, no prerequisites, and no alternatives — for example it never says whether to call this versus the generic fetch tool when a site's llms.txt is needed. The only routing hint ("see list_sites") lives in the schema, not the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description contributes the useful fact that the response is an aggregate summary of four metric families, which matters because there is no output schema, but it says nothing about freshness of crawl data, cost, or pagination.

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 dense sentence with no filler, and the scope ('for one site') is placed at the end so the metric families land first. It is efficient, though the missing verb makes it read as a capability list rather than an instruction.

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

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

With no output schema, the description does the right thing by naming what comes back, which is the minimum an agent needs. It stops short of describing the shape of those metrics (ranges, units, whether llms.txt coverage is a percentage) or the multi-site failure mode, leaving gaps for a tool that returns several data families.

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% for the single 'site' parameter, including the example and the 'optional when the account has one site' caveat, so the schema carries the semantic load. The description only restates the 'one site' scoping and adds no format or resolution guidance beyond it. Baseline 3 applies.

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

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

The description enumerates concretely what the tool returns (crawl statistics, AI-readiness score, llms.txt coverage, document counts) scoped to one site, which is more informative than the name alone. However it is a noun phrase with no verb, and it never distinguishes this aggregate view from siblings such as get_account, get_llms_txt, or list_urls that surface overlapping data.

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

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

There is no indication of when to reach for this tool versus get_llms_txt (coverage details), get_account (account-level view), or list_urls (per-URL data). The schema note 'see list_sites' hints at a prerequisite for resolving a domain, but the description itself gives no usage context or exclusions.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is done. The description contributes beyond that by disclosing that the SEO/GEO analysis is pre-stored and only present 'when available', signalling the agent may get partial or cached results rather than fresh analysis.

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?

One sentence, front-loaded with what the tool returns, with no filler. Nothing in it is redundant with the annotations or schema.

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

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

There is no output schema, so the description carries the burden of describing returns, and 'full audit' plus 'stored SEO/GEO analysis' is vague about what fields or sections actually come back. For a read-only, two-parameter tool this is adequate, but an agent would benefit from knowing the shape of the audit result.

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

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

Schema description coverage is 100% and both parameters are documented (absolute URL as listed in the sitemap; optional site domain referencing list_sites). The description only echoes the sitemap constraint already in the schema, so schema coverage sets the 3 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?

It names a specific verb and resource ('audit of one URL') and adds scope detail ('from the site sitemap'). The purpose is clear, but it does not position itself against related siblings such as get_site_overview, list_urls, or analyze_content.

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 sitemap constraint and the 'site optional when one site' hint imply usage, but the description never says when to call this tool rather than crawling, listing URLs, or pulling a site overview. There is no explicit when-not guidance or named alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds only that status defaults to published, repeating the schema default, and says nothing about result cardinality, pagination, or whether an omitted site spans all sites. Modest added value on top of a rich annotation set.

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

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

Two short fragments with no padding, front-loaded with the resource and followed by the filter enumeration. It is efficient, though the fragment style leaves the operation itself unstated, which is under-specification rather than verbosity.

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 three-parameter, no-required-argument list tool with no output schema, the description does not say what comes back or how results are bounded, leaving the agent guessing at return shape. The one thing it clarifies, the status default, is already structured. Adequate but with a clear gap around return 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 coverage is 67%, with lang and site documented directly and status carrying an enum plus default. The description's status list restates the enum rather than adding meaning, and it never explains the semantics of omitting site. Baseline 3 is appropriate since the schema does most of the work.

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

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

The description is a noun phrase naming the resource ('Markdown documents of a site in Content Studio') rather than stating a verb, so the listing action is only recoverable from the tool name and title. It does add the Content Studio domain and the status dimension, which orients the agent somewhat. Still closer to a tautological restatement than a distinct statement of purpose.

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

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

The only guidance is the status default ('published'), which the schema already carries. There is no hint about when to prefer this over siblings like list_urls, search, get_document, or get_site_overview, all of which overlap in scope. No exclusions or prerequisites are offered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond that by disclosing what each entry contains (crawl status and average score), which matters since no output schema exists; it stops short of stating ordering or result-count 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?

One front-loaded sentence with no filler; the resource is named first and the returned attributes follow. Nothing is wasted and nothing needs to be re-read.

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 parameterless read with no output schema, naming the returned fields (crawl status, average score) and the account scope is most of what an agent needs. Minor gaps remain around result volume/ordering and how to follow up on a single site.

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

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

There are zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies an unfiltered, whole-account listing rather than suggesting any hidden arguments.

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 (Lists) and resource (websites/domains) plus an account-level scope and the attributes returned. It is clearly distinct from get_site_overview (single site) and list_urls (pages within a site), though it never names those siblings explicitly.

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

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

The zero-parameter, account-wide nature implies the when-to-use case (enumerate all sites), but the description gives no explicit guidance, no mention of pagination/limits, and no pointer to alternatives like get_site_overview for drilling into one site.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuine behavioral context that annotations cannot — notably that 'low_score' returns worst-first ordering and that 'errors' means HTTP errors. It says nothing about default ordering, how 'limit' affects result completeness, or whether truncation occurs.

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

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

Two short sentences with zero filler, and the core purpose is front-loaded before the filter list. The filter enumeration reads as a terse fragment, but that style suits a quick-scanning agent and wastes no tokens.

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

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

With no output schema, the description should say more about what each returned entry contains (URL plus what audit fields?) and about paging past the 200-URL cap. It covers the purpose and filter vocabulary adequately but leaves return shape and result exhaustion underspecified for a list tool.

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

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

Schema coverage is only 33% (only 'site' carries a description), so the description must compensate. It does clarify all four 'filter' values with parenthetical semantics, but 'limit' is left entirely to the schema (default 50, max 200) with no hint about pagination or how to retrieve more than 200 URLs.

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

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

Names a specific resource — sitemap URLs of a site together with their audit result — which clearly separates it from get_url_audit (single URL) and list_sites (sites rather than URLs). The verb is only implied by the title 'List audited URLs' rather than stated in the description, but the scope is unambiguous.

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

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

The filter enumeration gives implicit guidance: pick 'missing_md' to find pages lacking Markdown, 'errors' for broken pages, 'low_score' to review worst performers first. There is no explicit statement of when to prefer this over get_url_audit for a single URL, and no mention that 'site' can be omitted for single-site accounts (that only appears 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?

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the bar is lower, but the description still earns credit by disclosing the concrete downstream effects — the public URL, the llms.txt entry, and the external push to the customer server. The one gap is that destructiveHint is never explained: nothing warns that republishing can overwrite live/deployed content, and the 'when auto-deploy is configured' condition is mentioned but not elaborated.

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 colon-led sentence that front-loads the action and then lists side effects in order of increasing scope (URL → llms.txt → customer server). No filler, no repetition of the title.

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

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

For a three-parameter mutation with no output schema, the description covers the important behavioral surface. It stops short of the one thing an agent would still want to know — what happens on conflict or whether the response reports deploy status — but annotations and schema carry most of the remaining load.

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% — slug, site and lang are all documented in the schema, including defaults and pointer tools like list_sites and list_documents. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

The definition names a specific verb (publishes) and resource (a document) and then enumerates the three concrete effects: making the .md URL public, adding it to the site's llms.txt, and pushing to the customer server. An agent can tell exactly what state change results, and the inverse sibling (unpublish_document) is unambiguous by name.

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

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

Usage is implied by the description rather than stated: the agent can infer this is the counterpart to unpublish_document and follows create_document/update_document. There is no explicit 'use when…' framing, no prerequisite call (e.g. needing a slug from list_documents — that hint lives only in the schema), and no exclusion conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value by scoping results to published documents and audited URLs and by disclosing the return shape ('ids for fetch'). It omits ranking/ordering, result limits, and matching semantics, so a 3 is appropriate rather than a 4.

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 compact sentences with no filler; the scope is front-loaded and the downstream hint ('ids for fetch') follows naturally. Nothing is wasted.

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

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

For a one-parameter, annotation-covered read tool with no output schema, the description covers the searchable corpus and the shape of the return value well enough to call it correctly. The missing piece is query syntax and any result-count behavior, which are minor against the tool's 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 single required parameter 'query' has 0% schema description coverage, so the description carries the full burden and does not pay it: nothing is said about whether the query is free text, a phrase, boolean syntax, or how many results come back. With one low-coverage parameter the description should compensate, and here it does not.

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

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

States a specific verb+resource pair — searches published documents and audited URLs of the account sites — which is more precise than the generic name 'search'. However, it does not distinguish itself from the closely related siblings list_documents, list_urls, or compare_with_top_results, so the agent must infer the boundary.

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?

'Returns ids for fetch' implies the intended workflow (search, then fetch by id), which gives the agent a usable pattern. But there is no explicit statement of when to search versus list_all via list_documents/list_urls, and no exclusions or prerequisites.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description usefully qualifies that destructiveness: only the public URL and llms.txt entry are removed while the content itself is retained and republishable. That is precisely the context an agent needs before invoking a destructive-flagged tool, and it is not derivable from the 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?

Two short sentences, front-loaded with the action and its removal effects, ending with the retention guarantee. Every clause carries distinct information and nothing is repeated from the title or schema.

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 3-parameter mutation with no output schema, the description covers effects, preservation, and reversibility, which is what an agent most needs. It does not address edge cases such as calling it on an already-unpublished document or whether llms.txt updates are immediate.

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 slug, site, and lang are already fully documented in the schema, including cross-references to list_documents and list_sites. The description adds no additional parameter meaning, which is acceptable at this coverage level but not 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?

States a specific verb (archives) applied to a specific resource (a document) and then concretely enumerates the effects: removing the public .md URL and the llms.txt entry. This clearly separates it from publish_document and update_document in the sibling set.

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

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

The phrase 'can be published again' signals the reversible counterpart relationship with publish_document, giving an agent clear context for when this action applies. It stops short of an explicit 'use publish_document to restore it' routing sentence or any when-not-to-use exclusion.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds two genuinely useful behavioral facts: the previous version is retained as a revision, and a published document changes publicly immediately. That materially softens the destructive flag and warns of a live side effect. It stops short of saying whether omitted fields are left untouched or cleared.

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

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

Three short sentences: what changes, what is preserved, what the public impact is. The mutation and its scope are front-loaded with zero filler.

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

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

For a destructive 6-parameter mutation with no output schema, the description covers the essentials: what is replaced, revision retention, and immediate public effect. It is only missing return-value information (e.g., resulting revision identifier) and confirmation of partial-update semantics.

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

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

Schema coverage is 50%: slug, site, and lang are documented in-schema while title, markdown, and description are bare. The 'and/or' wording usefully signals partial updates are allowed (matching slug as the only required parameter), but it doesn't define whether an omitted title/markdown clears the field or preserves it, nor any format constraints on markdown.

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

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

It uses a specific verb ('Replaces') plus the exact resources modified (Markdown body, title, description) and scopes it to a single existing document. It implicitly separates itself from create_document and generate_document, though it never names a sibling explicitly.

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

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

Usage is only implied: the agent can infer this is the tool for editing an existing document rather than creating one. There is no explicit guidance on when to use publish_document/unpublish_document alongside it, or on preconditions such as the document already existing.

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