Did You SEO - MCP

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/network profile is covered. The description adds the scope of extraction (all meta tags, with example types) but says nothing about response shape, rate limits, or failure behavior for unreachable URLs — an openWorld web fetch has real failure modes left undisclosed.

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 tight sentence with the action front-loaded and the extraction scope enumerated. No filler, no redundancy, appropriately sized for a one-parameter read 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 single-parameter, read-only analysis tool with no output schema, the description tells the agent what is extracted and from where. The one remaining gap is how it relates to the overlapping sibling checkers, but the core contract is clear enough to invoke correctly.

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

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

Schema description coverage is 100% and the single 'url' parameter is documented as 'The URL to analyze.' The description's 'for a URL' adds no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb pair ('Extract and inspect') plus the resource ('meta tags') and enumerates the fields returned (title, description, robots, OG). However, it does not differentiate itself from closely overlapping siblings like check_open_graph and check_robots_txt, which cover a subset of the same tags.

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 guidance on when to use this versus alternatives, and the sibling list contains genuine overlap (check_open_graph, check_robots_txt, check_hreflang). The 'for a URL' phrasing implies scope but says nothing about when this broad analyzer is preferable to the targeted checkers.

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 openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: it runs on both mobile and desktop, and field data is only present 'when Google has it' — a conditional-availability disclosure that prevents the agent misreading an empty field-data section as an error.

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, zero filler. The core capability is front-loaded, with the sibling routing placed last as a pointer rather than padding.

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?

No output schema exists, so the description correctly compensates by listing the metrics returned and flagging the conditional field data. For a one-parameter read tool that is close to complete; only the response shape/pagination details are absent, which is minor here.

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 at 100% schema coverage, so the schema carries the burden and the baseline is already high. The description still adds meaning by clarifying that the single URL input yields results for both mobile and desktop, which the schema does not convey.

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 ('Quick Core Web Vitals check for a URL') and enumerates the exact outputs (performance score, LCP, CLS, FCP, TBT, TTFB, field data). It also distinguishes itself from the nearest sibling by naming run_pagespeed_insights as the fuller alternative.

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

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

Explicitly routes the agent: use this for a quick check, use run_pagespeed_insights for the full report. That is a clear alternative-selection rule, though it doesn't state explicit exclusions or prerequisites (auth, rate limits, quota cost).

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 openWorldHint=true, so safety and reach are covered. The description adds no behavioral context beyond that — nothing about whether the live page is fetched, how hreflang sets are evaluated, or what a failed/unreachable URL yields. With annotations present the bar is lower, but this adds essentially no incremental value.

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

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

A single front-loaded sentence with the action and scope stated immediately and zero filler. Nothing to trim and nothing 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?

For a one-parameter read-only inspection tool this is minimally adequate: annotations cover safety, the schema covers the input, and there is no output schema to explain. It still leaves open what the inspection returns and whether a live fetch is required, which an agent calling it correctly might care about.

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% for the single url parameter, so the schema already documents the input fully. The description restates only that analysis applies to a URL and adds no format, absolute-vs-relative, or locale-related 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 names a specific verb (inspect) and resource (hreflang / international targeting tags) scoped to a URL, which distinguishes it from siblings like analyze_meta_tags, check_open_graph, and validate_schema. It is clear what the tool examines, though it does not explicitly frame itself against those siblings.

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

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

There is no guidance on when to choose this tool over related checks (analyze_meta_tags, validate_schema, check_open_graph) or any stated prerequisites such as the page needing to be publicly reachable. The agent must infer usage entirely from the name and one-line purpose.

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 openWorldHint=true, covering the safety profile. The description adds nothing on top of that: no note on whether it fetches live (open-world) content, handles missing tags, or has rate/error 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 short sentence, front-loaded with the verb and resource and free of filler. It is efficient but extremely terse, leaving no room for routing or behavioral context.

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 this is minimally adequate, and annotations cover the safety profile. With no output schema, though, the description says nothing about what is returned (which tags, missing-tag handling), leaving the agent guessing at results.

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

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

