Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@optiqra-mcp Run a full SEO audit on https://mystore.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that exposes every tool in OptiQra's API to MCP-compatible AI clients (Claude Desktop, Claude Code, Cursor, etc.).
OptiQra has four HTTP endpoints. This server wraps all four as MCP tools:
Tool | OptiQra endpoint | What it does |
|
| Crawls a URL and runs the full SEO/GEO/AEO/perf/a11y/security audit |
|
| Generates an AI-written fix for one issue from a report |
|
| Generates a site-wide AI strategy summary across a full report |
|
| Verifies a provider/API key/model combo works before using the two above |
By default it talks to the public demo, https://optiqra.vercel.app. Point
it at your own deployment (see OptiQra's own DEPLOYMENT.md/Docker setup)
with an env var — see below.
npm install(or, once published, npm install -g optiqra-mcp / run directly with npx optiqra-mcp)
Related MCP server: mcp-seo
Variable | Required | Purpose |
| No | Base URL of the OptiQra instance to call. Defaults to |
| No | A default AI-provider API key used by |
| No | Request timeout in ms. Defaults to |
node src/index.jsIt speaks MCP over stdio, so you won't see anything happen — it's waiting for an MCP client to connect.
Add to your MCP config (claude_desktop_config.json, or via claude mcp add
for Claude Code):
{
"mcpServers": {
"optiqra": {
"command": "node",
"args": ["/absolute/path/to/optiqra-mcp/src/index.js"],
"env": {
"OPTIQRA_BASE_URL": "https://optiqra.vercel.app",
"OPTIQRA_PROVIDER_API_KEY": "sk-..."
}
}
}
}
Any other MCP-compatible client (Cursor, Windsurf, etc.) uses the same
`command`/`args`/`env` shape — check that client's docs for where the config
file lives.
## Notes on the AI-key tools
`optiqra_ai_fix`, `optiqra_ai_insights`, and `optiqra_ai_test` all need a
provider API key, exactly like pasting one into OptiQra's own UI — OptiQra's
server forwards it straight to the provider (OpenAI, Anthropic, Google, Groq,
OpenRouter, Mistral, DeepSeek, or xAI) and never stores it. This server does
the same: it never persists keys. Prefer setting `OPTIQRA_PROVIDER_API_KEY`
in your MCP client's env config over having the model pass a key through
chat.Given a single issue from an OptiQra report (as produced by optiqra_analyze), asks an AI provider to generate a suggested fix. Requires an API key for the chosen provider — OptiQra forwards it directly to that provider and never stores it server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| issue | Yes | The issue object (from an optiqra_analyze report) to generate a fix for. | |
| model | No | Optional specific model name to use for that provider. | |
| apiKey | No | API key for the chosen provider. Optional if OPTIQRA_PROVIDER_API_KEY is set in this server's environment. | |
| provider | Yes | AI provider to use for this request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: the API key is forwarded directly to the provider and never stored server-side. This addresses security/privacy behavior. However, it does not mention other behaviors like error handling, cost, or whether the fix is returned vs. persisted, which would add further 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 two sentences, front-loaded with the core purpose, and includes critical context (input provenance, API key handling) without redundancy. Every sentence 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?
The description covers purpose, input source, authentication, and privacy for a tool with no output schema or annotations. It could be more complete by outlining the expected response structure, but the essential context for invoking the tool is present.
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 the schema fully documents all four parameters. The description only states that an API key is required, which slightly overlaps with the schema's note that apiKey is optional if an environment variable is set. It adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('generate a suggested fix') and identifies the resource (a single issue from an OptiQra report). It clearly distinguishes from siblings by specifying it operates on output from optiqra_analyze, while siblings like optiqra_ai_test and optiqra_ai_insights serve different purposes.
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?
It provides clear context on when to use: after optiqra_analyze produces an issue, and mentions the API key prerequisite. It does not explicitly state when not to use or name alternatives, but the sibling list and the description's provenance reference imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a full OptiQra report (as produced by optiqra_analyze), asks an AI provider to generate a strategic, site-wide summary reasoning across all audit categories and pages. Requires an API key for the chosen provider — OptiQra forwards it directly to that provider and never stores it server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional specific model name to use for that provider. | |
| apiKey | No | API key for the chosen provider. Optional if OPTIQRA_PROVIDER_API_KEY is set in this server's environment. | |
| report | Yes | The full report object returned by optiqra_analyze. | |
| provider | Yes | AI provider to use for this request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden of disclosing behavior. It discloses API key handling (forwarded directly, never stored server-side), which is valuable. However, it does not mention failure behaviors, rate limits, or what happens if no API key is provided (though schema says optional via env var). This is adequate but not rich.
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 fluff. The first sentence explains the core function and input constraint, the second addresses a crucial prerequisite. Every phrase 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?
Given no output schema, the description sufficiently indicates the output is a strategic summary. It covers input (report), processing (across categories/pages), and a caveat (API key). Could be more explicit about return format or potential errors, but for the complexity shown, it 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 all parameters are already documented. The description adds contextual meaning by stating the report must be a full OptiQra report from optiqra_analyze and that the API key is forwarded to the provider, but it does not elaborate further on individual parameters beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('generate') and resource ('strategic, site-wide summary reasoning across all audit categories and pages'), and explicitly references optiqra_analyze as the producer of the input, distinguishing it from sibling tools that test or fix.
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 sets clear context: it takes the report from optiqra_analyze and generates AI insights, implying it should be used after analysis. It does not explicitly list alternatives or when-not-to-use, but the sibling tool names (ai_test, ai_fix) provide implicit differentiation. The mention of API key requirements adds a practical precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies that a given AI provider + API key + model combination is reachable and working, before using optiqra_ai_fix or optiqra_ai_insights.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional specific model name to test. | |
| apiKey | No | API key for the chosen provider. Optional if OPTIQRA_PROVIDER_API_KEY is set in this server's environment. | |
| provider | Yes | AI provider to use for this request. |
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 only states the verification intent but omits any side effects, whether the operation is read-only, the meaning of 'working', or the response format. For a tool that likely performs network calls, this leaves important behavioral traits undisclosed.
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 immediately states the action and context. It contains zero filler or redundancy, 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 relatively simple verification tool, the description is adequate but incomplete. It lacks any mention of success/failure outcomes, whether the call is destructive, or how the result is returned. Given no output schema and no annotations, more detail would be valuable for the agent to set expectations.
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, so the parameters are already well documented. The description adds minimal semantic value beyond listing the combination in prose; it does not introduce dependencies, constraints, or environment-specific details beyond what the schema already includes for apiKey.
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 'verifies' with a clear resource ('AI provider + API key + model combination') and explicitly distinguishes the tool's role from the sibling tools by naming optiqra_ai_fix and optiqra_ai_insights. This makes the purpose unmistakable and contextually differentiated.
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 to use this tool 'before using optiqra_ai_fix or optiqra_ai_insights', providing clear timing guidance. It does not mention when to avoid using it or alternatives beyond the implied sequencing, but the primary usage context is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawls a website and runs OptiQra's full audit: SEO, GEO (generative engine optimization), AEO (answer engine optimization), performance, accessibility, security headers, structured data, links, images, and duplicate-content detection. Returns a report with per-category scores and issue details. This can take a while for larger sites since it crawls the whole site.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the website to analyze, e.g. https://example.com |
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 clearly states the tool crawls the entire site and may take a considerable amount of time, which is a significant behavioral trait. It also explains that the output is a report with per-category scores and issue details, providing good transparency without contradicting any 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 concise and well-structured. It opens with the main action, lists the audit categories efficiently, states the return value, and ends with a practical warning about time. Every sentence earns its place, and there is no fluff.
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 one-parameter tool with no output schema, the description is quite complete: it covers the tool's behavior, the audit scope, the return report format, and a performance caveat. It could optionally mention prerequisites like site ownership or robots.txt, but the core context is sufficiently provided.
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% coverage, with the 'url' parameter already described as 'The URL of the website to analyze, e.g. https://example.com'. The description adds no additional parameter-specific detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly explains the tool's purpose: it crawls a website and runs a comprehensive audit covering many specific categories (SEO, performance, accessibility, etc.). The verb 'crawls' plus the resource 'website' makes the action explicit, and the detailed list of audit areas distinguishes it from the vague sibling tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that the tool crawls the whole site and can take a while, implying it should be used when a full audit is needed. However, it does not explicitly mention when to use this tool versus the sibling tools (test, fix, insights) or any exclusions, leaving usage guidance mostly implicit.
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. Dates show when Glama detected each change.
v1.0.4optiqra_ai_fixoptiqra_ai_insightsoptiqra_ai_testoptiqra_analyzeEach tool has a distinct purpose: optiqra_analyze performs the site audit, while optiqra_ai_test validates AI connectivity, optiqra_ai_fix addresses individual issues, and optiqra_ai_insights provides site-wide strategy. No two tools overlap meaningfully; the input scope (single issue vs full report) clearly separates the AI generation tools.
All tools share the 'optiqra_' prefix and snake_case convention. The naming pattern is mostly consistent: 'optiqra_ai_*' for AI-related tools and 'optiqra_analyze' for the audit. The slight deviation is that 'optiqra_analyze' lacks the 'ai_' component, but this is logical since the audit is independent of AI providers.
With exactly 4 tools, the server is tightly scoped for its purpose: one comprehensive audit tool and three supporting AI utilities. Each tool fills a necessary role in the workflow, and the count is neither inflated nor insufficient.
The tool set covers the full lifecycle of an audit automation: optiqra_analyze generates the report, optiqra_ai_test ensures AI availability, and then optiqra_ai_fix/insights provide actionable output. There are no obvious missing functions—the report includes detailed issues and scores, and the AI tools address both granular and strategic needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/armin5872/optiqra-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
