customjs-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, so the description adds value by explaining that name is resolved to pageId via the page list. No other behavioral traits like auth needs or reversibility are disclosed, but the destructive nature is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, and contains no unnecessary information. 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 delete tool with no output schema, the description adequately covers the key usage points. It mentions the resolution behavior. Slightly missing is explicit mention of irreversibility, but annotations cover that.

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%, but the description adds meaning by stating that at least one parameter is required and that name is resolved to pageId. This goes beyond the schema's basic type 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 deletes a hosted HTML page using name or pageId. It specifies the identification methods, avoiding tautology. However, it does not explicitly differentiate from sibling tools like customjs_list_html_pages, which is a minor gap.

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 indicates when to use the tool (to delete a page) and provides a condition for parameters (at least one of name or pageId). It does not include guidance on when not to use or mention alternative tools, making the guidance adequate but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying it returns patterns, tips, and examples, complementing the safety profile.

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 that are front-loaded, with no 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 simple help tool with one enum parameter, the description adequately covers what it returns. Could mention no side effects, but annotations already cover safety. Output schema not 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?

Schema description coverage is 100% for the 'topic' parameter, including its enum and description. The tool description adds no further parameter meaning beyond 'all' for complete guide, matching 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 'Get help and examples' and distinguishes itself from sibling action tools (e.g., customjs_screenshot, customjs_run_code) by being a meta-help tool.

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 vs. alternatives. The context of sibling tools implies it's for guidance before actions, but lacks explicit when-not-to-use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide limited behavioral hints (readOnlyHint=false, etc.). The description adds critical details: upsert behavior ('Upserts by name'), cache delay via CloudFront ('immediately after an update it may briefly show the previous content'), and return values (public URL and creation/update status). 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?

The description is concise (three sentences) and front-loaded: the first sentence states the primary action and result. Every sentence adds vital information—no fluff. The structure efficiently communicates core functionality, upsert behavior, and a notable edge case (cache delay).

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 has 2 required parameters with full schema coverage and no output schema, the description covers the return values (public URL, created/updated status) and a key edge case (cache delay). This is complete for an agent to correctly invoke and interpret the tool's behavior.

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?

Both parameters ('name' and 'html') are fully described in the schema (100% coverage), so the baseline is 3. The description adds meaningful context about the 'name' parameter through upsert semantics ('reusing an existing name updates that page'), which justifies a 4.

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: 'Host a static HTML page on CustomJS and get a public URL back.' It uses a specific verb ('Host') and resource ('static HTML page'), and distinguishes from siblings by explicitly describing the upsert behavior ('Upserts by name: hosting with a name that already exists UPDATES that page').

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 when to use the tool (to host a static HTML page) and provides context via upsert semantics. It implicitly distinguishes from siblings like 'customjs_delete_html_page' or 'customjs_list_html_pages' by focusing on hosting. However, it lacks explicit 'when not to use' or direct alternative mentions, which would elevate it to a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses output (presigned URL with 1-hour expiration) and features (HTML5/CSS3, Nunjucks). Annotations indicate a write operation (readOnlyHint=false) and non-destructive behavior, which align. No contradictions, but could mention limits or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences front-load core purpose, features, and output. No redundant information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description explains the return value (presigned URL with expiration). Covers essential aspects (HTML5/CSS3, templating) but omits error handling or size limits. Adequately complete for medium complexity.

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 parameters (100% coverage). Description adds high-level context (Nunjucks support, output type) that reinforces schema but doesn't provide deep additional semantics. Baseline 3, plus a point for the extra context.

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 the tool converts HTML to PDF, supports HTML5/CSS3 and Nunjucks templating, and returns a presigned download URL. This distinguishes it from siblings like markdown_to_pdf.

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?