Schema description coverage is 100% for the single 'url' parameter, so the schema carries the semantics and the description correctly adds no redundant detail. 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 ('Inspect') and resource ('Open Graph / social-share tags') scoped to a URL, which is clear enough to distinguish it from generic meta-tag or SERP tools. It stops short of naming the sibling it differs from, so an agent must infer the boundary versus analyze_meta_tags.

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 offers no when-to-use guidance, no prerequisites, and never mentions alternatives such as analyze_meta_tags or serp_preview. The agent gets a purpose but no routing signal.

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 openWorldHint=true, so the network-fetch/safe-read profile is covered. The description adds that it both fetches and analyzes impact on crawling, which is useful context, but it says nothing about behavior on missing/404 robots.txt, redirects, or what the analysis covers. Adds some value but not rich disclosure.

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 efficient sentence with the action front-loaded. The trailing clause 'and how it affects crawling' is slightly loose but still earns its place by scoping the analysis.

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?

No output schema exists, so the description is the only place to hint at what comes back (allowed/disallowed rules, crawl impact), and it does not. For a single-param read tool with annotations covering safety, it is adequate but leaves the result shape entirely unspecified.

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 with 100% schema description coverage, so the schema already carries the burden and baseline is 3. The description adds no syntax, domain-vs-page-URL guidance, or format details beyond 'The URL to analyze.'

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 pair (fetch and analyze) and a specific resource (robots.txt), with the added scope 'how it affects crawling'. This clearly separates it from siblings like check_hreflang or analyze_meta_tags, though it never explicitly names an alternative. Clear but not sibling-differentiating in text.

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 when-to-use statement, no prerequisites (e.g. run before a crawl/audit), and no mention of alternatives such as run_seo_audit. Usage is only inferable from the resource name. Comparable to the MID calibration case with 'no when-to-use, no 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 already establish this is a safe, non-open-world read (readOnlyHint=true, openWorldHint=false). The description adds the useful detail that both *status* and *results* come back, hinting at an async/polling lifecycle, but it never explains behavior while the audit is pending, failing, or expired.

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

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

A single front-loaded sentence with no filler; the verb, resource, and key parameter are all in the first clause. Nothing to trim.

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 tool with readOnly annotations and full schema coverage, the essentials are present, and only one output field list is implied rather than described. The absence of an output schema means the description should ideally say what the status values mean or what a pending audit returns, which it does not.

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

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

Schema description coverage is 100% and the only parameter audit_id is already documented in the schema as 'returned by run_seo_audit'. The description merely restates that the id is required, adding no format or validity constraints beyond the schema.

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

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

Specific verb (Fetch) and resource (status and results of a previously run audit), keyed by audit_id. It is clear what the tool returns, though it never names its counterpart run_seo_audit in the description itself to differentiate it from sibling reads like get_page_score or get_site_score.

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?

"Previously run audit" implies a prerequisite call to run_seo_audit, and the schema pinpoints that dependency, but the description gives no explicit when-to-use guidance, no mention of polling until the audit completes, and no when-not-to-use 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=true and openWorldHint=true, so safety is covered. The description adds genuinely useful non-annotated behavior: a cost of 1 DidYouSEO AI credit per call and a refund on failed lookups. It stops short of covering rate limits or auth, so it is not a 5.

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

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

Two sentences, zero filler. The returned metrics are front-loaded and the cost/refund caveat follows immediately after, with nothing that fails to earn 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?

With no output schema, the description correctly compensates by enumerating the returned fields, and it discloses the credit cost and refund behavior. An agent has everything needed to decide to call it and interpret the 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?

One parameter with 100% schema description coverage, so the schema already documents the domain argument (e.g. example.com). The description adds no extra format or constraint detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb (Get) and resource (backlink totals for a domain) and enumerates the exact metrics returned: domain rank 0-1000, backlinks, referring domains, nofollow referring domains, broken backlinks, and first-seen date. No sibling tool covers backlinks, and the scope is unmistakable from the description alone.

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

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

