RGate MCP server scans public websites for release-readiness across five quality layers: security, SEO, accessibility, legal compliance, and sustainability. Here's what you can do:
Start a scan (start_scan): Kick off an asynchronous scan for any public URL.
Poll scan status & retrieve results (get_scan): Monitor scan progress and fetch structured findings, check results, tech detections, and an agent summary once complete. Supports report tokens for full, non-redacted access.
Unlock a free report (unlock_report): During active campaigns, submit an email to receive a 24-hour token granting full access to findings and fix plans at no cost.
Create a checkout handoff (create_checkout_handoff): Generate a URL to send a human to purchase a full report or subscription when a report is paywalled.
Browse the check catalog (list_checks): Explore all checks RGate performs, optionally filtered by layer.
Get pricing info (get_pricing): Retrieve machine-readable plan details including names, prices, billing periods, scan limits, and use cases.
Generate a fix plan (generate_fix_plan): Build a prioritized, implementation-ready fix plan from scan findings — release blockers first, then high-impact items, then backlog — in JSON or Markdown, optionally filtered by layer.
Export scan as Markdown (export_scan_markdown): Export results using templates suited for Cursor agent prompts, GitHub issues, or executive summaries.
Compare two scans (compare_scan_history): Diff two completed scans of the same domain to identify added, resolved, improved, or worsened findings — useful for tracking progress or catching regressions after a deploy.
Allows exporting scan results as a GitHub issue body for tracking website quality improvements.
RGate is the release gate agents call before they tell users a public website is ready to ship.
This repository documents the public RGate MCP server for agentic IDEs, coding agents, and MCP clients. The RGate product source code is not published here; this repo is the public integration and directory listing home for the operated MCP endpoint.
MCP endpoint: https://www.rgate.io/api/mcp
Transport: Streamable HTTP
Manifest: https://www.rgate.io/.well-known/mcp.json
OpenAPI: https://www.rgate.io/openapi.json
Agent guide: https://www.rgate.io/agents.md
Developer docs: https://www.rgate.io/en/developers
Agent recipes: https://www.rgate.io/en/agent-recipes
Related MCP server: blop
RGate scans public websites across five release-readiness layers:
Security
SEO
Accessibility
Legal compliance
Sustainability
Agents can start a scan, poll structured results, inspect the check catalog, generate fix plans, export Markdown, compare scan history, and hand paid report access back to a human.
{
"mcpServers": {
"rgate": {
"url": "https://www.rgate.io/api/mcp",
"transport": "streamable-http"
}
}
}Tool | Purpose |
| Start an RGate website quality scan for a public URL. |
| Fetch scan status and, once complete, structured findings and results. |
| Describe RGate scan layers and the check catalog. |
| Return machine-readable plan names, prices, limits, and use cases. |
| Create a human handoff URL for purchasing report access or a subscription. |
| Generate a prioritized release-readiness fix plan from findings. |
| Export scan results as Markdown for Cursor, GitHub issues, or summaries. |
| Compare two scans and return added, resolved, improved, and worsened findings. |
Confirm the user is allowed to scan the public website.
Call start_scan with the public URL.
Poll get_scan with the returned scanId until status is done or failed.
If the target passed green, report that the website passed the release gate.
If access is locked, send the human to the report URL for checkout and poll the same scanId again after payment.
Generate a fix plan or Markdown export for the coding agent working on that project.
CLI: npm install -g @rgate_io/rgate
Skill: npx skills add marcoldenburg/rgate-release-readiness-skill
Skill repository: https://github.com/marcoldenburg/rgate-release-readiness-skill
Glama: glama.json at repo root (maintainer claim for listing)
Name: rgate
Title: RGate
Description: Release gate agents call before they tell users a public website is ready to ship. Scans public websites across security, SEO, accessibility, legal compliance, and sustainability.
Tags: developer-tools, release-readiness, mcp, agent-tools, website-audit, security, seo, accessibility, compliance, sustainability
RGate is a remote MCP server hosted at https://www.rgate.io/api/mcp
(transport: Streamable HTTP). Some runners — including Glama's automated
build/quality check — start a local stdio process and speak MCP to it. This
repo doubles as a thin stdio↔remote bridge for exactly that:
npm install
npm start # = mcp-remote https://www.rgate.io/api/mcpBuild steps: ["npm install"]
Start command: npm start (or mcp-remote https://www.rgate.io/api/mcp)
Node.js ≥ 18; Python/base-image defaults are fine.
For direct clients (Cursor, Claude, VS Code) just use the remote URL from
mcp.json — no bridge needed.
Diff two completed scans of the SAME domain and return added, resolved, improved, and worsened findings. Read-only. Both scans must be done. Use to verify that fixes landed between two runs, or to catch regressions after a deploy.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional report token for non-public scans. | |
| scanId | Yes | The more recent scan (the 'after'). | |
| againstScanId | Yes | The earlier scan to compare against (the 'before'). Must be the same domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds 'Read-only' and clarifies the output (added, resolved, improved, worsened) and preconditions (both scans completed). No contradictions.
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 concise sentences, front-loaded with purpose and outcome. Every sentence adds value with zero 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?
Given no output schema, the description adequately explains return categories. Preconditions and constraints are stated. The tool's simplicity and good annotations make this 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 coverage is 100% with good descriptions. The description adds value by emphasizing that scans must be of the same domain and both must be completed, which are not fully captured in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diffs two completed scans of the same domain and returns categories of findings (added, resolved, improved, worsened). It distinguishes from sibling tools like get_scan or start_scan by focusing on comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: verifying fixes landed or catching regressions after deploy. It also notes both scans must be done, but doesn't explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a human handoff URL for purchasing a full report or subscription after a scan is complete. Behavior: creates a checkout/upgrade link and returns { handoffUrl }. The agent CANNOT complete payment itself — give the URL to the user to finish in a browser. Use only when the report is paywalled (get_scan shows access.level teaser with payment_required true) AND no free campaign is active. During a campaign, prefer unlock_report.
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | Plan to purchase: full-report (one-time unlock of this report), continuous (monthly, one domain), or portfolio (monthly, multiple domains). See get_pricing. | |
| scanId | Yes | The completed scan the purchase unlocks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior: creates a checkout/upgrade link and returns handoffUrl. Notes that agent cannot complete payment and must give URL to user. Annotations (readOnlyHint false, destructiveHint false) are consistent with this description.
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?
Concise, front-loaded description. First sentence states purpose, second explains behavior, third gives agent instruction, fourth and fifth provide usage conditions. Every sentence adds value without 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 tool with 2 required params, no output schema, and no nested objects, the description covers purpose, behavior, constraints, and usage guidelines completely. The output format is implied ({ handoffUrl }). No missing information.
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%. Description adds context to parameters: planId enums are explained with descriptions like 'one-time unlock' and reference to get_pricing; scanId context is repeated but clear. Additional value beyond schema justifies above 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 clearly states that it creates a human handoff URL for purchasing a report or subscription after a scan. It includes a specific verb (create), resource (handoff URL), and context (after scan complete). It also distinguishes from sibling tool unlock_report by noting when to prefer that tool.
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?
Explicitly states when to use: only when the report is paywalled (get_scan shows access.level teaser with payment_required true) and no free campaign is active. Provides clear alternative: during a campaign, prefer unlock_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a completed scan as Markdown in one of three templates: cursor (an agent fix prompt), github (an issue body), or executive (a stakeholder summary). Read-only. Requires full access — pass a token for a locked report. Use to hand results into an IDE/coding agent or a ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional report token (from unlock_report or a paid unlock) for full exports. | |
| scanId | Yes | The completed scan to export. | |
| template | No | cursor = agent fix prompt, github = issue body, executive = stakeholder summary. | cursor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Read-only' matching readOnlyHint=true and explains token requirement for locked reports. This adds context beyond the annotations, such as the need for full access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first defines main action, second adds constraints, third gives usage context. No waste, 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?
Covers key aspects: export format, templates, token requirement, and usage scenarios. No output schema needed; description adequately informs invocation. Could mention error if scan incomplete, but implied by 'completed scan'.
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?
With 100% schema coverage, baseline is 3. The description adds meaning by explaining each template's purpose (cursor=agent fix prompt, github=issue body, executive=summary) and token for locked reports.
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 exports a completed scan as Markdown with three specific templates (cursor, github, executive). It distinguishes from siblings like unlock_report (which provides token) and get_scan (raw data).
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 explicitly stated: 'Use to hand results into an IDE/coding agent or a ticket.' It also mentions the requirement of a token for locked reports. However, it does not explicitly exclude other use cases or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a prioritized, implementation-ready fix plan from a completed scan's findings: release blockers first, then high-impact follow-ups, then backlog. Read-only (derives from stored findings). Returns JSON (or Markdown). Requires full access: on a locked report it returns HTTP 402, or — during a campaign — a teaser with unlock instructions; pass a token from unlock_report or a paid unlock. Call after get_scan shows status done.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional report token (from unlock_report or a paid unlock) for full plans. | |
| format | No | json for structured steps, markdown for a ready-to-paste plan. | json |
| layers | No | Optional subset of layers to include. Omit for all layers. | |
| scanId | Yes | The completed scan to build a plan from. | |
| maxFindings | No | Cap on the number of findings turned into fix steps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description confirms read-only nature aligned with annotations, and discloses important behaviors: return HTTP 402 for locked reports, teaser during campaign, and token requirement. This adds context beyond the 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?
Description is concise, front-loads the main purpose, and uses clear bullet-like sentences. Every sentence adds necessary information without 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 tool's complexity (5 parameters, 1 required, edge cases like locked reports), the description covers return format options, token usage, and prerequisite (scan done). It adequately prepares the agent for invocation, even without an output schema.
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%, so baseline is 3. Description adds value by clarifying that token comes from unlock_report or paid unlock, and explains how layers work (omit for all). This elevates the score to 4.
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 builds a prioritized fix plan from completed scan findings, specifying verb, resource, and priority order. It distinguishes itself from siblings like get_scan by indicating it should be called after a scan is done.
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?
Explicitly states when to use: after get_scan shows status done. Also provides guidance for locked reports and how to unlock, effectively telling when not to use (if scan not done or report is locked) and alternatives (unlock_report).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return machine-readable RGate pricing: plan ids, names, prices (EUR/USD), billing period, scan limits, and best-fit use cases. Read-only, static, no arguments. Use to answer pricing questions or choose a planId for create_checkout_handoff.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it is static and has no arguments, which is helpful but not critical. The description does not contradict 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?
Two sentences, front-loaded with output description, then usage guidance. No unnecessary words. 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?
Lacks output schema but description enumerates all returned fields. For a simple read-only tool with no parameters, the description is 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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info but is not required. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns machine-readable RGate pricing with specific fields (plan ids, names, prices, etc.). It uses a specific verb and resource, and distinguishes itself from siblings by noting it's read-only and stateless.
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?
Explicitly states when to use: to answer pricing questions or choose a planId for create_checkout_handoff. Provides clear context and a direct link to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a scan and, once complete, return its structured results. Read-only. Returns { scan, findings, checkResults, techDetections, access, agentSummary }. scan.status moves through pending → running → retrying → done → failed; keep polling (every few seconds) until done or failed. On failed, a failure object explains the cause and next_action. access.level is none | teaser | full: teaser findings are diagnostic only (evidence, check keys, and fix text are redacted). To get full data, pass a report token via the token argument. If access.campaign is present the report is FREE right now — call unlock_report with an email to obtain that token instead of sending the user to checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional report token (from unlock_report or a paid unlock) that upgrades a teaser response to full findings. | |
| scanId | Yes | The scan ID returned by start_scan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds rich behavioral details: status progression, failure explanation, access level nuances (none/teaser/full), and token usage. No contradiction with 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 detailed yet efficient, with front-loaded purpose. Every sentence adds information, though slightly verbose in access level explanation. Overall 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?
No output schema, but the description comprehensively covers return structure fields, status flow, error handling, access levels, and token/campaign scenarios. This is exceptional completeness for a tool with no output schema.
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%, so baseline is 3. Description adds value by explaining token's purpose (upgrade teaser to full) and linking scanId to start_scan, providing more context than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Poll a scan and, once complete, return its structured results.' It uses specific verbs and resource, and the context of sibling tools (start_scan, unlock_report) helps distinguish it as a polling mechanism.
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 explains when to use: poll until done or failed, and when to use alternatives like unlock_report for token. It provides polling frequency guidance and clarifies the access level upgrade path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the RGate scan-layer and check catalog. Read-only, static, no side effects — safe to call any time. Use it to plan a scan, explain coverage to a user, or map a finding to its layer. Pass a layer to focus on just that layer's checks.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | Optional layer to focus on. Omit to list every layer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes itself as 'read-only, static, no side effects — safe to call any time', which reinforces and extends annotations (readOnlyHint, idempotentHint, destructiveHint). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, use cases, parameter guidance. Front-loaded with essential information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers all key aspects: what it returns, its behavior, and how to use the parameter. Complete for its complexity.
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 description for 'layer'. The description adds context: 'Pass a layer to focus on just that layer's checks', enhancing the parameter's meaning beyond the enum list.
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 returns the 'RGate scan-layer and check catalog' (specific verb and resource). It distinguishes from siblings like 'start_scan' or 'get_scan' by being read-only and catalog-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: plan a scan, explain coverage, map a finding. No explicit exclusions or alternatives, but the context is clear and distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a website release-readiness scan for a public URL across five layers: security, SEO, accessibility, legal compliance, and sustainability. Behavior: enqueues an asynchronous job and returns immediately with a scanId — it does NOT wait for results, and it fetches/renders the target site (not a read-only call). Returns { scanId, status, cached }; identical URLs within ~10 minutes return the cached scan. Next step: poll get_scan with the scanId until status is "done" or "failed". Use this first, once per site; do not busy-loop calling start_scan for the same URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to scan, including the scheme. Must be a reachable public site — IP literals, localhost/private ranges, and major-provider domains (google.com, etc.) are rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: enqueues async job, returns immediately with scanId, fetches/renders the site (not read-only), and describes caching. Annotations provide readOnlyHint=false, which is consistent.
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?
Four sentences, each with a distinct purpose: purpose, behavior, return/caching, next step. No 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?
Despite no output schema, the description explains the return shape, caching, and the asynchronous nature. All necessary context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema description is thorough. The description does not add significant new meaning beyond what the schema already provides for the url parameter.
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 it starts a release-readiness scan for a public URL across five layers, distinguishing it from sibling tools like get_scan and compare_scan_history.
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?
Explicitly says 'Use this first, once per site' and 'do not busy-loop calling start_scan for the same URL', and provides the next step to poll get_scan. Also explains caching behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlock a completed scan's full findings and fix plan for free during an active campaign. Behavior: records the submitted email as a lead and issues a 24h report token (not read-only). Returns { token, expires_at, report_url }. Only works while a free campaign is active (otherwise returns 403 — use create_checkout_handoff instead). Call this only when get_scan shows access.campaign; then re-poll get_scan or call generate_fix_plan with the returned token.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address used to unlock the free report; captured as a lead. Any valid email works during the campaign — it need not match the scanned domain. | ||
| scanId | Yes | The completed scan to unlock. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond annotations: 'records the submitted email as a lead and issues a 24h report token (not read-only).' It also describes the return structure and error condition. Annotations already show readOnlyHint=false, consistent with the description. Minor missing details about rate limits or full side effects, but sufficient for understanding.
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 with two sentences covering purpose, behavior, return, and usage instructions. Every sentence contributes essential information without redundancy. It is front-loaded with the main action.
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 no output schema, the description explains the return values (token, expires_at, report_url) and the prerequisite condition (get_scan shows access.campaign). It also provides next steps. This is complete for the tool's complexity with 2 required parameters and clear 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 coverage is 100% with detailed descriptions. The description adds extra semantic value, such as the email being captured as a lead and that any valid email works regardless of domain. This goes beyond the schema's basic parameter descriptions.
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 'Unlock a completed scan's full findings and fix plan for free during an active campaign.' It uses a specific verb and resource, and distinguishes from sibling tools by mentioning the alternative 'create_checkout_handoff' when the campaign is inactive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this only when get_scan shows access.campaign; then re-poll get_scan or call generate_fix_plan with the returned token.' It also specifies when not to use: 'Only works while a free campaign is active (otherwise returns 403 — use create_checkout_handoff instead).' This gives clear context and alternatives.
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.0compare_scan_history8 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / againstScanId / descriptionPrevious value: -"Older scan ID to compare against."New value: +"The earlier scan to compare against (the 'before'). Must be the same domain."Input schema / properties / againstScanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / againstScanId / titleAdded value: +"Older scan ID"Input schema / properties / scanId / descriptionPrevious value: -"Newer scan ID."New value: +"The more recent scan (the 'after')."Input schema / properties / scanId / examplesAdded value: +[
+ "f3fda7a1-04f2-498e-b7c9-0c20a4974937"
+]Input schema / properties / scanId / titleAdded value: +"Newer scan ID"Input schema / properties / token / titleAdded value: +"Report token"create_checkout_handoff7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / planId / descriptionAdded value: +"Plan to purchase: full-report (one-time unlock of this report), continuous (monthly, one domain), or portfolio (monthly, multiple domains). See get_pricing."Input schema / properties / planId / examplesAdded value: +[
+ "full-report"
+]Input schema / properties / planId / titleAdded value: +"Plan"Input schema / properties / scanId / descriptionAdded value: +"The completed scan the purchase unlocks."Input schema / properties / scanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / scanId / titleAdded value: +"Scan ID"export_scan_markdown7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / scanId / descriptionAdded value: +"The completed scan to export."Input schema / properties / scanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / scanId / titleAdded value: +"Scan ID"Input schema / properties / template / descriptionAdded value: +"cursor = agent fix prompt, github = issue body, executive = stakeholder summary."Input schema / properties / template / titleAdded value: +"Template"Input schema / properties / token / titleAdded value: +"Report token"generate_fix_plan12 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / format / descriptionAdded value: +"json for structured steps, markdown for a ready-to-paste plan."Input schema / properties / format / titleAdded value: +"Output format"Input schema / properties / layersAdded value: +{
+ "description": "Optional subset of layers to include. Omit for all layers.",
+ "examples": [
+ [
+ "security",
+ "legal"
+ ]
+ ],
+ "items": {
+ "enum": [
+ "security",
+ "seo",
+ "accessibility",
+ "legal",
+ "sustainability"
+ ],
+ "type": "string"
+ },
+ "title": "Layers",
+ "type": "array"
+}Input schema / properties / maxFindings / defaultAdded value: +5Input schema / properties / maxFindings / descriptionAdded value: +"Cap on the number of findings turned into fix steps."Input schema / properties / maxFindings / titleAdded value: +"Max findings"Input schema / properties / scanId / descriptionAdded value: +"The completed scan to build a plan from."Input schema / properties / scanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / scanId / titleAdded value: +"Scan ID"Input schema / properties / token / descriptionPrevious value: -"Optional report token (from unlock_report or a paid unlock) for full exports."New value: +"Optional report token (from unlock_report or a paid unlock) for full plans."Input schema / properties / token / titleAdded value: +"Report token"get_pricing1 field changedInput schema / additionalPropertiesAdded value: +falseget_scan5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / scanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / scanId / titleAdded value: +"Scan ID"Input schema / properties / token / descriptionPrevious value: -"Optional report token (from unlock_report or a paid unlock) for full findings."New value: +"Optional report token (from unlock_report or a paid unlock) that upgrades a teaser response to full findings."Input schema / properties / token / titleAdded value: +"Report token"list_checks4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / layer / descriptionPrevious value: -"Optional scan layer to focus on."New value: +"Optional layer to focus on. Omit to list every layer."Input schema / properties / layer / examplesAdded value: +[
+ "security"
+]Input schema / properties / layer / titleAdded value: +"Scan layer"start_scan6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / url / descriptionPrevious value: -"The public http or https URL to scan."New value: +"Public http(s) URL to scan, including the scheme. Must be a reachable public site — IP literals, localhost/private ranges, and major-provider domains (google.com, etc.) are rejected."Input schema / properties / url / examplesPrevious value: -[
- "https://www.rgate.io"
-]New value: +[
+ "https://example.com",
+ "https://www.rgate.io"
+]Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / patternAdded value: +"^https?://"Input schema / properties / url / titleAdded value: +"Target URL"unlock_report8 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / email / descriptionPrevious value: -"Email address used to unlock the free report. Captured as a lead."New value: +"Email address used to unlock the free report; captured as a lead. Any valid email works during the campaign — it need not match the scanned domain."Input schema / properties / email / examplesAdded value: +[
+ "dev@example.com"
+]Input schema / properties / email / formatAdded value: +"email"Input schema / properties / email / titleAdded value: +"Email (lead)"Input schema / properties / scanId / descriptionAdded value: +"The completed scan to unlock."Input schema / properties / scanId / examplesAdded value: +[
+ "cf11efd5-3878-40ae-b409-8d9ca3973227"
+]Input schema / properties / scanId / titleAdded value: +"Scan ID"v0.1.0compare_scan_historycreate_checkout_handoffexport_scan_markdowngenerate_fix_planget_pricingget_scanlist_checksstart_scanunlock_reportEach tool has a distinct function: starting scans, polling results, comparing histories, exporting reports, generating fix plans, handling pricing and unlocks, and listing checks. No two tools overlap in purpose; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in lowercase snake_case. Verbs like start, get, create, export, generate, compare, list, unlock are all imperative and paired with specific nouns.
With 9 tools, the server covers the core scanning lifecycle without being bloated. Each tool serves a necessary role in the workflow: initiating, monitoring, analyzing, and monetizing scans.
The tool set covers the full scan workflow: start, poll, compare, export, fix generation, and payment. A minor gap is the lack of a tool to list or manage historical scans, but the core use cases are well supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Public-site SEO/AEO readiness scans with evidence scores, issues, and clear measurement scope.
Free no-account URL security scan: 0-100 Launch Readiness score for any live site in ~15 seconds.
Rule-based site audits: accessibility, SEO, security headers, performance. Metered per call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/marcoldenburg/rgate-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