Implicitly suggests when to use (for HTML to PDF conversion, no external dependencies needed) but lacks explicit when-not-to-use or alternative scenarios. Sibling list provides context but description itself could be more directive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating the return fields (name, public URL, pageId), but does not disclose other behavioral traits like pagination, rate limits, or authentication requirements.

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 immediately states the action and outcome. It is concise, front-loaded, and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (zero parameters, no output schema, and clear annotations), the description is mostly complete. It covers the purpose and return fields, though it could mention that no parameters are required or clarify the scope (all pages).

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 tool has zero parameters, and schema coverage is 100% (trivially). No parameter information is needed, so the description meets 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 uses the specific verb 'List' and identifies the resource as 'HTML pages you have hosted on CustomJS', clearly distinguishing it from sibling tools like customjs_delete_html_page or customjs_host_html_page, which perform different actions.

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 any guidance on when to use this tool versus alternatives. It only states what the tool does, without mentioning when-not-to-use or specifying context where other tools would be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it returns a presigned download URL with 1-hour expiration. Annotations already indicate non-read-only and non-destructive behavior, so description adds useful context.

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 well-structured sentences with no waste. First sentence states purpose, second lists support, third explains output.

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?

Simple tool with one parameter, no output schema. Description fully explains input, output format, and expiration. No missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage and detailed description. Additional description of supported Markdown features adds value beyond 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?

Clearly states it converts Markdown to PDF and lists supported features. Differentiates from sibling customjs_html_to_pdf, which converts HTML to PDF.

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?

Mentions 'easiest way to create PDFs from text content' implying use case, but does not explicitly compare with alternatives or mention when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds critical details beyond annotations: sandbox security, return value capture (not console.log), async support, and available packages. 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?

Well-structured with front-loaded purpose, but descriptions for parameters are somewhat long. However, all text adds value, making it acceptable.

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?

Covers execution environment, parameter behavior, async support, and return value. No output schema exists, but description implies return value is the code's return. Could mention potential errors or limits, 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?

Adds significant meaning beyond schema: for 'code', requires explicit return, notes console.log not captured, provides example; for 'input', explains automatic JSON parsing. Schema coverage is 100%, but description enriches usage.

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 'Execute custom JavaScript/Node.js code in a secure sandbox', specifying verb and resource. It distinguishes from sibling tools like HTML/PDF manipulation by focusing on code execution.

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?

Provides explicit examples of when to use: 'data transformations, API calls, calculations, or any Node.js logic.' Does not explicitly list when not to use or contrast with siblings, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds that it executes browser automation and returns rendered HTML as text, which supplements the 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?

The description is three sentences, front-loading the purpose. Every sentence conveys essential 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 the tool's complexity (JS rendering, automation commands), the description covers purpose, usage, parameters, and return format. Absence of output schema is mitigated by stating the return type. Could mention potential limitations 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%, but the description provides concrete examples of the commands array (e.g., click, scroll, wait) and clarifies usage, adding value beyond the schema alone.

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 'Extract the complete HTML source code from any webpage' and specifies handling JavaScript-rendered content. It distinguishes from sibling tools like customjs_delete_html_page and customjs_html_to_pdf, which have different purposes.

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 advises using this tool for dynamic websites requiring interaction and suggests using empty commands for static pages. It does not explicitly mention when not to use it or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by mentioning the browser automation is handled internally, the screenshot is full-page, and the URL expires in 1 hour. However, it does not disclose potential side effects (e.g., cookies, browser sessions) or limitations like timeouts or dynamic content handling. Annotations confirm it is not read-only (readOnlyHint=false) and not destructive, so no 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?

The description is only three sentences, each serving a distinct purpose: defining the tool's function, explaining it requires no code, and specifying output and usage context. No filler or 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?

The description covers the tool's main purpose, input parameters with examples, and output format (presigned URL). It provides enough context for an AI agent to select and use the tool. Minor gap: it doesn't explain how box parameter interacts with 'full-page' capture, but the schema handles that.

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 every parameter is documented in the schema. The description adds value by providing concrete examples of the commands parameter (e.g., [{action: 'wait', value: 2000}]) and summarizing the purpose of each parameter. This goes beyond the schema's raw 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 explicitly states 'Capture a full-page screenshot of any website as a PNG image', clearly identifying the tool's verb (capture) and resource (screenshot). It distinguishes from sibling tools like customjs_scrape_html and customjs_html_to_pdf by offering quick browser automation without 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?

The description provides explicit usage guidance: 'Use this instead of Selenium, Playwright, or puppeteer when you need quick screenshots.' It clearly indicates the tool's niche but could also specify when not to use it (e.g., for complex interactions or non-screenshot tasks).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.