Provides a clear usage context: comparing your site's authority against a competitor's. It does not state when not to use it or name alternatives, but no sibling overlaps in this space, so the guidance is adequate without 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 only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them: the connection/property prerequisite and the plan-gated return (preview vs full landing-page list). It stops short of disclosing rate limits or freshness/lag of the GA 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?

Front-loads the returned metrics in one dense sentence, then tacks on prerequisites and plan behavior. Every clause carries information, though the metric enumeration is long enough to be slightly unwieldy.

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 must carry return-value burden, and it does: it lists the exact metrics, landing pages, and AI-referral data, plus prerequisites and plan-dependent scope. An agent has everything needed to call it and set expectations.

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

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

Schema coverage is 100% and the days parameter is already documented as the comparison-window length. The description echoes the same comparison semantics ('last N days compared with the previous N days') without adding format or default detail beyond the schema, 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 (Get) and resource (Google Analytics 4 organic traffic data) and enumerates exactly what is returned: organic sessions, engagement rate, key events, users, top organic landing pages, and AI-assistant referrals. No sibling tool covers GA4 data, so the agent can identify it immediately.

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

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

The description gives clear context and prerequisites — GA must be connected in DidYouSEO and a GA4 property chosen for the site — plus the plan-based scope (free = preview, paid = full). It doesn't name a when-not condition or an alternative tool, but no sibling overlaps, so exclusions are largely moot.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: a cost of 1 AI credit per call charged across all keywords, refunds on failed lookups, and default US/monthly data. It stops short of describing latency, rate limits, or error semantics.

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 front-loaded sentences, each carrying real information: metrics and scope first, then cost/refund behavior, then plan context. The closing sentence about Starter and Growth plans is the weakest, reading slightly like marketing copy rather than agent-relevant 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 correctly carries the burden of naming the returned fields (volume, difficulty, CPC, intent), which is the key information an agent needs to decide whether this tool answers its question. Missing return shape/pagination detail and any guidance on partial failures beyond the refund note.

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

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

Schema description coverage is 100% and the single array parameter (1-10 keywords) is fully documented there, so the baseline of 3 applies. The description's 'monthly, US by default' adds data-source context but hints at a locale option that no parameter exposes, which is mildly confusing rather than clarifying.

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 and enumerates the exact metrics returned (search volume, difficulty 0-100, CPC, search intent) plus the 1-10 keyword scope. It does not, however, distinguish itself from the sibling get_keyword_ideas, which an agent could easily confuse with this tool.

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 input constraints (1 to 10 keywords) and the cost statement, but there is no explicit when-to-use guidance and no mention of the obvious alternative get_keyword_ideas. The agent must infer the boundary between fetching metrics for known keywords and generating new ideas.

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

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

With readOnlyHint and openWorldHint already declared, the description adds genuinely new behavioral facts: a 50-result cap, sort order, a cost of 1 AI credit per call, and that failed lookups are refunded. These are operator-relevant details not derivable from annotations or schema; only latency/rate-limit behavior is absent.

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 core behavior (what you get, how many, sorted how), then the use case and the cost/refund caveat. No filler and nothing 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?

With no output schema, the description correctly carries the return-value burden by naming the fields returned, the 50-item cap, and the sort order, plus the credit cost. It is essentially complete for a single-parameter read tool; only the sibling distinction is missing.

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

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

There is only one parameter and the schema documents it at 100% coverage with an example. The description's phrase 'contain a seed phrase' corroborates the schema's meaning but adds no syntax, format, or constraint detail beyond it, 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 ('Get up to 50 keyword ideas that contain a seed phrase') plus the returned fields (search volume, keyword difficulty) and ordering (sorted by volume). This is clear and concrete, but it never contrasts itself with the nearby sibling get_keyword_data, leaving the agent to infer the difference between 'keyword ideas' and 'keyword 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?

