SEO Intelligence MCP — 13 tools: keyword research, SERP, domain audits, competitors.
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.4/5 across 13 of 13 tools scored.
Several tools focus on rankings: check_ranking, rank_tracker, and serp_alert all deal with keyword positions, which could confuse agents. Meta_generator and title_optimizer also overlap by both generating metadata. However, descriptions clarify distinct purposes (single check vs batch vs historical tracking), so boundaries are mostly clear.
Names are lowercase snake_case and readable, but follow mixed conventions: most are noun_noun (e.g., domain_overview, keyword_research), while check_ranking is verb_noun and backlink_check is noun_verb. The inconsistency in ordering and use of verbs/nouns prevents a higher score.
With 13 tools, the count is well within the ideal 3-15 range for a domain-specific server. Each tool addresses a distinct SEO need (rankings, keywords, on-page, backlinks, competitive analysis), and none feel redundant.
The toolset covers core SEO workflows: keyword research, rank tracking, SERP snapshots, backlink checking, on-page analysis (content, headings, meta, title), and competitor gaps. Minor omissions like link building tools or a comprehensive site audit are acceptable gaps for this scope.
backlink_checkAInspectCheck backlinks and referring domains for a domain (requires Backlinks subscription)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the subscription requirement, which is useful, but does not mention whether the operation is read-only, rate limits, or response format. Partial transparency 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 one concise sentence with no wasted words. It front-loads the action and includes the key prerequisite, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values and behavior. It only states 'backlinks and referring domains' without describing the output structure, pagination, or error cases. It is too minimal for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the domain parameter (100% coverage). The description's 'for a domain' adds no extra meaning beyond the schema's 'Domain to check'. No additional parameter context is provided.
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 backlinks and referring domains for a domain. The verb 'check' and resource 'backlinks and referring domains' are specific and distinct from sibling tools like check_ranking or domain_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when backlink data is needed and mentions a prerequisite (Backlinks subscription), but does not explicitly state when to use versus alternatives or when not to use. It provides context but no clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_rankingBInspectCheck where a domain ranks for a specific keyword in Google top 100
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to check | |
| country | No | Country code | |
| keyword | No | Target keyword |
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 explains the query logic but omits return format, output structure, potential limitations (e.g., top 100 only), or any side effects. It also does not state whether results are live or cached.
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 concise sentence with no redundant phrasing. It gets straight to the point and earns its place.
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 lookup tool, the description covers the core function and scope (top 100), but with no output schema and no usage rules, the agent lacks information about the return value and required parameters (schema indicates none are required at top level, which is odd). It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the parameter descriptions are tautological ('Domain to check', 'Country code', 'Target keyword') and add no practical meaning. The tool description itself does not clarify formats, optionality, or examples, failing to help an agent construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check') with a clear resource ('domain ranks') and scope ('Google top 100'). It clearly distinguishes from siblings like rank_tracker by indicating a one-off check rather than tracking over time.
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 on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or sibling tool comparisons. The intended context is implicit from the name and description only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
competitor_gapAInspectFind keywords your competitor ranks for — identify content gaps and opportunities
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| domain | No | Your domain | |
| country | No | Country code | |
| competitor | No | Competitor domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool finds keywords and identifies gaps, but does not disclose operational details such as whether it compares the competitor's keywords against your domain, what output format to expect, or any rate limits/pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It immediately states the main action and value proposition, making it easy for an agent to parse 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?
With four parameters, no annotations, and no output schema, the description provides only a minimal overview. It does not explain the return structure or the exact relationship between the 'domain' and 'competitor' parameters, leaving some ambiguity. However, the core purpose is clear enough for a relatively simple lookup 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 has 100% description coverage for all four parameters, providing basic meanings (e.g., 'domain' = Your domain, 'competitor' = Competitor domain). The description itself does not add extra parameter semantics, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') with a clear resource ('keywords your competitor ranks for') and states the intended outcome ('identify content gaps and opportunities'). It distinguishes itself from sibling tools like keyword_research by focusing on competitor-based gap analysis.
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 usage for competitive keyword gap analysis, but it does not explicitly state when to use this tool versus alternatives like keyword_research or domain_overview. No exclusions or prerequisites are mentioned, though the schema hints at needing both your domain and a competitor domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
content_scoreAInspectAnalyze URL for on-page SEO quality: score, readability, technical checks, recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to analyze | |
| keyword | No | Target keyword to check optimization |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states that the tool analyzes and returns a score, readability, technical checks, and recommendations, which implies a read-only operation. However, it does not mention potential prerequisites, such as the URL being publicly accessible, or any rate limits or output response format, leaving moderate 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?
The description is a single concise sentence beginning with the action verb 'Analyze', immediately naming the resource (URL) and summarizing deliverable categories. Every word contributes value, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and high-level output components, which is adequate for basic selection. However, it lacks usage criteria relative to siblings, behavioral caveats, and details about the return structure (since no output schema exists). Overall, it provides moderate but not comprehensive context.
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 provides 100% coverage of the two parameters (url and keyword) with descriptions. The tool description adds no additional meaning about how the keyword influences analysis or expected URL format. Since schema coverage is high, the baseline score of 3 applies without enrichment from the 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's function: 'Analyze URL for on-page SEO quality' and lists concrete outputs (score, readability, technical checks, recommendations). This is a specific verb+resource construction that distinguishes it from more targeted sibling tools like heading_analysis or title_optimizer.
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 usage for evaluating on-page SEO performance of a URL, but provides no explicit guidance on when to choose this tool over alternatives such as health_check or competitor_gap. There are no exclusions or comparative statements, leaving the agent to infer appropriate use from the general wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_overviewBInspectDomain SEO overview: organic keywords, traffic estimate, position distribution
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to analyze | |
| country | No | Country code for localized data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates the content of the output (keywords, traffic, positions) but does not state whether this is a read-only analysis, whether it requires authentication, any rate limits, or limitations such as data freshness or accuracy. It is a minimal statement of contents, not deeper 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded line that efficiently conveys the tool's purpose by listing the key data components. It is not bloated, but it does omit any contextual or usage information, making it concise but not comprehensive.
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 absence of an output schema and annotations, the description is under-specified. It lists high-level categories but does not explain the output structure, data granularity, time range, or how it differs from more specific sibling tools. For a tool with two simple parameters, it is still a thin description.
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 descriptions for both parameters (domain and country), covering 100% of the schema. The description adds no additional semantic meaning beyond what the schema states, so it remains at the baseline of 3.
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 identifies the tool as providing a domain-level SEO overview, listing three specific data categories (organic keywords, traffic estimate, position distribution). It distinguishes itself from sibling tools by its broad scope, though it lacks an explicit verb like 'get' or 'retrieve'. It is not a tautology and gives concrete information.
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 offers no guidance on when to use this tool versus sibling tools like keyword_research, rank_tracker, or check_ranking. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer context only from the name and list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heading_analysisAInspectAnalyze H1-H4 heading structure of a page with SEO recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to analyze |
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 only states the core function and that recommendations are included, but does not disclose authentication needs, rate limits, output format, or behavior on invalid URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loads the primary action and resource, and every word contributes to understanding the tool's 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 one-parameter tool, the description is adequate but lacks details on return format or error handling. Since there is no output schema, describing the analysis output would improve completeness.
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 documents the single parameter 'url' with description 'URL to analyze', achieving 100% schema coverage. The tool description adds context about heading analysis but does not fundamentally change the parameter's meaning, so the baseline 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 uses a specific verb ('Analyze') and resource ('H1-H4 heading structure') and clearly distinguishes this tool from siblings like rank_tracker or content_score by focusing on heading structure and SEO recommendations.
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 usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkBInspectServer health, version, tool status, and API connectivity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, whether it makes external network calls, what it returns, or if any authentication is required. The phrase 'API connectivity' hints at network activity but doesn't clarify side effects or response format, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase listing four relevant aspects. It is front-loaded and contains no filler or redundant information. For a no-parameter tool, this level of brevity is appropriate and 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?
Despite the tool's simplicity, the description is incomplete because there is no output schema and no behavioral details. It lists topics (server health, version, tool status, API connectivity) but doesn't explain what the response looks like, whether results are aggregated, or how to interpret potential errors. Given the lack of annotations and output schema, the description should provide more context to be fully useful.
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 zero parameters, and the input schema is empty with 100% schema description coverage (vacuously). Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter-specific meaning, but none is needed.
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 lists the tool's scope: server health, version, tool status, and API connectivity. It conveys the resource being queried, and the name 'health_check' reinforces that it checks system status. However, it lacks a specific verb (e.g., 'Checks' or 'Returns'), so it's not a fully explicit action statement, but it is distinct from the SEO-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any use cases, prerequisites, or exclusions. Given the sibling tools are all distinct, the description offers no contextual clues for selection, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
keyword_researchAInspectResearch keyword volume, difficulty, CPC, trends, and related keywords
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country code (DE, US, UK, AT, CH, etc.) | |
| keyword | No | Seed keyword to research |
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 says what the tool 'researches' and does not mention whether it is read-only, has side effects, rate limits, or returns a specific structure. These omissions leave the agent without clear expectations for side effects or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the core functionality without excess words. Every element adds value, and it is easy to scan.
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 low-complexity tool, the description covers the core functionality and indicates the output dimensions (volume, difficulty, CPC, trends, related keywords). It lacks an explicit output schema or further context about optional country parameter, but the description provides enough for basic invocation.
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% (country and keyword both have descriptions). The tool description adds no further parameter-level meaning beyond the schema; it simply lists the research outcomes, which relate to output rather than input. 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 uses a specific verb ('Research') with a clear resource ('keyword') and enumerates the data points returned (volume, difficulty, CPC, trends, related keywords). This clearly distinguishes the tool from siblings like backlink_check or rank_tracker.
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 by listing the research outputs, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There are no exclusions or cross-references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_generatorBInspectAnalyze and generate optimized meta title + description for a URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to analyze/optimize | |
| keyword | No | Target keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. It only mentions 'analyze' and 'generate optimized' but does not explain the output format, whether it modifies anything, or any limitations. Minimal behavioral detail is given.
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, concise sentence that is front-loaded with the key action. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description is minimally adequate. It conveys the core purpose but does not explain the return structure or any edge cases. For a generator tool, more context about output would be helpful, but it is not severely 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?
Schema coverage is 100% for the two parameters, so the baseline is 3. The description does not add additional meaning beyond the parameter descriptions; it only restates 'URL' which is already in the schema. No extra clarity for 'keyword' is provided.
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: 'Analyze and generate optimized meta title + description for a URL'. It uses a specific verb ('generate') and resource ('URL'), and it is distinct from siblings like title_optimizer, though it doesn't explicitly contrast with it.
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 alternatives like title_optimizer or content_score. It simply states what the tool does without any contextual or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_trackerAInspectTrack ranking positions for multiple keywords at once (max 10)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to track | |
| country | No | Country code | |
| keywords | No | Keywords to track (1-10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior. It only mentions a limit of 10 keywords and the action of tracking, but does not state whether it performs live checks, stores results, requires authentication, or what output is returned. Very minimal behavioral disclosure.
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 concise single sentence with clear verb and object, front-loaded with action. There is zero wasted wording, and it effectively communicates the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values and additional context. It fails to mention output format, how domain/country are used, or what 'tracking' entails, leaving a significant gap for a multi-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?
Schema provides 100% parameter descriptions, so baseline is 3. The description adds no extra semantics beyond the schema, like country code format or domain pattern, and the max-10 limit is already present in the keywords parameter 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 uses specific verb 'Track' and identifies the resource as 'ranking positions for multiple keywords'. It clearly distinguishes from sibling tools like check_ranking by emphasizing multi-keyword tracking and the max-10 constraint, which indicates a different use case.
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?
Description implies a clear use case for tracking multiple keywords simultaneously but does not explicitly name alternatives or exclude single-keyword checks. It provides context but no direct when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
serp_alertAInspectCheck current SERP position and compare against previous check — tracks changes over time
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to watch | |
| country | No | Country code | |
| keyword | No | Keyword to monitor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior and it does explain the core behavior (current position + comparison). Yet it is ambiguous whether the tool stores previous checks, requires them to exist, or has side effects. The description does not clarify data persistence or error behavior, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that communicates the tool's purpose and the tracking behavior without any redundancy. Every word earns its place, making it highly 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 three-parameter tool with no output schema, the description covers the primary functionality and the comparison aspect adequately. It leaves out details about return format or what happens if no previous check exists, but given the tool's simplicity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (domain, keyword, country) already has a basic description. The tool description adds no further meaning beyond the schema's parameter names and brief descriptions, so it meets the baseline but does not exceed it.
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 current SERP position and compares against a previous check, indicating temporal change tracking. This specific verb+resource+scope differentiates it from siblings like serp_snapshot (which likely only takes a snapshot) and rank_tracker (which may track rankings over time but this tool emphasizes comparison with a stored previous 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 phrase 'tracks changes over time' provides clear context for when to use this tool: when a historical comparison of SERP position is needed. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
serp_snapshotBInspectGet top 10 Google results for a keyword with SERP features
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country code | |
| keyword | No | Keyword to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply states the action without any details on rate limits, required auth, error handling, or what 'SERP features' entails. This leaves much to the agent's inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function without any fluff. Every word adds value, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description is mostly complete but lacks explicit return structure details. The phrase 'with SERP features' is vague and could be expanded, but given the simplicity, it is minimally adequate.
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 descriptions for both parameters ('Country code' and 'Keyword to search'). The description adds no additional meaning beyond restating the keyword context, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('top 10 Google results') and clearly distinguishes this tool from siblings like backlink_check or keyword_research. It also specifies the input (keyword) and an additional feature (SERP features), making the purpose unambiguous.
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. The description does not mention any context, prerequisites, or exclusions. Sibling tool names are available but not referenced, so the description fails to help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
title_optimizerCInspectAnalyze current title tag and generate SEO-optimized title suggestions
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch current title from (optional) | |
| keyword | No | Target keyword | |
| draft_title | No | Your current title (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It says it analyzes a current title tag but doesn't disclose how it obtains that title (URL fetch vs draft input), whether the operation is safe/read-only, or what occurs if neither url nor draft_title is provided. This ambiguity is significant given the lack of structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently captures the tool's core function. However, it omits some behavioral details, which slightly detracts from its completeness, but as a concise statement it is well-structured.
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 absence of annotations and output schema, the description should clarify return values and input requirements. It doesn't mention whether at least one of url or draft_title is needed, nor the format of the suggestions. This under-specification limits its contextual completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for all three parameters (url, keyword, draft_title), achieving 100% schema coverage. The description adds no additional parameter semantics, so 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 uses specific verbs 'Analyze' and 'generate' with resource 'title tag' and 'title suggestions', clearly indicating it evaluates existing titles and produces optimized alternatives. While it doesn't explicitly name sibling tools, its focus on title tags distinguishes it from related tools like meta_generator or heading_analysis.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only states the tool's function, leaving the agent to infer appropriate usage.
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!
Sign in to create a connector for this server.