customjs-mcp
Server Details
Host static HTML pages, generate PDFs, screenshots, scrape JS sites, run sandboxed JavaScript.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.2/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: HTML page management (list, host, delete), PDF conversion (from HTML or Markdown), code execution, web scraping, screenshots, and help. No two tools could be confused.
All tools follow the 'customjs_' prefix followed by a descriptive verb_noun pattern (e.g., delete_html_page, host_html_page, html_to_pdf, run_code). The naming is consistent and predictable.
With 9 tools, the server covers its core capabilities without being bloated or sparse. Each tool serves a necessary function for the intended domain.
The tool set covers CRUD for hosted pages (create via upsert, read via list, delete), PDF generation from two formats, plus scraping, screenshots, and code execution. A minor omission is a dedicated tool to get a single page's details, but list provides enough info, so it's not a critical gap.
Available Tools
9 toolscustomjs_delete_html_pageAInspect
Delete a hosted HTML page by name or pageId. Provide either 'name' or 'pageId' (at least one is required). If only 'name' is given, it is resolved to a pageId via the page list.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the page to delete (resolved to a pageId via the list). | |
| pageId | No | Exact pageId of the page to delete. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the deletion action and resolution logic, which implies destructive behavior. However, without annotations, it could benefit from explicitly noting that deletion is permanent or irreversible.
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 extremely concise: two sentences that get straight to the point, with the action and key requirement 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 deletion tool, the description adequately covers the key functional aspects: what it deletes, how to specify the page, and the resolution logic. It could optionally mention the return value, but for a void operation it's sufficient.
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 description clarifies that at least one of name or pageId must be provided, and explains the resolution of name to pageId, which adds meaning beyond the schema's 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 the specific verb 'Delete' and resource 'hosted HTML page', clearly indicating the action and target. It distinguishes from sibling tools that list, host, or convert pages.
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 two input options and resolution logic but does not provide explicit guidance on when to use this tool versus alternatives, such as when to delete vs. list or host.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_helpAInspect
Get help and examples for using CustomJS tools effectively. Returns common patterns, troubleshooting tips, and workflow examples.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Specific topic to get help on, or 'all' for complete guide |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only, safe operation but does not explicitly confirm no side effects, destruction, or authentication requirements. The description is adequate but not thorough.
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 concisely states the tool's purpose and return type. It contains no redundant or unnecessary information, earning a perfect score.
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 help tool with one optional parameter and no output schema, the description is fairly complete. It specifies the returned content (patterns, tips, examples) but does not detail the format or structure of the help response, leaving a minor gap.
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 covers the single parameter with a description, resulting in 100% coverage. The tool description adds no additional meaning beyond what the schema provides, so a baseline score 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 clearly states the tool's purpose: providing help and examples for CustomJS tools. It specifies the returned content (patterns, tips, examples) and distinguishes it from sibling tools that perform actions like scraping or PDF conversion.
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 does not explicitly state when to use this tool versus alternatives. While usage is implied (use when needing help), there is no guidance on prerequisites or when not to use it. This is adequate for a help tool but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_host_html_pageAInspect
Host a static HTML page on CustomJS and get a public URL back. Upserts by name: hosting with a name that already exists UPDATES that page, while a new name CREATES a new one. Returns the public URL and whether the page was created or updated. Note: the public URL is served via CloudFront, so immediately after an update it may briefly show the previous content (cache delay) before refreshing.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Complete HTML content of the page to host. | |
| name | Yes | Unique page name. Reusing an existing name updates that page (upsert by name). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the upsert behavior, return values (public URL and status), and an important cache delay via CloudFront. This is thorough for a simple 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?
The description is concise: three sentences covering main purpose, upsert behavior, and a cache caveat. Each sentence adds critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies return values (URL and status). It also addresses a performance nuance (cache delay). Missing details like size limits or authentication, but overall sufficient for this 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?
Schema coverage is 100% (both parameters documented). The description adds context by explaining the 'name' parameter's role in upsert and the 'html' as full content, beyond the schema's descriptions. The upsert clarification is valuable.
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 (host), the resource (static HTML page), and the outcome (get a public URL). It distinguishes from sibling tools like customjs_delete_html_page by focusing on hosting and upsert behavior.
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 upsert semantics (create vs update based on name), which guides usage. It does not explicitly list alternatives or when-not-to-use, but the context of sibling tools and the name makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_html_to_pdfAInspect
Convert HTML content to a professional PDF document. Supports full HTML5/CSS3 and Nunjucks templating for dynamic content. Returns a presigned download URL for the generated PDF (expires in 1 hour). No need for wkhtmltopdf or Chrome headless - this handles everything.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Optional data object for Nunjucks templating. Example: {name: 'John', items: ['a', 'b']} can be used in HTML as {{ name }} and {% for item in items %}. | |
| html | Yes | Complete HTML content to convert. Include <html>, <head>, and <body> tags. You can use inline CSS or <style> tags for formatting. For dynamic content, use Nunjucks template syntax like {{ variable }}. | |
| config | No | Optional PDF dimensions. Defaults to A4 portrait (210×297mm). Use 297×210 for A4 landscape, 215.9×279.4 for US Letter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses that the tool returns a presigned URL expiring in 1 hour and supports templating. However, it does not specify error behavior, size limits, or whether conversion is synchronous, which would be helpful for an agent.
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 three sentences, front-loaded with the primary action, and every sentence adds value. No redundant or wasted text.
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 moderate complexity (3 params, nested config) and no output schema, the description explains the main output and features. It could mention failure modes or limitations, but it covers the core conversion purpose and the presigned URL detail is helpful.
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 context about Nunjucks templating and the return type (presigned URL), but the schema already describes parameters adequately. No additional parameter-specific meaning beyond what is in 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 verb 'Convert', resource 'HTML content to PDF', and lists key features (HTML5/CSS3, Nunjucks templating). It distinguishes from siblings like customjs_markdown_to_pdf by specifying HTML input.
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 'No need for wkhtmltopdf or Chrome headless - this handles everything', implying when to use it. It provides context about supporting dynamic content but lacks explicit when-not-to-use or alternatives like customjs_markdown_to_pdf for markdown input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_list_html_pagesAInspect
List all HTML pages you have hosted on CustomJS. Returns each page's name, public URL, and pageId.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what the tool returns but does not disclose behavioral traits like idempotency, safety, or any side effects. For a simple read-only list tool, this is minimally adequate.
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 is clean, direct, and free of any extraneous information. Every word 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?
For a parameterless tool with no output schema, the description adequately explains the tool's purpose and return values (name, URL, pageId). No additional context is needed.
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?
There are no parameters, and the schema coverage is 100% (trivially). According to guidelines, 0 parameters warrants a baseline score of 4, as the description does not need to add parameter meaning.
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 'List', resource 'HTML pages you have hosted on CustomJS', and specifies the returned fields (name, public URL, pageId). It distinguishes well from sibling tools like delete, host, or convert.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The usage is implied but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_markdown_to_pdfAInspect
Convert Markdown text to a styled PDF document instantly. Supports all standard Markdown: headers, lists, code blocks, tables, bold, italic, links. Returns a presigned download URL for the generated PDF (expires in 1 hour). This is the easiest way to create PDFs from text content.
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | Markdown content to convert. Use standard Markdown syntax: # Header, ## Subheader, **bold**, *italic*, - lists, ```code blocks```, [links](url), tables, etc. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the output (presigned URL expiring in 1 hour) and performance ('instantly'). However, it omits potential limitations like file size, custom styling, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no unnecessary words. Front-loaded with the main action, followed by supporting details. Every sentence 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 simple one-parameter tool with no output schema, the description covers input format, output format, and value proposition. Could mention default styling, but 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?
The description adds value beyond the input schema by explaining the Markdown syntax supported (headers, lists, code blocks, etc.). Schema coverage is 100%, so the description enhances understanding.
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 ('Convert Markdown text to a styled PDF document instantly') and the resource (Markdown text). It distinguishes from sibling customjs_html_to_pdf by specifying Markdown input, and lists supported features.
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 implies when to use ('easiest way to create PDFs from text content') but does not explicitly exclude alternatives or state when not to use. The sibling customjs_html_to_pdf is contextually distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_run_codeAInspect
Execute custom JavaScript/Node.js code in a secure sandbox with access to popular NPM packages. Use this for data transformations, API calls, calculations, or any Node.js logic. Your code receives an 'input' variable and should return a value. Available packages: axios, lodash, cheerio, date-fns, uuid, moment, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute. MUST include explicit 'return' statement. Use 'input' variable for the data passed in. console.log() output is NOT captured - only return values are returned. Example: return input.items.map(x => x * 2); Available: require('axios'), require('lodash'), require('cheerio'), etc. For async operations, use await and return the result. | |
| input | Yes | Data to pass into your code, accessible as the 'input' variable. Can be a simple string, number, or JSON string like '{"items":[1,2,3]}'. The code will automatically parse JSON strings. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: sandboxed execution, access to popular NPM packages, console.log not captured, only return values returned, automatic JSON parsing of input, async support via await. It does not mention execution time limits or resource constraints, but otherwise provides good 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 concise (4 sentences) and front-loaded: the first sentence immediately states the tool's action. Every sentence adds value (purpose, usage guidance, input/output contract, available packages). No fluff or 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 the tool's complexity (2 params, no output schema, no annotations), the description covers essential aspects: what it does, how code and input work, and available packages. It does not explain error handling or return value format in detail, but overall it provides enough context 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 description coverage is 100% with thorough param descriptions. The tool description adds context about available packages and overall usage, but the schema already explains return statements, input variable, and JSON parsing. The description reinforces rather than substantially supplementing 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's purpose: 'Execute custom JavaScript/Node.js code in a secure sandbox with access to popular NPM packages.' It specifies concrete use cases: data transformations, API calls, calculations. This distinguishes it from sibling tools (HTML pages, PDF, scraping, screenshot) which involve different operations.
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 use cases: 'Use this for data transformations, API calls, calculations, or any Node.js logic.' It provides guidance on how to use the tool (code must return a value, input variable). However, it does not mention when to avoid this tool or what alternatives exist, though sibling tools are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_scrape_htmlAInspect
Extract the complete HTML source code from any webpage. Handles JavaScript-rendered content by executing browser automation first. Use this to scrape dynamic websites that require clicking, scrolling, or waiting for content to load. Returns the final rendered HTML as text (not base64).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to scrape (must include https://) | |
| commands | No | Browser automation steps before scraping. Examples: [{action: 'waitForSelector', selector: '.content'}] waits for element, [{action: 'scroll', value: 500}] scrolls down 500px, [{action: 'click', selector: 'button#load-more'}] clicks button. Use [] for static pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully conveys behavioral traits: it executes browser automation before scraping and returns the final rendered HTML as text (not base64). This is sufficient disclosure for agent decision-making.
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 three sentences with no waste. It front-loads the primary action, then adds context and usage guidance. Every sentence 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?
Given the two-parameter input schema with 100% coverage and no output schema, the description is complete. It explains what the tool does, its behavioral characteristics, and what it returns. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters, including examples for the 'commands' parameter. The tool description adds context about the purpose of automation steps, slightly exceeding 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 clearly states the tool extracts complete HTML source code from any webpage, handling JavaScript-rendered content. It uses a specific verb ('extract') and resource ('HTML source code from webpage'), distinguishing it from sibling tools like customjs_html_to_pdf or customjs_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?
The description explicitly says to use this for dynamic websites requiring actions like clicking or scrolling. It provides context for when the tool is appropriate, though it does not explicitly state when not to use it or mention alternatives within the suite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customjs_screenshotAInspect
Capture a full-page screenshot of any website as a PNG image. This tool handles all browser automation internally - you don't need to write any code. Simply provide the URL and optionally specify browser actions (click, scroll, wait) to perform before capturing. Returns a presigned download URL for the screenshot (expires in 1 hour). Use this instead of Selenium, Playwright, or puppeteer when you need quick screenshots.
| Name | Required | Description | Default |
|---|---|---|---|
| box | No | Optional crop region {x, y, width, height} in pixels to capture only part of the page. Omit this to capture the full viewport. | |
| url | Yes | URL of the webpage to capture (must include https://) | |
| commands | No | Optional browser automation steps to execute before taking the screenshot. Examples: [{action: 'wait', value: 2000}] waits 2 seconds, [{action: 'click', selector: 'button.accept'}] clicks a button. Leave empty [] for immediate screenshot. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return type (presigned URL, expires in 1 hour) and that it handles browser automation. Does not mention authorization needs, rate limits, or behavior on invalid URLs. Acceptable but could be more thorough.
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 main purpose. No filler. Each sentence contributes uniquely: first defines the tool, second provides usage guidance and return 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 3 parameters (1 required, 2 optional with nested objects) and no output schema, description adequately explains output format and expiration. Could mention error handling or limitations, but covers essential context for an AI agent to invoke 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 coverage is 100% with descriptions for all parameters. Description adds value by providing usage examples for the 'commands' parameter and clarifying that 'box' is optional for full viewport. Baseline 3 is elevated due to these additions.
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?
Description clearly states 'Capture a full-page screenshot of any website as a PNG image.' It specifies the resource (website screenshot), format (PNG), and return type (presigned download URL). Distinguishes from siblings by noting it handles browser automation internally, unlike tools like customjs_scrape_html or customjs_run_code.
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 advises 'Use this instead of Selenium, Playwright, or puppeteer when you need quick screenshots.' Provides context that no coding is needed. However, does not explicitly mention when not to use or compare to sibling tools like customjs_html_to_pdf.
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!