Keyword research MCP: search volume, CPC, keyword difficulty and keyword ideas by country.
Monthly search volume, CPC, competition, keyword difficulty and intent for any keyword and country, keyword ideas from seed terms, and the keywords a competitor ranks for that you don't.
Use for keyword ideas, search volume, CPC, difficulty and competitor keyword gaps when planning content or choosing targets. This is a focused subset of SEO Data; connect it instead of the toolkit when you only need keyword research.
Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices.
Example prompts:
Compare search volume and CPC for my keyword batch in the US after I approve the API-credit cost.
After confirming the API-credit spend, compare keyword difficulty for my shortlist and explain the limits of the estimates.
Find keyword ideas and competitor keyword gaps for the seed and domains I provide, within my approved API-credit budget.
Scored across 5 tools
The three data tools have distinct framings: find_keyword_ideas is discovery from seed keywords, find_competitor_keywords is a domain gap analysis, and get_keyword_search_volume / get_keyword_difficulty are metric lookups for known keywords. The only real overlap is that get_keyword_search_volume already returns difficulty (for 200 keywords) while get_keyword_difficulty returns only difficulty (for 500), so an agent could occasionally hesitate between those two, but the batch-size and output-scope hints largely resolve it.
All names follow a clean verb_noun pattern (find_* for discovery, get_* for retrieval) in consistent snake_case. The find/get split also maps meaningfully to the discovery-versus-lookup distinction.
Five tools is well-scoped for a keyword research server: three research operations, one competitor analysis, and one free meta/utility call. Nothing appears redundant or filler.
The core workflow is covered end to end: discover ideas, find competitor gaps, validate metrics (volume, CPC, difficulty, intent, 12-month trend), and check credits before spending. Minor gaps: no way to list organic keywords your own domain ranks for (only the competitor gap view), and no rank-tracking or SERP-position tool, so follow-up ranking checks would be a dead end.
Competitor keywords: keywords a competitor domain ranks for in Google that your domain does not, with search volume, difficulty and the competitor's position. Costs API credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many keywords to return, 10 to 1000. Default 100. | |
| country | No | Two-letter country code of the search market, for example US, GB, DE or IN. Default US. | US |
| language | No | Language code of the search market, for example en, de or pt-BR. Default en. | en |
| competitor | Yes | Competitor domain, for example competitor.com. | |
| yourDomain | Yes | Your domain, for example example.com. |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| nextStep | No | Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically. |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so safety is covered. The description adds a genuinely useful piece of context the annotations lack: that each call consumes API credits, which affects how freely an agent should invoke it. It does not mention pagination or rate limits, keeping it short of a 5.
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 tight sentences, front-loaded with the defining concept before the output fields and the cost note. Nothing is redundant and nothing is missing from the framing.
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 an output schema present, the description does not need to explain return values, and it still names the key metrics (volume, difficulty, position) to set expectations. Combined with the credit-cost warning, an agent has enough to call it correctly; only explicit sibling routing is absent.
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%, with defaults, ranges, patterns and examples for all five parameters, so the schema does the heavy lifting. The description only echoes that the inputs are domains (competitor and your own), adding no format or constraint detail beyond what the schema already states — baseline 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 gives a specific verb-and-resource definition and, crucially, defines the core concept: keywords a competitor domain ranks for in Google that your domain does not. That set-difference framing instantly separates it from siblings like get_ranked_keywords (your own rankings) and find_competitor_domains (domain discovery).
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 gap concept implies when to use it (competitive keyword research), but there is no explicit when-to-use or when-not-to-use guidance and no sibling is named. An agent must infer the boundary from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword ideas: related keywords for up to 20 seed keywords with search volume, CPC, difficulty and intent, sorted by search volume. Costs API credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many ideas to return, 10 to 500. Default 100. | |
| seeds | Yes | Up to 20 seed keywords that describe the topic. | |
| country | No | Two-letter country code of the search market, for example US, GB, DE or IN. Default US. | US |
| language | No | Language code of the search market, for example en, de or pt-BR. Default en. | en |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| nextStep | No | Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically. |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds one genuinely new behavioral fact not in structured data: it costs API credits per call, which matters for an agent's retry and batching decisions. It doesn't quantify the cost or note rate limits/pagination.
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?
One sentence, front-loaded with the resource name, then scope, then output fields, then a cost caveat. Nothing is redundant.
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 an output schema present, return values and sorting need no elaboration, and the schema fully documents parameters. What's left thin is the decision boundary against the three lookup/competitor siblings; the credit-cost warning partially offsets this.
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 all four parameters (seeds, limit, country, language) are already fully documented with defaults and bounds. The description adds only the seed-count cap, which the schema's maxItems already states, and the output ordering, which is not a parameter. 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?
Names a specific verb+resource ("Keyword ideas: related keywords") and scopes it precisely ("up to 20 seed keywords"), plus names the returned metrics. It implicitly distinguishes itself from lookup-style siblings like get_keyword_search_volume by being a discovery tool, but never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is the discovery step producing 10-500 related ideas, whereas siblings get_keyword_difficulty / get_keyword_search_volume look up single known keywords. No explicit when-to-use or when-not-to-use statement, and no routing guidance toward find_competitor_keywords.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
API credit balance: prepaid credits left for SEO data calls, amount spent, whether spending is suspended, and the per-call pricing rule. Free; no supplier call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| packs | No | API credit packs the account owner can buy, smallest first. |
| frozen | Yes | True when spending is suspended after a refund or dispute. |
| pricing | Yes | |
| creditsUrl | No | Dashboard page where the account owner buys API credits. |
| historyUrl | No | Dashboard page listing this account's data calls and costs. |
| spentMicros | Yes | |
| availableUsd | Yes | |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
| availableMicros | Yes | |
| dataCallsEnabled | Yes | False until SEO data calls are switched on for this deployment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the call is free of charge and triggers no upstream supplier call, which tells the agent it is cheap in both cost and latency. It does not discuss caching or freshness of the balance value.
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?
A single front-loaded sentence packs the returned fields and the cost/latency caveat with no filler. The leading 'API credit balance:' label is mildly redundant with the title but functions as a scannable anchor rather than waste.
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 an output schema documenting the return shape, zero parameters, and rich annotations, the description's burden is small and it meets it: what the tool reports and that it costs nothing. Only the when-to-use signal is absent, which keeps it short of a 5.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly offers no parameter guidance, which is appropriate rather than a gap.
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 names the exact resource (prepaid API credit balance) and enumerates the four facts it exposes: credits remaining, amount spent, suspension status, and per-call pricing rule. An agent can tell this is an account/billing read, distinct in substance from the SEO-data siblings, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Free; no supplier call' hints it is safe to call speculatively (e.g., to verify credits before paid SEO queries), but the description never states when to use it or what alternative exists. Nothing misleads, but the agent must infer the check-before-spending workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword difficulty: how hard it is to rank organically in Google for up to 500 keywords, scored 0 to 100. Costs API credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter country code of the search market, for example US, GB, DE or IN. Default US. | US |
| keywords | Yes | Up to 500 keywords. | |
| language | No | Language code of the search market, for example en, de or pt-BR. Default en. | en |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| nextStep | No | Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically. |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing that each call consumes API credits and by bounding batch size and score range, which materially affects how an agent should budget calls.
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 compact sentences, front-loaded with the metric definition, and the cost warning is placed where it will be read. Minor redundancy in repeating the 500-keyword limit already enforced by the schema.
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?
An output schema exists so return values need no explanation, and the description covers what the metric is, its scale, batch limits and cost. Only the absence of any routing guidance to sibling tools keeps it from being 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?
Schema description coverage is 100%, so country, language and the keyword array are already fully documented in the schema. The description adds nothing about parameter semantics beyond restating the 500-keyword cap, 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?
States a specific metric ('keyword difficulty'), its meaning ('how hard it is to rank organically in Google'), its scale (0-100), and its batch capacity (up to 500 keywords). An agent can immediately tell this is the difficulty-metric tool rather than a volume or ideas tool, though no sibling is named explicitly.
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?
There is no guidance on when to reach for this tool versus get_keyword_search_volume, find_keyword_ideas, or find_competitor_keywords, and no stated prerequisites or exclusions. Usage is only inferable from the metric name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search volume, CPC and difficulty for up to 200 keywords in any country: monthly Google searches, cost per click, competition, keyword difficulty, intent and the last 12 months trend. Costs API credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter country code of the search market, for example US, GB, DE or IN. Default US. | US |
| keywords | Yes | Up to 200 keywords. | |
| language | No | Language code of the search market, for example en, de or pt-BR. Default en. | en |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| billing | Yes | |
| nextStep | No | Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically. |
| dashboardUrl | No | Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent. |
| creditsNotice | No | Low API credit balance: tell the user once, with this link to add credits. Never open it automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds the genuinely useful fact that each call consumes API credits, which an agent cannot infer from annotations or schema, though it says nothing about rate limits or partial failures on large batches.
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?
A single front-loaded sentence that leads with the resource and then lists the metrics, with the cost caveat last. It is dense but every clause carries content; a short split for the cost note would read slightly better.
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 a full output schema and 100% parameter coverage, the description need not explain return values, and it correctly adds only the cost signal. What is missing is routing guidance among the closely related sibling tools (notably get_keyword_difficulty) and any note on large-batch behavior.
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 country, language, and keyword formats are already fully documented with defaults and patterns. The description only restates the 200-keyword cap and "any country", adding no syntax or constraint meaning beyond the schema; 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?
Names a specific resource (keyword search volume, CPC and difficulty) and enumerates the returned metrics, so the agent knows exactly what data comes back. It does not distinguish itself from the sibling get_keyword_difficulty, which plausibly returns an overlapping metric, so it falls short 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?
Usage is implied by the batch limit ("up to 200 keywords") and the per-call cost, which nudges toward batching, but there is no explicit statement of when to use this instead of get_keyword_difficulty or find_keyword_ideas. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_competitor_keywords1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_keyword_ideas1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}Output schema / properties / packsAdded value: +{
+ "description": "API credit packs the account owner can buy, smallest first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "url": {
+ "description": "Page where the account owner confirms this pack in checkout.",
+ "type": "string"
+ },
+ "usd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "usd",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_keyword_difficulty1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_keyword_search_volume1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_competitor_keywords1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}find_keyword_ideas1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}Output schema / properties / packsRemoved value: -{
- "description": "API credit packs the account owner can buy, smallest first.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "url": {
- "description": "Page where the account owner confirms this pack in checkout.",
- "type": "string"
- },
- "usd": {
- "type": "number"
- }
- },
- "required": [
- "usd",
- "url"
- ],
- "type": "object"
- },
- "type": "array"
-}get_keyword_difficulty1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}get_keyword_search_volume1 field changedOutput schema / properties / creditsNoticeRemoved value: -{
- "additionalProperties": false,
- "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
-}find_competitor_keywords1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_keyword_ideas1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_api_credit_balance2 fields changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}Output schema / properties / packsAdded value: +{
+ "description": "API credit packs the account owner can buy, smallest first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "url": {
+ "description": "Page where the account owner confirms this pack in checkout.",
+ "type": "string"
+ },
+ "usd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "usd",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_keyword_difficulty1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_keyword_search_volume1 field changedOutput schema / properties / creditsNoticeAdded value: +{
+ "additionalProperties": false,
+ "description": "Low API credit balance: tell the user once, with this link to add credits. Never open it automatically.",
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_competitor_keywords2 fields changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."Output schema / properties / nextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically.",
+ "properties": {
+ "label": {
+ "description": "Short suggestion to show the user.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Page in the user's CrakSEO account.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_keyword_ideas2 fields changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."Output schema / properties / nextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically.",
+ "properties": {
+ "label": {
+ "description": "Short suggestion to show the user.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Page in the user's CrakSEO account.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_keyword_difficulty2 fields changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."Output schema / properties / nextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically.",
+ "properties": {
+ "label": {
+ "description": "Short suggestion to show the user.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Page in the user's CrakSEO account.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}get_keyword_search_volume2 fields changedOutput schema / properties / dashboardUrl / descriptionPrevious value: -"Dashboard page with this server's call history and costs. Share it when the user asks what they ran or spent."New value: +"Dashboard page where this tool also runs in the app; its call history and costs are linked from there. Share it when the user asks what they ran or spent."Output schema / properties / nextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional suggestion for the user's next step. Mention it once when it helps; never open it or act on it automatically.",
+ "properties": {
+ "label": {
+ "description": "Short suggestion to show the user.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Page in the user's CrakSEO account.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+}find_competitor_keywordsfind_keyword_ideasget_api_credit_balanceget_keyword_difficultyget_keyword_search_volumeGoogle rank checker MCP: live positions, ranked keywords, competitor domains and keyword gaps. Check a domain's live Google positions for up to 10 keywords per call, retrieve ranked keywords, find organic competitors and compare competitor keyword gaps. Results are snapshots, not built-in scheduled tracking or ranking history. Use to check current Google positions or research competitor keywords. This is a focused SEO Data subset. Use Search Console instead for your own connected site's historical performance; this connection does not schedule future checks. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - Check my domain's live Google positions for these five keywords in the US after I approve the per-keyword API-credit spend. - Within my approved API-credit budget, show keywords the supplied domain currently ranks for. - Find competitor domains and keyword gaps for my domain after confirming the API-credit cost. Do not imply this sets up scheduled tracking. Docs: https://docs.crakseo.com/mcp-servers/rank-tracker
SEO data MCP: SERP, keywords, backlinks, live rank checks, page audits, local and AI checks. Every SEO data tool in one server: Google and Bing SERP results, live rank checks, AI Overview sources, keyword search volume, ideas and difficulty, backlinks, referring domains and anchors, ranked keywords, competitor domains and keyword gaps, site audits with Lighthouse scores, Google Maps rankings, Google Business Profiles, and ChatGPT and Perplexity brand mentions. Start here for paid SEO research with one connection. Includes all seven focused SEO data servers' tools at the same prices and from the same API-credit balance; do not connect both for duplicate results. Search Console reporting and URL Indexing are separate connections. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - After I approve the API-credit cost, compare US search volume and difficulty for 'trail running shoes' and 'running shoes for flat feet'. - For the domain I provide, check its backlink summary, referring domains and anchor texts after confirming the API-credit spend. - Compare live Google positions and competitor keyword opportunities for my domain and keywords, within the API-credit budget I approve. Docs: https://docs.crakseo.com/mcp-servers/seo
Google SERP API MCP: live Google, Bing, AI Overview and Google Maps results as JSON. Pay per call. Live search engine results pages as structured JSON: Google organic results with SERP features and AI Overview sources, Bing results, Google Maps local results, and live Google rank checks for a domain across up to 10 keywords. Use when an agent needs live Google or Bing search results for a keyword, country, language and device. This is a focused subset of SEO Data, not an additional required connection or a scheduled monitoring service. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - Show the top ten Google results and SERP features for 'trail running shoes' in the US, after I approve the API-credit spend. - Compare Google and Bing results for my keyword in the same market, within my approved API-credit budget. - After confirming the API-credit cost, report which source URLs Google's AI Overview cites for my keyword. If none is present, say so. Docs: https://docs.crakseo.com/mcp-servers/serp-api
Local SEO MCP: Google Maps rankings, Google Business Profile ratings and review counts. Google Maps positions for a keyword in a city with rating, review count, category and address, and a business's Google Business Profile with rating distribution and claimed status. Use for point-in-time Google Maps rankings and Google Business Profile lookup by location. This focused SEO Data subset returns rating and review-count summaries, not full review text, review replies or Business Profile management. Billing: paid data calls use API credits; get_api_credit_balance is free. The focused connections and SEO Data use the same balance and prices. Example prompts: - Check Google Maps results for 'running shoe store' in the city I specify after I approve the API-credit cost. - Within my approved API-credit budget, compare Maps rankings for the same keyword in two specified places. - After confirming the API-credit spend, retrieve the business profile I specify and summarize its rating and review counts, not review text. Docs: https://docs.crakseo.com/mcp-servers/local-seo
Add one secure layer between your agents and this server.