distribea-mcp
Server Details
Brand-aware image generation MCP, powered by Nano Banana Pro — on-brand, production-ready images.
- 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.1/5 across 10 of 10 tools scored. Lowest: 2.9/5.
Each tool has a clear, distinct purpose: blog_cover for article covers, brand_pack for brand assets, bring_alive for page imagery suggestions, create_reference for registering real photos, edit_image for retouching, forget_project for resetting memory, generate_image for single image generation, list_projects for listing projects, pack_status for account info, and site_style for style management. No overlapping functionality.
Tool names mix conventions: some are verb_noun (create_reference, edit_image), others are noun phrases (blog_cover, brand_pack, pack_status, site_style), and one is verb_adjective (bring_alive). While readable, the inconsistency may confuse an agent expecting a uniform naming pattern.
With 10 tools, the set is appropriately scoped for a brand-consistent image generation service. It covers style setup, image generation, editing, brand assets, project management, and reference management without being bloated or insufficient.
The tool surface covers the core workflow: style setup, image generation, reference management, editing, and project tracking. Minor gaps exist (e.g., no explicit image deletion, no full image history beyond latest), but agents can work around them.
Available Tools
10 toolsblog_coverCover (and illustrations) for an articleAInspect
Generates the 16:9 cover of an editorial article from ITS specific topic (never a generic photo), consistent with the site's style. Returns the CDN URL + an tag. Provide the article via article_text (pasted text) or article_url (public link). illustrations:N adds N images inside the article.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional title (overrides the one read from the source) | |
| product | No | Optional: name of a locked product to deliberately feature on the cover | |
| project | No | Optional: site identifier. Default: "lovable". | |
| character | No | Optional: name/role of a locked character to deliberately feature on the cover | |
| article_url | No | Public URL of the article — its text is read for you | |
| orientation | No | Cover shape — default "wide" (16:9) | |
| article_text | No | The article text (title + body), pasted directly | |
| illustrations | No | Extra images inside the article (default 0, max 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the generation behavior (never generic photo, consistent with site style), the return format (CDN URL + img tag), and the ability to add illustrations. It does not mention auth or error cases but adequately describes core 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?
The description is concise with three sentences, each serving a purpose: first states main function, second adds return info and input methods, third explains the illustrations parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description covers main behavior, parameter usage, and constraints. It does not cover edge cases like conflicting inputs or error handling, but it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how article_text and article_url are alternative inputs, and that illustrations adds N images inside the article. It also clarifies that title overrides the read title and product/character lock specific features.
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 16:9 cover for editorial articles from a specific topic, not a generic photo, and adds illustrations. This distinguishes it from sibling tools like generate_image or edit_image, which are more generic.
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 specifies that the article can be provided via article_text or article_url, and that illustrations:N adds images. While it gives clear context on how to use the tool, it does not explicitly state when not to use it or compare it with alternatives like generate_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brand_packLogo, favicon pack, social (link-preview) imageAInspect
The brand finishing pack. action 'all' (default) chains: logo (clean lettering, correct spelling) + favicon pack (favicon.ico, apple-touch-icon, 192/512 PNG incl. maskable, site.webmanifest) + social image (og:image, needs a title). Or one piece: 'logo' | 'favicons' | 'social_image'. Returns the logo as an to place in the header, the favicon FILES (base64) to write into /public + the tags, and the og:image tags. Optionally derive the favicon from a given logo via image_base64/image_url.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | social_image: title written on the image (required for social_image; also enables it in 'all') | |
| action | No | Default 'all' | |
| project | No | Optional: site identifier. Default: "lovable". | |
| tagline | No | logo: optional small tagline under the brand name | |
| subtitle | No | social_image: optional smaller subtitle | |
| image_url | No | favicons: optional logo/icon URL to derive the pack from | |
| background | No | favicons: solid background colour behind the icon (default white) | |
| image_base64 | No | favicons: optional existing logo/icon (base64) to derive the pack from |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool returns outputs (logo as img, favicon files as base64 plus head tags, og:image meta tags) and that it can derive favicons from a given logo. It does not mention destructiveness or permissions, but the tool appears safe and idempotent. The description adds useful behavioral context beyond the 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?
The description is a single paragraph that efficiently conveys the core functionality, action options, and return values. It front-loads the purpose and then lists details. While it could benefit from bullet points for clarity, it is still well-structured and 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?
Given no output schema and no annotations, the description covers all necessary aspects: what each action produces, the return format (img, base64 files, head/meta tags), and optional parameter usage. It mentions specific file names (favicon.ico, apple-touch-icon, etc.) and conditions like deriving favicons from a logo. This completeness supports correct agent 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 coverage is 100%, so baseline is 3. The description adds context: explains that 'title' is required for social_image, 'tagline' for logo, 'subtitle' for social_image, and 'image_url'/'image_base64' for favicons. It clarifies the role of 'project' as a site identifier and the default action. This additional meaning merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a brand finishing pack including logo, favicon pack, and social image. It distinguishes each component and specifies that action 'all' chains them, while individual pieces can be requested. This specificity differentiates it from sibling tools like blog_cover or site_style.
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 explains the default action and how to request single pieces, with examples like 'logo', 'favicons', 'social_image'. It also mentions optional derivation from an existing logo. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so it gets a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bring_aliveBring a page to life (propose new spots + replace existing images)AInspect
Make an EXISTING page feel alive with on-brand imagery. It PROPOSES (free, generates nothing): (1) where to ADD images in sections that have none (hero, testimonials, team/about, a key benefit, gallery…), and (2) it returns the page's EXISTING tags so you can REPLACE them too. DEFAULT BEHAVIOR — replace every existing image with an on-brand one UNLESS the user explicitly asks to keep a specific image; if the user only wants to add images, leave the existing ones untouched. WORKFLOW: show both lists, ask which to KEEP; then for approved NEW spots insert the given placeholder at its anchor and call generate_image to fill it, AND for each existing image to replace, call generate_image with a matching subject and swap that image's src. Use this BEFORE generate_image whenever a page's imagery is missing or off-brand. Pass the page's current code as page_text.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: site identifier. Default: "lovable". | |
| page_text | Yes | The current code (or visible text) of the page to bring alive |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the default behavior (replace existing images unless user asks to keep) and workflow. It clarifies that it only proposes and returns data, not generates images. It could mention if any state changes occur, but overall it is transparent.
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 detailed but every sentence is necessary. It is front-loaded with the core purpose, and the structure flows logically from purpose to workflow to usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns: proposed spots with anchors and a list of existing img tags. The workflow is fully described, making the tool's role clear in the broader process.
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 description coverage is 100% with clear descriptions for both parameters. The description adds context, such as how to use page_text ('pass the page's current code') and the default for project. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: making an existing page feel alive by proposing new image spots and returning existing img tags for replacement. It distinguishes itself from sibling tools like generate_image by stating it should be used before that tool.
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 explicitly says when to use this tool: 'Use this BEFORE generate_image whenever a page's imagery is missing or off-brand.' It also provides a detailed workflow. However, it doesn't explicitly state when not to use it, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_referenceLock a real photo (face, product or shop) reused identicallyAInspect
Register a REAL photo so Distribea reuses it IDENTICALLY in generated images — the user's own person, product or place. kind 'character' = a recurring face (founder, baker…), 'product' = the exact same object, 'place' = the real shop/location. Give the photo as image_base64 (the uploaded file's bytes — MOST RELIABLE) or image_url (a PUBLIC image URL). Free (0 credits) when a photo is given. AFTER this, call generate_image with character:"" (or product:"") to feature that exact reference in a scene. For a whole product range at once, pass items:[{name,image_base64|image_url}].
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Default 'character' (a recurring face) | |
| name | No | What to call it: a role ("le boulanger"), a product name ("Tarte pralinée"), or a place ("la boulangerie") | |
| items | No | Register several products/places at once: each {name, image_base64 or image_url, description?}. | |
| project | No | Optional: site identifier. Default: "lovable". | |
| image_url | No | Public URL of the photo (fallback if no base64) | |
| description | No | Optional physical description (product/place) | |
| image_base64 | No | The photo bytes as base64 (raw or data-uri). Preferred — works even when the image isn't on a public URL. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the free cost, preferred image input method (base64), and the effect of registering a reference for later use. It does not mention rate limits or idempotency, but covers key behaviors for a mutation tool.
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 dense paragraph. It packs all information but could be better structured with bullet points or clearer separation of core usage, parameter roles, and follow-up steps. Adequate but not optimally 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?
Given 7 parameters (mostly optional), 100% schema coverage, no output schema, and no sibling overlap, the description sufficiently covers purpose, parameter semantics, and workflow context. It explains the crucial follow-up step, making the tool's role clear 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%, but the description adds significant value beyond schema definitions: it explains the semantic purpose of each kind, the workflow linkage to generate_image, and the bulk registration capability via items. This enrichment justifies a score above baseline.
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 registers a real photo for identical reuse in generated images. It distinguishes three kinds (character, product, place) and explains each, making it distinct from sibling tools like generate_image or blog_cover.
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 explicit when-to-use guidance, including the follow-up call to generate_image with the registered name. It also notes free credits and bulk registration via items, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_imageRetouch an existing image (edit, redo, cutout, upscale, extend)AInspect
Retouch an image the user already has (pass it as image_base64 or image_url). action 'edit' (default): a plain-language change (remove an object, change the background, relight; apply_style=true to also match the site's locked look); 'redo': a feedback tweak; 'remove_background': transparent PNG cutout; 'upscale': ×4; 'extend': widen to a new aspect_ratio, the scene continues seamlessly. Returns the NEW image's CDN URL + an tag — swap the original's src with it. Billed; use only on the user's explicit request.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Default 'edit' | |
| project | No | Optional: site identifier. Default: "lovable". | |
| image_url | No | Public URL of the image to retouch (fallback) | |
| out_format | No | Output format (default webp; cutouts stay png) | |
| apply_style | No | edit only: also match the site's locked style | |
| instruction | No | edit/redo: what to change, plain language | |
| aspect_ratio | No | extend only: target frame (default 21:9) | |
| image_base64 | No | The image to retouch, as base64 (preferred) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses billing, return format (CDN URL + img tag), and per-action behavior. However, lacks details on error handling, rate limits, or whether the original image is preserved.
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?
Single well-organized paragraph front-loads purpose, then details each action. No redundant sentences.
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 all parameters and return values. Missing error cases or validation details, but adequate for a tool with comprehensive schema.
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?
Adds context beyond schema (e.g., default action 'edit', examples of plain-language instructions, apply_style specifics). Schema coverage is 100%, so description enhances understanding.
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 retouches existing images with specific actions (edit, redo, remove_background, upscale, extend). It distinguishes from sibling tools like generate_image by focusing on editing rather than creation.
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 describes when to use each action (e.g., 'remove_background' for transparent cutout, 'upscale' for ×4) and warns that it's billed and only for explicit user requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forget_projectForget a project's memory (start fresh)AInspect
Wipe a project's saved memory (locked style, characters, products) so it starts fresh. Nothing on the page is touched. Free. Use when a reused project carries over unwanted style or products.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Site identifier to wipe. Default: "lovable". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what is wiped (memory) and what is not (page), and that it's free. No annotations provided, so description handles behavioral disclosure well, though could note irreversibility.
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 with clear front-loading and no wasted words. Every sentence adds value: action, scope, and usage guidance.
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 low complexity (1 param, no output schema), description fully covers purpose, usage, parameter meaning, and behavioral impact. No missing information.
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?
Only one parameter 'project' with description including default value 'lovable'. Schema coverage is 100%, but description adds context beyond schema's basic description.
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?
Title says 'Forget a project's memory (start fresh)' and description specifies wiping saved memory (locked style, characters, products) while leaving page untouched. Distinguishes from siblings like site_style or list_projects.
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 'Use when a reused project carries over unwanted style or products' and notes it's free. Does not list when not to use or mention alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageGenerate a brand image for a siteAInspect
Generates ONE image consistent with the site's style and returns its CDN URL + a ready-to-paste tag. A subject mentioning a review/testimonial/avatar automatically switches to a realistic customer selfie (UGC). Ideal for heroes, about, sections, cards…
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | Optional: name of a locked product to show (identical object) | |
| project | No | Optional: site identifier (to keep a consistent style across its images). Default: "lovable". | |
| subject | Yes | What the image shows, e.g. "hero photo: modern villa at sunrise" | |
| character | No | Optional: name/role of a locked character to feature (same face). Pass "none" to FORCE no face (stops a locked founder/team face being auto-attached here). | |
| brand_text | No | If true, the brand name appears as a clean physical sign in the image | |
| orientation | No | Default: landscape | |
| cross_site_unique | No | Review/avatar subjects only. Default false. true = reviewer faces never repeat across ALL the user's sites. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It reveals that the tool generates one image, returns specific outputs, and auto-switches for certain subjects. However, it does not mention side effects (e.g., storage, idempotency), rate limits, or potential variation in style consistency, leaving moderate transparency gaps.
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-loading the core purpose and output, then adding key behavioral nuance. Every sentence is informative with 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?
Given the complexity (7 params, no output schema), the description covers main behavior and parameter nuances. It does not detail error handling or style inheritance, but it is sufficient for an agent to understand the primary functionality and constraints.
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 covers all 7 parameters (100% coverage), but the description adds meaning beyond the schema by explaining automatic behavior (review subjects trigger selfie), the 'none' option for character to force no face, and cross_site_unique behavior for avatars.
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 ONE image consistent with the site's style and returns a CDN URL and ready-to-paste img tag. It also mentions automatic switching for review/testimonial/avatar subjects, distinguishing it from sibling tools like blog_cover or edit_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 includes 'Ideal for heroes, about, sections, cards…' which gives usage context. However, it lacks explicit when-not-to-use guidance or direct comparisons to sibling tools, though the behavioral details (auto-switch for review subjects) implicitly guide proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList your Distribea projectsCInspect
List the projects saved on the account (name, brand, image count, products). To keep working on one, reuse its name in the project: parameter of your calls. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: current site identifier. Default: "lovable". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose behavioral traits. It fails to mention if the operation is read-only, safe, or requires authentication. The word 'Free.' is ambiguous. Listing what fields are returned is helpful but insufficient.
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, mostly concise. The inclusion of 'Free.' is unnecessary and slightly distracts. The structure could be improved by separating parameter instructions.
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?
No output schema exists, but the description only lists fields without explaining return structure, pagination, or error conditions. The parameter ambiguity and lack of comparison with sibling tools make it incomplete for an agent to use 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?
Schema coverage is 100%, but the description's interpretation of the parameter ('reuse its name') conflicts with the schema description ('current site identifier'). This adds confusion rather than clarity, reducing the 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 verb 'List' and the resource 'projects' with details like name, brand, image count, and products. However, the mention of 'Free.' is irrelevant and the parameter description in schema contradicts the tool description (project name vs current site identifier), slightly reducing clarity.
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 limited guidance: it tells to reuse the project name in the parameter to continue working. However, it does not compare with siblings like forget_project or specify when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pack_statusCredit balance and current styleBInspect
Shows the Distribea credit balance, the locked style, the known characters/products/avatars, and the latest generated images. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: site identifier. Default: "lovable". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Shows' implying read-only. No disclosure of authentication requirements, rate limits, or other behavioral traits.
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?
Description is one sentence plus 'Free.' which is unnecessary. Could be more concise without the extraneous note.
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 status tool with one optional param and no output schema, the description adequately lists the key data displayed. Missing details about return format but acceptable given 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% with a well-documented optional parameter. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows multiple specific pieces of information (credit balance, locked style, known characters/products/avatars, latest generated images), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings (e.g., site_style). No when-not or alternative suggestions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
site_styleSet or adjust the site's visual styleAInspect
The site's art direction. action "setup": locks the style from a brief and/or the URL of an existing site (run this FIRST for consistent images). action "refine": plain-language feedback ("warmer") OR a correction of a misrepresented subject — the rule is recorded and honored by every subsequent image.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | setup: plain-language brand brief (business, mood…) | |
| force | No | setup: true to let the engine guess if the brief is short | |
| action | No | "setup" (default) to set the style, "refine" to adjust/correct it, "lock_image" to anchor the style on an approved image (pass image_base64/image_url) | |
| project | No | Optional: site identifier. Default: "lovable". | |
| feedback | No | refine: what to change or correct, in plain language | |
| site_url | No | setup: URL of an existing site to draw inspiration from (optional) | |
| image_url | No | lock_image: public URL of the approved image (fallback) | |
| moodboard | No | setup, ONLY on request: also generate a 2×2 moodboard image of the locked style (billed as 1 image) | |
| image_base64 | No | lock_image: the approved image's bytes as base64 — its look becomes the permanent style anchor |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two main actions and their effects: 'setup' locks the style from a brief/URL, and 'refine' records a rule to be honored by subsequent images. It does not address whether repeated calls overwrite, potential destructive effects, or any rate limits. Given no annotations, the description partially shoulders the transparency 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 concise: two sentences, each dedicated to one main action. It front-loads the core concept ('The site's art direction') and provides clear, actionable details. It could be more organized (e.g., bullet points), but it is efficient and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters and no output schema, the description covers the primary actions and key parameters (brief, site_url, feedback) but does not explain the roles of 'force', 'project', 'moodboard', 'image_url', or 'image_base64'. The schema documents them, but the description alone leaves gaps for an agent to infer complete usage context.
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 100% schema coverage, the baseline is 3. The description adds value by explaining the purpose of 'action', 'brief', 'site_url' (for setup), and 'feedback' (for refine) in a narrative that goes beyond the schema's parameter descriptions. It omits specifics for 'force', 'project', 'moodboard', 'image_url', and 'image_base64', but the overall context aids understanding.
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 manages the site's art direction, with specific actions 'setup' and 'refine' that lock or adjust the style. It distinguishes itself by focusing on site-wide visual branding rather than individual image generation, making its purpose concrete and distinct from siblings.
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 advises to 'run this FIRST for consistent images' for the 'setup' action, providing clear sequencing guidance. It also explains the 'refine' action's role for adjustments. However, it does not explicitly exclude when not to use this tool versus alternatives like 'brand_pack' or 'generate_image', limiting full discrimination.
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!