Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@renderform-mcp render an image from template 'social post' with text 'Hello World'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
RenderForm is an API for automatically generating images, PDFs, screenshots and videos from templates.
This is a Model Context Protocol (MCP) server that provides tools for interacting with the RenderForm API.
Render an image/PDF from a template
Create a screenshot of a web page
Convert a web page to PDF
List render results
Get render result details
Delete a render result
List templates
Get template details
Delete a template
Get organization usage (credits, uploads, plan)
List available fonts
Feel free to add more tools by making a pull request or creating a feature request.
Related MCP server: doc-ops-mcp
To use the MCP server, you'll need an API key. You can create and manage API keys in RenderForm > Settings > API Keys.
To run the server in a client like Claude Desktop, Cursor or Windsurf, add the following to your MCP config:
{
"servers": {
"renderform": {
"type": "stdio",
"command": "npx",
"args": ["-y", "renderform-mcp", "--api-key=RENDERFORM_API_KEY"]
}
}
}Replace RENDERFORM_API_KEY with your API key.
For detailed setup guides, see:
Install dependencies:
npm installBuild the server:
npm run buildUpdate client to use the local build:
{
"servers": {
"renderform": {
"command": "node",
"args": ["path/to/renderform-mcp/build/index.js"],
"env": {
"RENDERFORM_API_KEY": "your_api_key"
}
}
}
}To debug the MCP server, you can use the MCP Inspector tool:
Run the server with the inspector:
npm run inspectorOpen the provided URL in your browser to view and debug the MCP requests and responses.
Include the --api-key argument.
This tool converts a web page into a PDF using RenderForm.
Provide 'url' (required).
Optionally provide 'format' (A5, A4, A3, LETTER or LEGAL - defaults to A4), 'waitTime' (ms, 0-5000) before capturing, and 'expires' (seconds, 1-604800) to auto-delete the generated PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to capture as a PDF. | |
| format | No | Output page format of the PDF. Defaults to A4. | |
| expires | No | Automatically delete the generated PDF after this many seconds (1-604800). | |
| waitTime | No | Wait time in milliseconds before capturing the PDF (0-5000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, and the description adds behavioral context such as auto-delete via expires, default format, and wait time behavior. It provides useful details 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 sentences followed by a clear bullet list of parameters. It is concise, front-loaded, and every sentence adds value without 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?
Given the tool has 4 parameters with full schema descriptions and no output schema, the description covers the essential usage. It could mention error handling or output format explicitly, but the tool name implies PDF output.
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?
All parameters have schema descriptions (100% coverage), and the description adds value by summarizing defaults (A4), units (ms, seconds), and ranges. It does not repeat but synthesizes the schema info effectively.
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 converts a web page to PDF using RenderForm, with a specific verb and resource. It distinguishes itself from sibling tools like create_screenshot by focusing on 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 lists required and optional parameters with defaults and ranges, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool captures a screenshot of a web page using RenderForm.
Provide 'url' (required), 'width' and 'height' (required, 32-5000px).
Optionally provide 'waitTime' (ms, 0-5000) to wait before capturing, useful for pages with animations or async content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to capture. | |
| width | Yes | Width of the screenshot in pixels (32-5000). | |
| height | Yes | Height of the screenshot in pixels (32-5000). | |
| waitTime | No | Wait time in milliseconds before capturing the screenshot (0-5000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already give behavioral hints: not read-only, open-world, not idempotent, not destructive. The description adds no contradictory info and provides useful detail on waitTime behavior. No major gaps.
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 and front-loaded: first sentence states purpose, then lists parameters with constraints in a bullet-like format. Every sentence adds value, 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?
Adequate for a simple capture tool with no output schema. Explains parameters and waitTime use case. Lacks description of output format (e.g., image type) or error cases, but given low complexity, it's minimally 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?
Input schema has 100% description coverage, so the schema already explains parameters. The description adds marginal value by explicitly restating constraints and explaining waitTime's use case, but doesn't add deeper semantics beyond what's 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?
Clearly states it captures a screenshot using RenderForm. The verb 'capture' and resource 'screenshot' are specific. Sibling tools include 'render_image' which could be confused, but the description distinguishes by naming the service RenderForm.
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 context for when to use 'waitTime' (pages with animations or async content). However, lacks explicit guidance on when not to use this tool or alternatives like 'render_image'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool permanently deletes a render result (and its file) from your RenderForm account.
Provide 'identifier' (required), the requestId of the result to delete.
This action is destructive and cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Identifier (requestId) of the render result to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. The description adds that deletion is permanent and cannot be undone, and that the associated file is also deleted. This provides context 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?
The description is two sentences and a bullet point, front-loading the purpose. No unnecessary words, 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 one parameter and no output schema, the description covers the action, parameter, and destructive behavior. It is nearly complete, though it could mention return value or error handling for full clarity.
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?
With 100% schema coverage, the baseline is 3. The description restates that identifier is the requestId, matching the schema description. It does not add new parameter-level details beyond what 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 tool permanently deletes a render result and its file, using specific verb 'delete' and resource 'render result'. It distinguishes from sibling tools like delete_template by targeting a different resource.
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 required identifier and notes the destructive nature, but it does not provide when-to-use guidance vs alternatives like delete_template. Implicit context from sibling names is insufficient for explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool permanently deletes a template from your RenderForm account.
Provide 'templateId' (required).
This action is destructive and cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | Identifier of the template to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'cannot be undone' beyond annotations' destructiveHint, but annotations already indicate destructive nature; adds minimal extra value.
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 efficient sentences, front-loaded with purpose, 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 single parameter, no output schema, annotations present, description covers purpose, requirement, and destructiveness adequately.
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 100%, description restates 'required' but adds no meaning beyond schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'deletes' and resource 'template', clearly distinguishing from siblings like delete_render_result which deletes a render result.
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 basic requirement ('provide templateId') but no guidance on when to use vs alternatives like delete_render_result or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool lists fonts available in your RenderForm account, including Google fonts and any custom uploaded fonts.
No parameters required.
Use this to find a valid font family name to use in a template.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, etc. The description adds value by specifying the scope (Google fonts and custom uploaded fonts), which is not evident from annotations alone.
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 with no fluff. The critical information is front-loaded: the tool's purpose and usage context.
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 zero-parameter, read-only listing tool with thorough annotations, the description covers everything needed: what it lists, why to use it, and that it has no parameters.
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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description reinforces 'No parameters required,' adding no confusion.
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 ('lists') and resource ('fonts available in your RenderForm account'), clearly distinguishing from sibling tools that perform create, delete, or render 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?
States 'No parameters required' and explicitly advises using the tool 'to find a valid font family name to use in a template.' While it doesn't mention when not to use, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool retrieves details of a single render result by its identifier (requestId).
Provide 'identifier' (required), returned as 'requestId' from the render/screenshot/pdf tools.
Returns status, dimensions, href, template info and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Identifier (requestId) of the render result, e.g. req-xxxx. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive hints. Description adds specific return fields (status, dimensions, href, template info, timestamps), providing useful context 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 well-structured sentences with a bullet point listing return fields. No wasted words; front-loaded with main purpose.
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 key aspects: what it retrieves, how to get the identifier, and return fields. Could mention potential state issues (e.g., result not ready) but low complexity reduces need.
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 clear parameter description. Description adds workflow context (identifier from prior tools), enhancing understanding 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?
Description clearly states the tool retrieves details of a single render result by identifier. Distinguishes from sibling tools like get_render_results (plural) and delete_render_result.
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 context that the identifier comes from render/screenshot/pdf tools, implying when to use. Does not explicitly exclude alternatives, but sibling list provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool lists past render results (images, PDFs, screenshots) in your RenderForm account.
Optionally filter by 'template' or 'batch' identifier.
Supports pagination with 'page' (default 0) and 'size' (default 20, max 50).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default 0). | |
| size | No | Page size for pagination (default 20, max 50). | |
| batch | No | Filter results by batch identifier. | |
| template | No | Filter results by template identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating the tool is for listing, the types of results (images, PDFs, screenshots), and pagination behavior. No contradiction exists; the description complements annotations effectively.
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 concise sentences, front-loaded with the core purpose, followed by clear bullet points. Every sentence adds necessary information without redundancy. Excellent structure.
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 tool lacks an output schema, so the description should explain return values more thoroughly. It mentions result types but not structure or pagination response details (e.g., total count). While adequate for a simple list tool with good annotations, the missing return format context prevents a higher score.
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%, and the description restates parameter functions (filtering by template/batch, pagination with defaults). It does not add new meanings beyond what the schema provides, so 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 'lists past render results (images, PDFs, screenshots)' in the user's account, using specific verbs and resource types. It distinguishes from sibling tools like 'get_render_result' (single result) and creation/deletion tools, making the purpose unambiguous.
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 specifies when to use the tool (to list past render results) and includes options for filtering by 'template' or 'batch' and pagination. It does not explicitly mention when not to use it or contrast with alternatives, but the sibling list implies differentiation. A clear usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool retrieves the full details of a single template, including its editable 'properties' (component IDs, property names and default values), fonts and tags.
Provide 'templateId' (required).
Use the returned 'properties' to build the 'data' object for the 'render_image' tool.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | Identifier of the template to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior; description adds that it returns editable properties for use in render_image, enhancing transparency without contradicting 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?
Very concise, two lines plus bullet. Front-loaded purpose, no superfluous 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 single parameter and no output schema, description fully explains tool purpose, return type, and how output is used downstream.
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 templateId fully; description merely restates requirement. No additional parameter meaning 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 retrieves full details of a single template, including properties, fonts, tags. Distinguishes from siblings like get_templates and render_image.
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 requires templateId and advises using returned properties for render_image. Provides downstream context but no 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.
This tool lists templates available in your RenderForm account.
Optionally filter by 'name', 'tags' or 'sourceTemplateId'.
Supports pagination with 'page' (default 0) and 'size' (default 20, max 50).
Use this to find a template identifier before rendering or fetching template details.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter templates by name. | |
| page | No | Page number for pagination (default 0). | |
| size | No | Page size for pagination (default 20, max 50). | |
| tags | No | Filter templates by tags. | |
| sourceTemplateId | No | Filter by the identifier of the source template used to create a template. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and not destructive. The description adds pagination defaults and filter options, which are useful but not critical behavioral traits. Missing error behavior or rate limits, but acceptable given strong 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?
Extremely concise with bullet points, front-loading the main purpose. Every sentence is relevant and 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?
Adequate for a list tool with no output schema, but lacks any description of what is returned (e.g., template summary fields). Missing explicit comparison to sibling 'get_template'.
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 parameters are fully documented. The description summarizes filters and pagination defaults but does not add new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists templates and optionally filters/paginates. It implies use for finding a template identifier but does not explicitly distinguish from sibling 'get_template' (singular), which likely returns a single template.
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 using this tool 'to find a template identifier before rendering or fetching template details', providing clear context. No mention of when not to use or alternatives like 'get_template' for individual retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool returns the organization's usage summary: render credits (used/total/renewal), file storage uploads (used/total bytes) and plan/billing status.
No parameters required.
Use this to check remaining credits before running large render batches.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the return content (credits, storage, plan), but does not mention rate limits or any other behavioral aspects 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?
Two sentences: first declares purpose and data, second gives usage hint. Front-loaded, 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?
No output schema, but description lists major data categories. With all annotations present and low complexity, the description is sufficient for the agent to understand the tool's output.
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?
No parameters exist, and schema coverage is 100%. The description correctly notes 'No parameters required.' Per guidelines, 0 parameters yields a baseline of 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 returns the organization's usage summary with specific data (credits, storage, billing). However, it does not explicitly distinguish from sibling tools, though the context of usage monitoring versus rendering is implicit.
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 says 'No parameters required' and gives explicit guidance to check remaining credits before large render batches. It does not state when not to use, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool renders an image, PDF or video from a RenderForm template.
Provide 'template' (required): the template ID, e.g. template_1234.
Provide 'data' to merge dynamic content into the template. Keys follow the 'componentId.property' convention (e.g. { "my-text.text": "Hello World!", "my-image.src": "https://example.com/image.jpg" }).
Component IDs and editable properties can be discovered with the 'get_template' tool (see the 'properties' field of the template).
Optionally provide 'fileName', 'webhookUrl' (called when the render finishes), 'version' (cache key - reusing it returns a cached result instead of re-rendering), 'metadata' (passed through to the webhook), 'batchName' (to group renders together) and 'waitTime' (delay before rendering, max 5000ms).
Use 'output: json' (default) to get back a JSON object with the href of the rendered file. Avoid 'output: image' here since it returns raw binary bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to be merged into the template. Keys follow the 'componentId.property' convention, e.g. { 'my-text.text': 'John' }. | |
| output | No | Output format. 'json' (default) returns a JSON object with the href of the rendered file, which is recommended here. 'image' returns raw image bytes and is not suitable for text responses. | |
| version | No | Cache key used for caching the rendered output. Reusing the same version returns the cached file. | |
| fileName | No | Name of the file to be returned (without extension). | |
| metadata | No | Additional metadata to be passed to the webhook. | |
| template | Yes | Template ID to render, e.g. template_1234. | |
| waitTime | No | Wait time in milliseconds before rendering (max 5000). | |
| batchName | No | Batch name used for grouping renders together. | |
| webhookUrl | No | Webhook URL to be called when the render is done. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details like caching via version, webhook callback, batch grouping, and wait time. Annotations indicate non-read-only and non-destructive. A contradiction exists: description suggests idempotent behavior for same version, but annotations set idempotentHint to false.
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 well-structured with bullet points and front-loads key information. It is slightly verbose but every sentence adds necessary context. Could be more concise without losing clarity.
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 9 parameters, no output schema, and complexity with nested objects, the description covers the rendering workflow, caching, async webhook, retry via version, and warns against using 'output: image'. It sufficiently explains how to use the tool end-to-end.
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 significant value by explaining the 'data' key convention, providing examples, and clarifying output format behavior. It also references the 'get_template' tool for component discovery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool renders an image, PDF, or video from a RenderForm template, using clear verb and resource. Although the name 'render_image' might suggest only images, the description corrects that. It differentiates from siblings like 'create_pdf' and 'create_screenshot' by specifying template-based rendering.
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 instructions for required and optional parameters, including output format recommendations and how to discover template properties via 'get_template'. However, it does not explicitly state when not to use this tool versus siblings like 'create_pdf'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_pdfcreate_screenshotdelete_render_resultdelete_templateget_fontsget_render_resultget_render_resultsget_templateget_templatesget_usagerender_imageEach tool has a clearly distinct purpose: PDF from URL, screenshot from URL, render from template, CRUD for templates and render results, listing fonts and usage. No overlapping functionality.
All tools follow a consistent verb_noun pattern with lowercase snake_case (e.g., create_pdf, get_templates, render_image). No deviations or mixed styles.
11 tools cover the essential operations for a render service: creating, listing, deleting renders and templates, plus utility tools for fonts and usage. Neither too few nor too many.
Core workflows are covered: browse templates, render, check results, delete, check usage. Missing create/update template and font upload, but these may be out of scope. Minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AutoRender's MCP server for media assets, transformations, delivery, and workflow automation.
MCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RenderForm/renderform-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