Explicitly supplies a use case: 'Use it to find low-difficulty keywords a new page can rank for,' which tells the agent the scenario that fits. It stops short of when-not-to-use or naming an alternative sibling for other scenarios, so it is clear context without 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=true and openWorldHint=false, so safety is covered; the description usefully adds that the score is the 'most recent' one (implying stored/stale data rather than a live crawl). It says nothing about what happens if the URL is untracked or what the score scale represents, so value beyond annotations is modest.

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 zero filler. Nothing could be trimmed without losing meaning.

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 tool with annotations covering safety, the description is close to sufficient, but with no output schema an agent gets no hint of what the score looks like (scale, range, freshness window) or how a missing/untracked URL is handled.

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 there is only one parameter, which the schema already documents as 'The page URL to look up.' The description reinforces that the URL must belong to the account but adds no format, canonicalization, or normalization guidance.

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

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

States a specific verb (Get), resource (SEO score) and scope of retrieval (most recent, for a specific page URL in the account). The 'page URL' qualifier implicitly distinguishes it from the sibling get_site_score, but it never names or contrasts that sibling, so an agent must infer the page-vs-site 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives despite get_site_score being an obvious candidate for confusion. The agent is left to infer that this is the per-URL lookup while get_site_score is the account/site-level one.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: plan-gated result depth (preview vs full) and the shape of each returned conflict (competing pages, severity, reason). It stops short of covering data freshness or rate limits.

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

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

Three tight sentences with the core purpose front-loaded, followed by return shape and prerequisites. 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?

With only two parameters and no output schema, the description compensates by describing the returned fields and the plan-dependent depth, plus the GSC connection prerequisite. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and both parameters (days range 7-180 default 90, website URL example) are fully documented in the schema. The description adds no parameter-level meaning 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?

States a specific verb and resource ('Find keyword cannibalization from real Search Console data') and defines the concept inline ('queries where two or more of your own pages compete, splitting rankings'). This clearly separates it from siblings like get_search_console_keywords and get_search_console_changes.

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

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

Gives a concrete applicability prerequisite ('Requires GSC connected') and distinguishes output tiers ('Free plans return a preview; paid plans return full results'). It does not explicitly name an alternative tool or say when-not to use it, so it falls short of a 5.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds genuinely new context: the GSC connection prerequisite and the free-vs-paid tier behavior (preview vs full results). It doesn't mention pagination or result limits, but tiering and auth needs are the important disclosures here.

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 tightly packed sentences: purpose first, then what is returned, then prerequisites and tier behavior. No filler and nothing 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?

With no output schema, the description steps in to describe the return shape (losers, gainers, position changes) and covers the prerequisite and tiering caveat. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100% and both parameters are documented in the schema, including the 7-180 range and default. The description restates the comparison-window semantics of 'days' and the site scope of 'website' but adds no format or edge-case detail beyond the schema, 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 (compare), resource (Search Console performance), and scope (last N days vs previous N days), plus the concrete output (biggest click losers/gainers with position changes). This cleanly separates it from siblings like get_search_console_keywords and get_search_console_cannibalization.

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

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

Gives a clear use case ('spotting traffic drops and decaying pages') and a prerequisite ('Requires GSC connected'), and distinguishes the tool by its period-over-period comparison framing. It stops short of naming an explicit alternative sibling or stating when not to use it.

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, openWorldHint=true), and the description adds genuinely useful context beyond them: the external-account dependency and the plan-gated truncation of results. It does not cover rate limits, pagination, or what happens when GSC is not connected, so it is good but not exhaustive.

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, both front-loaded with the highest-value information: what is returned first, then the precondition and plan caveat. No filler, no 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?

With no output schema, the description carries the burden of describing returns, and it does so concretely (search terms plus clicks, impressions, CTR, average position). The plan-based truncation is disclosed, but result limits, pagination, and error behavior for an unconnected site are not.

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

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

Schema description coverage is 100%, so both parameters (days with its 7-180 range and default 90, and website with its URL format) are already fully documented in the schema. The description adds no syntax, format, or default information beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Get real Google Search Console query performance for one of your connected sites') and enumerates the returned metrics (clicks, impressions, CTR, average position). It implicitly separates itself from siblings like get_keyword_data or get_search_console_changes by scoping to query performance, but never names an alternative to make the boundary explicit.

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

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

