SEO, AEO, GEO, Local SEO & CRO Growth Auditor + Safe Code Fixer with multi-page sitemap crawling, HTTP security headers inspection (HSTS, CSP), and universal WebMCP support.
Performs Answer Engine Optimization audit: Direct answer blocks, question headings (What/How/Why), FAQ schema alignment, concise definition snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is solely responsible for behavioral disclosure. It describes what the audit checks, but does not state whether the tool is read-only, whether it requires authentication or network access to the target URL, or what format the results take. It never explicitly says the audit causes no modifications, and the word 'audit' only weakly implies a non-destructive operation.
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 entire description is a single, efficiently structured sentence that front-loads the action and uses a colon to itemize the audit's focus areas. Every phrase adds distinct information (What/How/Why headings, FAQ schema, definition snippets) without filler or repetition.
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 is concise and explains the audit's scope, but for a tool with no annotations and no output schema, it leaves significant gaps: it doesn't explain what the agent should expect after invocation (report, issues list, score), how the target should be formatted for different cases, or how this audit relates to the many sibling audit tools. These omissions make the description adequate but not fully 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 coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details beyond the schema; the target parameter is not mentioned at all, and no syntax, allowed values, or examples are given. There is no value added over 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?
States a specific verb ('Performs') and a distinct resource ('Answer Engine Optimization audit'), then enumerates the exact audit dimensions (direct answer blocks, question headings, FAQ schema alignment, definition snippets). This clearly distinguishes it from sibling audits like seo_audit_schema or seo_audit_content, even without reading their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to call this tool (when an AEO audit is needed) through its title and scope, but it never states explicit conditions, prerequisites, or alternatives. There is no guidance about choosing this over the overlapping sibling seo_audit_schema or seo_audit_content, leaving the agent to infer usage from the audit type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits content quality, search intent classification (Informational, Commercial, Transactional, Navigational), thin content risks, readability, and E-E-A-T signals.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose what dimensions are assessed, such as intent classification and E-E-A-T signals, which is useful behavioral context. However, it does not mention side effects, permissions, rate limits, or whether the operation is read-only, leaving some behavioral ambiguity.
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 information-dense sentence with no filler. Each listed audit dimension adds meaningful scope, and the structure fronts the main action clearly.
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 one parameter and no output schema, the description lists what will be audited in reasonable detail, which helps an agent understand the tool's scope. However, it does not describe what the returned report looks like or how results are structured, and with no annotations or output schema the description could do more to fully prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, 'target', is already described as 'Target file path or live URL.' The description does not add further semantic detail about the parameter, so the schema carries the heavy lifting.
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 ('Audits') and a clear resource ('content quality') while naming concrete dimensions: search intent classification, thin content risks, readability, and E-E-A-T signals. It distinguishes itself from siblings like seo_audit_technical or seo_audit_onpage by focusing on content, though it does not explicitly contrast itself with them.
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 choose this tool over alternatives. Siblings like seo_audit_onpage and seo_audit_technical may overlap in scope, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits Conversion Rate Optimization (CRO) & digital marketing: Primary/secondary CTAs, contact channels (forms, phone, WhatsApp), social proof, risk reversal.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It communicates audit scope but does not state whether the operation is read-only, what output or report format is produced, whether it requires authentication, or if it makes network requests. 'Audits' mildly implies non-mutation, but behavioral transparency is largely 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?
A single, front-loaded sentence with the verb and resource up front, followed by a tight list of audit dimensions. There is no filler; every phrase contributes to understanding what the tool inspects.
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 audit tool, the focus areas are reasonably complete. However, with no output schema and no annotations, the description leaves important behavioral context undocumented, such as what the audit returns and whether any side effects are possible. Invocation is clear, but post-invocation expectations 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 the baseline is 3. The description does not add parameter-specific meaning beyond the schema's 'Target file path or live URL'; it only clarifies the audit content, not how the target behaves.
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-resource pair, 'Audits Conversion Rate Optimization (CRO)', and then enumerates concrete focus areas such as primary/secondary CTAs, contact channels, social proof, and risk reversal. This clearly distinguishes the tool from sibling SEO audit tools focused on technical, content, local, or performance topics.
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 domain of CRO and digital marketing gives a clear contextual signal, but the description does not explicitly state when to prefer this audit over sibling audit tools or when it should not be used. Usage is implied rather than prescribed, so the agent must infer the boundary from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs Generative Engine Optimization audit: Brand/Organization entities, sameAs knowledge graph reconciliation, Author E-E-A-T credentials, service relationships.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It reveals the audit's subject matter but does not state whether the tool is read-only, whether it modifies anything, how results are returned, or whether special access is required. 'Audit' implies analysis, but the operational behavior is left unstated.
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 focused sentence that front-loads the action and then lists the audit's specific focus areas. It contains no filler or redundant phrasing.
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 audit tool this is reasonably compact, but with no annotations and no output schema the agent is left to infer return behavior and operational scope. The listed topics give enough topic-level context to make the first call, yet the description is thin on what the agent should expect from the audit.
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 only parameter, target, is fully documented in the schema ('Target file path or live URL'), so schema description coverage is 100%. The description adds no additional detail about accepted formats, limitations, or interaction with the target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Performs Generative Engine Optimization audit') and enumerates distinct audit dimensions (Brand/Organization entities, sameAs knowledge graph reconciliation, Author E-E-A-T credentials, service relationships). It is clearly not a generic audit, though it does not explicitly contrast with sibling seo_audit_aeo.
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 is provided on when to select this tool over siblings such as seo_audit_aeo, seo_audit_schema, or seo_audit_onpage. The intended context is implied only by the tool name and the listed audit topics, with no explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits internal link architecture, generic anchor text, orphan pages, and generates high-value contextual linking recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'Audits' and 'generates ... recommendations' accurately convey a non-mutating analysis tool that produces output, and the specific audit subject (orphan pages, anchor text) adds useful context beyond the tool name. However, it does not disclose process, response shape, crawl behavior, or any limits, so it is not fully 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, front-loaded sentence that lists the audited elements and the produced outcome without filler or redundancy. Every phrase contributes meaning, making the definition efficient and scannable.
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, non-mutating audit tool, the description covers what it analyzes, what it produces, and the schema specifies how to supply the target. It does not specify output formatting or detailed usage caveats, but nothing critical is missing for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, target, already carries a clear schema description ('Target file path or live URL'), so schema coverage is 100% and the description adds no additional meaning. The baseline of 3 is appropriate because the schema does the semantic heavy lifting and no ambiguity exists.
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 ('audits') and resource ('internal link architecture, generic anchor text, orphan pages'), and it names the output ('high-value contextual linking recommendations'). Together with the tool name, this clearly distinguishes it from the many sibling seo_audit_* 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 the tool is for diagnosing internal-link health and generating linking suggestions, but it never states when to prefer it over alternatives such as seo_audit_technical or seo_audit_onpage. There are no explicit exclusions or alternative tool pointers, so the context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs Local & Area SEO audit: LocalBusiness schema completeness, visible NAP consistency, click-to-call phone, address validation, location page duplication.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal what the audit inspects (schema completeness, NAP consistency, click-to-call, address validation, duplication), which is useful. Yet it does not explicitly state that the operation is read-only, whether it returns a report, or what the side effects, if any, are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a colon followed by a compact list of audit dimensions. It is efficient and front-loads the main purpose, though the list is somewhat dense and 'Local & Area' plus 'LocalBusiness' is slightly redundant.
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 tool with full schema coverage, the description gives a reasonable sense of what will be checked. However, with no output schema and no annotations, it does not explain what the agent will receive after the audit, how results are presented, or any prerequisites or side effects, leaving the behavioral outcome somewhat underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, 'target', as 'Target file path or live URL.', giving 100% coverage. The description does not add parameter-specific details such as supported URL formats, file extensions, or how the target should be provided, so it does not elevate meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Performs') and a specific resource ('Local & Area SEO audit'), then enumerates distinct audit areas: LocalBusiness schema completeness, NAP consistency, click-to-call phone, address validation, and location page duplication. This clearly differentiates it from siblings like seo_audit_schema, seo_audit_content, or seo_audit_technical even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool through 'Local & Area SEO audit' and the listed local-SEO checks, so an agent can infer it is for local search audits. However, it does not explicitly state when to prefer it over related siblings such as seo_audit_geo or seo_audit_schema, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs On-Page SEO audit: Title tag length/CTR/keywords, Meta Description, H1-H6 hierarchy, OpenGraph and Twitter cards.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. The word 'audit' and the listed checks suggest a read-only analysis, but the description does not explicitly state that the target is never modified or describe output behavior. It is not contradictory, just thin.
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 states the action first and then lists the audit dimensions compactly. There is no filler or redundant repetition 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?
The tool is low-complexity: one required parameter is fully documented, and the audit scope is explicitly enumerated, so an agent can invoke it with only a target. The absence of output details is a minor gap, especially since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, 'target', as 'Target file path or live URL' with 100% coverage. The description adds no additional 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?
The description uses a clear action and resource: 'Performs On-Page SEO audit' and then enumerates concrete audit areas (title tag, meta description, H1-H6, OpenGraph, Twitter cards). It is clear, but it does not explicitly contrast itself with the many sibling audit 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 use when an on-page audit is needed, but it gives no explicit when-to-use or when-not-to-use guidance. With 20 similar seo_audit_* siblings present, an agent gets little help choosing this tool over seo_audit_content or seo_audit_technical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identifies code-level Core Web Vitals risks: CLS risks (images without width/height), LCP risks (legacy image formats), and render-blocking scripts.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It indicates an analysis-oriented operation but does not state whether it performs network fetches, parses files locally, returns a report, or has any side effects. There is no enrichment beyond the basic 'identifies risks' claim.
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 efficient sentence that front-loads the core purpose and follows with a compact, scannable list of risk categories. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, and the description covers its primary purpose well. However, with no output schema and no annotations, the description leaves out return format and behavioral context, and it does not help an agent choose among closely related audit siblings. It is minimally viable but not 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 100%, so the target parameter is already documented as a file path or live URL. The description adds no additional meaning about how the target is used or validated, but because the schema already covers it, a baseline 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 uses a specific verb ('identifies') and a clear resource ('code-level Core Web Vitals risks'), then enumerates concrete risk categories: CLS, LCP, and render-blocking scripts. This clearly distinguishes it from sibling tools like seo_audit_content or seo_audit_technical by naming exact technical concerns.
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 context is implied: use this tool when investigating Core Web Vitals or performance-related code risks. However, it does not explicitly state when to prefer this over seo_audit_technical, seo_audit_onpage, or seo_generate_full_audit, nor does it mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deeply inspects robots.txt rules (allow/disallow per user-agent), sitemap.xml validity, disallowed pages mistakenly in sitemap, and HTTP security headers (HSTS, CSP, X-Frame-Options).
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Website URL (https://...) or local codebase folder path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. The verb 'inspects' implies a read-only audit and the description lists concrete checks, but it does not mention whether live network requests are made, whether authentication is needed, what kind of output is returned, or any rate/time implications.
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 efficient sentence that front-loads the core audit targets in a readable list. The word 'Deeply' adds little value, but overall the structure is compact and easy to parse.
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 audit tool, the description covers a broad and clear functional scope: robots rules, sitemap validity, sitemap/robots conflicts, and security headers. It lacks output format details and usage differentiation, but given the tool's simplicity, it is reasonably 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?
The input schema already fully documents the single 'target' parameter, including both URL and local folder path options. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline score 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 clearly specifies what the tool inspects: robots.txt allow/disallow rules per user-agent, sitemap.xml validity, disallowed pages appearing in sitemaps, and HTTP security headers. It is specific about the resource and scope, though it does not explicitly differentiate itself from overlapping siblings like seo_audit_sitemap_multipage or seo_audit_technical.
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 use this tool versus alternatives. The description implies it is for robots.txt and sitemap auditing, but it never states when not to use it or names sibling tools that cover partially overlapping concerns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extracts and validates Schema.org structured data (Organization, LocalBusiness, FAQPage, Service, Product, BreadcrumbList, Article) for JSON syntax and completeness.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the tool checks JSON syntax and completeness, which is useful, but it does not explicitly state that this is a read-only audit, what output the agent should expect, or any environmental requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core action and resource, and the parenthetical list of supported schema types is compact and informative.
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 is acceptable for a simple single-parameter audit tool, but it lacks context about return values, whether the operation modifies anything, and how it differs from other audit tools. This makes it minimally viable but not fully 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 100% for the single parameter, so the schema itself already documents 'target' as a file path or live URL. The description adds no additional parameter-level meaning, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Extracts and validates') and names a clear resource ('Schema.org structured data'), also listing relevant schema types. It clearly indicates this tool is for schema auditing, though it does not explicitly contrast it with 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?
No guidance is provided about when to use this tool versus alternatives like seo_audit_technical or seo_audit_onpage. The intended use is only implied by the word 'schema' in the description, with no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawls and audits every page registered in a website sitemap.xml (or local routes), cross-checks robots.txt allow/disallow rules, inspects HTTP security headers (HSTS, CSP), and generates a site-wide SEO/AEO/GEO/CRO health score, inventory table, and remediation roadmap.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Website URL (https://...) or local codebase folder path. | |
| maxPages | No | Maximum number of sitemap URLs to crawl and audit (default: 25). | |
| userAgent | No | Target crawler user-agent to test robots.txt permissions against (default: Googlebot). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses key behaviors: crawling every sitemap page, cross-checking robots.txt rules, inspecting HSTS/CSP headers, and generating deliverables. It does not explicitly state that the operation is read-only or mention rate limits, but 'audits' and the output framing make the non-destructive intent clear.
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 dense sentence but each clause contributes meaningful information about scope, checks, and outputs. It is not bloated, though splitting it into two sentences would improve scanability slightly.
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 names the key return artifacts (health score, inventory table, remediation roadmap) despite lacking an output schema, and covers the main scope and checks. It does not describe output format or detailed edge cases, but for a complex audit tool it provides enough context for an agent to understand what it will get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The tool description adds no parameter-level detail beyond what the schema already documents for target, maxPages, and userAgent, though it does reinforce that target can be a URL or local path.
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 a specific action (crawls and audits every page in a sitemap) and a defined scope (sitemap.xml or local routes), and lists concrete checks and outputs. It does not explicitly differentiate itself from sibling tools like seo_audit_robots_and_sitemap, but the multipage sitemap-wide scope makes its purpose reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a full sitemap-wide audit covering robots.txt, headers, and a health score is needed. However, it offers no explicit exclusions or comparisons to alternatives such as seo_audit_technical or seo_audit_robots_and_sitemap, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs Technical SEO audit: Canonical consistency, robots.txt, meta robots noindex/nofollow, sitemaps, trailing slash consistency, mixed content.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. | |
| projectPath | No | Optional project root path for sitemap/robots discovery. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It reveals the audit scope but does not state whether the tool is read-only, whether it makes network requests, or what kind of report it produces; 'audit' weakly implies no mutation but leaves side effects implicit.
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 tight sentence with a front-loaded action and a scannable list of audit checks. 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?
Adequate for selecting the tool's topic, but not complete: the description doesn't describe expected output/return values and doesn't disambiguate from closely related siblings (robots_and_sitemap, sitemap_multipage). The simple 2-parameter schema mitigates the 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?
Schema covers both parameters fully with descriptions ('Target file path or live URL', 'Optional project root path for sitemap/robots discovery'), so the baseline applies. The tool description adds no new parameter detail beyond reinforcing that sitemaps/robots are involved.
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 ('Performs') with a clear resource ('Technical SEO audit') and enumerates six concrete checks, so an agent can understand the audit scope. It does not explicitly contrast with siblings such as seo_audit_robots_and_sitemap or seo_audit_onpage, which may overlap on robots/sitemap topics.
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 context is only implied: the description names topics where this tool applies (canonical, robots, sitemaps, mixed content), suggesting 'use when these checks are needed.' It gives no explicit when-not-to-use or alternatives, despite many sibling audit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawls a live URL or reads a local template/HTML file to extract Title, Meta, Headings (H1-H6), Canonical, Schema (JSON-LD), OpenGraph, Links, and Images.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target live URL (https://...) or local file path. | |
| pageType | No | Optional override for page type (homepage, service, product, blog, location, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It clearly implies a read-only operation ('crawls', 'reads', 'extracts') and lists the output scope, which is useful context. It does not mention behavioral details such as JavaScript rendering, redirects, authentication, rate limits, or error handling for invalid targets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that leads with the action and target, then delivers a compact list of extracted elements. Every word earns its place, and there is 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?
Even without an output schema, the description tells the agent what kinds of data will be returned by listing the extracted elements, and it clarifies both accepted input types. It falls slightly short by not specifying the exact return format or explicitly addressing when raw extraction is preferable to the sibling audit tools.
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 input schema already documents both parameters. The description largely duplicates the target parameter's schema text and adds only minor specificity ('template/HTML'). pageType is not elaborated in the description, but the schema covers it sufficiently.
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 ('crawls'/'reads') with a clear resource (live URL or local file) and enumerates exactly what gets extracted (Title, Meta, Headings, etc.). This differentiates it from the seo_audit_* siblings by nature of the operation, though it does not explicitly name a sibling 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?
Usage is implied: the description tells the agent this tool extracts raw SEO elements from a URL or file, so an agent can infer it should be used when raw data is needed. However, it does not state when NOT to use it, or explicitly route to audit tools when a full audit is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discovers website framework (Laravel, Next.js App/Pages, Nuxt, Astro, Raw PHP, HTML), routes, sitemaps, robots.txt, llms.txt, and page inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute or relative path to project root directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'Discovers' signals a read-style inventory action and the artifact list sets expectations for what will be inspected or returned, but it does not disclose whether it operates only on the local filesystem, whether large projects could be slow, or what the result payload looks like. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, front-loaded sentence that spends no words on filler. Each listed artifact type adds useful search context for an agent deciding whether to invoke the 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 one-parameter discovery tool, the description is largely complete: it enumerates the expected outputs and the schema already handles the path input. It loses a point because it never states the return format or timing/usage context (e.g., that this should be run before audits), and there is no output schema to fill that 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?
The input schema already documents projectPath as an 'Absolute or relative path to project root directory' with 100% coverage, so the description does not need to restate it. The description adds no extra parameter-level guidance such as path normalization, required file structure, or common mistakes, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Discovers', and a concrete resource list (framework types, routes, sitemaps, robots.txt, llms.txt, page inventory) that clearly differentiates it from audit/crawl/generate siblings. The projectPath parameter reinforces that this is a local project discovery tool, resolving any residual ambiguity about scope.
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 verb 'Discovers' implies that this tool should be used when an agent needs a project's structural and SEO inventory, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like seo_crawl_and_extract or seo_audit_robots_and_sitemap, leaving selection mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates surgical, framework-aware code fixes (Laravel Blade, Next.js App/Pages, HTML, PHP, Astro, Svelte) including WebMCP discovery link injection with unified diff preview. Set applyDirectly to true to write changes.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New or updated title tag. | |
| filePath | Yes | Path to the source file to modify. | |
| canonicalUrl | No | Canonical URL. | |
| jsonLdSchema | No | Schema.org JSON-LD object to inject. | |
| applyDirectly | No | Whether to write changes directly to disk (default: false). | |
| webMcpEndpoint | No | WebMCP endpoint URL to inject into HTML <head> via <link rel="mcp-server" /> (e.g. /mcp or /api/mcp). | |
| metaDescription | No | New or updated meta description. | |
| addWebMcpDiscovery | No | Whether to inject standard <link rel="mcp-server" href="/mcp" /> tag. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It does disclose the most important behavioral trait: by default it appears to produce a 'unified diff preview', and actual writes only happen when applyDirectly is set to true. It also reveals that WebMCP discovery link injection is part of the generated fix, giving the agent a clear model of what the tool changes and when to expect destructive side effects.
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: two sentences, with the primary action and scope front-loaded before the framework list and write behavior. The framework list is somewhat long but directly relevant to helping the agent understand supported targets. No fluff or repeated schema content dominates the description.
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 an 8-parameter mutation tool with no output schema and no annotations, the description should explain more about the expected return value and how this fits with related tools like seo_validate_code_fix. It does cover the diff-preview and opt-in write behavior, which is essential context, but it omits workflow context such as whether generated fixes should be validated after generation or how the diff is returned. This is adequate but leaves clear gaps for a complex 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 baseline is 3 because the schema already documents all 8 parameters. The description adds high-level context about framework awareness and WebMCP injection, but it does not enrich individual parameter semantics beyond what the schema already provides. It mostly restates concepts like webMcpEndpoint/addWebMcpDiscovery and applyDirectly in aggregate terms.
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 leads with a specific verb and resource: 'Generates surgical, framework-aware code fixes', listing concrete target frameworks (Laravel Blade, Next.js, HTML, PHP, Astro, Svelte). It clearly distinguishes itself from the sibling tools, especially seo_validate_code_fix, by making generation the core action. The WebMCP discovery-link injection is also called out as a specific capability.
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 prefer this tool over alternatives such as seo_validate_code_fix or seo_test_web_mcp. The only operational hint is 'Set applyDirectly to true to write changes', which addresses how to invoke behavior rather than when to select the tool. An agent is left to infer the appropriate context without any explicit routing or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the complete 8-dimension audit suite, computes 0-100 scores and letter grades, builds the P0-P3 prioritized action matrix, and outputs formatted Markdown report.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. | |
| projectPath | No | Optional project root directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently lists what the tool runs, what it computes, and what format it outputs, which is helpful. However, it doesn't disclose potential side effects (e.g., crawling, file writes), execution cost, or whether a prior discovery/crawl is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and flows logically through the pipeline: run suite, compute scores, build matrix, output report. Every clause contributes meaningful information with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description usefully specifies the output format (Markdown report) and its contents. The required parameter is documented in the schema, and the optional parameter is self-explanatory. A minor gap is not enumerating the 8 dimensions or stating prerequisites, but the description is sufficient for an agent to invoke 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?
Schema description coverage is 100%, with both 'target' and 'projectPath' already documented in the schema. The description adds no additional parameter-level meaning, so the baseline score 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 clearly states the specific verb ('Runs'), the resource ('complete 8-dimension audit suite'), and the concrete outputs (scores, grades, action matrix, Markdown report). The word 'complete' and the detailed pipeline distinguish it from the individual seo_audit_* siblings without opening any schemas.
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 is the comprehensive/aggregate audit tool versus the single-dimension siblings, but it never explicitly states when to choose it over them or when not to. The 'complete 8-dimension audit suite' phrasing provides context, but no alternatives or exclusion conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a comprehensive digital marketing strategy blueprint, buyer intent & funnel mapping, CRO recommendations, AEO AI overview tactics, and a 30-60-90 day growth roadmap.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target file path or live URL. | |
| projectPath | No | Optional project root directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the only behavioral signal. It does disclose what the tool produces and names five output components, but it does not disclose side effects, whether files are written to projectPath, authentication needs, or return format. This is a meaningful but incomplete behavioral picture.
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 dense sentence with no filler, and the most important deliverable ('digital marketing strategy blueprint') is front-loaded. It could be slightly better structured with separators, but it is 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 2-parameter tool with no output schema and no annotations, the description gives a good list of deliverable categories but omits how the target is used, whether projectPath receives output files, and what the returned artifact looks like. It is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: target is described as 'Target file path or live URL' and projectPath as 'Optional project root directory.' The description adds no parameter detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Generates') and names a concrete deliverable: a digital marketing strategy blueprint, plus buyer intent/funnel mapping, CRO recommendations, AEO tactics, and a 30-60-90 day roadmap. This clearly distinguishes it from sibling audit and code-fix 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 a use case—when a marketing strategy, funnel mapping, and growth roadmap are needed—and the sibling tools are mostly audits, so context is inferable. However, it provides no explicit when-to-use, when-not-to-use, or alternative tool names, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates standard-compliant, production-ready sitemap.xml and robots.txt configuration files for any website or codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | Array of relative or absolute URLs to register in sitemap.xml. | |
| targetUrl | Yes | Base website URL (e.g., https://example.com). | |
| disallowedPaths | No | Paths to disallow in robots.txt (e.g. ["/admin/", "/api/private/"]). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says the output is standard-compliant and production-ready, but does not disclose whether files are written to disk, returned as content, overwrite existing files, or require any permissions or side-effect awareness.
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 compact sentence with no redundant wording. The core-purpose information is front-loaded and every phrase adds value.
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 no annotations and no output schema, this description leaves important context uncovered: what the generated files look like, whether optional params produce partial outputs, and what the tool returns. For a generation tool with possible filesystem side effects, this is a material 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?
Schema description coverage is 100%, so the schema already documents targetUrl, urls, and disallowedPaths. The description adds no parameter-specific 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?
The description uses a specific verb ('Generates') with concrete resources (sitemap.xml and robots.txt configuration files), and adds qualitative scope ('standard-compliant, production-ready'). It clearly distinguishes this generation tool from sibling audit tools by naming the artifacts it produces.
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 by the verb and resource: use when sitemap.xml or robots.txt files need to be generated. However, the description gives no explicit guidance about when not to use it, nor does it contrast with sibling tools like seo_audit_robots_and_sitemap or seo_validate_code_fix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tests a live website or local codebase to check if Web MCP (Streamable HTTP/SSE endpoint, manifest, or DOM tools) is enabled, runs protocol compliance diagnostics, and provides language-specific implementation code fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Live website URL to test for Web MCP enablement (e.g. https://example.com). | |
| targetLanguage | No | Optional target programming language or framework to generate customized code fixes for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It states that the tool runs tests and diagnostics and provides code fixes, which gives a reasonable picture. It does not disclose potential side effects such as network requests to the target site or whether generated fixes are actually applied, but the non-mutating language ('tests', 'provides') offers a baseline of transparency.
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 dense sentence that front-loads the main purpose ('Tests') and then efficiently lists the main outcomes. Every clause adds information, though it could be split into separate sentences for easier parsing.
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 core inputs and outputs well enough for an agent to select and invoke the tool, especially with a fully documented required parameter. However, there is no output schema, and the description does not explain what the diagnostics report contains or the relationship between 'local codebase' and the required 'live website URL' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that targetLanguage is for language-specific fixes, matching the schema. It does not add much beyond the schema, and it introduces a slight ambiguity by mentioning 'local codebase' while the schema only documents a live website URL.
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 action ('Tests'), a clear resource ('live website or local codebase'), and a distinctive objective ('check if Web MCP ... is enabled'). It also mentions diagnostics and code-fix generation, which helps differentiate it from generic audit siblings. It does not explicitly name a sibling to distinguish from, but the unique Web MCP focus makes the purpose 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 when to use the tool: when you need to verify Web MCP enablement or get compliance fixes. However, it does not provide explicit guidance on when not to use it or how it compares to related tools like seo_generate_code_fix or seo_audit_technical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates modified code files for duplicate meta tags, JSON-LD syntax errors, and calculates Before vs After score improvements.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to modified source file. | |
| beforeScores | No | Optional previous dimension scores to compute score diff. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it validates specific issues and computes score diffs, which implies read-only behavior, but it does not explicitly state whether the tool modifies files, what happens on validation failure, or the response format. The lack of output schema and side-effect disclosure leaves some ambiguity.
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 that front-loads the core action ('Validates modified code files') and packs the key details (validation types and score calculation) with no redundant wording. Every word contributes to understanding.
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 validation tool with two parameters and no output schema, the description explains what it checks and what it computes, but it does not specify the return format or provide usage guidance relative to siblings. Given the absence of an output schema, the agent would benefit from more detail about what the tool returns, reducing completeness to a moderate level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (filePath and beforeScores) with 100% coverage. The description's mention of 'Before vs After score improvements' loosely aligns with beforeScores, but it adds no new syntactic or semantic detail beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Validates modified code files'), specifies the exact validation checks (duplicate meta tags, JSON-LD syntax errors), and mentions the score improvement calculation. This clearly distinguishes it from the audit tools (seo_audit_*) and the fix generator (seo_generate_code_fix) among its 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?
The phrase 'modified code files' implies the tool is used after code changes, and 'Before vs After score improvements' suggests it compares prior scores with new ones. However, there is no explicit statement about when to use it versus alternatives like seo_generate_code_fix or the audit tools, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most audit tools target distinct SEO dimensions, but several overlap: seo_audit_technical, seo_audit_robots_and_sitemap, and seo_audit_sitemap_multipage all involve robots.txt, sitemaps, and header checks. The descriptions help, but an agent could easily misselect between these related tools.
All tools follow a consistent seo_ prefix with clear verb_noun snake_case naming: audit_, crawl_, discover_, generate_, suggest_, test_, validate_. There is no mixing of conventions or vague generic verbs.
With 21 tools, the server sits in the 16-25 'heavy' range. The broad SEO scope justifies many of them, but the large number of overlapping audit variants makes the set feel slightly bloated.
The server covers the SEO lifecycle well: discovery, crawling, dimension-specific audits, full audits, code fixes, sitemap/robots generation, and validation. Minor gaps such as dedicated backlink or mobile usability audits exist, and the '8-dimension' full audit claim does not align with the 12 distinct audit tools.