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., "@CheckMyLaunch MCP server scan my GitHub repo for launch issues"
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.
Lets an AI coding tool (Claude Code, Claude Desktop, Cursor, etc.) run a CheckMyLaunch scan and read back findings + repair prompts without leaving the chat.
This is a paid feature. Every tool call is gated behind a CheckMyLaunch API key from a paid account (one-time Launch Check purchase or the Continuous Guard subscription) — get one at checkmylaunch.com/account after signing in and upgrading. Without a valid key configured, every tool refuses with a message pointing you there instead of running.
scan_repo { repoUrl } — scans a public GitHub repo.
scan_url { url } — scans a live site.
get_repair_prompt { scanId, findingId } — fetches the paste-back fix
prompt for one finding.
Related MCP server: Sekrd Security Scanner
Sign in at checkmylaunch.com, upgrade to a paid plan, then go to your account page and generate an API key.
Add this to your MCP client's config:
{
"mcpServers": {
"checkmylaunch": {
"command": "npx",
"args": ["github:matdtools-code/checkmylaunch-mcp"],
"env": { "CHECKMYLAUNCH_API_KEY": "cml_live_..." }
}
}
}Claude Code: claude mcp add or edit .claude/mcp.json /
~/.claude.json. Claude Desktop / Cursor: same JSON shape in their
respective MCP config files.
npm install
CHECKMYLAUNCH_API_KEY=cml_live_... node test/smoke.jsCHECKMYLAUNCH_API_KEY — required. From your CheckMyLaunch account page.
CHECKMYLAUNCH_API_URL — override the API base URL (defaults to
https://www.checkmylaunch.com); useful for pointing at localhost:8899
during development.
Every tool call first verifies the key against GET /api/auth/api-key on
the CheckMyLaunch server, which only resolves for a signed-in, paid account
(see server/src/routes/auth.js in the main app repo). A missing, invalid,
or free-plan key stops the call before any scan runs.
This doesn't (and can't) prevent someone from calling CheckMyLaunch's public
/api/scan/public-github / /api/scan/url endpoints directly without this
plugin — those intentionally stay open, capped at a small free weekly quota
with truncated findings, as the website's own no-signup teaser. What the key
unlocks is the difference that actually matters for real use: uncapped
findings and no weekly quota, from inside your coding tool.
Get a ready-to-use repair prompt for one finding from a previous scan_repo or scan_url result. The returned prompt is safe to run as-is in a coding tool: it names the exact fix, forbids unrelated changes, and never deploys or rotates secrets automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| scanId | Yes | The scanId from a scan_repo/scan_url result | |
| findingId | Yes | The findingId of the specific finding to fix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behaviors: the prompt is safe, no auto-deploy, no secret rotation. Adequate for a read/get operation.
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: first states purpose and context, second describes output characteristics. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with 2 params, no output schema, no annotations, the description fully explains purpose, context, and output safety. 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 has 100% coverage. Description adds context that scanId comes from a previous scan result, adding value beyond the schema 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 the verb 'get', the resource 'repair prompt for one finding', and the context 'from a previous scan_repo or scan_url result'. It distinguishes from sibling tools by specifying it operates on their results.
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 explains the output is safe to run as-is, naming exact fix and forbidding unrelated changes. While it doesn't explicitly state when not to use, the context of previous scans is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a CheckMyLaunch readiness scan on a public GitHub repository. Finds exposed secrets, security risks, deployment problems and launch blockers, and returns a readiness score plus a findings list. Use this after making changes to a project to check it is safe to ship. Only works on public repos reachable at github.com// — private repos need the signed-in flow at checkmylaunch.com.
| Name | Required | Description | Default |
|---|---|---|---|
| repoUrl | Yes | Public GitHub repo URL, e.g. https://github.com/owner/repo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers the tool's behavior: it scans, returns readiness score and findings list, and lists checked categories. It does not mention potential side effects or limitations like rate limits, but the described behavior is complete for a read-only scan tool.
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 convey purpose, outputs, usage guidance, and constraint. No redundant information; every sentence adds value.
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 single parameter, no output schema (output described in text), and related sibling tools, the description fully covers what the tool does, its prerequisites, and its output, providing complete contextual 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?
The single parameter (repoUrl) is described in the schema (100% coverage), and the tool description adds extra context on format (github.com/<owner>/<repo>) and example URL, enhancing understanding 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 clearly identifies the tool as running a CheckMyLaunch readiness scan on a public GitHub repository, listing specific findings (secrets, risks, deployment problems) and outputs (score and findings list). It distinguishes from siblings (scan_url for generic URLs, get_repair_prompt for repair prompts) by specifying the GitHub repo context.
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 advises when to use ('after making changes to check safe to ship') and when not ('private repos need signed-in flow'), providing clear usage context and an alternative for private repos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a CheckMyLaunch readiness scan on a live website URL. Checks security headers, cookie flags, TLS, exposed sensitive paths, mixed content, broken links and metadata, and returns a readiness score plus a findings list. Use this to check a deployed site before announcing a launch.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The live site to scan, e.g. https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details what the scan checks (security headers, TLS, etc.) and what it returns (readiness score, findings list), implying a read-only operation. Missing details on rate limits or authentication, but still fairly transparent.
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-loading the purpose and checks, then providing usage context. Every sentence is informative with 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?
Given the simple tool (one parameter, no output schema), the description fully explains the tool's function, return values, and intended use case, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'url' is well-described in the schema as 'The live site to scan, e.g. https://example.com' and the description adds context about usage. With 100% schema coverage, the description adds value 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 clearly states the tool performs a readiness scan on a live website URL, listing specific checks. It is distinct from siblings (scan_repo, get_repair_prompt) by focusing on URL scanning.
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 recommends using this tool 'to check a deployed site before announcing a launch,' providing clear context. It does not mention when not to use it, but the guidance is sufficient.
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.
v0.1.0get_repair_promptscan_reposcan_urlEach tool has a distinct purpose: scan_repo scans a repository, scan_url scans a live URL, and get_repair_prompt provides repair instructions. No overlap.
All tools follow a consistent verb_noun snake_case pattern: scan_repo, scan_url, get_repair_prompt. Highly predictable.
Three tools is a reasonable minimal set for a security scanning server. While it could be expanded, the count is appropriate for the core functionality.
The set covers scanning code (repo) and live sites (URL), plus remediation (repair prompt). A minor gap is lack of result listing or management, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Scan a web page for accessibility, security, privacy, quality and SEO issues, with fixes.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
Scan any website for AI agent readiness, payment protocols, and discovery endpoints
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matdtools-code/checkmylaunch-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
