Checks how a URL will appear when shared in Discord, validating Open Graph and Twitter Card metadata and preview image requirements to prevent broken or missing link previews.
Checks how a URL will appear when shared in iMessage, validating Open Graph metadata and preview image requirements to prevent broken or missing link previews.
Checks how a URL will appear when shared in Slack, validating Open Graph and Twitter Card metadata and preview image requirements to prevent broken or missing link previews.
Click on "Deploy 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., "@golive-mcp check https://mysite.com before I share it on LinkedIn"
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.
Check a site before you share the link.
You deploy, paste the link into LinkedIn, and get a grey box with no image. Or someone refreshes /pricing and gets a Vercel 404. golive catches both before anyone sees them, plus the staging noindex you forgot and the Vite logo still sitting in the tab.
It runs as an MCP server, so Claude, Cursor or any MCP client can check a URL after deploying and fix what it finds. It also runs as a plain CLI. No API key, no account.
This is a React app straight out of npm create vite, built, and served by a host with no SPA fallback. Real output, trimmed:
$ npx golive-mcp check http://localhost:4791 /about
Not ready: 2 blocking, 10 to look at, 4 fine.
## Link previews
✗ og:image: No preview image. On LinkedIn, X and iMessage the link becomes a plain grey text card.
Fix: Add a 1200x630 image: <meta property="og:image" content="https://yoursite.com/og.png">
! og:title: Missing. Platforms fall back to the <title> ("demo"), which is often not what you want shared.
! twitter:card: Missing. X reads your og: tags but only shows a small thumbnail without this.
## How the link will look
LinkedIn: [no image] / demo / localhost:4791
X: small square thumbnail (no twitter:card tag) / demo / localhost:4791
Slack: localhost:4791 / demo / (none) / [no image]
## Routes
✗ link /about: Opening /about directly returns 404. It works when clicked inside the app,
but breaks on refresh, bookmark or share.
Fix: Configure the host to serve index.html for unknown paths, so the client router can take over.On Vercel the fix line names the exact vercel.json rewrite. On Netlify it names the _redirects line.
Related MCP server: RGate MCP
Claude Code
claude mcp add golive -- npx -y golive-mcpClaude Desktop, Cursor, Windsurf (add to the MCP config file)
{
"mcpServers": {
"golive": { "command": "npx", "args": ["-y", "golive-mcp"] }
}
}No MCP client
npx golive-mcp check yoursite.com
npx golive-mcp check localhost:5173 /about /pricingThe CLI exits with code 1 when anything is blocking, so it drops into CI as a pre-launch gate.
Then ask your assistant something like "I just deployed, check https://mysite.com before I post it" and it will run the checks and fix the findings in your code.
Tool | What it checks |
| Everything below in one pass, with a verdict |
| og and Twitter card tags, and whether the image loads, is a raster format, is about 1200x630 and is under 5 MB. Shows how the card will look on LinkedIn, X, Slack, iMessage and Discord, and returns the image itself so the model can look at it |
| Opens internal links directly, the way a refresh or a shared link does. Catches the SPA 404 and soft 404s |
| Template titles, the Vite favicon, noindex or |
| HTTPS and the http redirect, HSTS, nosniff, clickjacking protection, CSP, Referrer-Policy, X-Powered-By |
Every tool takes a url. golive and check_routes also take paths, a list of routes to open directly. Client-rendered apps have no links in their HTML, so pass your real routes to test them.
The platform mockups are text, not screenshots. Titles get cut by pixel width, so the cut-off points are a guide.
golive reads the HTML your server sends. It does not run JavaScript, which is also what LinkedIn, Slack and the other scrapers do, so a tag that only appears after React renders is a tag they never see.
It can check localhost, which is the point: run it before you deploy. It only speaks http and https, caps every response at 5 MB and times out after 10 seconds.
Text quoted from the page (titles, header values) is truncated before it reaches the model, which limits how much a hostile page can inject into your assistant's context.
npm install
npm test # 28 tests against local fixture servers
npm run build
node dist/index.js check example.comMIT
Check the things that get forgotten at launch: template titles like 'Vite + React', the Vite favicon, missing meta description, viewport and lang, apple-touch-icon, noindex or robots.txt left on from staging, and mixed content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check: a live URL, a preview deployment, or a local dev server like http://localhost:5173 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Check' clearly implies a read-only, non-mutating operation, and the description discloses what is inspected. However, it does not describe the return behavior, such as whether it reports a pass/fail list or throws on mixed content, which would add 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 a single front-loaded sentence that immediately states the purpose and uses a compact list of concrete examples. Every phrase earns its place, and the examples make the scope vivid without padding.
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 only one fully documented parameter and no output schema, the description is largely complete for selecting and invoking the tool. It clearly defines what the tool checks, though it stops short of describing the result format, which is a minor gap in the absence of 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 the schema already fully documents the url parameter, including acceptable values like a live URL, preview deployment, or localhost. The description adds no additional parameter semantics beyond what the schema provides, matching the baseline of 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 states a specific verb ('Check') and a clearly scoped resource ('the things that get forgotten at launch'), then enumerates concrete examples such as the Vite favicon, missing meta description, and robots.txt. This itemized scope distinguishes it from sibling tools like check_security_headers or check_routes without needing to name them.
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 phrase 'at launch' gives clear contextual timing for when this tool is relevant, and the list of checks implies this is the go-to tool for common launch oversights. It does not explicitly name alternatives or say when not to use it, but the context is strong enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the Open Graph and Twitter card tags on a URL and show how the link will look on LinkedIn, X, Slack, iMessage and Discord. Loads the og:image and checks it is reachable, a raster format, about 1200x630, and under platform size limits. Returns the image so you can see it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check: a live URL, a preview deployment, or a local dev server like http://localhost:5173 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool fetches the URL, loads og:image, verifies reachability, raster format, approximate dimensions, and platform size limits, and returns the image. This goes beyond a generic 'checks the link' and gives the agent a clear picture of what happens and what the output is.
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 compact and front-loaded: primary purpose first, then the specific checks performed, then the output. Every sentence contributes useful information and there is no redundancy or filler.
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 single-parameter tool with no output schema, the description explains the return value ('Returns the image so you can see it') and the core behavior well. It does not mention failure modes or error handling, but the information provided is sufficient for an agent to invoke the tool correctly and interpret its primary result.
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% and the 'url' parameter is already well documented in the schema, including live URLs, preview deployments, and localhost. The description adds only general context ('on a URL') without adding parameter-level meaning beyond the schema, so the baseline 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 names a specific verb ('Check') and a specific resource ('Open Graph and Twitter card tags on a URL'), then adds concrete detail about rendering on named platforms. This clearly distinguishes it from sibling tools like check_security_headers and check_routes without needing to open their schemas.
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 makes the usage context clear: use this when you need to inspect social sharing tags or preview how a link appears on LinkedIn, X, Slack, iMessage, and Discord. It does not explicitly state when not to use it or name alternatives, but the platform-specific preview behavior is sufficient contextual guidance for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a site's internal links directly, the way a refresh, bookmark or shared link does. Catches the single-page-app 404 (works when clicked, breaks on refresh) and names the host-specific fix, e.g. the vercel.json rewrite. Also checks that made-up URLs return a real 404.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check: a live URL, a preview deployment, or a local dev server like http://localhost:5173 | |
| paths | No | Extra paths to open directly, e.g. ["/about", "/pricing"]. Use this for client-rendered apps whose links are not in the HTML. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool opens links, detects SPA refresh failures, names host-specific fixes, and validates 404 behavior. This is meaningful beyond what the schema shows, though it does not detail output formatting or side effects.
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 dense but efficient, front-loading the core purpose in the opening sentence and adding valuable capabilities without fluff. Every clause contributes useful 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?
For a two-parameter tool with fully documented schema and no output schema, the description gives enough context for an agent to select and invoke it correctly. It could more explicitly state what output format to expect, but the behavioral purpose is well 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific detail beyond the schema, which already explains URL, live/preview/local usage, and optional extra paths for client-rendered apps.
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 specific verbs and objects: it opens internal links directly, catches single-page-app 404s, names host-specific fixes, and checks that made-up URLs return real 404s. This clearly distinguishes check_routes from generic link/preview-related sibling tools.
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 strong context: use this when needing to verify that internal routes survive refresh, bookmarks, or shared links, especially for SPAs. It does not explicitly name alternatives or when-not-to-use scenarios, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check HTTPS, the http to https redirect, HSTS, nosniff, clickjacking protection, CSP, Referrer-Policy and X-Powered-By on a URL, each with the header to add.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check: a live URL, a preview deployment, or a local dev server like http://localhost:5173 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clarifies that the tool performs multiple checks and returns the header to add for each, which is useful. But it does not disclose whether it makes live network requests, whether it is read-only, or what happens when a URL is unreachable or returns non-HTTP responses.
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 one tight, front-loaded sentence that lists the checks and the output nature ('each with the header to add') without any filler. Every part 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?
For a single-parameter tool with no output schema, the description is largely complete: it names the input, the full set of checks, and the nature of the output. It could be more explicit about the result format or failure behavior, but those are minor gaps given the tool's simplicity.
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 already documents the single url parameter at 100% coverage, including examples like localhost dev servers. The description adds little beyond 'on a URL', so the baseline 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 uses a specific verb ('Check') and a precise resource/scope: security headers on a URL, enumerating HTTPS, redirect, HSTS, nosniff, clickjacking, CSP, Referrer-Policy, and X-Powered-By. It also notes the output includes the header to add, which distinguishes it clearly from sibling checks like check_routes or check_link_preview.
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 intended use is implied: call this tool when you need to evaluate a URL's security headers and get recommended remediation headers. However, it does not explicitly state when to prefer this over check_basics or other sibling tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run every check on a URL before it gets shared or launched: how the link preview will look on LinkedIn, X, Slack, iMessage and Discord (and whether the image loads, is the right size, and is not an SVG), sub-pages that 404 on refresh, noindex or robots.txt left on from staging, template titles and Vite favicons, missing security headers, and http that does not redirect. Returns findings with fixes, text mockups of each platform's card, and the preview image itself. Use it after deploying, before posting a link, or on localhost before pushing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to check: a live URL, a preview deployment, or a local dev server like http://localhost:5173 | |
| paths | No | Extra paths to open directly, e.g. ["/about", "/pricing"]. Use this for client-rendered apps whose links are not in the HTML. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses what the tool checks, the return artifacts (findings with fixes, platform card mockups, preview image), and the broad execution scope. It does not mention potential side effects like external fetches or rate limits, but the behavior is a read-only audit and is well described.
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 dense but organized: it opens with the general purpose, follows with a colon-delimited list of checks, then covers return values and usage timing. There is minimal filler, though the single long sentence could arguably be broken up for easier scanning.
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 and lack of an output schema, the description covers the check categories, return format, and practical use cases. The optional paths parameter is only documented in the schema, but that is acceptable since the schema already provides examples and constraints.
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 already documents both url and paths with examples and constraints. The description reinforces the live/preview/localhost use cases but adds little parameter meaning beyond what the schema provides, which matches the 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 states a clear verb-resource pair ('Run every check on a URL') and lists the concrete coverage areas: link previews, 404 sub-pages, noindex/robots.txt, titles/favicons, security headers, and redirects. This makes it easy to distinguish from the narrower sibling tools like check_security_headers or check_link_preview.
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 gives explicit positive triggers: 'Use it after deploying, before posting a link, or on localhost before pushing.' It does not explicitly say when NOT to use it or name the sibling alternatives, but the 'every check' framing makes the intended all-in-one context clear.
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.
v1.0.1check_basicscheck_link_previewcheck_routescheck_security_headersgoliveScored across 5 tools
Each granular tool has a distinct, well-defined purpose (preview, headers, routes, basics), but the aggregate 'golive' tool intentionally overlaps with all of them, which could cause an agent to call the umbrella tool when only a specific check is needed. The descriptions make the distinction clear, so misselection is unlikely but possible.
Four of the five tools follow a consistent 'check_*' verb-noun pattern (check_link_preview, check_security_headers, etc.), but the primary tool breaks the pattern with the single word 'golive'. This is a minor deviation that fits the umbrella tool's purpose, not a chaotic mix of styles.
Five tools is an ideal size for a URL-checking server: one aggregate entry point plus four focused diagnostic tools. Every tool has a clear reason to exist, and there's no bloat or thinness.
The tool set covers the core pre-launch concerns: social link previews, security headers, SPA route 404s, and common template/meta oversights. The 'golive' aggregate ensures no dead ends by running everything at once. Minor gaps like performance or accessibility checks exist, but they fall outside the apparent scope.
Read, screenshot, diff, verify and audit any URL: SEO, links, sitemaps, schema, a11y.
Social cards and OG images from designed templates: card from a URL, presets, meta tags, link checks
Free no-account URL security scan: 0-100 Launch Readiness score for any live site in ~15 seconds.
Live web checks for AI agents: sitemaps, robots.txt, URL status, broken links, feeds, citations.
