inbox-preview
Server Details
Render HTML/.eml emails in real Gmail, Outlook & Yahoo web clients and screenshot them
- 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 3.9/5 across 4 of 4 tools scored. Lowest: 2.9/5.
Each tool has a clear and distinct purpose: submitting previews, checking job status, fetching specific screenshots, and listing clients. No overlapping functionality.
All tool names follow a consistent verb_noun pattern (get_job, get_screenshot, list_clients, submit_preview), making them predictable and easy to distinguish.
With four tools, the server is well-scoped for its purpose—submitting email previews, tracking jobs, retrieving screenshots, and listing clients. No tools feel extraneous or missing.
The toolset covers the full workflow: submission, status polling, screenshot retrieval, and client discovery. There are no obvious gaps for the stated purpose of rendering email previews.
Available Tools
4 toolsget_jobAInspect
Get the status and screenshots for a preview job. Poll until status is "completed".
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID returned by submit_preview |
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 polling behavior and return fields (status, screenshots), but omits details like error handling, authentication requirements, or rate limits. Adequate but not comprehensive.
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 wasted words. Front-loads the core purpose and critical polling instruction. Ideal for quick agent comprehension.
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 tool with one parameter, no output schema, and simple polling behavior, the description is largely sufficient. Could mention failure handling or timeout limits, but overall complete enough for typical use.
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%, already documenting job_id as a string. Description adds helpful context that the ID comes from submit_preview, which is valuable for correct invocation. Exceeds baseline 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?
Description explicitly states it gets status and screenshots for a preview job, with a specific verb 'get' and resource. It also includes polling guidance, distinguishing it from siblings like get_screenshot (specific screenshot) and submit_preview (submission).
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 clear polling instruction 'Poll until status is completed', but does not explicitly explain when to use this tool over siblings or mention alternatives. The context is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screenshotCInspect
Fetch a rendered screenshot. Returns the image URL for the given job, client, width, and environment (color scheme / images).
| Name | Required | Description | Default |
|---|---|---|---|
| client | Yes | Client ID | |
| job_id | Yes | The job ID | |
| color_scheme | No | The render's color scheme | light |
| viewport_width | Yes | Viewport width of the render, matching the job (1280 when the job used client defaults) | |
| images_disabled | No | Whether the render had images blocked |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action and return value, omitting details like side effects, permissions, rate limits, or error conditions. No contradiction with annotations (none provided).
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 two-sentence structure with front-loaded action. Every word adds value, no filler. Ideal length for quick comprehension.
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 5 parameters and no output schema, the description is too brief. It mentions return type (URL) but lacks details on prerequisites, default behavior for optional parameters, or what happens with invalid inputs. Schema annotations absent, so completeness relies solely on description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description groups 'color scheme / images' as 'environment', adding minor context, but does not provide meaning beyond the schema's individual parameter 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?
Description clearly states it fetches a rendered screenshot and returns an image URL, naming key parameters (job, client, width, environment). While not explicitly contrasting with sibling tools, the action is distinct enough to infer usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_job or submit_preview. The description implies its purpose but does not set usage boundaries or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_clientsAInspect
List the email clients this deployment can render right now, with their rendering tier, engine, and capabilities
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states the tool lists clients that 'this deployment can render right now', implying current state read-only access, but does not explicitly mention idempotency, data freshness, 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?
The description is a single, well-structured sentence that conveys the essential information without any redundant or irrelevant details.
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 no output schema, but the description adequately explains what is returned (list of clients with rendering tier, engine, and capabilities). It meets the needs for this tool's 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?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter information because none exists, but the baseline for zero-parameter tools is 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 lists email clients with rendering details (tier, engine, capabilities), distinguishing it from sibling tools like get_job, get_screenshot, and submit_preview which focus on 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 is clear about the tool's function but does not explicitly state when to use it vs alternatives. However, the sibling list shows distinct tool purposes, so usage context is implied and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_previewAInspect
Submit an email for rendering across email clients — full HTML, or a complete raw .eml (base64). Provide exactly one of html/eml. Returns a job ID to poll for results.
| Name | Required | Description | Default |
|---|---|---|---|
| eml | No | A complete raw RFC 822 message (.eml), base64-encoded — inserted verbatim (real headers, multipart, attachments). Max 10MB decoded. Provide exactly one of html or eml. | |
| html | No | The full email HTML to preview. Provide exactly one of html or eml. | |
| renders | No | Exactly the renders you want, one entry each (e.g. outlook light + outlook dark are two entries). Omit for the server default: every live client at its default width, light. | |
| subject | No | Email subject line | |
| include_previews | No | Also capture the inbox-list row (how the message looks unread in the list) and the subject heading, returned as inbox_preview / subject_preview on each render. Default false: they cost more than the body render itself, so ask only when you need them. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions the return type (job ID) and input constraints, but misses details on rate limits, authentication, or error handling. Adequate but not comprehensive.
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, no wasted words, front-loaded with the core action and key constraint. Highly efficient and well-structured.
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 covers the key outcome (job ID) and parameter constraints. Missing details about job ID format or polling URL, but sufficient for basic understanding.
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%, but the description adds value by summarizing the exclusive choice between html and eml and the polling mechanism, which is not in the schema. Adds meaningful context beyond parameter 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 submits an email for rendering across email clients, specifies the two input formats (HTML or raw .eml), and distinguishes from sibling tools like get_job, get_screenshot, and list_clients by focusing on the submission action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the input constraint 'Provide exactly one of html/eml' and mentions the return of a job ID for polling, implying usage for previewing emails. However, does not explicitly say when not to use or compare to alternatives.
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!