Diagrams, badges, charts and QR codes as plain image URLs you can paste into Markdown.
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.
Average 4.5/5 across 7 of 7 tools scored.
Each tool produces a distinct output type—badge, chart, QR code, diagram, spritesheet, or AI-generated image—so there is no overlap. The polling utility check_job is clearly separate from the generation tools.
Three tools share the 'make_' prefix (make_badge, make_chart, make_qr), but others use different verbs (render_diagram, split_spritesheet, text_to_image, check_job). The naming is understandable but not uniformly consistent.
With seven tools, the server is well-scoped for an image generation service. Each tool covers a specific image type or utility, and none seems superfluous.
The set covers a broad range of image generation needs (badges, charts, QR codes, diagrams, sprite sheets, AI images) and includes a job-polling mechanism for async operations. Minor gaps include lack of image editing tools (resize, crop, format conversion) and check_job referencing tools not in this server.
check_jobCheck a long-running jobAGet the status or result of a job started by deep_research, translate_pdf, or make_slides. Poll every 15-30 seconds until status is "done" or "error". While work is pending, follow retry_after_seconds and next_action; when complete, prefer structured_result when present. Example — GET https://ainetcafe.com/t/check_job?job_id=
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned when the task was started. |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| error | No | |
| job_id | Yes | |
| result | No | |
| status | Yes | |
| is_terminal | No | |
| next_action | No | |
| structured_result | No | |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds critical behavioral context: the polling interval, the terminal statuses, the handling of intermediate responses (retry_after_seconds, next_action), and the preference for structured_result. It also includes a concrete GET URL example, fully disclosing the interaction pattern.
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 information-dense but not verbose, delivering purpose, polling guidance, response handling, and an example in three sentences. Each sentence earns its place, and the example is clearly separated for easy scanning.
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?
With an output schema present, return values are already specified, so the description correctly focuses on the asynchronous polling protocol. It covers when to call, how to poll, what to do while pending, what to do on completion, and the exact endpoint format, making it fully self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents job_id (100% coverage), so the baseline is 3. The description enhances this by specifying that the job_id comes from deep_research, translate_pdf, or make_slides, and by showing its placement in the URL example, which adds context beyond the schema's generic 'returned when the task was started'.
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 identifies the verb ('Get'), the resource ('the status or result of a job'), and the originating tools (deep_research, translate_pdf, make_slides). This differentiates it from sibling creation tools like make_badge or render_diagram, which are all about generating artifacts rather than checking job status.
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: poll every 15-30 seconds until status is 'done' or 'error', follow retry_after_seconds and next_action while pending, and prefer structured_result when complete. It also indicates the tool is for jobs started by specific tools, which serves as both an inclusion and exclusion criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_badgeMake a README badge (SVG)ALabel + message + colour → a shields.io-style badge SVG, plus a ready-to-paste Markdown embed line. Stateless URL form: https://ainetcafe.com/i/badge/-- — embed it and it renders forever.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | brightgreen | green | blue | red | orange | yellow | grey | purple, or a hex like "007ec6". | |
| label | Yes | Left side text, e.g. "build". | |
| message | Yes | Right side text, e.g. "passing". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds extra value by noting the stateless URL form that renders forever, which clarifies the long-term behavior of the generated badge. It does not contradict 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, front-loads the core output, and includes a concrete URL example. Every sentence earns its place with 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?
The tool is simple, with full schema coverage and an output schema present. Annotations cover safety, and the description explains the output format and embedding use case. There is no missing behavioral context that would prevent correct 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?
Schema description coverage is 100%, so the schema fully documents the three parameters (label, message, color). The description mentions 'Label + message + colour' but adds no additional parameter details beyond what the schema already provides. Hence, the 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 generates a shields.io-style badge SVG from label, message, and color, plus a Markdown embed line. The title 'Make a README badge' reinforces the specific resource, and it is easily distinguished from sibling tools like make_chart or make_qr.
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 gives clear context: it is for creating README badges with a stateless URL that can be embedded. It implies the use case and the embed line, but it does not explicitly mention when not to use it or contrast with alternative tools. Still, the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_chartMake a chart imageALabels + values (or a full Chart.js config) → a chart PNG URL. Bar, line, pie, radar, scatter. Stateless URL form for embedding: https://ainetcafe.com/i/chart/|
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | bar (default) | line | pie | doughnut | radar | scatter. | |
| config | No | Optional full Chart.js JSON config; overrides labels/values. | |
| labels | No | Comma-separated labels, e.g. "Mon,Tue,Wed". | |
| values | No | Comma-separated numbers, e.g. "3,7,5". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the tool read-only and idempotent. The description adds that it returns a stateless PNG URL and that a full Chart.js config can override labels/values, providing behavioral context beyond the annotation flags. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core transformation, then supporting details on chart types and URL form. No redundant phrasing.
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 purpose, chart types, and URL form, relying on schema and output schema for parameter and return details. However, it omits the 'doughnut' chart type listed in the schema, and doesn't address potential overlap with render_diagram, leaving minor gaps.
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 descriptions cover 100% of parameters, giving baseline clarity. The description adds a concise summary of the main inputs ('Labels + values') and notes the override semantics, plus the URL encoding format, offering marginal additional value.
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 converts labels and values (or a Chart.js config) into a chart PNG URL, listing supported chart types. It uses a specific transformation and resource, distinguishing it from siblings like make_badge or text_to_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?
The description gives context (stateless URL for embedding) but doesn't explicitly state when to use this tool over alternatives like render_diagram. No exclusions or alternative tools are mentioned, leaving usage guidance implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_qrMake a QR codeAAny text or URL → a QR code PNG you can embed or download. Stateless URL form: https://ainetcafe.com/i/qr/
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text or URL to encode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the stateless URL form and confirms the PNG output, providing useful behavioral context beyond the structured metadata. No contradictions.
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, information-dense sentence followed by a concrete URL example. Every word earns its place, with no redundancy or filler.
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 single-parameter tool with full annotations and an output schema, the description is complete. It explains what the tool produces, how it can be used (embed/download), and provides an alternative stateless invocation method, making it sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'text' parameter as 'The text or URL to encode.' The description repeats this in 'Any text or URL' but adds no new parameter semantics. Since schema coverage is 100%, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: converting any text or URL into a QR code PNG that can be embedded or downloaded. This is a specific verb+resource construction and naturally distinguishes it from sibling tools like make_badge or text_to_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?
The description provides clear usage context: the tool returns an embeddable/downloadable PNG, and offers a stateless URL form for direct HTTP access. It doesn't explicitly mention when to use this over alternatives, but the purpose is so distinct that the context effectively guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_diagramRender a diagram from textATurn diagram-as-code into an image: Mermaid, PlantUML, Graphviz/DOT, C4, Excalidraw and 20+ more (self-hosted Kroki). Returns a hosted SVG/PNG URL you can embed directly in Markdown or HTML. Example — GET "https://ainetcafe.com/t/render_diagram?source=graph TD;A--%3EB&format=png"
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Diagram language: mermaid (default), plantuml, graphviz, c4plantuml, excalidraw, blockdiag, erd… | |
| format | No | "svg" (default) or "png". | |
| source | Yes | The diagram source code (e.g. a Mermaid flowchart). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds useful context by stating the result is a hosted SVG/PNG URL and mentions 'self-hosted Kroki', indicating the underlying service. The example also illustrates the endpoint usage. It does not cover auth or rate limits, but the annotations reduce the burden.
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 plus an example, with the core purpose stated first. The example includes a realistic URL but is not overly verbose. Every clause adds information: supported formats, output type, and usage pattern.
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, and the description covers the essential aspects: what it does, supported formats, output format, and an example. The schema provides full parameter details, annotations cover safety, and an output schema exists. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage for all three parameters, so the baseline is 3. The description adds value by providing a concrete example of the query-string format (source=...&format=png) and clarifying the supported diagram types. This helps an agent understand parameter syntax 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 'Turn diagram-as-code into an image' which clearly identifies both the action (rendering) and the object (diagram source text). It explicitly names supported languages (Mermaid, PlantUML, Graphviz/DOT, etc.), distinguishing it from sibling image-generation tools like text_to_image or make_chart. The purpose is unambiguous and specific.
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 clearly implies the tool is for diagram-as-code languages, giving context for when to use it. However, it does not explicitly contrast with alternatives or state when not to use it. An agent can infer use cases from the listed formats, but there are no direct exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_spritesheetSplit a sprite sheet into individual PNGsACut a packed sprite sheet / texture atlas into separate transparent PNGs, returned as a zip. Give rows and cols for a uniform grid, or omit them to auto-detect sprites by transparent gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL of the sprite sheet image. | |
| cols | No | Grid columns. | |
| rows | No | Grid rows. Omit together with cols to auto-detect. | |
| margin | No | Pixels to trim inside each grid cell (for sheets with padding). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the output is a zip file, auto-detection works by transparent gaps, and margin trims inside grid cells. These details go beyond the annotations and help an agent understand the tool's behavior.
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 with no fluff. The first sentence states the action and output; the second explains the two operational modes concisely. It is front-loaded and every word 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?
The description, combined with the rich annotations and output schema, fully equips an agent to invoke the tool: it explains the key decision (grid vs. auto-detect), the output format (zip), and the margin option. No critical information is missing given the 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?
Schema coverage is 100%, so the baseline is 3. The description enriches the parameter meanings by explaining the relationship between rows/cols and uniform grid mode, and the auto-detect mode when omitted. It also gives purpose to 'margin' (trimming padding), adding value over the plain schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cut') and resource ('packed sprite sheet / texture atlas') and clearly states the output ('separate transparent PNGs, returned as a zip'). This clearly distinguishes it from sibling tools like make_badge, make_chart, etc., which serve entirely 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?
It provides clear context on when to use the grid-based approach (provide rows/cols) versus auto-detection (omit them). It also explains the margin parameter for padding. While it does not explicitly compare to sibling tools, they are all unrelated so no exclusion is needed; the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
text_to_imageGenerate an image from a text promptAText prompt → a generated image, returned as a hosted URL you can embed straight into Markdown, HTML or a chat reply. Use it for illustrations, covers, concept art, social cards and mockups. Returns a job_id; poll check_job for the image url (about 1 minute). Metered per image, no account needed for the free quota.
| Name | Required | Description | Default |
|---|---|---|---|
| aspect | No | Aspect ratio: "1:1" (default), "16:9", "9:16", "4:3", "3:4". | |
| prompt | Yes | What to draw. Be specific about subject, style and composition. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses asynchronous behavior (job_id and ~1 minute polling), the hosted URL return format, and metering/free quota constraints. This gives the agent essential operational 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 sentences cover purpose, use cases, and async workflow with no redundancy. The structure is front-loaded with the core transformation and each sentence adds distinct 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 an async image generation tool, the description covers the key workflow (submit prompt, get job_id, poll for image URL), the embeddable return format, and usage contexts. Given the output schema exists, return details need not be re-explained.
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 already provides full descriptions for both parameters (prompt and aspect), so the description adds no additional parameter-level semantics. With 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: converting a text prompt into a generated image and returning a hosted URL. It distinguishes from sibling tools by specifying the transformation (prompt → image) and unique output format, as well as the job-based flow.
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 concrete use cases (illustrations, covers, concept art, social cards, mockups) that help the agent decide when to use this tool. It also mentions the need to poll check_job for results, which guides the orchestration flow, though it does not explicitly exhaust 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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
