Renders Chart.js chart configurations as images, enabling AI agents to visualize data with charts.
Give your AI agent (Claude, Cursor, Windsurf, Cline) the ability to screenshot any URL and render charts — directly from the model context.
Tool | Description |
| Capture a screenshot of any public web page |
| Render a Chart.js config as a chart image |
| Check your current usage and rate limits |
Related MCP server: mcp-dashboards
Add to your claude_desktop_config.json:
{
"mcpServers": {
"hermesforge": {
"command": "uvx",
"args": ["hermesforge-mcp"],
"env": {
"HERMESFORGE_API_KEY": "your-key-here"
}
}
}
}{
"mcpServers": {
"hermesforge": {
"command": "python",
"args": ["-m", "hermesforge_mcp.server"],
"env": {
"HERMESFORGE_API_KEY": "your-key-here"
}
}
}
}Free tier: 10 screenshots/day, no key required
Free API key: 100/day — get one at hermesforge.dev/api/keys
Paid plans: higher volume at hermesforge.dev/pricing
Once connected, your AI agent can:
Take a screenshot of https://example.comRender this chart:
{"type": "bar", "data": {"labels": ["Q1","Q2","Q3"], "datasets": [{"label": "Revenue", "data": [12000, 15000, 18000]}]}}Rate limits are per API key (or per IP for anonymous use). When you hit a limit, the tool returns a helpful message with upgrade options.
MIT
Check your current API usage and rate limit status.
Returns your current usage counts and remaining quota for:
Screenshot API
Chart Rendering API
Requires HERMESFORGE_API_KEY environment variable to be set. Without an API key, shows anonymous tier limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns (usage counts, remaining quota) and the environment variable requirement, including anonymous tier behavior. Some additional details like rate limit reset times could improve 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 very short and front-loaded, using bullet points for clarity. Every sentence is necessary and provides value with 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?
The tool is simple with no parameters and has an output schema (not shown but present). The description covers the return values and prerequisites comprehensively, making it fully complete for an agent to invoke.
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, so the baseline is 4. The description adds no parameter information because none is needed.
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 checks API usage and rate limit status, listing specific APIs (Screenshot, Chart Rendering). It distinguishes itself from sibling tools like render_chart and screenshot_url, which perform different functions.
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 mentions the prerequisite of HERMESFORGE_API_KEY and fallback behavior without it, providing clear context for usage. It doesn't explicitly state when to use this tool, but the use case is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Chart.js configuration as a chart image.
Use this when you need to:
Visualize data as bar, line, pie, scatter, or other Chart.js chart types
Generate charts programmatically from data
Create charts for reports or documentation
Args: chart_config: A JSON string containing a valid Chart.js configuration object. Example: '{"type":"bar","data":{"labels":["A","B","C"],"datasets":[{"label":"Values","data":[1,2,3]}]}}' width: Chart width in pixels (default: 800) height: Chart height in pixels (default: 600) format: Image format - 'png' or 'jpeg' (default: 'png')
Returns: Base64-encoded chart image with data URI prefix.
Rate limits: Shared with screenshot API. Get a free API key at https://hermesforge.dev/api/keys
| Name | Required | Description | Default |
|---|---|---|---|
| chart_config | Yes | ||
| width | No | ||
| height | No | ||
| format | No | png |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a Base64-encoded chart image with data URI prefix, and mentions rate limits shared with the screenshot API along with a link to get an API key. It does not cover potential errors, validation, or performance characteristics, but the key behavioral aspects (output format, rate limiting, auth requirement) are addressed.
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 remarkably concise and well-structured. It opens with a one-sentence summary, followed by bulleted use cases, then an Args section listing parameters with explanations, a Returns line, and a Rate limits note. Every sentence adds value, and the structure makes it scannable for an AI agent.
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 (rendering a chart from a JSON config), the description covers input parameters, output format, and rate limits. The output schema exists but is not detailed; however, the description clarifies the return type (Base64 image with data URI). It lacks error handling details, but overall it provides sufficient contextual information for basic usage.
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 has 0% description coverage, so the description must compensate. It does so thoroughly with an Args section explaining chart_config (including a valid JSON example), width and height with defaults, and format with accepted values ('png' or 'jpeg') and default. This adds significant meaning beyond the schema's type and default annotations.
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 renders a Chart.js configuration as a chart image. It lists specific use cases (visualize data as bar/line/pie/scatter charts, generate charts programmatically, create charts for reports) and the primary verb 'render' with the resource 'chart image' is precise. This effectively distinguishes it from sibling tools (get_api_usage, screenshot_url) which serve 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 provides a 'Use this when you need to' section enumerating three common scenarios, giving clear context for when the tool is appropriate. However, it does not explicitly mention when not to use it or compare against alternatives, but the use cases are sufficiently illustrative for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of any web page and return it as a base64-encoded image.
Use this when you need to:
See what a website looks like visually
Verify a page rendered correctly
Capture UI state for debugging or documentation
Extract visual information from a web page
Args: url: The URL to screenshot (must be publicly accessible) width: Viewport width in pixels (default: 1280) height: Viewport height in pixels (default: 800) format: Image format - 'png' or 'jpeg' (default: 'png') full_page: Capture the full page height, not just the viewport (default: False)
Returns: Base64-encoded image data with data URI prefix, ready to display. Example: "data:image/png;base64,iVBORw0KGgo..."
Rate limits: 10/day free tier. Get a free API key at https://hermesforge.dev/api/keys for 100/day. Paid plans available for higher volume.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| width | No | ||
| height | No | ||
| format | No | png | |
| full_page | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (base64), default behaviors, and rate limits. It could mention error handling for invalid URLs or pages that don't load.
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: purpose statement, bullet list of use cases, clear Args section, Returns, and rate limits. Every sentence adds value 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 (5 params, with output schema), the description covers the main points. It explains the return format and constraints. Missing minor details like error behavior or performance considerations.
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 0%, but the description fully explains each parameter: url (publicly accessible), width/height (viewport, defaults), format (options), full_page (boolean). This adds significant 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 opens with a specific action ('Capture a screenshot') and resource ('any web page'), clearly distinguishing it from sibling tools (get_api_usage and render_chart). The list of use cases further reinforces the purpose.
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 includes explicit use cases ('Use this when you need to:') and mentions rate limits. It lacks explicit 'when not to use' guidance, but the use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique and clearly distinct purpose: checking API usage, rendering charts, and taking screenshots. There is no overlap or ambiguity among them.
All tool names follow a consistent verb_noun snake_case pattern (get_api_usage, render_chart, screenshot_url), making them predictable and easy to understand.
With only 3 tools, the server is on the lean side, but each tool serves a necessary function within the server's scope (API usage, chart rendering, screenshot). The count is acceptable for a focused utility server.
The server fully covers its stated purpose: it provides the core operations for generating screenshots and charts, plus a tool to monitor API usage. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Desktop and mobile website screenshots plus page context for AI agents and automation workflows.
Build a hosted website by chatting. Snapshots, forms, analytics. Hand off the dashboard. Walk away.
Build a real website from a chat — then run it: read messages, check traffic, publish changes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermesagent/hermesforge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
