SEOPro AI

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

Annotations are all false, so the description carries the burden. It discloses that the operation takes 1-3 minutes and results are cached for 7 days, which is useful behavioral context. However, it does not clarify whether the call is synchronous or asynchronous, whether it triggers network requests, or any rate limits. It adds some transparency but leaves significant gaps.

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 with no extraneous words. The primary purpose is front-loaded, and the operational details (duration, caching) are delivered in the second sentence. Every element earns its place; 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?

Despite the tool's complexity (checking multiple AI assistants, likely network calls), the description omits critical operational details: what the output looks like (no output schema), how to interpret results, whether it returns a job ID for async polling, and what happens on failure. The timing and caching info hint at async behavior but do not explain the workflow. This is incomplete for an agent to invoke and interpret successfully.

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

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

With only one parameter (url) and 0% schema description coverage, the description must compensate. It indirectly clarifies that the url refers to the website being checked, but does not provide format details, examples, or validation rules. The single parameter is self-evident enough to warrant a baseline score, but the description adds minimal explicit value beyond the schema's field name.

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 verb 'Check' and the specific resource: whether AI assistants (ChatGPT, Claude, Gemini, Perplexity) mention or cite a website. It distinguishes this tool from siblings like get_ai_search_traffic or generate_article by focusing on citation behavior across named assistants. No ambiguity about what it does.

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 instead of alternatives. It does not mention any exclusions, prerequisites, or contrasting scenarios. The presence of siblings like get_ai_search_traffic suggests potential overlap, but the description does not address when one is preferred over the other.

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 say all hints are false, so the description carries the burden. It discloses asynchronous background execution, 5-10 minute wait, polling requirement, dedupe behavior returning the existing blog_id, and quota consumption. 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?

Compact and well-structured: action and async return first, then date/dedupe semantics, then quota impact. Every sentence carries operational value with no filler.

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

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

Covers the async lifecycle, polling target, dupe behavior, and plan limit. With no output schema, a minor gap is that for a non-dupe generation it doesn't explicitly state what the immediate response value contains beyond 'returns immediately.'

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

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

Schema description coverage is 0%, but the description meaningfully expands scheduled_date (format, default, uniqueness per website/date) and keyword (target keyword). It does not explicitly explain the optional topic parameter, though the schema title and optionality make it low-risk.

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: 'Start generating an SEO article for a target keyword.' It also disambiguates itself from get_article_status by positioning this tool as the initiator of background generation rather than the status checker.

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: use this to kick off generation, then poll get_article_status until a blog appears. It also explains the one-article-per-website-per-date rule and the monthly limit, but does not explicitly contrast with siblings like publish_article or list_articles.

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 carry destructiveHint=true, but the description adds concrete guardrails: replace_existing=true requires explicit user approval to discard pending topics and also requires confirm_replace_existing=true. It also warns about multi-minute latency, going 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?

Three sentences, front-loaded with the core action, followed by optional inputs, latency, and then the critical destructive guardrail. No filler or redundant restatement 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?

Complete enough to invoke: required website, optional keyword/instructions, wait-time expectation, and safeards for the destructive path. It does not describe the return value or point to get_keyword_plan for retrieving the generated plan, but there is no output schema and the core behavior is clear.

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

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

With 0% schema coverage, the description is the main source of parameter meaning. It clarifies that primary/secondary keywords are comma-separated, treats topic_instructions as an optional guide, and explains the replace_existing/confirm_replace_existing relationship. It does not explicitly define website_id, but the name and required status make it reasonably clear.

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

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

Description opens with a specific verb and resource: generate an AI keyword/content plan. It distinguishes itself from sibling tools such as get_keyword_plan (retrieval) and generate_article (article creation) by naming the output type.

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

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

It gives clear context: use it to produce a plan, optionally shaped by topic instructions and keywords, with a latency warning. It does not explicitly contrast with fetching an existing plan via get_keyword_plan or say when not to generate, so it lacks full when/when-not alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: date format is YYYY-MM-DD and it defaults to the last 30 days. It doesn't describe pagination or response structure, but the annotations lower the burden.

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

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

The description is two sentences with no fluff. The primary behavior is front-loaded, followed by concrete output examples and date handling. Every sentence adds useful information.

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

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

For a read-only report tool with strong annotations, the description covers the core purpose, output metrics, date format, and default range. There is no output schema, but the description names the key return components. Minor gaps like limit semantics remain, but the definition is largely 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 0%, so the description must compensate. It partially covers the date parameters by specifying format and default behavior, but it does not explain website_id or limit semantics. This leaves half the parameters under-documented.

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

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

