Rendex: Rendering API for Images, PDFs & Content Extraction
Server Details
Render HTML, Markdown, or any URL to images or PDF, plus reader-mode extraction. MCP-native.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- copperline-labs/rendex-mcp
- GitHub Stars
- 6
- Server Listing
- rendex-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 13 of 13 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose. The rendering tools (screenshot, artifact, hosted link) are explicitly differentiated, and watch tools form a separate coherent set. Descriptions include explicit do/don't instructions to prevent confusion.
Most tools follow the 'rendex_' prefix, and watch tools consistently use 'watch_'. However, 'render_artifact' breaks the pattern by using 'render_' instead of 'rendex_', creating a minor inconsistency.
13 tools cover rendering, extraction, account management, and webpage monitoring. The count is well-scoped for the server's purpose, with no unnecessary tools.
The tool set covers the full lifecycle: rendering (multiple output types), content extraction, account info, and complete watch management (CRUD, run, test, history). No obvious gaps for the stated domain.
Available Tools
13 toolsrender_artifactRender Branded Artifact (PDF + PNG)ARead-onlyInspect
Use this when the user asks to make or create a branded report, invoice, summary, release notes, or document — or to 'turn this Markdown/HTML into a PDF and PNG' (optionally with a logo or accent color). Do NOT use to screenshot an existing URL (use rendex_screenshot). Turns Markdown or HTML into a branded, downloadable artifact — a PDF, a PNG, and a hosted share page — in one call. Apply a logo, accentColor, font, header, and footer. Returns hosted URLs { pdfUrl, pngUrl, shareUrl, expiresAt }. Each requested format costs 1 render credit.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Optional Mustache data. When present, content is rendered as a logic-less Mustache template (plus the branding fields as {{logo}}/{{header}}/...) before conversion. | |
| font | No | CSS font-family stack for the body (e.g. 'Georgia, serif'). | |
| logo | No | Absolute http(s) URL of a logo image shown in the header. | |
| footer | No | Plain-text footer line shown at the bottom. | |
| header | No | Plain-text header line shown beside the logo. | |
| content | Yes | The Markdown or HTML body to render (up to ~4MB). | |
| formats | No | Which formats to produce. Each costs 1 credit. Default both. | |
| expiresIn | No | Seconds until the hosted URLs expire (3600-2592000). Default 86400 (24h). | |
| pageSetup | No | Optional paper/viewport setup. | |
| accentColor | No | CSS accent color for the bar, links, and headings (e.g. '#EA580C'). | |
| inputFormat | No | How to interpret content. 'markdown' is converted to styled HTML; 'html' is used as a body fragment. | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a creation action (mutating), but annotations declare readOnlyHint: true, which suggests no state changes. This contradiction reduces transparency. The description itself is otherwise clear about behavior, but the annotation conflict is a significant issue.
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 (5 sentences), front-loads the primary use case, and wastes no words. Every sentence adds essential information: purpose, alternatives, return structure, cost.
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 (11 params, nested pageSetup, no output schema), the description adequately covers return values (pdfUrl, pngUrl, shareUrl, expiresAt) and cost. Missing details about error handling or pagination, but overall sufficient for basic invocation.
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 covers all 11 parameters with descriptions (100% coverage). The description adds value by explaining that the 'data' parameter enables Mustache templating and that branding fields are exposed as template variables. This goes beyond the schema's basic 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 tool creates branded artifacts from Markdown/HTML (PDF, PNG, share page), listing use cases like reports, invoices, summaries. It explicitly distinguishes from rendex_screenshot, avoiding confusion.
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 (user requests creation of branded documents) and when not to (existing URLs, pointing to rendex_screenshot). Also mentions credit cost per format, guiding resource-aware usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_accountCheck Plan & UsageARead-onlyIdempotentInspect
Check the Rendex account: which plan it's on, how many render credits have been used vs. the monthly limit (and when it resets), the per-minute rate limit, and a one-tap link to upgrade to a higher tier. Use this whenever the user asks about their usage, remaining quota, current plan, or how to get more renders / stop hitting limits. Read-only — costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the annotations by stating 'Read-only — costs no credits.' It also adds behavioral detail: the tool provides a 'one-tap link to upgrade,' which is not covered by annotations. 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 sentences, front-loaded with the action and key information. Every sentence adds value: the first enumerates outputs, the second provides usage guidance and reads/credits cost. 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?
Given zero parameters and no output schema, the description covers all necessary context: what the tool does, what it returns, when to use it, and that it costs no credits. Complete for its 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?
Input schema has no parameters and 100% coverage, so baseline is 4 per rules. The description does not need to add parameter info but correctly implies no input is required.
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 clearly identifies the resource 'Rendex account'. It lists the exact information returned (plan, credits used, limit, reset, rate limit, upgrade link), which distinguishes it from sibling tools that deal with rendering, screenshots, or watches.
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 the tool: 'whenever the user asks about their usage, remaining quota, current plan, or how to get more renders / stop hitting limits.' This provides clear context and triggers, making it easy for the agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_extractExtract Reader-Mode ContentARead-onlyInspect
Use this when the user asks to read, extract, get the text/content/article of, or summarize a webpage/URL. Do NOT use for a visual screenshot (use rendex_screenshot). Extracts clean reader-mode content from any webpage as Markdown, JSON, or HTML. Runs the same Chromium render pass as a screenshot, so it captures content after JavaScript runs — handles SPAs that fetch-only readers miss. Strips nav, ads, and boilerplate, returning the article body plus title, byline, and excerpt. Great for feeding page content to an LLM, summarization, or RAG ingestion. Costs 1 render credit per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The webpage URL to extract readable content from (a schemeless host like 'example.com' is accepted). | |
| device | No | Device preset that sets viewport, scale factor, and user agent in one shot. E.g. 'iphone_15' to extract the mobile version of a page. | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before extraction | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| extractFormat | No | Output shape — markdown (default, LLM-friendly prose), json (structured fields: title/byline/excerpt/siteName/length), or html (cleaned reader-mode HTML). | markdown |
| hideSelectors | No | CSS selectors to hide (display:none) before extraction. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before extraction. A curated selector list, lighter than custom hideSelectors. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes execution behavior: same Chromium render pass as screenshot, captures JS, strips nav/ads/boilerplate, returns article body plus title/byline/excerpt. Annotations (readOnlyHint, nondestructive) are consistent and description adds context about render cost and credit.
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, well-structured, front-loaded with usage rule, then technical details, then cost. Every sentence adds value, no 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?
Despite 8 parameters and no output schema, description explains output format choices (markdown, json, html) and key metadata fields. Cost and rendering behavior are covered. Sufficient for an agent to use correctly.
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 baseline 3. Description adds no parameter-specific enrichment beyond schema, but it does contextualize the extractFormat option. No contradiction.
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?
Clear verb 'extract' with specific resource 'reader-mode content' and explicit use case: when user asks to read, extract, or summarize a webpage. Distinguishes from sibling rendex_screenshot.
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 (read/summarize webpage) and when not (visual screenshot, with sibling tool named). Also mentions suitability for LLM, summarization, RAG ingestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_render_linkMint Hosted Render URLARead-onlyInspect
Use this when the user wants a reusable, HOSTED image URL — an og:image or a link to embed in an tag — rather than the image bytes. Do NOT use for a one-off inline screenshot (use rendex_screenshot). Renders a URL, raw HTML, or Markdown and gives back a signed, hosted, edge-cached image URL instead of the bytes — ideal for dynamic OG images: drop the URL into or an tag and Rendex serves a cached copy on every share. Takes the same options as rendex_screenshot, plus an optional expiresIn. Returns { url, expiresAt, format, cacheTtl } as JSON. Costs 1 render credit per fresh render; cached repeat hits don't re-charge.
| Name | Required | Description | Default |
|---|---|---|---|
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| geo | No | ISO 3166-1 alpha-2 country code for geo-targeted capture (e.g., 'US', 'DE', 'JP'). Renders the page as seen from that country. Pro/Enterprise only. Note: CSS/JS injection, cookies, element capture, dark mode, and some other features are not available with geo-targeting. | |
| url | No | The webpage URL to capture (a schemeless host like 'example.com' is accepted). Mutually exclusive with 'html' and 'markdown'. | |
| data | No | Key-value data object for Mustache templating. When provided, the 'html' or 'markdown' string is rendered as a logic-less Mustache template before capture — {{var}} inserts HTML-escaped, {{{var}}} inserts raw, {{#items}}...{{/items}} iterates arrays, {{a.b}} accesses nested fields. Not valid with 'url'. Max 256KB serialized. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| width | No | Viewport width in pixels (320-3840) | |
| device | No | Device preset that sets viewport, scale factor, and user agent in one shot. E.g. 'iphone_15' for a mobile screenshot. Overrides width/height/deviceScaleFactor/userAgent. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| height | No | Viewport height in pixels (240-2160) | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before capture | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. | |
| markdown | No | Markdown to render to an image or PDF. Mutually exclusive with 'url' and 'html'. The server converts it to HTML before rendering. Great for reports, release notes, README snapshots, documentation cards. | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| selector | No | CSS selector of a specific element to capture instead of the full page. Useful for OG images, component extraction (e.g. '#hero', '.pricing-card') | |
| expiresIn | No | Seconds until the signed URL expires (60–2592000). Defaults to the server's TTL. | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| userAgent | No | Override the browser user agent string. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='pdf'. | |
| resizeHeight | No | Downscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF. | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true and destructiveHint: false; the description adds credit cost per fresh render and caching behavior. No contradictions. Slightly more detail on return fields would be nice, but sufficient.
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, efficient paragraph that front-loads the core purpose and usage guidelines. Every sentence adds value, no repetition.
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 38 parameters and no output schema, the description covers purpose, usage, sibling differentiation, output shape, and credit cost. It does not explain every parameter, but the schema handles that. Completeness is high.
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 description adds limited value beyond noting the extra expiresIn parameter and that it shares options with rendex_screenshot. This is acceptable for high-coverage schemas.
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 produces a hosted image URL for reuse (og:image, <img> tag), explicitly distinguishing from the sibling rendex_screenshot which returns bytes. It specifies the inputs (URL, HTML, Markdown) and the output format.
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 says when to use ('wants a reusable, HOSTED image URL') and when not to ('Do NOT use for a one-off inline screenshot'), and directs to the alternative (rendex_screenshot).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rendex_screenshotCapture Screenshot or PDFARead-onlyInspect
Use this when the user asks to screenshot, capture, or take a picture of a webpage/URL, or to render raw HTML or Markdown to an image or PDF. Do NOT use to get a reusable hosted image URL (use rendex_render_link) or to make a branded multi-format document (use render_artifact). Captures a screenshot or PDF of any webpage, raw HTML, or Markdown. Supports full-page capture, dark mode, ad blocking, custom viewports, CSS/JS injection, cookie/header injection, PDF output, HTML and Markdown rendering, and progressive fallback for heavy sites. Returns partial renders on timeout by default (bestAttempt mode). Costs 1 render credit per call. Cookie/header injection requires Starter+; geo-targeting requires Pro+.
| Name | Required | Description | Default |
|---|---|---|---|
| js | No | Custom JavaScript to execute in the page before capture. Runs in the browser sandbox. Max 50KB. | |
| css | No | Custom CSS to inject into the page before capture. Hide cookie banners, add watermarks, override styles. Max 50KB. | |
| geo | No | ISO 3166-1 alpha-2 country code for geo-targeted capture (e.g., 'US', 'DE', 'JP'). Renders the page as seen from that country. Pro/Enterprise only. Note: CSS/JS injection, cookies, element capture, dark mode, and some other features are not available with geo-targeting. | |
| url | No | The webpage URL to capture (a schemeless host like 'example.com' is accepted). Mutually exclusive with 'html' and 'markdown'. | |
| data | No | Key-value data object for Mustache templating. When provided, the 'html' or 'markdown' string is rendered as a logic-less Mustache template before capture — {{var}} inserts HTML-escaped, {{{var}}} inserts raw, {{#items}}...{{/items}} iterates arrays, {{a.b}} accesses nested fields. Not valid with 'url'. Max 256KB serialized. | |
| html | No | Raw HTML to render and capture. Mutually exclusive with 'url' and 'markdown'. Great for invoices, social cards, email templates, OG images. | |
| delay | No | Milliseconds to wait after page load before capture (useful for JS-rendered content) | |
| width | No | Viewport width in pixels (320-3840) | |
| device | No | Device preset that sets viewport, scale factor, and user agent in one shot. E.g. 'iphone_15' for a mobile screenshot. Overrides width/height/deviceScaleFactor/userAgent. | |
| format | No | Output format — png (lossless), jpeg (smaller), webp (smallest), or pdf (document). Use pdf for invoices, reports, archival. | png |
| height | No | Viewport height in pixels (240-2160) | |
| cookies | No | Cookies to set before capture. Useful for authenticated pages. Max 50 cookies. | |
| geoCity | No | City for more precise geo-targeting (e.g., 'Berlin', 'New York'). Requires 'geo'. | |
| headers | No | Custom HTTP headers to send with the page request. Cannot override Host, Connection, Content-Length, or Transfer-Encoding. | |
| quality | No | Image quality 1-100 (JPEG/WebP only, ignored for PNG/PDF) | |
| timeout | No | Maximum seconds to wait for page load (5-60). Cloudflare has a 60s hard cap. | |
| blockAds | No | Block ads and trackers before capture | |
| darkMode | No | Emulate dark color scheme (prefers-color-scheme: dark) | |
| fullPage | No | Capture the full scrollable page instead of just the viewport | |
| geoState | No | State or region for more precise geo-targeting (e.g., 'California'). Requires 'geo'. | |
| markdown | No | Markdown to render to an image or PDF. Mutually exclusive with 'url' and 'html'. The server converts it to HTML before rendering. Great for reports, release notes, README snapshots, documentation cards. | |
| pdfScale | No | PDF scale factor (0.1-2). Default: 1 | |
| selector | No | CSS selector of a specific element to capture instead of the full page. Useful for OG images, component extraction (e.g. '#hero', '.pricing-card') | |
| pdfFormat | No | PDF page size. Only used when format='pdf'. Default: A4 | |
| pdfMargin | No | PDF page margins. Only used when format='pdf'. Accepts CSS values. | |
| userAgent | No | Override the browser user agent string. | |
| waitUntil | No | Page readiness event. networkidle2 (default) is best for most sites. Use domcontentloaded for speed, networkidle0 for completeness. | networkidle2 |
| bestAttempt | No | If true (default), capture whatever is rendered on timeout instead of failing. Set to false to get a hard error on timeout. | |
| resizeWidth | No | Downscale the captured image to this width in pixels (16-3840). Aspect ratio is preserved if resizeHeight is omitted. Ignored for PDF. | |
| pdfLandscape | No | PDF landscape orientation. Only used when format='pdf'. | |
| resizeHeight | No | Downscale the captured image to this height in pixels (16-2160). Aspect ratio is preserved if resizeWidth is omitted. Ignored for PDF. | |
| hideSelectors | No | CSS selectors to hide (display:none) before capture. E.g. ['.modal', '#newsletter-popup'] to remove overlays. Max 50 selectors. | |
| waitForSelector | No | CSS selector to wait for before capture. Essential for SPAs (e.g. '.main-content', '#app-loaded') | |
| deviceScaleFactor | No | Device pixel ratio (1 = standard, 2 = retina). Defaults to 2× Retina. | |
| blockCookieBanners | No | Hide common cookie/consent walls (GDPR/CCPA banners) before capture. A curated selector list, lighter than custom hideSelectors. | |
| blockResourceTypes | No | Block specific resource types to speed up capture. E.g. ['font', 'image'] for text-only screenshots. | |
| pdfPrintBackground | No | Print background colors/images in PDF. Default: true |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, not destructive, not idempotent), the description adds behavioral details: returns partial renders on timeout (bestAttempt mode), supports progressive fallback, costs credits, and lists feature tiers. 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?
Description is a single paragraph but front-loaded with primary use case and exclusions. Could be more structured (e.g., bullet points for features) but remains concise given the breadth of information. Only necessary sentences included.
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 37 parameters and no output schema, the description explains core functionality, boundaries, and return behavior (partial renders on timeout). However, it does not explicitly describe the response format (e.g., image URL or data), which would be helpful for an agent. Still, it covers the essential context.
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% (all 37 parameters described in schema). The description provides general context but does not add meaningful detail beyond what the schema already provides per parameter. 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 starts with explicit use cases: screenshot, capture, render HTML/Markdown. It also distinguishes from sibling tools (rendex_render_link, render_artifact) by specifying what not to use it for. Clear verb+resource+scope.
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 (screenshot, capture, render) and when not to use (reusable hosted image, branded document) with alternative tool names. Also mentions cost (1 render credit) and feature prerequisites (Starter+ for cookies/headers, Pro+ for geo).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_createCreate WatchAInspect
Use this when the user asks to monitor, watch, or track a webpage for changes, or to be alerted/notified when a page changes. Do NOT use for a one-time capture (use rendex_screenshot). Creates a Rendex Watch — monitors a URL on a schedule and notifies when it changes (real-Chrome visual diff with a highlighted overlay, an extracted-text diff, or both). An active watch captures its baseline immediately. Returns the created watch as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to monitor (a schemeless host like 'rendex.dev/pricing' is upgraded to https). | |
| name | No | Optional label for the watch. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| webhookUrl | No | Starter+ — HMAC-signed change-webhook target. | |
| notifyEmail | No | Any plan — send change alerts here. Must be your OWN account email (others are rejected). Defaults to it if omitted. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that an active watch captures its baseline immediately, and describes the diff modes (visual, text, both). No contradictions 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 concise (4 sentences) and front-loaded with usage guidance. Every sentence adds value: usage, exclusion, behavior, and return type. 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 tool's complexity (10 params, nested objects, no output schema), the description covers core behavior and return format. Could mention more about the returned JSON structure, but is adequate.
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. The description adds extra context by explaining diffMode options (visual diff with highlighted overlay, extracted-text diff) and mentioning that it returns JSON, slightly exceeding the baseline.
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: to create a watch for monitoring webpage changes. It uses specific verbs ('monitor, watch, track') and distinguishes from the sibling tool 'rendex_screenshot' for one-time captures.
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 tells when to use (monitoring, tracking) and when not to (use rendex_screenshot for one-time capture). It also describes what the tool does, though it does not detail all alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_deleteDelete WatchADestructiveIdempotentInspect
Delete a watch and its run history. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds 'Irreversible' and specifies that run history is also deleted, enhancing transparency beyond 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 short sentences, front-loaded with main action, 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?
For a simple delete tool with one required parameter and no output schema, the description covers the essential aspects: what is deleted and its irreversibility.
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 parameter 'id' described as 'The watch ID (UUID)'. The description adds no additional meaning beyond what the schema provides.
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 action 'Delete' on the resource 'a watch and its run history', which is distinct from sibling tools like watch_create or watch_update.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for deletion but lacks context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_getGet WatchARead-onlyIdempotentInspect
Fetch one watch by ID, including its current baseline image URL and status. Returns JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return fields (baseline image URL, status) but does not mention behavior on error (e.g., if ID not found) or any 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 a single sentence that conveys the essential information: action, resource, and output. No unnecessary 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?
For a simple fetch tool with a single parameter, the description covers the core functionality and key output fields. It does not explain error responses or edge cases, but that is acceptable given the tool's simplicity and strong annotations.
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 a description for the 'id' parameter. The description does not add additional meaning beyond what the schema provides, so 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 the verb 'Fetch', the resource 'one watch by ID', and the specific output including 'current baseline image URL and status'. This distinguishes it from siblings like 'watch_list' which would list multiple.
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?
No guidance is provided on when to use this tool versus alternatives such as 'watch_list' for multiple watches or 'watch_test' for testing. The description only explains what the tool does, not the context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_listList WatchesARead-onlyIdempotentInspect
List your watches (newest first), optionally filtered by status and paged. Returns { items, nextCursor }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (1–100). | |
| cursor | No | Pagination cursor from a previous nextCursor. | |
| status | No | Filter by status. | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral details: ordering by newest first, optional status filter, pagination, and return format. 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?
The description is a single concise sentence that front-loads the action and key details (ordering, filter, pagination, output). Every piece of information is essential and efficiently presented.
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 list tool with three parameters, annotations cover safety, and the description specifies ordering, optional filtering, pagination, and return format. No missing information needed for correct invocation.
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 descriptions for all parameters (limit, cursor, status). The description does not add additional meaning beyond the schema, so baseline score of 3 applies.
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 action 'list' and resource 'watches', specifies ordering 'newest first', and mentions optional filtering and pagination. It distinguishes from siblings like 'watch_get' and 'watch_runs' by focusing on listing with optional filters.
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 clear context for when to use the tool (listing watches with optional status filter and pagination). It does not explicitly state when not to use or mention alternatives, but the context is sufficient given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_runRun Watch NowAInspect
Run an immediate check now (charges 1 credit). Returns the queued run; poll watch_runs for the result or receive a watch.changed webhook.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds context: credit charge, queued return, and webhook option, which are valuable beyond 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, efficient and front-loaded with the primary action and key details (cost, return, next steps). No unnecessary 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?
For a simple trigger tool with one parameter and no output schema, the description covers purpose, cost, return type, and next steps. It is reasonably complete, though could mention error conditions.
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 'id'. The tool description does not add additional semantics beyond what the schema provides, so baseline of 3 applies.
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 'Run an immediate check now', specifying verb and resource. It distinguishes from sibling tools like watch_runs (polling) and watch_create (creation).
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 mentions the credit cost and provides clear next steps: poll watch_runs or use webhooks. However, it doesn't explicitly state when not to use this tool or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_runsList Watch RunsARead-onlyIdempotentInspect
Read a watch's run history (newest first), paged. Each run includes changed, diffScore, and signed before/after/overlay image URLs. Returns { items, nextCursor }.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID). | |
| limit | No | Page size (1–100). | |
| cursor | No | Pagination cursor from a previous nextCursor. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds specific return fields (changed, diffScore, image URLs) and pagination structure, going beyond annotations without 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?
Two concise sentences that front-load the purpose and enumerate key return fields. Every sentence is essential and free of 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 read-only list tool with good annotations and simple schema, the description covers purpose, pagination, and return format. It does not mention potential emptiness or limits beyond page size, but is largely 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 descriptions for all 3 parameters. The description adds context about ordering and return format, aiding understanding of pagination parameters (cursor) and the id 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 the tool reads a watch's run history, specifies ordering (newest first) and paging, and distinguishes itself from siblings like watch_get or watch_list by focusing on run 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?
The description implicitly indicates usage for retrieving run history, but does not explicitly contrast with alternative tools like watch_get (single run) or watch_list (list of watches). Still, it's clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_testTest Watch Config (dry-run)ARead-onlyInspect
Dry-run a watch config BEFORE creating it — render the proposed config once and report what was captured + whether the page is reachable (and the text a text-watch would compare). Creates no watch, no baseline, no diff. Use this to validate a selector/scope/identity first. Returns JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to monitor (a schemeless host like 'rendex.dev/pricing' is upgraded to https). | |
| name | No | Optional label for the watch. | |
| paused | No | Create the watch paused (no baseline capture or charge until resumed). | |
| diffMode | No | visual = pixel diff + highlighted overlay; text = extracted-text diff; both runs each. | visual |
| aiSummary | No | Pro+ — attach an AI 'what changed' summary (roadmap). | |
| threshold | No | Visual-change noise floor as a 0..1 fraction; the diff must EXCEED it to count as changed. | |
| webhookUrl | No | Starter+ — HMAC-signed change-webhook target. | |
| notifyEmail | No | Any plan — send change alerts here. Must be your OWN account email (others are rejected). Defaults to it if omitted. | |
| renderParams | No | Render knobs applied on every check (a subset of the screenshot capture params). | |
| intervalMinutes | No | Check frequency in minutes. Minimum is your plan's floor — Free 1440 (daily), Starter 180, Pro 30, Enterprise 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm readOnlyHint=true and destructiveHint=false. The description adds specific behavioral details: no watch creation, no baseline/diff, and reports on page reachability and text capture. This goes 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?
The description is two concise sentences plus a note about JSON return. It front-loads the purpose ('Dry-run... before creating') and key outcomes, with no unnecessary 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?
For a test/dry-run tool with complex nested parameters and no output schema, the description adequately explains what the output contains (captured info, reachability, text) and that it returns JSON. It could be more explicit about exact return fields, but it's sufficient 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?
Schema coverage is 100% with detailed parameter descriptions. The description does not add additional meaning beyond stating the tool renders the config once, which is already implied. Baseline 3 is appropriate given high schema coverage.
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's a dry-run to validate a watch config before creation, specifying it renders the config once, reports captured info, and checks reachability. It distinguishes itself from the sibling watch_create by emphasizing no actual watch is created.
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 using this tool before creating a watch ('Dry-run a watch config BEFORE creating it') and to validate selectors/scopes/identities. It does not explicitly mention when not to use it or list alternatives, but the context with siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_updateUpdate WatchAIdempotentInspect
Update a watch in place — pause/resume (paused), re-point (url), change schedule/diff/notify settings, or turn a channel off (webhookUrl/notifyEmail = null). Only the fields you send change; renderParams is deep-merged over the existing config. A scope change (url/selector/fullPage/size/device) re-baselines on the next check. Returns the updated watch as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The watch ID (UUID) to update. | |
| url | No | Re-point to a new URL (clears the baseline; the next check re-baselines). | |
| name | No | Rename the watch (null to clear). | |
| paused | No | true to pause the watch, false to resume. | |
| diffMode | No | Change what counts as a change. | |
| aiSummary | No | Pro+ — toggle the AI 'what changed' summary (roadmap). | |
| threshold | No | Change the visual-change noise floor (0..1). | |
| webhookUrl | No | Starter+ — set or replace the change-webhook target; null to turn it off. | |
| notifyEmail | No | Set the alert email (your account email only); null to turn it off. | |
| renderParams | No | Render knobs to deep-merge over the existing capture config. | |
| intervalMinutes | No | New check frequency in minutes (subject to your plan's floor). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotency and non-destructiveness; the description adds meaningfully by detailing deep-merge semantics, re-baseline triggers, and return format, exceeding what annotations provide.
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 efficient sentences with no redundancy, front-loaded with key actions, and logically structured covering all essential aspects.
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 (11 params, nested renderParams) and lack of output schema, the description adequately covers update mechanics, partial updates, and return type, though omits potential error scenarios (already implied by 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. The description enhances parameter understanding (e.g., 'url clears baseline', 'renderParams is deep-merged'), adding value beyond 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 uses a specific verb-resource pairing ('Update a watch') and enumerates modifiable aspects (pause/resume, url, settings, etc.), clearly distinguishing it from sibling tools like watch_create or watch_delete.
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 states what happens (only sent fields change, deep-merge, re-baseline) but does not explicitly contrast with alternatives or provide when-not-to-use guidance, leaving some implicit inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.