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.
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.