The description states a specific verb and resource: it shows traffic from AI assistants and AI search sources, with concrete examples (ChatGPT, Perplexity, Claude, Gemini) and specific metrics (sessions, engaged pages, per-source breakdowns). This clearly distinguishes it from sibling tools like get_search_performance or get_website_stats.

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 clear context for when the tool is relevant: measuring AI-assistant and AI-search traffic. It does not explicitly name alternatives or state when not to use it, but the AI-source scope is specific enough to imply the intended use.

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

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

The description adds meaningful behavioral context beyond the readOnly/idempotent annotations by disclosing the default return value (metadata and a short excerpt) and how include_content changes the response to full HTML. This helps an agent predict output without seeing an output schema. It omits error and auth details, but annotations already cover the safety profile.

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 tight sentences with no filler. The core action is front-loaded, followed by a clear explanation of the optional parameter's effect. Every clause earns its place.

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

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

For a simple read-only tool with two parameters and helpful annotations, the description sufficiently covers invocation behavior and output options. It does not enumerate metadata fields, but with no output schema that would be a minor enhancement rather than a critical gap.

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

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

With schema description coverage at 0%, the description must explain parameters itself. It does this well: blog_id is identified as the article key, and include_content is explicitly tied to returning full HTML. The schema already provides types and defaults, so the description adds the necessary semantic meaning.

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 reads a single article by blog_id, using a specific verb and resource. It also explains the default output and the optional full-content mode, which conveys the tool's scope. It does not explicitly contrast with siblings like list_articles or get_article_status, but the 'single article' phrasing makes the distinction reasonably clear.

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

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

The description implies the tool is for retrieving one article, optionally with full HTML content. It does not explicitly mention when to prefer a different tool such as list_articles for multiple articles or get_article_status for status-only checks. The guidance is adequate but relies on inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: date format YYYY-MM-DD, default to current month, and the meaning of has_blog/blog_id as readiness indicators. This goes beyond the annotations without contradicting them.

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

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

Three sentences with no filler: purpose first, then date behavior, then result interpretation. Every sentence earns its place and the critical 'ready to read via get_article' signal is included without extra verbiage.

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 clearly explain return values. It covers has_blog and blog_id, but the tool name mentions both generation and publication status, and the description does not clarify what other statuses may appear or how to interpret dates without has_blog=true. This leaves an agent somewhat under-informed about the full response shape.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain date format and default behavior for start_date/end_date, which are the non-obvious parameters. However, website_id is not described at all, and the exact semantics of omitted start vs. end date are not specified, leaving a partial gap.

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

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

The description opens with a specific verb and resource: 'Check article generation/publication status per date.' It further distinguishes itself from the sibling get_article by stating that has_blog=true and a blog_id mean the article is ready to read via get_article. This makes the tool's role clear and separable from related 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 description explicitly indicates when the result should be followed up with get_article, giving a clear usage context: check status first, then read the article if ready. It does not enumerate exclusions like 'not for indexing status', but the relationship to get_article is explicit enough for correct routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about what data the call returns, but does not disclose behaviors like data freshness, pagination, or authorization requirements. With the annotations present, this is adequate but not exceptional.

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, front-loaded with the action and resource, then a tight list of returned elements. There is no filler, repetition, or unnecessary detail; 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, single-parameter, read-only tool, the description covers the key return contents and the source network. It omits explicit preconditions (e.g., that website_id must exist or come from list_websites), but the simple schema and rich annotations make this omission relatively minor.

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

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

Schema description coverage is 0% and the description never explains website_id semantics or how to obtain valid values. The only connection is the phrase 'the website's,' which weakly maps to the parameter name but does not compensate for the complete lack of 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?

