Skip to main content
Glama
@genready/mcp-server

@genready/mcp-server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GENREADY_API_KEYYesYour GenReady API key (starts with `gr_live_`). Required for the stdio server.
GENREADY_MCP_URLNoHosted MCP endpoint. Defaults to `https://genready.ai/mcp`.https://genready.ai/mcp

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
analyze_websiteA

Scan one URL for readiness to be cited by AI search engines (ChatGPT, Perplexity, Google AI Overviews) and used by AI agents. Returns scores and the fix checklist: prioritized problems with concrete fixes. Uses one API credit per call, so re-scan only after deploying a change. scope='content' or 'crawlability' runs a narrower, faster scan.

get_reportA

Read a stored page report by report ID: the scores and the prioritized fix checklist, with a note on any fixes locked on the account's plan. Use it when you already have a report ID (from analyze_website, check_status or list_reports). It reads saved data and never rescans, so it shows the page as it was when scanned; call analyze_website to see changes. Returns an error if the ID is unknown or belongs to another account. Free: does not use a credit.

get_findingsA

Findings are the fix list keyed by rule: each carries a stable id that survives re-scans, a policy saying whether an agent may apply the fix unattended ('apply') or should only propose it, and whether a fix can be confirmed by one cheap fetch. Pass exactly one of report_id (the findings of one page) or domain_id (the findings of the latest site analysis), otherwise it returns an error. Use get_report instead if you only need scores. Pass the ids it returns to verify_findings, update_finding and get_artifact. Read-only. Free: does not use a credit.

verify_findingsA

Re-check findings after deploying a fix. Fetches the live page once per check, with no analysis and no credit, and answers verified, still_failing or unverifiable per finding. Use this instead of re-running analyze_website. Pass exactly one of report_id, domain_id or site_analysis_id, and optionally the finding ids to check. Included with Pro and Agency.

get_artifactA

Generate a file that fixes a deterministic finding: 'robots_txt' (unblocks AI crawlers while leaving other rules alone), 'llms_txt' (lists the site's real pages) or 'jsonld' (a script block for one page). Anything we did not measure comes back as TODO rather than a guess, so check needsHumanInput before committing. Pass exactly one of report_id or domain_id. Free: does not use a credit.

update_findingA

Remember a decision so a later session does not redo it. 'fixed_pending' means you changed something and it is not deployed or confirmed yet; 'ignored' silences a finding and requires a reason; 'open' undoes either. You cannot set 'verified': that is earned by calling verify_findings against the live site. Free: does not use a credit.

start_site_analysisA

Start a site-wide analysis and let it pick its own pages: the homepage first, then the sections covering the most pages, since a template problem there repeats across the site. Spends one credit per page scanned, so it can cost a lot at once; the plan cap and the credits left both apply and the smaller wins. When connected through OAuth (for example from Claude), a run scans at most 25 pages unless you pass max_pages. Returns immediately. Over an API key it requires the Start site analyses (site:analyze) scope.

check_statusA

Check the progress of one page scan by report ID. Returns its status (queued, processing, complete or failed), a progress percentage when known, and which tool to call next. Use it when analyze_website returned a report ID before the scan finished, or after you started a scan with wait=false. Poll every few seconds, not in a tight loop. For a whole-site run started with start_site_analysis, call get_fix_plan instead. Returns an error if the report ID is unknown. Read-only. Free: does not use a credit.

list_reportsA

List the page reports this account has generated, newest first. Each entry has the report ID, URL, overall score, status and creation time. Use it to find a report ID for get_report or get_findings, or to see which pages were already scanned before spending a credit on analyze_website. Filter by URL or status; results come in pages of up to 100, so check the page count at the top of the output and request the next page for more. Read-only. Free: does not use a credit. Returns 'No reports found.' when nothing matches.

get_usageA

Check the plan, API credits used and remaining, and the billing period. Call before a batch of scans.

list_domainsA

List the account's monitored domains and their IDs, for use with get_fix_plan. Requires an API key with the domain:read scope.

get_fix_planA

Read the ranked, site-wide fix plan from a domain's latest site analysis: each action says how many pages it affects, how to fix it, and which URLs to verify on. Pass exactly one of domain_id (latest run) or site_analysis_id (a specific run). Free: does not use a credit. Requires the domain:read scope.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 12 tools

Disambiguation4/5

Most tools have clearly distinct roles: scanning (analyze_website, start_site_analysis), reading (get_report, get_findings, get_fix_plan), and lifecycle (update_finding, verify_findings, get_artifact). The get_report/get_findings/get_fix_plan trio overlaps somewhat, but descriptions explicitly steer ('use get_report instead if you only need scores'), and the page-vs-site distinction is stated.

Naming Consistency5/5

All twelve tools use consistent snake_case verb_noun form (get_usage, list_reports, check_status, start_site_analysis, verify_findings). No mixing of camelCase or vague single-verb names.

Tool Count5/5

Twelve tools falls squarely in the well-scoped 3-15 range, and each maps to a distinct step in the scan-fix-verify workflow. No redundant or filler tools.

Completeness4/5

The surface covers the full workflow: credit check, single/site scanning, status polling, report and findings reads, artifact generation, finding state updates, and post-deploy verification. Minor gaps exist around domain management (only list_domains, no add/remove) and report cleanup, but core CRUD/lifecycle is covered.

Maintenance

ActivityNo data
ResponsivenessSyncing