SEO automation MCP with 39 tools. 12 free tools (no auth): audit pages, check Core Web Vitals, validate schema, score AI visibility, generate keywords. 27 pro tools with account: manage content calendar, track GSC traffic, monitor AI bot visits (ChatGPT/Perplexity), analyze backlinks, and publish directly to WordPress, Webflow, or Wix.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.9/5.
Most tools have distinct targets, but seo_audit, seo_plan, and seo_score overlap in purpose—all evaluate SEO health with varying depth, which could confuse an agent. noindex_checker and ai_visibility_score also both touch indexing/crawling, though from different angles.
Tool names are predominantly descriptive noun phrases in snake_case (broken_link_check, keyword_generator, seo_audit), but 'discover' is a lone verb and there's a mix of suffixes (_check, _analyzer, _validator, _score). Still, the pattern is readable and mostly consistent.
With 12 tools, the server covers a broad SEO toolkit without overwhelming. Each tool adds a distinct diagnostic capability, and the count fits well within the ideal 3-15 range.
The suite covers crawling, indexing, content, schema, performance, and overall audits—solid diagnostic coverage. Minor gaps like sitemap validation or backlink analysis exist, but the core SEO workflows are well supported.
ai_visibility_scoreAI Visibility ScoreAInspect[FREE] How well can AI bots crawl your site? Checks robots.txt AI rules, llms.txt, structured data. FR: Score de visibilité IA — votre site est-il accessible aux bots IA ?
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'Checks' but does not explicitly state that it is a read-only operation, nor does it mention any limitations, rate limits, or what happens if the URL is invalid. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose, and includes a helpful French translation. Every word earns its place, with no unnecessary 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 the tool's simplicity (one parameter, no output schema), the description sufficiently communicates what it checks. However, it does not mention what the tool returns or how the 'score' is presented, which would be useful for a complete understanding, but it is not a major 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 single parameter 'url' has 100% schema description coverage ('The URL to check'). The description adds no additional semantic context beyond what the schema already provides, 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 clearly states the tool's purpose with a specific verb and resource: 'Checks robots.txt AI rules, llms.txt, structured data.' It distinguishes itself from sibling tools by focusing specifically on AI crawlability, which is unique among the listed SEO 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 provides a clear context for when to use the tool ('How well can AI bots crawl your site?') and mentions the included checks. However, it does not explicitly list when not to use it or name alternative sibling tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
broken_link_checkBroken Link CheckAInspect[FREE] Find broken links (404, 500, timeout) on any page. FR: Trouvez les liens cassés sur n'importe quelle page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check for broken links |
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 indicates a read-only operation ('find') and specifies some detail about what qualifies as a broken link (404, 500, timeout). However, it does not mention potential behaviors like redirect handling, rate limits, or output format, which would add 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 extremely concise: one English sentence and a French translation. It front-loads the key information (free, purpose, error types, scope) with no wasted words. The French repetition adds minimal value for an agent but does not harm conciseness.
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 a single parameter, no output schema, and no annotations, the description provides sufficient context: it explains what the tool does, what inputs it accepts, and what constitutes a broken link. It does not specify the output format, but given the simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'url' parameter is described as 'The URL to check for broken links'). The description adds no additional parameter-level detail beyond what the schema already provides, 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 states a specific verb ('Find'), a specific resource ('broken links'), and the scope ('on any page'). It also lists concrete error types (404, 500, timeout), which clearly distinguishes it from sibling tools like noindex_checker or page_speed_check.
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 (to check a page for broken links) but provides no explicit guidance on when to use it over alternatives. No exclusions or conditions are mentioned, and sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discoverDiscoverAInspect[FREE] See all available free SEO tools and recommended workflows. Call this first. FR: Découvrez les outils SEO gratuits et les workflows recommandés.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that the tool is a read-only discovery action, showing available tools and workflows. However, it does not explicitly disclose any limitations, side effects, or the exact nature of the output, though the simplicity of the tool mitigates the risk.
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, clear sentence with a redundant French translation. It is front-loaded with the purpose and usage instruction, but the translation adds length without new information, preventing a perfect score.
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 zero-parameter, low-complexity tool with no output schema, the description fully covers what the tool does and when to call it. The lack of output schema is compensated by the description's explicit reference to what users will see (available tools and workflows).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds no parameter-specific information because none exist, which 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 function: 'See all available free SEO tools and recommended workflows.' It also specifies the action ('See'/'Discover') and the resource, distinguishing it from sibling tools which are individual SEO analyzers. The instruction 'Call this first' further clarifies its role as an entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Call this first,' indicating when to invoke this tool (before other sibling tools). It does not explicitly state when not to use it or name alternatives, but for a discovery tool, this context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
keyword_generatorKeyword GeneratorAInspect[FREE] Generate keyword suggestions for any topic. Returns related terms with estimated intent. FR: Générer des suggestions de mots-clés pour un sujet.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The topic or seed keyword | |
| language | No | Target language | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the return type ('related terms with estimated intent') and implies a non-mutating operation, but lacks detail on data sources, rate limits, or the meaning of 'estimated intent.' The '[FREE]' tag hints at cost but is not substantive.
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 short and front-loaded with the core purpose. The French translation is somewhat redundant in an English-language description, but it is not distracting and the overall content remains efficient. The '[FREE]' label is minor but not a major issue.
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 the simple tool with only two well-documented parameters and no output schema, the description provides sufficient context: it explains the purpose and the type of output. It does not elaborate on the format of the returned terms, but this is acceptable for a lightweight suggestion 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 input schema already documents both parameters fully: 'topic' described as 'The topic or seed keyword' and 'language' as 'Target language' with an enum. The description adds no extra parameter semantics beyond the schema, so a 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 clearly states the tool 'Generate keyword suggestions for any topic' with a specific verb and resource. It also describes the output ('Returns related terms with estimated intent'), and this tool is distinct from all sibling tools, which focus on SEO audits and site checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for any topic' provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, but given the sibling list, the use case is unambiguous and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_tag_analyzerMeta Tag AnalyzerBInspect[FREE] Analyze title, meta description, Open Graph, and Twitter Card tags for any URL. FR: Analyse des balises meta, OG et Twitter Card.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it does not mention that the tool fetches a live URL, may require network access, or can fail on inaccessible pages. It also does not describe what the output looks like beyond the listed tag types, leaving the 'Analyze' behavior opaque.
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 extremely concise, with two short sentences offering the core information and a bilingual alternative. The [FREE] tag is upfront, and there is no filler or repetition beyond the intentional French translation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the primary purpose but lacks any detail about return values, error handling, or limitations (e.g., does not analyze JavaScript-rendered tags). Since there is no output schema, some of this burden falls on the description, making it adequate but incomplete.
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 provides 100% coverage for the single 'url' parameter with 'The URL to analyze'. The description adds the phrase 'any URL', implying broad scope, but it does not add syntax or format details beyond what the schema provides. Baseline 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 function with a specific verb ('Analyze') and a specific resource ('title, meta description, Open Graph, and Twitter Card tags for any URL'). This precise enumeration distinguishes it from sibling tools like schema_validator or seo_audit, which cover other or broader aspects.
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 explicit guidance on when to use this tool versus alternatives like seo_audit or schema_validator. The phrase 'for any URL' implies a general use case, but it does not state exclusions, prerequisites, or mention when a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noindex_checkerNoindex CheckerAInspect[FREE] Check if a URL is indexable — detects noindex tags, canonical issues, robots.txt blocks. FR: Vérifiez si une URL est indexable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the types of checks performed (noindex, canonical, robots.txt), but does not describe the return format, whether the URL is fetched live, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core function. The French translation and '[FREE]' marker add concise relevant context without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description states the core purpose and detection scope. However, without an output schema or annotation, it omits what the agent should expect in the response, and there is no alternative guidance.
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 sole 'url' parameter with a clear description. The tool description does not add additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks URL indexability and names three specific issue types (noindex tags, canonical issues, robots.txt blocks). This distinguishes it from sibling tools like meta_tag_analyzer or ai_visibility_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or context for selecting this over other SEO tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
page_speed_checkPage Speed CheckAInspect[FREE] Performance check with real Core Web Vitals (CrUX field data) + Lighthouse score + page weight analysis. FR: Vérification de performance avec vrais Core Web Vitals (données terrain CrUX) + score Lighthouse + analyse du poids de page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data sources (CrUX field data, Lighthouse, page weight) and notes it's free, but doesn't state whether it's a read-only operation or any other behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with English and French versions, front-loaded with [FREE]. It is compact, though the French repetition adds length without new information for English readers.
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 tool without output schema, the description adequately conveys the tool's scope. It doesn't document return format or potential limitations, but the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'url' with schema description 'The URL to check' covering 100%. The description adds no additional parameter details beyond that, so it meets the baseline but does not enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Performance check with real Core Web Vitals (CrUX field data) + Lighthouse score + page weight analysis' – a specific verb and resource, clearly differentiated from sibling SEO tools that focus on audits, keywords, or schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use vs alternatives. The description implies usage for performance checks, but does not mention when not to use it or which sibling tool to use instead for broader SEO audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
readability_checkReadability CheckCInspect[FREE] Readability score and content quality analysis. FR: Score de lisibilité et analyse de la qualité du contenu.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions the free nature and the general output, but does not explain what 'content quality analysis' entails, whether the URL is fetched, or any limitations (e.g., paywall, non-HTML). It does indicate a read-only analysis, but lacks depth.
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 very short and to the point, with the French translation providing bilingual access. No filler is present, though the French phrase adds minimal informational 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 the tool has only a single parameter and no output schema, the description should clarify what results to expect. It mentions readability score and content quality but not the format or criteria, leaving ambiguity about the output.
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 fully documents the 'url' parameter, so the description does not need to add much. The description reinforces that the URL is the target of readability analysis, but adds no additional syntax or format details 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 clearly states the tool provides a readability score and content quality analysis for a URL, making its core function apparent. However, it lacks an explicit verb like 'computes' or 'analyzes', and does not differentiate from sibling analysis tools beyond the name.
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 use this tool versus alternatives such as page_speed_check or seo_score. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schema_validatorSchema ValidatorBInspect[FREE] Validate JSON-LD structured data and detect missing schema types. FR: Validez vos données structurées JSON-LD.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a read-only validation action and detection of missing schema types, but does not describe the return format, error handling, or limitations. For a tool without annotations, this leaves the agent uncertain about the tool's output, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core function in the first segment. The bilingual text adds a minor redundancy for English-only use, but the '[FREE]' tag provides useful context without waste. Overall, it is efficient, though the French translation could be considered extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and no output schema, the description covers the essential purpose but lacks details about what the tool returns. It is minimally viable for an agent to understand the tool's function, but the absence of output behavior leaves a gap. Given the simplicity of the tool, a brief note on response format would make it 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 fully describes the only parameter 'url' with 100% coverage. The description adds no additional semantics beyond the schema, which is acceptable because the schema already provides all necessary details. With full schema coverage, a 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 validates JSON-LD structured data and detects missing schema types, using a specific verb and resource. It distinguishes from sibling tools which focus on SEO metrics and analysis, as none cover structured data validation. However, it does not explicitly name an alternative, so it lacks the full sibling differentiation of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for validating JSON-LD, but gives no explicit guidance on when to use it versus alternatives. It does not mention prerequisites, intended use cases, or tools not to use. The context is clear but not prescriptive, matching the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seo_auditSEO AuditAInspect[FREE] Full 8-category SEO audit for any URL. Returns score, issues, strengths. No account needed. FR: Audit SEO complet en 8 catégories pour n'importe quelle URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to audit (e.g. https://example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries transparency burden. It discloses that it's free and requires no account, and outlines return content. However, it doesn't mention potential limitations, rate limits, or whether it modifies anything, though an audit is likely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with key features (FREE, 8 categories, outputs), and includes a French translation for accessibility. No wasted words.
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 tool with no output schema, the description adequately conveys what it does and what it returns. It could mention time/error behavior but is otherwise 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 schema covers the url parameter fully with an example. The description adds 'any URL' and '8 categories' but doesn't provide additional parameter-specific 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 clearly states a full 8-category SEO audit for any URL, with explicit outputs (score, issues, strengths). It distinguishes itself from the more specific sibling tools (e.g., broken_link_check, seo_score) by emphasizing completeness.
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 for a comprehensive audit but doesn't explicitly contrast with single-purpose sibling tools. No '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.
seo_planSEO PlanBInspect[FREE] Run a full audit and get a prioritized SEO action plan with estimated impact. The 'what do I fix first?' tool. FR: Audit complet + plan d'action SEO priorisé avec impact estimé.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to audit and plan for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears full responsibility. It discloses that the tool performs an audit and returns a plan, but does not explain how the audit is performed, whether it caches results, or what the plan output looks like beyond being prioritized. It also adds '[FREE]' which is unrelated to behavior. The lack of detail on side effects or output structure leaves a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the key purpose stated in the first sentence. The bilingual French translation adds redundancy but is not excessive. It stays under three sentences and each part contributes to understanding the tool's 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?
Despite the absence of output schema and annotations, the description is complete enough for a simple tool with one parameter. It explains the core functionality (full audit, plan, prioritization) and the use case. The lack of output format details is acceptable because the output is conceptually simple and the description clearly signals a plan artifact.
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 covers 100% of the parameter (url) with a clear description ('The URL to audit and plan for'). The tool description adds context about what the URL is used for (audit + plan), but does not introduce new parameter-level semantics beyond the schema. A baseline of 3 is appropriate given full 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 clearly states the tool runs a full audit and produces a prioritized SEO action plan with estimated impact. It uses specific verbs ('run', 'get') and identifies the key differentiator ('what do I fix first?'), distinguishing it from sibling tools like seo_audit or seo_score that may only provide audit/scoring without a prioritized plan. The title is generic but the description fills the gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need a prioritized action plan ('what do I fix first?'). However, it does not explicitly mention when not to use it or list alternative tools. It implies the use case but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seo_scoreSEO ScoreAInspect[FREE] Quick SEO score (0-100) with letter grade for any URL. FR: Score SEO rapide (0-100) pour n'importe quelle URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to score |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explains the output (score 0-100 with letter grade) but gives no details about potential errors, rate limits, required permissions, or the practical meaning of 'any URL' (e.g., public accessibility). This is a significant gap for a network-based tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The English description is a concise single sentence front-loaded with the key value proposition. The French translation is arguably redundant but serves a specific bilingual audience, so it earns its place. Slightly more concise than a 5 because the translation could be seen as extra.
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 (1 param, no output schema). The description explains the primary output (score with letter grade) and scope ('any URL'), which covers the essentials for such a tool. It could provide more context on what constitutes a 'quick' score or how it relates to other SEO tools, but the low complexity warrants a high but not perfect score.
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% with a single 'url' parameter described as 'The URL to score'. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 for full schema coverage 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 performs a quick SEO score (0-100) with a letter grade for any URL. This specific verb+resource combination distinguishes it from siblings like seo_audit (which implies a more comprehensive analysis) and page_speed_check.
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 '[FREE]' and 'Quick' markers provide clear context that this is a lightweight, low-cost check compared to deeper alternatives like seo_audit. However, it doesn't explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