The description uses a specific verb and resource ('Get the website's backlink profile') and enumerates exact data points returned (totals, unique sources, available credits, recent earned backlinks). It also scopes the source to the SEOPro AI backlink network, making it easily distinguishable from sibling get_* tools targeting articles, keywords, or traffic.

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 guidance on when to use this tool versus alternatives such as get_website_stats or get_search_performance. Usage context is left entirely to inference from the tool name and subject matter, with no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is lighter. It adds useful behavioral context by specifying exactly what statistics are returned (indexed, pending, failed counts) and does not contradict any annotation. Minor details like data freshness or pagination are absent but not critical for a simple read-only stats tool.

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

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

The description is a single, front-loaded sentence that leads with the action and resource, then gives concrete details about the returned metrics. Every word adds value with no filler or redundancy.

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

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

Given a single simple parameter, no output schema, and safety annotations, the description provides enough context for calling and interpreting the result. It could be more explicit about the response format, but the enumeration of indexed/pending/failed counts is sufficiently complete for this tool's 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?

The schema has one required website_id with no description (0% coverage). The description's phrase 'for the website' hints at the parameter's role but does not explicitly map website_id to the target website. Since the parameter name is self-explanatory and the description offers partial context, a mid-range score is appropriate.

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

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

The description states a clear verb ('Get'), a specific resource ('auto-indexing stats for the website'), and enumerates the exact data categories (indexed, pending, failed URLs). This makes it immediately distinguishable from sibling tools like get_website_stats or request_indexing.

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 usage context by naming 'auto-indexing stats', but it does not explicitly state when to prefer this tool over alternatives such as get_website_stats or request_indexing. No exclusions or alternative routing are provided, so only implied usage is present.

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

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

Annotations already cover safety traits: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds what the plan contains, but no additional operational behavior such as authentication needs, rate limits, or response format caveats. It neither contradicts annotations nor significantly extends them.

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 filler. It states the action, the resource, and the key returned information efficiently, which is ideal for a simple one-parameter tool.

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

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

For a simple read-only retrieval with one parameter and no output schema, the description sufficiently lists the response contents: keywords, scheduled dates, and statuses. It could mention other possible fields or behavior when no plan exists, but this is a minor gap for such a straightforward 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?

There is only one parameter, website_id, and the schema gives its name and integer type but no description beyond that. The tool description's 'website's' clarifies that website_id selects the website, but it does not add meaningful extra detail such as required format, validation, or related entities.

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 ('Get') and names the exact resource: the website's scheduled keyword/content plan, including keywords, scheduled dates, and statuses. This clearly distinguishes it from generate_keyword_plan and other sibling retrieval 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 description implies this tool is for retrieving an existing scheduled plan, but it does not explicitly state when to use it instead of generate_keyword_plan, get_article_status, or list_articles. There is no direct comparison or exclusion, leaving the selection primarily to inference.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail by specifying date format (YYYY-MM-DD) and the default time range of the last 30 days, which helps an agent understand how the tool will behave when optional dates are omitted.

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

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

The description is compact and front-loaded: it states the tool's purpose in the first line, lists the key outputs in a scannable list, and adds only the essential date behavior in a second short sentence. No words are 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 read-only tool with three parameters and no output schema, the description covers the main purpose, expected output categories, and date semantics. It is complete enough for an agent to call the tool correctly for a typical use case. It could be more complete by noting how this tool relates to overlapping siblings, but that gap is already captured in usage_guidelines.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It directly clarifies that dates are YYYY-MM-DD and that they default to the last 30 days, and it identifies 'website' as the scope for website_id. It does not explain constraints like start_date <= end_date, but the provided semantics add meaningful value beyond bare parameter names.

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 the Google Search Console performance summary for a website,' and lists concrete metrics such as clicks, impressions, CTR, average position, top keywords, AI-assistant traffic sources, and device/country breakdowns. However, it does not distinguish itself from overlapping siblings like get_top_search_keywords and get_ai_search_traffic, so it stops short of full differentiation.

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

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

The description implies the tool should be used when an overall Google Search Console performance summary is needed, and it notes the default 30-day behavior. However, it gives no explicit when-not-to-use guidance or alternatives, especially given siblings that cover top keywords and AI traffic specifically.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds the monthly aggregation and metric scope but discloses no further operational behavior such as return shape, pagination, or error handling. Moderate added value, consistent with annotations — no contradiction.

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 zero waste: the first packs verb, resource, metrics, and time window; the second adds the use case. Nothing repeats the title 'Get Search Trends' and the description is front-loaded with the core function. Every sentence earns its place.

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

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

For a read-only tool with one required parameter and no output schema, the description covers purpose, metrics, and granularity well. Since no output schema exists, an explicit statement of the return shape (one row per month) would strengthen it, but 'monthly trends for the last N months' makes that inferable. Only a minor gap.

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

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

With schema description coverage at 0%, the description must compensate. 'For the last N months' usefully implies that `months` controls the lookback window, and `website_id` is reasonably self-evident. However, it never names the parameter explicitly, offers no valid range, and leaves the default behavior to the schema — only partial compensation for zero schema documentation.

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

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

States a specific verb ('Get') with a specific resource (monthly search-performance trends) and enumerates the exact metrics (clicks, impressions, CTR, average position) plus the time grain (monthly, N months). Clear and informative; however, given the near-identical sibling get_search_performance, the lack of explicit differentiation keeps it from 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?

'Use to spot growth or decay' gives an explicit use case, which is better than no guidance. But with 17 siblings including the ambiguous get_search_performance, there is no when-not-to-use statement and no routing to alternatives, leaving the selection decision largely to inference.

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

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

Annotations already mark it read-only and idempotent, so the description does not need to repeat that. The description adds value by specifying the output fields (clicks, impressions, CTR, position) and the date default behavior. There is no contradiction with annotations, and it provides useful context 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?

The description is concise (three short sentences) and front-loaded with the core purpose. Each sentence serves a distinct function: what it does, why it's useful, and date format. There is no filler or repetition of schema information, making it highly efficient.

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

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

For a tool with 4 parameters and no output schema, the description covers the essential: purpose, metrics, use case, and date format. The only gap is the lack of explanation for the 'limit' parameter, which might confuse an agent about its effect. Overall, it is fairly complete for a simple read-only 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 description coverage is 0%, so the description must compensate. It explicitly explains date format and defaults for start_date and end_date, which is helpful. However, it does not explain 'limit' (meaning or behavior), and 'website_id' is only implied. Thus it partially compensates but leaves ambiguity for the limit 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 states a specific verb ('List'), a resource ('website's top search keywords'), and the exact metrics returned (clicks, impressions, CTR, average position). It also adds a concrete use case ('finding quick wins positions 5-15') that distinguishes it from broader tools like get_search_performance. This is very clear and actionable.

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 a clear context for when to use it ('Great for finding quick wins'), and it explains date handling. However, it does not explicitly mention alternatives or when not to use it; it relies on the implicit differentiation from sibling tools. This is good guidance but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the included stat categories but does not disclose potential caveats such as data freshness, permissions, or output size. This is acceptable but not exceptional given annotation coverage.

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 that wastes no words and efficiently lists all relevant output categories. It is easy to scan and directly supports tool selection.

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 read-only tool with annotations covering safety, the description is mostly complete: it states the purpose and enumerates expected results. The only gap is lacking any note on return format or how website_id relates to other tools like list_websites, but this is minor given 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?

Schema description coverage is 0%, with one integer parameter website_id. The description only says 'for a website' and does not explain that website_id is the website identifier, how to obtain it, or any format expectations. This adds minimal value beyond the schema's 'Website Id' title.

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 ('Get') and resource ('content stats') and enumerates the exact fields returned: total articles, keywords tracked, published posts, and SEO autopilot status. This clearly distinguishes it from sibling tools without requiring schema inspection.

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

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

No explicit when-to-use guidance or comparison with alternatives is provided. While siblings like list_websites and list_articles have distinct names, the description does not clarify that this tool returns aggregate stats rather than raw lists, leaving usage context to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not burdened with safety disclosure. It adds useful behavioral context beyond annotations: the list includes both drafts and published (not only published), is newest-first, and can be filtered by status with example values. It does not mention pagination or return fields, but the annotation coverage lowers the bar and the added context is meaningful.

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

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

Two sentences with no filler. The core action and scope are front-loaded in the first sentence, and the optional filter is stated succinctly in the second with helpful examples. 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 read-only list tool with annotations covering safety, the description gives enough to invoke it correctly: resource, ordering, and optional filter. It does not describe the response structure or pagination, but no output schema exists to carry that burden, and the list semantics are clear from the name and description. Slightly more detail about what fields each article includes would push it higher, but it is adequate for selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds value for the 'status' parameter by providing example values ('draft', 'published'), which the schema lacks. However, it does not clarify 'limit' (e.g., max results) or 'website_id', though those are reasonably inferable from titles and defaults. Partial compensation for a low-coverage schema earns a 3.

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

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

The description uses a specific verb ('List') with a clear resource ('the website's articles') and adds scope ('drafts and published') and ordering ('newest first'). This distinguishes it from siblings like get_article (singular) and get_article_status (status-specific lookup) — an agent can tell exactly what this tool does without opening the schema.

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

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

The description provides clear context for when to use the tool: when you want a list of articles with optional status filtering. However, it does not explicitly name alternatives or state when not to use it, such as pointing to get_article for a single article. The usage is implied rather than explicitly differentiated from siblings.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds valuable behavioral context beyond that by specifying exactly what data is returned (website_id, URL, platform, autopilot status) and the positional role of the tool as the first call to make.

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 tight sentences with no filler. The first sentence states the core action, and the second provides only essential return-field info and the 'call this first' directive. Every sentence earns its place.

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

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

For a no-parameter, read-only list tool, the description is complete. It names the output fields (website_id, URL, platform, autopilot status), explains why the output matters for other tools, and gives sequencing guidance. With no output schema, this description sufficiently covers what an agent needs to know to call the tool correctly.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly focuses on the output and usage context rather than inventing parameter details.

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 ('List') and a clear resource ('the websites in the user's SEOPro AI account'), making the tool's purpose immediately obvious. It also differentiates itself from siblings like list_articles by focusing on websites, and the note 'Call this first' establishes its role as a discovery entry point.

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 clear usage context: 'Call this first' and explains that the returned website_id is needed by most other tools. This tells an agent when to use the tool, though it does not explicitly mention alternatives or scenarios where the tool should not be used.

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

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

Annotations already mark the tool as destructive and non-idempotent, and the description builds on this by adding critical behavioral context: it can publish live or as a draft, it requires confirm_publish=true on every call, and it demands prior user approval. This goes beyond the structured annotations without contradicting them.

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 short sentences, each carrying essential information: the core action, the draft option, the approval requirement, and the confirmation requirement. No filler or redundant restatement of the tool name.

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

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

For a destructive publish action with no output schema, the description provides enough guidance for safe and correct invocation: what it does, how to avoid going live, and the mandatory confirmation flag. A small gap is the lack of detail about what happens after publishing or how blog_id relates to the chosen destination, but overall it is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly explains publish_as_draft and states that confirm_publish must be true, which adds real meaning beyond the bare boolean schema. However, blog_id is left unexplained; while 'destination' hints at its role, the description does not explicitly map blog_id to the target CMS/blog.

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 ('Publish'), names the resource ('an article'), and identifies the destination ('the website's connected platform') with concrete examples. It also differentiates the draft mode from live publishing, so it is clearly distinct from the read-only and generation-focused sibling 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 description clearly establishes when the tool should be used: when an article is ready to be pushed to a connected CMS, with an explicit user approval step. It does not explicitly name alternatives or say when not to use it, but the context is clear enough that an agent can infer appropriate invocation.

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

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

The description discloses externally visible side effects (submitting URLs to Google/Bing indexing), the dependency on the account feature, and the critical user-approval requirement. This meaningfully exceeds what the annotations alone communicate, especially 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?

Three concise sentences deliver the action, scope, prerequisites, and mandatory approval workflow with no filler. The most important behavioral rules are front-loaded.

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

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

The description covers the main operational constraints: URL cap, required account feature, approval workflow, and confirmation flag. It is complete enough for calling the tool, though it could be slightly stronger by referencing get_indexing_status for follow-up and resolving the confirm_indexing schema ambiguity.

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

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

With 0% schema description coverage, the description must compensate, and it does explain the 50-URL cap and the confirm_indexing=true requirement. However, it does not clarify the role of website_id beyond the schema's title, and it introduces a mild ambiguity by saying confirm_indexing is required while the schema marks it optional with default false.

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 ('Submit') with a clear resource ('up to 50 URLs for search-engine indexing') and names the search engines (Google/Bing). It is immediately distinguishable from sibling status-checking tools like get_indexing_status.

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 clear prerequisites (auto-indexing feature must be enabled), a required user-approval workflow, and the confirmation flag requirement. It does not explicitly name alternatives or say when not to use it, but the action is straightforward enough that the usage 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 provide no positive safety hints, so the description's disclosure of rate limiting for free accounts, the list of audit areas, and the scored result add meaningful behavioral context. It does not describe side effects or authentication requirements, but for an audit tool this is reasonably transparent.

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

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

A single dense sentence front-loads the action and target, then lists important scope categories and a usage constraint. No filler or redundant 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?

With no output schema and weak annotations, the description should explain more about the return value than 'scored result' and should clarify rate limit implications. It covers the main audit scope well but leaves response structure and error behavior unstated.

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

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

Schema description coverage is 0%, so the description carries the burden. It identifies the URL as an unconstrained target ('any URL'), but does not specify expected format such as protocol, trailing paths, or validation rules. This is minimal but adequate for a single string 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 names a specific verb ('Run') and resource ('technical SEO audit') and distinguishes the tool from siblings by emphasizing 'any URL' and listing concrete audit categories. This makes it easy to separate from get_* tools and content generation 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 intended use is implied: use this when you need a broad technical SEO audit of a URL. However, it does not explicitly contrast with alternatives or mention when not to use it compared to the get_* siblings.

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