Remote SEO/GEO MCP: Search Console, keyword research, backlinks, competitor & on-page audits.
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.8/5 across 7 of 7 tools scored. Lowest: 2.8/5.
Tools are mostly distinct: analyze_url_structure and classify_keywords_simple perform concrete analyses, while get_google_guidelines, seo_guidance, seo_checklist, get_skill, and list_locations serve different informational purposes. However, seo_guidance, seo_checklist, and get_google_guidelines could be somewhat confused as all provide SEO advice in different forms.
Naming mixes verb_noun patterns (analyze_url_structure, get_google_guidelines, list_locations) with noun-only names (seo_checklist, seo_guidance). The 'seo_' prefix is used inconsistently, and 'classify_keywords_simple' includes an extraneous modifier. While readable, the pattern is not uniform.
Seven tools is a well-scoped number for a server focused on SEO guidance and analysis. Each tool covers a distinct aspect, and this count is neither too sparse nor overwhelming.
The server provides solid coverage of SEO guidance and reference material but lacks broader analysis tools (e.g., on-page content analysis, backlink checks, ranking queries). The presence of list_locations hints at integration with other data tools that are not included, leaving noticeable gaps in a fully functional SEO toolkit.
analyze_url_structureBInspectAnalyze a URL for SEO-friendliness. Checks length, structure, and common issues. Free - no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. Only mentions 'Free - no API key required', but omits read-only status, rate limits, side effects, or other important behaviors. 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?
Three sentences, each with clear purpose. The most important information (purpose and free nature) is front-loaded. Slightly verbose with three separate sentences, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers core purpose and a key fact. However, it omits what 'common issues' means, the output format, and any limitations, leaving some ambiguity.
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%, but the description does not add meaningful context beyond the schema's 'URL to analyze'. No clarification on URL format, acceptable schemes, or examples, so it adds minimal value.
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?
Clearly states the verb 'analyze' and resource 'URL', and elaborates on what it checks (length, structure, common issues). Distinguishes from siblings like seo_checklist and seo_guidance, which are broader or different.
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?
Mentions 'Free - no API key required' as a usage note, but does not specify when to use this tool over alternatives like seo_checklist or seo_guidance. 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.
classify_keywords_simpleAInspectClassify keywords locally by intent, funnel stage, brand type, and topic. Free and available without an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Keywords to classify | |
| brand_name | No | ||
| competitors | No | ||
| brand_variations | No | ||
| product_keywords | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that processing happens locally (no external API calls) and requires no authentication ('without an API key'), which are useful behavioral traits. It does not detail the return format or potential limitations, but for a simple classification tool, the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at two sentences, immediately stating the tool's purpose and key traits. Every word adds value—'locally' and 'free without API key' are substantive, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (4 optional), no output schema, and no annotations, the two-sentence description is insufficiently complete. It does not explain how to use the optional parameters or what the classification output looks like, leaving a significant gap for an agent attempting to invoke the tool effectively.
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 only 20% (only 'keywords' is described), yet the description does not compensate by explaining the optional parameters such as 'brand_name', 'competitors', 'brand_variations', or 'product_keywords'. The high-level list of classification dimensions (intent, funnel stage, brand type, topic) gives some context but does not clarify how these parameters influence classification, leaving them under-specified.
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: 'Classify keywords locally by intent, funnel stage, brand type, and topic.' This uses a specific verb (classify), identifies the resource (keywords), and lists the classification dimensions, effectively distinguishing it from sibling tools that focus on URL structure, guidelines, and SEO guidance.
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 by noting it operates 'locally' and is 'Free and available without an API key,' implying it is a self-contained, no-cost option. While it does not explicitly name alternatives or state when not to use it, this contextual guidance is sufficient for an agent to infer its suitability for offline, keyless keyword classification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_google_guidelinesCInspectGet official Google Search developer guidelines by category. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose what the tool returns, how the 'category' parameter affects behavior, or what happens if no category is provided. The default 'list' behavior is not mentioned, leaving the agent guessing.
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 brief and front-loaded, but the second sentence 'Free.' is unnecessary and does not contribute to tool selection. Despite that, it is not verbose and gets the core message across quickly.
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 is simple with one optional parameter, the description is still incomplete because it fails to explain the default category behavior and valid inputs. The lack of output schema and insufficient parameter semantics make it hard for an agent to use correctly without further assumptions.
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 has one parameter 'category' with 0% description coverage, and the tool description adds no meaningful semantics. It only repeats 'by category' without explaining valid values, the default 'list', or expected return format. This is a significant gap for an agent to correctly invoke the tool.
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: retrieving official Google Search developer guidelines. It specifies the verb 'Get', the resource 'official Google Search developer guidelines', and the scope 'by category', which distinguishes it from sibling tools like seo_guidance or seo_checklist.
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 no guidance on when to use this tool versus the sibling tools. It only says 'Free', which is a feature, not usage context. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillAInspectGet an SEO workflow skill with step-by-step methodology, triggers, credits, and quality gates from the current seo_skills catalog. Use name='list' for all available skills. Free - no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name (e.g. 'seo-audit') or 'list' for all available skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the tool is free and requires no API key, which adds useful behavioral info. However, it does not mention idempotency, rate limits, or any side effects, leaving some gaps.
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, no unnecessary words, front-loaded with the primary action. Every sentence serves a purpose.
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 retrieval tool with one parameter and no output schema, the description covers the key aspects: what it returns (methodology, triggers, credits, quality gates), how to list all, and its free nature. It could mention return format but not essential.
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% for the single 'name' parameter. The description adds value by explaining how to use 'list' to retrieve all skills, enhancing the schema's basic description.
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 retrieves an SEO workflow skill from a specific catalog, using the verb 'Get' and naming the resource 'seo_skills catalog'. It distinguishes itself from siblings (e.g., analyze_url_structure) by focusing on skills retrieval.
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?
Explicit guidance is provided: use 'list' for all available skills. While it doesn't list when not to use it or alternatives, the context implies a straightforward retrieval tool, and the instruction is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_locationsAInspectList available countries/locations for SEO data queries. Free - no API key required.
| 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 full burden. It discloses the authentication requirement (no API key) but omits other behavioral traits like rate limits, data freshness, or output format. It is adequate but not comprehensive.
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 succinct sentences that are front-loaded with purpose and usage condition. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should ideally describe the return format or any limitations. It does not, so completeness is minimal but acceptable for a zero-parameter 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?
There are zero parameters, so the input schema is trivially covered. The description adds no parameter information since none exist; baseline 4 is appropriate per guidelines.
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 action ('List') and the resource ('available countries/locations') and distinguishes it from sibling tools like 'analyze_url_structure' and 'get_auth_status', none of which list locations.
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 explicitly states 'Free - no API key required', which is a key usage condition. It does not provide explicit when-not-to-use or alternatives, but for a simple list tool with no parameters, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seo_checklistAInspectGet an SEO checklist. Types: general, blog, ecommerce, discover, backlink, all. Available in English and German. Free - no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language (en or de) | en |
| checklist_type | No | Checklist type | general |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior (free, no API key), but does not disclose whether the operation is read-only or if any side effects occur. It adds some value but not comprehensive 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 with two sentences, no fluff, and front-loads the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers input options and access, but does not describe the output format or content of the checklist, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have enums with descriptions. The description merely restates the available options without adding new meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get an SEO checklist' with specific verb and resource. It lists available types, but does not differentiate from sibling tool 'seo_guidance', which may overlap. Hence not 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 mentions it is free and requires no API key, providing clear usage context. However, it does not give explicit when-not or alternative recommendations, stopping 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.
seo_guidanceAInspectGet SEO best practices on a topic. Topics: title_tags, meta_descriptions, heading_structure, internal_linking, core_web_vitals, eeat, keyword_research, schema_markup, image_optimization, local_seo. Use topic='list' for all. Free - no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | SEO topic or 'list' for all topics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses non-destructive nature and no authentication needed, but doesn't detail return format or result behavior. Adequate for an informational read-only 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?
Two clear sentences, front-loaded with verb and topic list. 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?
Given the tool's simplicity (one required param, no output schema), the description is complete: lists topics, explains usage, notes free and no API key.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter. Description adds value by enumerating valid topic values and emphasizing 'list' to get all topics, which goes beyond the schema's generic description.
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 clearly states it provides SEO best practices on a topic, lists 10 specific topics, and explains the special 'list' value. Differentiates from siblings like analyze_url_structure and seo_checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: get SEO best practices on a topic, use 'list' for all, free and no API key. Lacks explicit when-not-to-use or alternatives, but context is sufficient for simple tool.
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!
