io.github.pvliesdonk/image-generation-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.12.1
Disambiguation4/5
Most tools have clearly distinct purposes (polling, displaying, browsing, editing, listing providers). However, gallery_page and gallery_full_image are app-only helpers that overlap conceptually with browse_gallery and show_image, creating mild ambiguity for an agent.
Naming Consistency3/5
The majority follow a verb_noun pattern (check_generation_status, show_image, browse_gallery, edit_image, list_providers, get_server_info, list_resources, read_resource), but gallery_page and gallery_full_image break the pattern by starting with a noun. This makes the naming convention somewhat inconsistent.
Tool Count5/5
With 10 tools, the count falls within the ideal 3–15 range and feels well-scoped for an image generation server, assuming the missing generate_image tool existed. The number itself is appropriate.
Completeness1/5
The server is named image-generation-mcp, yet there is no generate_image tool among the listed functions; check_generation_status references it but it is absent. This is a severe gap—the core generation capability is missing, leaving only supporting utilities and viewing/browsing tools.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 55 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds valuable behavioral details beyond that: how templated resources must be handled, that content is returned as a string, and that binary content is base64-encoded. This is meaningful context not present in the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the core action stated in the first sentence. The subsequent lines provide essential usage details without unnecessary filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description provides enough context for correct invocation. It covers URI construction and return format, so the agent has the key details. It could mention how to discover valid URIs, but that is not critical for this simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with a basic description for uri, giving a baseline of 3. The description adds extra meaning by explaining how to fill in the URI for static versus templated resources, which goes beyond the schema's simple 'URI of the resource to read.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a resource by its URI, which is a specific verb and resource. It distinguishes itself from list_resources by focusing on reading a single resource, though it does not explicitly contrast with show_image, so it misses some sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives conditional instructions for static vs. templated resources, which is useful for constructing the URI correctly. However, it does not explain when to use this tool versus alternatives like list_resources or show_image, so usage guidance relative to siblings is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safe read behavior. The description adds valuable behavioral detail: 'Images larger than 1 MB are downscaled to 1024 px wide WebP before encoding,' which informs the agent of potential data transformation. It also mentions 'full (or near-full) resolution,' acknowledging possible downscaling. This goes beyond the annotations, meriting a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. However, there is slight redundancy: the first sentence ('Return full-resolution image data...') is essentially repeated in the second sentence ('load a single image at full (or near-full) resolution'). While not verbose, this minor repetition prevents a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, helpful annotations, and an output schema (confirmed by context signals), the description adequately covers purpose, intended caller, and a key behavioral trait (downscaling). It does not detail error handling or return structure, but those are likely covered by the output schema. The context 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (image_id: 'The image ID to load.') with 100% schema coverage. The description does not add any additional parameter semantics or clarify the format or usage of image_id beyond what the schema already provides. Per the baseline rule for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return full-resolution image data for the gallery lightbox.' It uses a specific verb ('Return') and resource ('full-resolution image data'), and the context 'App-only helper called by the gallery lightbox' distinguishes it from user-facing image tools. However, it does not explicitly differentiate itself from sibling tools like show_image, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it is an 'App-only helper called by the gallery lightbox to load a single image.' This implies it is not for direct user invocation, but it offers no explicit exclusions or alternatives (e.g., 'use show_image for user-facing display'). No when-not-to-use guidance is provided, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior, so the description adds value by explaining the helper/pagination nature and the direct-invocation caveat. It does not contradict annotations or the schema, and the read-only hint is consistent with 'Return a page'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear action, and every sentence earns its place. It avoids marketing fluff, tautology, or repetition of the title/schema, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 optional params, read-only), and the description, combined with a rich schema and output schema, fully explains its purpose, usage boundary, and pagination behavior. It tells the agent exactly when to use it (by the UI) and when not to (direct model invocation), leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions (page, origin, page_size), so the description doesn't need to add parameter-level meaning. It provides only a high-level 'page of thumbnails' context, which is not parameter-specific. Schema carries the semantic load, meriting baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Return a page of image thumbnails') and resource ('gallery UI'), immediately distinguishing itself from sibling tools like show_image or gallery_full_image. It also adds scope ('pagination') which reinforces its unique role among gallery tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is an 'App-only helper called by the gallery UI' and 'Not intended for direct model invocation,' giving clear when-to-use and when-not-to-use guidance. It doesn't explicitly name alternatives, but the exclusion is strong and contextually sufficient given sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint annotation by explaining the output format (JSON with resource metadata) and the difference between static resources (uri) and templates (uri_template). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, front-loaded with the primary purpose, and every sentence provides valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, output schema present), the description is complete. It explains the two types of resources and the field naming convention, which is all that is needed for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter semantics, and it correctly avoids inventing non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'resources and resource templates', which distinguishes it from siblings like read_resource. It is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly mention when to use it over alternatives like read_resource or list_providers. Usage context is implied by the tool's purpose, but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: editor transforms are persistent and user-facing, while resource template transforms are ephemeral and LLM-facing. This clarifies the tool's role 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The second sentence efficiently distinguishes this tool from resource templates. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with strong annotations and full schema coverage, the description is mostly complete. However, it does not clarify the return behavior after opening the editor or explicitly state that the original image is preserved when saving a new image, leaving slight ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents image_id (100% coverage), so the baseline is 3. The description adds the useful point that edits apply to the original image, not a resource template, helping the AI understand the parameter's meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Open an image for interactive editing' and includes concrete operations (crop, rotate, flip). It clearly distinguishes this from viewing or browsing tools, and the saving-as-new-image behavior adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for persistent, user-facing edits and contrasts it with ephemeral resource template transforms. However, it does not explicitly name alternative tools or say when not to use it, so it misses the full mark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the safety profile is clear. The description adds value by detailing the exact return fields (server_name, server_version, core_version, upstream block) and the condition for upstream, which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, good annotations, and an output schema exists. The description covers the purpose and return data sufficiently for a simple informational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% trivially. Following the '0 params = baseline 4' rule, the description does not need to add parameter info, and it doesn't contradict anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports version info (server_name, server_version, core_version, optional upstream) for image-generation-mcp, which distinguishes it from sibling tools focused on images and generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is useful for verifying deployment matches expected build, providing a clear use case. It does not compare to alternatives, but given no similar version-checking siblings, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations, including the caching behavior of force_refresh, the semantic difference between 'clip' and 'natural_language' prompt styles, and the refreshed_at timestamp. However, it doesn't fully detail the response structure, though that is covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, leading with the core purpose and following with useful details about prompt_style, refreshed_at, and force_refresh. Every sentence earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema and robust annotations, the description provides all necessary context: return contents, prompt_style semantics, refresh behavior, and the alternative resource access. It is complete and leaves no critical gaps for an agent to trip over.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of force_refresh ('if providers may have changed') echoes the schema's already detailed description rather than adding new meaning. It provides no additional semantics beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement: 'List available image generation providers, models, and capabilities.' This clearly distinguishes the tool from siblings like get_server_info or gallery_page. It also provides additional detail about prompt_style and refreshed_at, further clarifying the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditional guidance: 'Pass force_refresh=true if providers may have changed since the last check.' It also mentions an alternative representation (info://providers resource), helping an agent decide between tool vs. resource access. This is clear usage guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds important context about requiring completed images and encoding transforms in the URI query string. It does not contradict the annotations and provides practical guidance on usage constraints beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose, followed by concise usage instructions and a resource pointer. It avoids unnecessary fluff, though the 'no separate parameters needed' note is slightly redundant given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers when to use the tool, the prerequisite of completed images, the URI format with examples, and how to discover available images. This is sufficient for a one-parameter display tool with supportive annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of the single 'uri' parameter, and the description adds examples of valid URIs and explains the query-string transform mechanism. While not extensive, the examples and explanation help clarify how to construct the URI, exceeding what the schema alone offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays a completed image with optional on-demand transforms, using a specific verb and resource. It distinguishes itself from sibling tools by explicitly limiting use to completed images and referencing check_generation_status for polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool ('Only call this for completed images') and how to coordinate with check_generation_status. It also directs users to the image://list resource for browsing IDs, providing clear exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations indicating readOnlyHint and idempotentHint, the description adds valuable behavioral context: it returns a 'short JSON status — no image data, no heavy UI,' which signals lightweight polling. It also enumerates possible return values ('completed', 'generating', 'failed') and the associated next steps. This goes beyond annotations and helps the agent understand expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the purpose, the second gives usage context, and the bulleted list concisely explains the status outcomes. No unnecessary words or repetition; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with one parameter and an output schema, the description is complete. It explains the return statuses, the expected next actions, and notes that it returns no image data. With annotations covering safety and idempotency, and the output schema documenting return structure, the description sufficiently covers all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (image_id is fully described as 'The image_id returned by generate_image'). The description doesn't add extra parameter details beyond referencing generate_image, which is consistent with the schema. Since the schema already documents the parameter well, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check whether a background image generation has finished.' This is a specific verb+resource (check status of generation) and clearly differentiates from siblings like show_image (display) and edit_image (edit). It also places the tool in the workflow by saying 'Call this after generate_image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call this after generate_image to wait for completion.' It also gives context on how to handle each returned status, including waiting and re-checking or advancing to show_image. This effectively tells the agent when and how to use the tool in a polling loop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds significant behavioral context: it reads from the 'scratch directory', returns thumbnail previews, and describes the response shape for non-UI clients including pending vs. completed items. This goes well beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: an opening summary sentence, then response-format details for non-UI clients, then explicit usage guidance. Every sentence contributes either behavioral transparency or usage direction. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, but rich annotations, the description covers the response format, filtering behavior, and usage notes. It provides everything an agent needs to select and invoke the tool correctly, including how pending items behave. The context is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the 'origin' parameter with enum and default. The description adds a valuable nuance: 'a pending generation always counts as generated', which is not in the schema. This extra semantic detail justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as browsing all generated images in an interactive gallery, with a specific verb ('browse') and resource ('generated images'). It distinguishes itself from show_image by explicitly stating 'Use browse_gallery to see all images; use show_image... to view one image at full resolution.' This provides clear differentiation from a key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to see all images') and points to an alternative (show_image for a single full-resolution view). It also gives context about non-UI clients receiving a JSON response, which helps agents decide how to invoke and parse the result. This exceeds the high calibration example's guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![image-generation-mcp MCP server](https://glama.ai/mcp/servers/pvliesdonk/image-generation-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pvliesdonk/image-generation-mcp)

Score Badge

Copy to your README.md:

[![image-generation-mcp MCP server](https://glama.ai/mcp/servers/pvliesdonk/image-generation-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pvliesdonk/image-generation-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pvliesdonk/image-generation-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server