designforyou
Server Details
Generate logos, social posts, app screenshots, comic panels & visual-novel assets from prompts.
- 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 4.3/5 across 8 of 8 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose: browsing templates, editing text, generating designs, generating variations, checking credits, listing text fields, recommending templates, and generating VN sprite sheets. No significant overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., browse_templates, edit_text, get_credits), making them predictable and easy to understand.
With 8 tools, the server is well-scoped for a design template service. The count covers the main workflow without being excessive or insufficient.
The tools cover browsing, recommending, generating, editing, and credit checking. Minor gap: no explicit tool for listing user's previously created designs or deleting them, but the core lifecycle is well represented.
Available Tools
8 toolsbrowse_templatesBrowse templatesARead-onlyInspect
Browse the DesignForYou template catalog. Optionally filter by category (e.g. 'instagram', 'app-store', 'logo'). Returns template IDs, names, and previews.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (e.g. 'instagram', 'app-store', 'logo') | |
| subcategory | No | Optional subcategory filter (e.g. 'lettermark', 'wordmark', 'app_icon') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context beyond stating it returns IDs, names, and previews. No mention of auth or side effects, but annotations cover the safety profile.
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 short sentences, front-loaded with the main action, and 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?
For a read-only browse tool with two optional parameters and no output schema, the description is largely complete. It could mention pagination or ordering, but it's not essential given the tool's simplicity.
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%; both parameters have descriptions. The description adds examples for category but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses the DesignForYou template catalog, with optional filtering and specific return values. It is distinct from sibling tools like generate (creation) or edit_text (modification).
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 implies usage for browsing templates, but does not explicitly compare to siblings like recommend_template or explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_textEdit design textAInspect
Change the text on an EXISTING generated design without regenerating it — pass the design's image URL plus from/to text pairs (e.g. from='SALE' to='50% OFF'). Costs credits, but is faster and cheaper than a full re-generate. Use when the user only wants to fix wording on an image you already produced.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | URL of the design image to edit | |
| text_changes | Yes | Array of text changes as {from, to} pairs |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive; description adds costs-credits and faster/cheaper comparison. No contradiction. Provides useful behavioral context beyond structured fields.
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 concise sentences, front-loaded with main action, then details and use case. Every sentence adds value. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 2 params, no output schema, and minimal complexity. Description covers purpose, usage, behavioral traits, and parameter structure adequately. No major 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 coverage is 100% with descriptions for both parameters. Description adds example (from='SALE' to='50% OFF') and clarifying 'from/to text pairs', but schema already covers essentials. 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?
Description clearly states verb+resource: 'Change the text on an EXISTING generated design without regenerating it.' Distinguishes from siblings like 'generate' (full regenerate) and 'get_text_fields' (likely reads text).
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?
Explicit use case: 'Use when the user only wants to fix wording on an image you already produced.' Compares with alternative (full regenerate) mentioning speed and cost benefits. No explicit when-not-to-use, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generateGenerate designAInspect
Generate one or more finished images from a template (get a template_id from recommend_template or browse_templates) plus a description. When the user has described what they want, pick the best-matching template and generate directly — don't ask them to choose a template unless they request options. Works for all categories (Instagram, logo, app-store, Visual Novel backgrounds/sprites, CG illustrations). Pass variants for multi-image output (expressions, time-of-day, etc.). Pass session_id to refine a prior result. Pass context_ids to ground a new image on prior designs (character consistency for VN CG scenes).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional image model override, such as grok-imagine-image-quality, gemini-3.1-flash-image, or gpt-image-2. | |
| variants | No | For character sheets: expression names e.g. ['neutral','smile','angry']. For backgrounds: time variants e.g. ['day','sunset','night']. For single images: omit or pass ['default']. | |
| edit_tier | No | Quality tier when reference images (context_ids) are supplied. 'expert' routes the edit to gpt-image-2 for high-fidelity output; 'fast'/'pro' use Gemini. Ignored when no references are present. | |
| session_id | No | Pass the session_id from a prior generate call to continue refining. The model will edit the previous image instead of generating from scratch. | |
| context_ids | No | Design IDs of prior outputs to use as visual context. Use for CG scenes that should match a previously generated character. | |
| description | Yes | What you want - describe the scene, asset, or design in as much detail as needed | |
| template_id | Yes | Template ID from browse_templates | |
| context_labels | No | Optional human labels for each context_id, in the SAME order. When the edit routes to a multi-reference model (gpt-image-2), an ordered legend ('reference image 1 = <label>, ...') is appended to the prompt so the model binds each named subject to its own reference instead of blending identities. Ignored for single-reference edits. | |
| skip_prompt_merge | No | Skip the smart prompt-merge step (which compresses to ~150 words) and send the description through verbatim, with the template's base prompt concatenated for style. Use when the description is already complete and precise — e.g. a multi-character scene where each subject's outfit and a reference->subject legend must survive intact. Ignored on refines. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false, openWorldHint=true, destructiveHint=false. The description adds significant detail: behavior for refining (session_id), multi-image output (variants), context grounding (context_ids), quality tiers (edit_tier), and prompt merging (skip_prompt_merge). No contradiction with 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 a single paragraph, fairly long but well-structured. It front-loads the core purpose and then explains parameters. A bit verbose, but every sentence adds value. Could be more concise, but still effective.
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 complexity (9 parameters, no output schema), the description covers all usage scenarios comprehensively. It explains when to use each parameter, the categories, and how to achieve multi-image output or character consistency. Leaves no obvious gaps for an agent.
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% (all 9 parameters described). The description adds meaning beyond schema, e.g., explaining how to obtain template_id, usage of variants for character sheets vs backgrounds, and when to use edit_tier. Provides clear real-world use cases for each parameter.
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 finished images from a template plus a description, specifying categories like Instagram, logo, app-store, etc. It distinguishes from sibling tools like recommend_template and browse_templates by telling agents to get a template from those tools first.
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 explicit guidance: 'don't ask them to choose a template unless they request options', and explains when to use variants, session_id, context_ids, edit_tier, and skip_prompt_merge. It directly advises the agent on decision-making, making it easy to use correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_variationsGenerate design variationsAInspect
Generate several style variations of one template in a single call — returns multiple designs with different looks. Use when the user wants OPTIONS to compare ('show me a few directions'); for a single final design use generate instead. Costs credits per variation.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of variations to generate (default: 3, max: 10) | |
| quality | No | Image quality: 'pro' (default, high quality) or 'fast' (quick thumbnails) | pro |
| template_id | Yes | The template ID to generate variations for | |
| text_overrides | No | Optional text overrides as key-value pairs (field_name → new_text) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds cost information ('Costs credits per variation') beyond annotations. Could further disclose response structure or failure handling.
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, front-loaded with core purpose, no 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?
Covers purpose, usage context, cost, and alternative. No output schema, but returns multiple designs is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions; description adds no extra semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it generates multiple style variations of a template in one call, distinguishing from sibling 'generate' which produces a single design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use when user wants options to compare, and directs to 'generate' for a single final design, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_creditsCheck credit balanceARead-onlyInspect
Return the authenticated user's current credit balance, usage, and Stripe subscription status. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating safe read. The description adds that it is 'Free to call' and returns specific data fields, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The main action and outputs are front-loaded, and the extra note about being free is concise.
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 no parameters and no output schema, the description sufficiently explains the return values (credit balance, usage, subscription status), making it complete for a simple read tool.
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 description does not need to add parameter info. The baseline of 4 applies, and the description provides context on what is returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns credit balance, usage, and Stripe subscription status. It uses specific nouns and verbs, and is distinct from sibling tools which are about templates and generation.
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 implies usage context by stating it returns authenticated user's credit info. It does not explicitly mention when not to use or compare to alternatives, but the sibling tools are unrelated, so guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_text_fieldsGet template text fieldsARead-onlyInspect
List a template's editable text fields (headline, subhead, CTA, etc.) with their current values. Free. Use right after a template is chosen and BEFORE generate when you want to fill the template's fields precisely instead of relying on a freeform description.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | The template ID to get text fields for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true, and the description's 'List' action aligns perfectly. Additionally, it adds that the tool is free (no cost), which is beyond annotations and provides useful behavioral 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?
Two sentences: first states purpose, second provides usage guidance. No redundant information, front-loaded, and every sentence serves a distinct informative purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers what the tool returns (editable text fields with current values), its scope (template-specific), and prerequisites (template chosen). No 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 coverage is 100%, so the description does not need to elaborate on parameters. The description simply reinforces the usage context without adding new semantic detail 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 uses a specific verb ('List'), names the resource ('template's editable text fields'), includes illustrative examples ('headline, subhead, CTA'), and distinguishes from siblings like 'edit_text' and 'generate' by implication (listing vs. modifying).
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 when to use ('right after a template is chosen and BEFORE generate'), when not to rely on it ('instead of relying on a freeform description'), and notes it's free.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_templateRecommend a templateARead-onlyInspect
Recommend the best matching templates for any use case. Describe what you need and the system auto-detects the category and ranks templates by relevance. When the user has clearly described the design they want, take the top recommendation and call generate directly in the same turn — only ask them to pick if they explicitly want to compare options.
| Name | Required | Description | Default |
|---|---|---|---|
| needs | No | Optional explicit needs such as favicon, navbar, og-image | |
| category | No | Optional category override. Auto-detected from use_case if not provided. | |
| use_case | Yes | Describe what you need the template for (e.g. 'Instagram post for a restaurant daily special', 'logo for a fitness brand') | |
| subcategory | No | Optional subcategory constraint such as lettermark or app_icon |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-open-world behavior. The description adds context about auto-detecting category and ranking templates, but does not describe the response format, which is a minor gap given no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: main purpose, automatic behavior, and usage guidance. No fluff, front-loaded with the essential function.
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, behavior, and usage well. The lack of output schema details is partially mitigated by guidance to call generate next, but explicit response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description implies use_case as primary and mentions auto-detection for category, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends templates based on a use case description, with auto-detection of categories and ranking by relevance. It distinguishes itself from sibling tools like 'browse_templates' and 'generate' by guiding the agent to call generate directly when the user's design is clear.
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 guidance: use this tool to get recommendations, then call generate if the user is clear, or let them compare if they want. This tells the agent exactly when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vn_generate_sprite_sheetGenerate VN sprite sheetBInspect
Generate one fixed-grid visual-novel character sprite sheet, crop it into cell assets, remove the chroma-key background, validate transparent sprites, and return a VN Creator-ready manifest.
| Name | Required | Description | Default |
|---|---|---|---|
| cells | Yes | ||
| model | No | Image model override for the source sheet, e.g. gemini-3.1-flash-image. | |
| sheet | Yes | ||
| style | Yes | ||
| output | No | ||
| quality | No | ||
| provider | No | Image provider override for the source sheet, e.g. gemini, grok, or a known model alias. | |
| character | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it reveals steps like cropping, chroma-key removal, and validation. Annotations indicate non-destructive and open-world, which align with the described creation process. 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 sentence that front-loads the main action. It is concise and covers all major steps without redundancy. Slightly verbose due to listing multiple steps, but still efficient.
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 (8 params, nested objects, no output schema), the description lacks detail on parameter usage and return format. It mentions a 'VN Creator-ready manifest' but doesn't specify its structure. An agent would need more information to invoke it 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?
With only 25% schema coverage, the description should compensate by explaining parameters, but it does not. It provides no details about what 'character', 'style', 'cells', etc., mean. The generic overview does not add value beyond the schema names.
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 specific purpose: generating a fixed-grid VN character sprite sheet, cropping, chroma-key removal, validation, and returning a manifest. It uses specific verbs and resources, distinguishing it from sibling tools like 'generate' or 'generate_variations'.
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 direct guidance on when to use this tool versus siblings. It does not mention use cases, prerequisites, or exclusions. The description only lists actions without contextualizing against 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!