Skip to main content
Glama

Cluby MCP

by com.cluby.api
OverviewDiscussionsAdmin

Import image

import_image

Import a photo from a public https URL into the organization's image storage, the same as picking an image in the Partner Hub. Returns originalUrl and images; pass images unchanged as a benefit's content.images in create_benefit or update_benefit, which wait for the processed versions before saving. Only images imported this way (or image sets already on a Cluby benefit) are accepted by the benefit write tools; a birthday gift takes the originalUrl as content.imageUrl.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublic https URL of the image
orgIdNoOrganization public id, the `id` field from list_orgs. Omit it when the API key reaches exactly one organization.
attributionNoPhotographer credit for an Unsplash photo. Kept on every processed version so the credit travels with the image.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / attribution / properties / license
      Added value: +{
+  "description": "Wikimedia only, e.g. \"CC BY-SA 4.0\"",
+  "type": "string"
+}
    • addedInput schema / properties / attribution / properties / licenseUrl
      Added value: +{
+  "format": "uri",
+  "type": "string"
+}
    • removedInput schema / properties / attribution / properties / source / const
      Removed value: -"unsplash"
    • addedInput schema / properties / attribution / properties / source / enum
      Added value: +[
+  "unsplash",
+  "pexels",
+  "wikimedia"
+]
    • changedInput schema / properties / attribution / required
      Previous value: -[
-  "source",
-  "photoId",
-  "photographerName",
-  "photographerProfileUrl",
-  "sourceUrl"
-]New value: +[
+  "source",
+  "photoId",
+  "photographerName",
+  "sourceUrl"
+]
  2. Added

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover openWorldHint and destructiveHint, so the description carries the important semantics: it returns originalUrl and images, processing is asynchronous (write tools "wait for the processed versions"), and only imported images are accepted downstream. It does not mention auth requirements beyond the orgId note in the schema, or any failure modes for a non-public/dead URL, which keeps it short of a 5.

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?

Three sentences, front-loaded with the action and storage destination, then the return/pass-through contract, then the acceptance constraint. Every clause carries routing or contract information; no filler.

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?

With no output schema, the description supplies the return shape (originalUrl, images) and the exact downstream consumption contract, plus the constraint that other image sources are rejected. For a 3-parameter tool feeding two sibling write tools, nothing an agent needs is missing.

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 schema already documents url, orgId (including the omit-when-single-org rule) and the nested attribution object. The description adds no input-level meaning beyond that; its named fields (images, originalUrl) are return values, not parameters. Baseline 3 applies.

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?

States a specific verb and resource ("Import a photo ... into the organization's image storage") with an analogy to the Partner Hub UI action, and distinguishes itself from siblings by naming the tools it feeds (create_benefit, update_benefit, birthday gifts). An agent can tell this is the image-sourcing prerequisite step, not a content-writing tool.

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?

Explicitly states when to use it (before benefit writes, since those tools wait for processed versions) and encodes a hard constraint on alternatives: "Only images imported this way (or image sets already on a Cluby benefit) are accepted by the benefit write tools." It also routes the birthday-gift case differently (originalUrl as content.imageUrl), which is genuine conditional guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cluby MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources