automatelab-ai-seo

Official

by AutomateLab-tech

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, and descriptions explicitly guide when to use each (e.g., audit_page vs. specialized tools). However, some overlap exists (e.g., multiple scoring tools, aggregate vs. specific audits) which could cause minor confusion.
Naming Consistency3/5
Tools follow a mix of verb_noun (audit_page, check_robots) and noun_verb (pricing_generate, report_save) patterns. While readable, this inconsistency slightly reduces predictability.
Tool Count4/5
20 tools is a reasonably large set but appropriate for the comprehensive SEO audit domain. Each tool covers a distinct aspect (pages, sitemaps, robots, schema, scoring, rewriting), and no clearly redundant tools exist.
Completeness4/5
The set covers most essential read-only audit operations for SEO and AI readiness. Minor gaps exist (e.g., no tool for checking SSL or speed), but the domain is well-addressed with tools for auditing, scoring, rewriting, and generating standard files.
Average 4.8/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds context about file path restrictions (escapes rejected) and automatic detection of audit result shape. This is useful but not extensive; the core behavioral insight (writes to disk) is already conveyed by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and outcome. Every word is necessary; no fluff. Perfectly concise for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, high schema coverage, and presence of an output schema, the description covers all key aspects: what it does, input requirements (audit_result shape), file path constraints, and overwrite behavior. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value by explaining that audit_result should be passed verbatim and that the tool auto-detects its shape. For path, it reiterates the relative-to-root and rejection behavior. This raises the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders an audit_page or audit_site result as Markdown and writes to a file under MCP_WORKSPACE_ROOT. The verb 'Save' and resource 'audit report to disk' are specific and unambiguous. Among siblings, only this tool performs file I/O, so it's well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is used after running audit_page or audit_site, providing clear context. It does not explicitly state when not to use it or mention alternatives, but the sibling tools are all read-only or analysis-focused, making this the sole write operation. A slight nudge toward exclusivity would push this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: read-only when given url (one HTTP GET), zero network when given schema_json, deterministic and rule-based (no LLM), and conflict resolution (schema_json wins). This adds value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loads the main purpose. It uses bullet-like sentences for behavioral points. It is not overly long, but could be slightly more concise (e.g., 'Deterministic, rule-based; no LLM.' is efficient). Overall earns its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema (3 params, 100% coverage), annotations (readOnly, idempotent, destructive), and existence of an output schema, the description covers all essential aspects: purpose, usage context, behavioral traits, parameter constraints. It provides sufficient context for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add much beyond schema parameter descriptions, but it clarifies the either-or constraint and the fact that schema_json wins over url. These additions are minor, so score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates JSON-LD structured data against Schema.org rules and AI-citation best practices. It distinguishes from sibling 'audit_page' by noting that this tool is for focused JSON-LD audits versus full page audits. The verb 'validate' and resource 'JSON-LD schema' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'focused JSON-LD audits, or to validate a schema block you're about to ship.' Also specifies when not to use: 'For a full page audit that includes schema + everything else, use audit_page instead.' Additionally, clarifies that either url or schema_json must be provided, not both, with a win condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral details: read-only, HTTP GETs, deterministic, no LLM, no write/upload. This is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful: purpose, behavior details, usage context. No wasted words, well-structured, and front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and clear annotations, description is complete. Covers what, how, when, and fallback. Output schema exists but not shown; description clarifies return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds meaning by explaining automatic detection of pricing page, return type (string), and fallback template. Provides significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a machine-readable /pricing.md file for AI shopping/agent flows. It specifies the verb 'generate', resource 'pricing.md', and distinguishes from sibling audit/score tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: SaaS/e-commerce sites needing agent-readable pricing. Mentions fallback behavior when no prices are detectable. Could improve by naming alternative tools, but overall clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it specifies read-only behavior ('one HTTP GET' for url, 'zero network' for text), confirms no writes, and emphasizes determinism and reproducibility. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the complexity of the tool. It is well-structured with an initial summary, then details on evaluation factors, behavioral notes, usage guidelines, and sibling distinction. Every sentence provides useful information, though it could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, behavior, and parameter semantics adequately. It does not address edge cases (e.g., handling of both url and text simultaneously, or fetch failures), but the presence of an output schema and annotations means not all details must be in the description. It provides sufficient context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds value by explaining the mutual exclusivity of url and text, and by specifying that target_query influences scoring (answer-shape fit, query-term coverage) when provided. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores citation worthiness for AI engines, lists specific evaluation factors (BLUF, FAQ, etc.), and explicitly distinguishes itself from the sibling tool score_ai_overview_eligibility by contrasting what each tool measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'pre-publish content QA' and 'triage which existing pages are worth optimizing for AI citation first.' It also notes that either url or text must be provided. However, it does not explicitly state when NOT to use the tool or provide direct alternatives beyond the one sibling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds valuable nuance: network behavior differs between 'url' (one HTTP GET) and 'text' (zero network), two execution paths (sampling vs regex fallback) are explained, and the output includes a 'mode' field to indicate which path ran. Dependencies for headless rendering are also noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and is well-structured into logical sections (overview, paths, when to use). It is longer than ideal but every sentence adds distinct value. Minor redundancy: 'Extract named entities, linked concepts, and sameAs graph nodes' is slightly verbose but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are documented elsewhere) and 4 well-described parameters, the description covers all essential aspects: input conditions, execution modes, dependencies, and use cases. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema: it clarifies the mutual exclusivity of 'url' and 'text' (schema does not mark them required but description explains they are conditionally required), explains the render modes and their implications, and notes that 'respect_robots' is ignored when 'text' is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Extract') and resource ('named entities, linked concepts, and sameAs graph nodes'), immediately clarifying the tool's core function. It differentiates from sibling 'audit_schema' by stating that tool is for validating JSON-LD itself, not extracting entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: building an entity map... or auditing whether a page's entities match its target topic.' It also provides an alternative ('To validate the JSON-LD itself, use audit_schema') and clarifies that either 'url' or 'text' must be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds significant context: 'read-only', 'HTTP GETs', 'no writes, no auth required, no rate limits', 'deduplicated', 'deterministic, rule-based scoring; no LLM calls', and 'same domain returns same grade'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but well-structured, with key information front-loaded (purpose, behavior, output). Every sentence adds value, though it could be slightly trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sub-audits, deterministic scoring, output structure), the description covers input, behavior, output components, and use cases thoroughly. It mentions the output fields (domain, homepage_url, etc.) and sub-audit results, making it complete even without the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description for the 'domain' parameter includes examples, explains the sub-audits run in parallel, and notes that it issues several HTTP GETs. The 'respect_robots' parameter is also well described. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'Single-call site sweep' that runs multiple audits in parallel and returns an overall grade and top-5 fixes. It differentiates itself from siblings like audit_sitemap (samples pages from sitemap) and audit_page (single-URL deep dive) with specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'When to use' section: 'quick how does this site look overall?' and distinguishes from alternative tools (audit_sitemap, audit_page). It also states it is read-only and issues HTTP GETs, but could more explicitly mention when not to use it (e.g., when deep multi-page analysis is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description adds 'One HTTP GET to /robots.txt. No auth, no rate limits applied. Deterministic, rule-based; no LLM.' No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three paragraphs, each focused. First paragraph defines action and scope, second adds behavioral details, third provides usage guidance. No fluff, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, annotations, output schema (not shown but indicated), and sibling context, description covers all needed: behavior, use cases, limitations, and contrast.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value by listing example domains and known crawlers, and clarifying the fetch URL. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Fetch and parse a domain's robots.txt; report per-crawler allow/disallow posture.' Distinct from siblings like check_sitemap and audit_page, as explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('figuring out which AI crawlers a site blocks vs allows'), suggests combining with check_sitemap, and distinguishes from audit_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: describes parallel execution, deterministic rule-based logic, no LLM calls, 2 URL cap, heuristic verdict. Consistent with readOnlyHint and idempotentHint. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized into sections (purpose, behavior, deterministic, when to use, limitations). Slightly verbose but all sentences add value. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are covered. Description explains process, limitations, and use cases comprehensively. Annotations provide additional safety context. Complete for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds useful details: query is optional, url_a/b must be fully-qualified and return 200, respect_robots default and when to override. Adds meaningful value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two URLs for AI citation-worthiness, returning a structured breakdown. It distinguishes from siblings like audit_page (single-URL audit) and score_citation_worthiness (overall scoring), providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for competitive gap analysis and tells when not to use: for single-URL audits use audit_page, for overall scoring use score_citation_worthiness. Also gives typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature (one HTTP GET for url, zero network for text), the fallback to heuristic if sampling is unsupported, and the mode indicator in results. Adds significant value beyond annotations by explaining the dual execution paths.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded main purpose. Every sentence adds value, covering fallback, usage, and parameters. Could be slightly shorter, but not wasteful. Good balance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the simulation logic, fallback mechanism, engine simulation, and output contents (verdict, excerpt, improvements, mode). With an existing output schema, this is fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining engine-specific tuning (e.g., perplexity favors statistic-dense excerpts), the mutual exclusivity of url and text, and the effect of respect_robots. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates whether an AI engine would cite a page, returning a cite/no-cite verdict with an excerpt and improvements. It distinguishes from sibling tools like score_citation_worthiness and audit_page by specifying the binary verdict tied to a single query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: pre-publish gut-check for a specific query or auditing citation surface. Also implies when not to use by contrasting with deterministic scoring and whole-page rubric. Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: read-only, one HTTP GET, only HEAD section, deterministic and rule-based. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose. Three short paragraphs, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not explain return values. It covers scope, behavior, and usage conditions sufficiently. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds extra context for the url parameter (must be fully-qualified, follows redirects, only inspects <head>), which adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool audits canonical link integrity including presence, self-reference, cross-domain mismatches, trailing-slash hygiene, and og:url consistency. It distinguishes itself from sibling tools like audit_page and check_technical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (focused canonical-only audit) and when not to (use check_technical for full HEAD audit, audit_page for everything-on-a-page). Provides concrete alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no auth, no rate limits, deterministic rule-based scoring, and headless mode dependencies. These details go beyond annotations (readOnlyHint, idempotentHint, etc.) and add significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and front-loaded information. Slightly verbose but every sentence earns its place. Minor improvement could be achieved by condensing some parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, parameters, usage guidelines, dependencies, and edge cases (robots blocking). Output schema exists, so return values need not be explained. Complete for a complex tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds rich context: explains render modes with performance trade-offs, when to set respect_robots false, and the purpose of generate_report and include_raw_html. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full AI-SEO audit of a single URL' and lists outputs. It distinguishes from sibling tools by naming them explicitly and positioning this tool as the composite entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: the default entry point for audit any page' and advises against using individual sub-audit tools unless needed. Provides clear context for when to use headless rendering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), it details read-only nature, HTTP calls, polite throttling, deterministic sampling, and rule-based scoring. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded. Each sentence adds value without redundancy. Summary paragraph, then behavioral details, determinism, and usage guidance in a logical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of what, how, when, behavioral traits, determinism, safety, and alternatives. Satisfies all needs given complexity and existing annotations/schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. Description adds further context for each, e.g., explaining domain discovery, concurrency throttling, deterministic sampling behavior, and respect_robots purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: discovers sitemap, samples URLs by uniform stride, runs audit_page on each, and returns findings. It uses specific verbs and resources, and distinguishes itself from siblings like audit_site and check_sitemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (portfolio-level health check) and contrasts with audit_site (homepage-only) and check_sitemap (structure validation), providing clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds concrete behavioral details: 'Read-only. Issues N+1 HTTP GETs: one for robots.txt + sitemap, then up to max_urls_to_check HEADs against sampled URLs. Deterministic, rule-based; no LLM.' This goes beyond annotations and provides transparency about network requests and determinism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three short paragraphs) and well-structured: purpose first, then behavioral traits, then usage guidelines. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sitemap checks), full parameters, annotations, and the presence of an output schema, the description is complete. It covers what the tool does, how it works, and when to use it, with no missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The description adds extra context: domain parameter notes tool tries /sitemap.xml and follows robots.txt and sitemap indexes; max_urls_to_check explains it caps HTTP HEADs. This adds meaning beyond the schema, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a domain's XML sitemap, listing specific checks (presence, accessibility, URL count, lastmod freshness, sitemap-index handling, image/video extensions). It uses a specific verb ('Validate') and resource ('domain's XML sitemap'), and distinguishes from siblings like audit_sitemap and check_robots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'site-wide indexing audits.' It also provides pairings ('Pair with check_robots for a full pre-crawl picture') and alternatives for per-page checks ('use audit_page or check_technical instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: read-only (one HTTP GET), only inspects HEAD, deterministic/rule-based, no LLM. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences: purpose, behavioral traits, deterministic nature, usage guidelines. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of an output schema, the description provides all necessary context for correct agent selection and invocation, including what is checked and when to use alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by elaborating on the URL parameter's scope (all the signals inspected) and providing context for the `respect_robots` parameter's usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Audit') and resource ('a page's HEAD section for technical signals'), listing the exact signals checked. It distinguishes from siblings by noting what it does not cover, such as schema or full page audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'When to use' section that specifies the appropriate context (HEAD-tag audit) and names alternative tools (audit_page, audit_canonical) for related but different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: 'Read-only', 'Issues one HTTP GET for the sitemap then one per sampled page', 'Deterministic; no LLM', 'does NOT write to disk or upload anywhere'. No contradiction with annotations (readOnlyHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured, and front-loaded with the main action. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity and presence of output schema, the description fully explains the tool's operation, output format, and caller responsibilities. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaningful context beyond the schema, e.g., explaining the number of HTTP GETs per page and recommending low max_pages for large sites.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a spec-compliant llms.txt for a domain by reading its sitemap, sampling pages, and synthesizing a summary. It distinguishes itself from the sibling tool llms_txt_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('bootstrapping llms.txt for a site you own') and when not ('to check an existing llms.txt, use llms_txt_validate instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral traits: 'Read-only. One HTTP GET when given url; zero network when given content. Optional link-check issues HEAD requests against each link if check_links is true. Deterministic; no LLM.' This goes beyond the annotations which already declare readOnlyHint and idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each conveying essential information. No redundant phrases. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but context indicates), the description does not need to detail return values. It covers usage, network behavior, constraints, and alternatives comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the mutual exclusivity of url and content, and the behavior of check_links (default true).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Validate an existing llms.txt or llms-full.txt against the spec: structure, section ordering, link format, and (optionally) broken-link detection.' It clearly distinguishes from the sibling tool llms_txt_generate, which is for generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use: auditing an llms.txt you already have. To generate one from scratch, use llms_txt_generate.' Also clarifies the requirement that 'Either url or content must be provided.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint true, openWorldHint true) are consistent. Description adds critical behavioral details: does not write back to source URL, returns string, delegates rewrite to the calling LLM via MCP sampling (no external API call), and output may vary across runs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence captures core purpose, then expands on behavior, usage guidelines, alternative tool, and parameter hints. Every sentence adds value with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 1 required, output schema exists) and richness of annotations, the description covers all necessary aspects: purpose, usage, behavioral transparency, parameter semantics, and alternatives. The existence of an output schema makes return value explanation unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the role of `target_query` in driving entity selection and comparison framing, clarifying the `add_comparison_table` parameter for X-vs-Y queries, and noting mutual exclusivity of `url` and `text`. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool rewrites a content block for Generative Engine Optimization with specific characteristics (entity-rich, comparison-ready, synthesis-friendly). Explicitly distinguishes from sibling tool `rewrite_aeo` by describing different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (optimizing for synthesis-style answers across multiple sources) and when not to (use `rewrite_aeo` for direct-answer optimization). Also clarifies read-only behavior and delegation to LLM via sampling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and no destruction. The description adds significant behavioral context: 'Read-only. One HTTP GET for the page plus one for /llms.txt... Deterministic, rule-based heuristics... no LLM and no headless render required.' It also clarifies limitations (approximates Lighthouse, does not execute it). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear purpose statement, then provides detailed behavior, parameter guidance, and usage context. Every sentence adds value with no redundancy. The final paragraph succinctly covers when to use and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema exists), the description covers all necessary aspects: purpose, behavioral details, parameter semantics, usage guidelines, and sibling differentiation. The existence of an output schema means return values need not be detailed. The description is fully satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining parameter interactions, e.g., 'Pass html instead of url to score markup offline (llms.txt is then treated as absent)' and 'Set false to skip that extra HTTP GET' for check_llms_txt. This contextual guidance elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Score a page against the four signals Google added to the Lighthouse Agentic Browsing category.' It specifies the verb (score), resource (page), and the specific signals. It distinguishes from siblings by directly naming alternatives like score_citation_worthiness and audit_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'When to use: checking whether a site is ready for AI agents / agentic browsers, or tracking the new Lighthouse Agentic Browsing category.' It also lists alternative tools for different tasks, clearly defining when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds key traits: 'Read-only. One HTTP GET.', 'Deterministic, rule-based scoring... No LLM calls.', 'Same URL returns the same score on repeated runs.' No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose first, then output details, then behavioral traits, then usage guidance. Every sentence adds unique value with no redundancy. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with full schema coverage, an output schema (mentioned), and annotations covering safety, the description is complete. It explains what the tool does, what it returns (overall score + six subscores), and how to choose it over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The main description adds value by explaining the URL parameter's behavior ('fetches the URL once and runs deterministic...') and providing usage guidance for respect_robots ('Set false only for auditing your own site where you've intentionally blocked crawlers.').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Score') and resource ('page's probability of appearing in Google AI Overviews'). It distinguishes from siblings by naming audit_page and score_citation_worthiness as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('AI-Overview-specific prioritization') and when not, with named alternatives: 'use audit_page' for multi-dimensional audit, 'use score_citation_worthiness' for passage citation-worthiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains behavior beyond annotations: read-only when given url (one HTTP GET), zero network when given text, no side effects, delegates to LLM via sampling (no external API), and acknowledges non-idempotence due to model variability. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (8 sentences), well-structured, and front-loaded. Each sentence adds value: purpose, behavior, delegation mechanism, usage guidance, and input requirements. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, delegation to LLM, output schema exists), the description covers all essential aspects: purpose, behavior, parameter requirements, usage alternatives. The presence of an output schema obviates the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description adds value by clarifying the mutual exclusivity of `url`/`text` (not enforced in schema), listing `format` enum examples, and explaining `target_query` drives heading shape and BLUF wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool rewrites content for Answer Engine Optimization, listing specific transformations (BLUF, FAQ, schema, headings) and target AI overviews. It distinguishes from sibling `rewrite_geo` by stating use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (direct-answer surfaces) and contrasts with `rewrite_geo`. It also specifies that either `url` or `text` must be provided, and `target_query` is required, providing clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-seo-mcp MCP server](https://glama.ai/mcp/servers/AutomateLab-tech/ai-seo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AutomateLab-tech/ai-seo-mcp)

Score Badge

Copy to your README.md:

[![ai-seo-mcp MCP server](https://glama.ai/mcp/servers/AutomateLab-tech/ai-seo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AutomateLab-tech/ai-seo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AutomateLab-tech/ai-seo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server