It clearly states the precondition (the site's Search Console must be connected to the account) and the plan-dependent behavior (free plans get a top-queries preview, paid plans get full data). There is no explicit when-not-to-use or named alternative tool, so it stops 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=true and openWorldHint=false, so safety and scope are covered. The description adds two useful behavioral details — that the result is the *latest* score (freshness) and that it includes top issues — but says nothing about pagination, error cases for unregistered sites, or rate limits.

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

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

A single front-loaded sentence with the resource, scope, and return content in one pass. 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?

No output schema exists, so the description usefully signals the return shape (score plus top issues). For a one-parameter read tool with full annotation coverage this is nearly sufficient, though it omits any hint about staleness, caching, or what 'top' means in terms of count.

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

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

Schema description coverage is 100%, and the schema already documents site_id including its provenance (from list_sites). The description adds no parameter-level detail, so baseline 3 applies; the schema carries the full burden.

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

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

Names a specific verb (Get) and resource (overall SEO score + top issues) scoped to a site, which implicitly separates it from the sibling get_page_score. It stops short of naming the sibling or the site-vs-page distinction explicitly, so the differentiation is inferred rather than stated.

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

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

The phrase "for a registered site" implies the prerequisite that the site must already exist and that site_id comes from list_sites, but no when-to-use context or alternative tools (e.g. get_page_score, get_audit_result) are named. Usage is implied rather than guided.

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 openWorldHint=false, so safety and scope are covered structurally. The description adds the account-scoping detail ('signed-in DidYouSEO account'), which is useful context, but says nothing about pagination, result limits, or what happens with an empty account.

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

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

One sentence, zero waste, with the scope qualifier (signed-in account) stated inside the same breath as the action. Nothing to trim.

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 present, the description carries the burden of hinting at return shape, and it doesn't — an agent cannot tell whether it gets site IDs, names, or URLs, which matters for chaining into the many site-scoped siblings. Adequate for invoking, incomplete for downstream wiring.

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 per the rubric the baseline is 4 — there is no parameter surface for the description to explain or for the schema to under-document.

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 — listing websites registered in the signed-in DidYouSEO account — which is immediately distinguishable from the write counterpart register_site. It stops short of explicitly naming or contrasting with any sibling, so it lands at clear-but-undifferentiated.

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 phrase 'registered in the signed-in DidYouSEO account' hints that this enumerates the accounts' sites, but there is no statement of when to call it versus alternatives, or that its results are the prerequisite input for tools like get_site_score or run_seo_audit.

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=false, so the safety profile is covered. The description adds the post-registration behavior (tracked/audited), but does not address the meaningfully non-idempotent hint -- i.e. whether re-registering the same URL creates a duplicate -- which is the highest-value behavior an agent would need.

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

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

A single front-loaded sentence with zero filler; it states the action, target account, and purpose in one pass.

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

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

For a simple two-parameter tool with no output schema and annotations covering safety, the description is minimally sufficient. It omits the duplicate/already-registered case implied by idempotentHint=false, which is the main gap for an agent deciding whether to call it.

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

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

Schema description coverage is 100%, with both url and label documented in the schema itself. The description adds no format, constraint, or scoping detail beyond what the schema provides, 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+resource ('Add a new website') and the domain (DidYouSEO account), plus the outcome (tracked and audited). This clearly separates it from siblings like list_sites or run_seo_audit, though it does not name 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?

The phrase 'so it can be tracked and audited' implies this is a prerequisite step before audit tools, but there is no explicit when-to-use, when-not-to-use, or guidance on what to do if the site already exists.

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

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

With readOnlyHint and openWorldHint already set, the description still adds real behavioral context: it is free, needs no account, and results are cached for an hour — the caching caveat is the kind of trait an agent needs to avoid re-running for stale data. It does not describe failure modes or rate limits, so it stops short of a 5.

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

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

Front-loaded with the action and result inventory; the closing two sentences (free/no account, one-hour cache) are short and earn their place. The middle sentence is a long enumeration but remains readable and information-dense rather than padded.

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

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

There is no output schema, so the description carries the return-value burden itself and does so thoroughly — scores, lab metrics, field CWV at p75, and opportunities. Combined with the safety annotations, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so the url and strategy parameters (including the mobile/desktop/both enum and the mobile-ranking rationale) are already fully documented in the schema. 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?

Specific verb+resource ('Run Google PageSpeed Insights on a URL') followed by a precise enumeration of outputs (four Lighthouse scores, CrUX field metrics at p75, opportunities with estimated savings). The output profile distinguishes it implicitly from siblings like check_core_web_vitals and get_page_score, which return narrower 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?

The description establishes context ('free, no account needed') but never states when to choose this over the overlapping siblings check_core_web_vitals or get_page_score, nor any exclusions. Usage is only implied by the fact that it runs a full PSI report.

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 useful execution context: synchronous, returns the result inline. It also discloses the output shape (score plus critical/warning issues plus fixes), which annotations do not. It doesn't explain why the audit isn't read-only or whether it persists state.

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 padding; the capability and its scope are front-loaded and the synchronous-return caveat follows logically.

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 usefully describes the return (score, critical/warning issues, fixes) and the sync behavior. It is nearly complete for a single-URL tool, with only the sync-vs-poll routing against get_audit_result left 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 100%, so both 'url' and the optional 'site_id' are already documented in the schema, including a concrete example. The description adds nothing about parameter formats or the purpose of site_id, 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 ('Run') and resource ('SEO audit on any URL') with scope detail ('40+ point'). The '40+ point full audit' framing implies an aggregate check versus the granular check_* siblings, but no sibling is named explicitly, so differentiation is inferential rather than stated.

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 through the phrase 'Runs synchronously and returns the result directly', which hints this is a blocking call rather than something to poll via get_audit_result. It never states when to choose this over the individual check_* tools or the get_page_score/get_site_score 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=true and openWorldHint=true, so safety and network-access behavior are covered. The description adds essentially nothing beyond that – no mention of truncation/pixel-width limits, no note that the page is fetched live, no return-shape hints, so it does not exploit the lower bar for added context.

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

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

One well-formed sentence that front-loads the verb and resource with zero filler. Nothing could be removed without losing meaning.

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, single-parameter tool with annotations covering safety, the description is adequate, but with no output schema it omits the most useful behavior for this task – that the preview reflects SERP truncation limits and how the snippet is rendered.

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 a single parameter with 100% schema description coverage ('The URL to analyze'), so the schema fully documents it. The description adds no format details (e.g., absolute vs relative URL, required scheme), making the baseline 3 appropriate.

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

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

States a specific verb (preview) and resource (SERP appearance of a page's title/description), which an agent can distinguish from siblings like analyze_meta_tags or check_open_graph. However, it never names or contrasts with those siblings, so differentiation rests on inference.

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

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

The purpose implies when the tool is useful (checking search-result snippet rendering), but there is no explicit when-to-use guidance, no exclusions, and no pointer to the sibling tools that analyze the underlying tags. Usage is left implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, network-dependent read; the description adds the scope of what is inspected (JSON-LD/schema.org markup on a page). It does not disclose what a validation outcome looks like (errors vs. warnings), which matters for a validation 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?

One sentence, front-loaded with the action and the target, with no filler. Exactly proportionate to a 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?

With no output schema, the description is the only place to explain what comes back (missing required properties, invalid types, warnings) and it omits that entirely. For a simple single-URL validation tool this is a noticeable but not severe 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?

There is a single required parameter with 100% schema description coverage ('The URL to analyze'), so the schema already carries the semantics. The description adds nothing about URL format, depth, or whether subpages are crawled; 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 pair (detect and validate) and a precise resource (JSON-LD / schema.org structured data on a page), which separates it from generic 'analyze' siblings. It does not explicitly distinguish itself from nearby tools such as check_open_graph, but the resource is narrow enough that an agent can route correctly.

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 guidance, no prerequisites, and names no alternatives among the SEO-audit siblings. Usage is only implied by the fact that it fits an audit suite.

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