Skip to main content
Glama
img-src-io

img-src MCP Server

by img-src-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

img-src MCP Server

Model Context Protocol (MCP) server for img-src.io image hosting API.

This server enables AI assistants like Claude to interact with your img-src.io account - uploading, searching, listing, and managing images directly through natural language.

Installation

pnpm add -g @img-src/mcp-server

Or run directly with pnpm dlx:

pnpm dlx @img-src/mcp-server

Related MCP server: Spronta MCP Server

Configuration

Environment Variables

Variable

Required

Description

IMG_SRC_API_KEY

Yes

Your img-src.io API key (starts with imgsrc_)

IMG_SRC_API_URL

No

API base URL (default: https://api.img-src.io)

Getting an API Key

  1. Log in to img-src.io

  2. Go to Settings > API Keys

  3. Create a new API key

  4. Copy the key (it starts with imgsrc_)

Usage with Claude Desktop

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Usage with Claude Code

Add to your project's .mcp.json (project-scoped) or ~/.claude/mcp.json (global):

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Or add it via the CLI:

claude mcp add img-src -- npx @img-src/mcp-server

Then set the API key in your environment or .env file:

export IMG_SRC_API_KEY=imgsrc_your_api_key_here

Usage with Cursor

  1. Open Cursor Settings (Cmd+, on macOS / Ctrl+, on Windows/Linux)

  2. Navigate to Features > MCP Servers

  3. Click "Add new MCP server"

  4. Enter the following configuration:

    • Name: img-src

    • Type: command

    • Command: npx @img-src/mcp-server

  5. Add the environment variable IMG_SRC_API_KEY with your API key.

Alternatively, create or edit .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Usage with VS Code (GitHub Copilot)

Create .vscode/mcp.json in your workspace:

{
  "servers": {
    "img-src": {
      "type": "stdio",
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Or add via CLI:

code --add-mcp '{"name":"img-src","command":"npx","args":["@img-src/mcp-server"],"env":{"IMG_SRC_API_KEY":"imgsrc_your_api_key_here"}}'

Note: VS Code uses "servers" (not "mcpServers") and requires "type": "stdio".

Usage with Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Usage with Cline

Open the Cline extension in VS Code, click the MCP Servers icon > Configure MCP Servers, then add:

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Usage with Zed

Add to your Zed settings (~/.config/zed/settings.json):

{
  "context_servers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Note: Zed uses "context_servers" as the key, embedded within the main settings.json.

Usage with JetBrains IDEs

In IntelliJ IDEA, WebStorm, PyCharm, or other JetBrains IDEs:

  1. Go to Settings > Tools > AI Assistant > Model Context Protocol (MCP)

  2. Click + (Add) and paste:

{
  "mcpServers": {
    "img-src": {
      "command": "npx",
      "args": ["@img-src/mcp-server"],
      "env": {
        "IMG_SRC_API_KEY": "imgsrc_your_api_key_here"
      }
    }
  }
}

Available Tools

upload_image

Upload an image from a local file, URL, or base64 data to your img-src.io account.

Upload ~/Photos/sunset.jpg to img-src as photos/vacation/sunset.jpg

Parameters:

  • file_path (optional): Local file path to upload (recommended for large files)

  • url (optional): URL of the image to upload

  • data (optional): Base64-encoded image data

  • mimeType (optional): MIME type of the image (required when using data)

  • target_path (optional): Target path for organizing the image

Note: One of file_path, url, or data must be provided.

list_images

List images in your account, optionally within a specific folder.

List my img-src images in the photos/vacation folder

Parameters:

  • folder (optional): Folder path to list

  • limit (optional): Max items to return (default: 50)

  • offset (optional): Items to skip for pagination

search_images

Search for images by filename or path.

Search for img-src images containing "beach"

Parameters:

  • query (required): Search query

  • limit (optional): Max results (default: 20)

  • offset (optional): Results to skip

get_image

Get detailed metadata for a specific image.

Get details for my img-src image at photos/vacation/sunset.jpg

Parameters:

  • id (required): Image ID (UUID) or filepath

delete_image

Permanently delete an image.

Delete my img-src image at photos/old/unused.jpg

Parameters:

  • id (required): Image ID (UUID) or filepath to delete

get_usage

View your current usage statistics.

Show my img-src usage stats

get_settings

Get your account settings and configuration.

What are my img-src account settings?

get_cdn_url

Generate a CDN URL with optional image transformations.

Generate an img-src CDN URL for john/photos/beach.jpg resized to 800x600

Parameters:

  • username (required): Image owner's username

  • filepath (required): Image path

  • width (optional): Resize width

  • height (optional): Resize height

  • fit (optional): cover, contain, fill, scale-down

  • quality (optional): 1-100 (default: 80)

  • format (optional): webp, avif, jpeg, png, jxl

Resources

The MCP server exposes your images as resources that Claude can access directly:

  • URI format: imgsrc://images/{imageId}

  • Content: JSON metadata including dimensions, formats, and CDN URLs

Claude can list and read these resources to understand what images you have and their properties.

Prompts

Pre-built prompts for common workflows:

upload-and-share

Upload an image and get shareable CDN URLs.

  • Arguments: imageUrl (required), width (optional)

check-usage

Check account usage and storage status.

  • No arguments required

find-images

Search for images by keyword.

  • Arguments: query (required)

Example Conversations

Upload and share an image

User: Upload ~/Photos/sunset.jpg to img-src and give me a resized URL

Claude: I'll upload that image and generate a CDN URL for you.

[Uses upload_image tool]

Image uploaded successfully! Here's a resized CDN URL: https://img-src.io/i/yourname/sunset.webp?w=1200&q=85

Search and organize

User: Find all my beach photos

Claude: [Uses search_images with query "beach"]

Found 5 beach photos:

  1. photos/vacation/beach-sunset.jpg

  2. photos/summer/beach-party.png ...

Check usage

User: How much storage am I using?

Claude: [Uses get_usage tool]

Your img-src.io usage:

  • Storage: 245 MB / 500 MB (49%)

  • Uploads: 67 / 100 this month

  • Bandwidth: 1.2 GB / 1 GB (120% - consider upgrading!)

Development

# Install dependencies
pnpm install

# Build
pnpm build

# Run locally
IMG_SRC_API_KEY=imgsrc_xxx pnpm start

# Type check
pnpm type-check

# Run tests
pnpm test

License

MIT

Available Tools

8 tools
delete_imageA

Delete an image by its ID. This permanently removes the image and all its paths from your account. The image will no longer be accessible via CDN URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesImage ID to delete (16-character hash prefix). This permanently removes the image and all its paths.

TDQS

A4/5.0
Behavior4/5

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

Description explicitly states permanence and CDN availability impact, which covers key behavioral traits. No annotations provided, so description carries full burden, and it does well for a simple deletion tool.

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 verb and resource, no wasted words. Every sentence adds essential context.

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 single-parameter tool without output schema, the description is complete enough. It covers the irreversible nature and effect on CDN access, though it could mention authentication requirements.

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%, so baseline of 3 is appropriate. The description adds no new information beyond the schema's parameter description (both mention permanent removal).

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?

Description clearly states the action (delete by ID) with resource specificity (image). Distinguishes from sibling tools which are all non-destructive (get, list, search, upload).

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?

No explicit when-to-use or when-not-to-use guidance. While it's the only delete tool, it lacks prerequisites like confirming the image exists or considering cascading effects.

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

get_cdn_urlB

Generate a CDN URL for an image with optional transformations. Supports resizing, format conversion, and quality adjustment.

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesimg-src.io username (appears in CDN URL path)
filepathYesImage path without extension (e.g., 'blog/photo' for blog/photo.webp)
widthNoResize width in pixels
heightNoResize height in pixels
fitNoResize fit mode: cover (crop), contain (fit), fill (stretch), scale-down (shrink only)
qualityNoImage quality 1-100 (default: 80)
formatNoOutput format (default: webp)

TDQS

B3.3/5.0
Behavior2/5

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 states it generates a URL but does not disclose behavioral traits such as whether it performs any side effects (e.g., uploading), requires authentication, or has rate limits. The minimal description leaves significant gaps.

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 a single concise sentence that covers the core functionality. No fluff, but it could be slightly more structured (e.g., listing transformations explicitly). Still, it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters and no output schema or annotations, the description is incomplete. It does not specify the output format (e.g., plain URL string), prerequisites (image existence), or error handling. The tool may generate a URL for a non-existent image without warning, which is not disclosed.

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 has 100% description coverage, with each parameter well-described. The tool description adds a summary of supported transformations (resizing, format, quality) but does not add meaningful detail beyond the schema. Baseline 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 generates a CDN URL with optional transformations like resizing, format conversion, and quality adjustment. It uses a specific verb ('generate') and resource ('CDN URL'), which distinguishes it from sibling tools like upload_image or get_image.

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 implies usage for generating CDN URLs for images, but does not explicitly state when to use this tool versus alternatives like get_image or search_images. No when-not-to-use or alternative recommendations are provided.

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

get_imageA

Get detailed metadata for a specific image by its ID. Returns full image information including dimensions, format, all associated paths, and CDN URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesImage ID (16-character hash prefix, e.g., 'abcdef1234567890')

TDQS

A4/5.0
Behavior4/5

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

No annotations provided, so the description carries the full burden. It accurately conveys a read-only operation returning metadata. It lists specific return fields (dimensions, format, paths, CDN URLs) which is helpful. However, it does not mention error cases (e.g., invalid ID) or rate limits, but that's acceptable for a simple retrieval tool.

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, no redundant information. The most important information (what it does and what it returns) is front-loaded. Every word is necessary.

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 simplicity of the tool (one parameter, no output schema), the description is sufficiently complete. It mentions the output fields. The sibling tools list provides context for differentiation. A minor improvement would be to explicitly state that it only returns metadata, not the image file itself.

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% with a detailed description of the 'id' parameter. The tool description does not add additional semantic meaning beyond what the schema already provides. According to the guidelines, when schema coverage is high, the baseline is 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 the action ('Get detailed metadata'), the resource ('a specific image'), and the means ('by its ID'). It distinguishes this tool from siblings like 'list_images' (bulk listing) and 'search_images' (query-based) by focusing on a single image retrieval.

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?

Usage is implied: use when you have a specific image ID and need full metadata. No explicit when-not-to-use or alternatives are mentioned, which is a minor gap. For example, it doesn't state that this tool is not for listing or searching, which are covered by siblings.

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

get_settingsA

Get your img-src.io account settings. Returns username, plan, default image settings, and account statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It indicates a non-destructive read operation but does not mention authentication, rate limits, or other behavioral traits. Adequate but minimal.

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?

Single sentence that efficiently states purpose and return value. No redundant or missing information.

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 no parameters and no output schema, the description fully explains what the tool does and what it returns. Complete and self-contained.

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?

No parameters exist; schema coverage is 100% trivially. Description adds value by specifying the returned content, earning baseline 4 for zero 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?

Clearly states it retrieves account settings and lists specific returned fields (username, plan, default image settings, account statistics). No sibling tool offers the same functionality, so it is well-distinguished.

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?

No explicit when-to-use or when-not-to-use guidance. However, the tool is straightforward with no alternatives, making usage implicit. Lacks exclusions or prerequisites.

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

get_usageA

Get current usage statistics for your img-src.io account. Shows uploads, storage, bandwidth, and API request usage against your plan limits.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states it 'gets usage statistics', which is read-only, but does not mention any potential side effects, authorization needs, or rate limits. For a simple read tool, the description is minimally adequate.

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 with no waste. The first sentence fronts the action and resource; the second adds specific statistics. Perfectly concise.

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 zero parameters, no output schema, and a simple read operation, the description fully covers what the tool does and what statistics it returns. No gaps.

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 tool has zero parameters and schema coverage is 100%, so the description does not need to explain parameters. Adding no parameter info is acceptable; baseline 4 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?

Description clearly states the verb ('Get'), resource ('usage statistics'), and specific metrics ('uploads, storage, bandwidth, and API request usage'). Distinguishes well from siblings like get_image or get_settings.

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?

While the purpose is clear, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. Usage is implied but not stated.

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

list_imagesA

List images in your img-src.io account. Supports pagination and folder browsing. Returns images and subfolders in the specified path.

ParametersJSON Schema
NameRequiredDescriptionDefault
folderNoFolder path to filter images (e.g., 'blog/2024'). Omit to list root level.
limitNoMax images to return (1-100, default: 50)
offsetNoNumber of images to skip for pagination (default: 0)

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided; description must cover behavioral traits. It states it returns images and subfolders, supports pagination, but does not mention authentication, rate limits, or ordering. Adequate but lacks depth.

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 purpose, then features and return info. No filler words.

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 100% schema coverage, no output schema, and simple listing operation, the description provides sufficient context. Could mention return format or default behavior for missing folders.

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?

Input schema has 100% description coverage. The description adds context linking folder and pagination parameters to tool features, but adds little beyond schema descriptions.

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 action (list), resource (images in img-src.io account), and key features (pagination, folder browsing). It distinguishes from siblings like delete_image and upload_image.

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?

No explicit when-to-use or when-not-to-use guidance. The description implies usage for browsing images and subfolders, but does not compare to search_images or get_image.

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

search_imagesA

Search for images by filename or path. Performs a fuzzy search across all your images. Returns matching images with their metadata and CDN URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term to match against filenames and paths (1-100 chars)
limitNoMax results to return (1-100, default: 20)
offsetNoNumber of results to skip for pagination (default: 0)

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the search as fuzzy and across all images, but does not explicitly state it is read-only or mention any side effects. The output content is mentioned, but pagination behavior is not explained beyond the schema parameters.

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, concise, and front-loaded with the key action. Every sentence adds value: purpose, scope, and output.

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 search tool without an output schema, the description adequately outlines the return information (matching images, metadata, CDN URLs). It addresses the core need, though more detail about output structure could be beneficial.

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% (all parameters have descriptions). The description adds that the search is fuzzy and by filename/path, which partially overlaps with the schema description. No additional parameter details are provided beyond what the schema contains.

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 searches for images by filename or path using fuzzy matching, and returns matching images with metadata and CDN URLs. This distinguishes it from siblings like list_images (all images), get_image (by ID), and delete_image.

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 implies when to use this tool (to search by filename/path), but does not explicitly state when not to use it or provide alternatives. Users must infer from sibling names.

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

upload_imageA

Upload an image to img-src.io. IMPORTANT: Always prefer 'file_path' (absolute path like /Users/name/image.png) over base64 'data' to avoid context length limits. Use 'url' for web images. Only use 'data' as last resort for small images. Supports JPEG, PNG, WebP, GIF, AVIF, HEIC, and more. Max 5MB. Returns CDN URLs for the uploaded image.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathNoPREFERRED: Absolute path to local image file (e.g., /Users/name/photo.png). Use this instead of base64 data.
urlNoURL of image to download and upload (for web images)
dataNoBase64-encoded image data. AVOID: causes context length issues. Use file_path instead.
mimeTypeNoMIME type (required only when using data, e.g., image/png)
target_pathNoOptional: Folder path to store the image (e.g., 'photos/2024'). Filename is determined from source.

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Discloses upload destination, format/size limits, and return of CDN URLs. Lacks details on error handling, authentication, or rate limits.

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?

Description is efficient and front-loaded with purpose and key guidance. Could condense format list, but overall each sentence is informative.

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 5 parameters and no output schema, description covers upload process, limits, and parameter choices. Return value is described briefly but adequately for basic use.

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 descriptions cover all 5 parameters at 100%. Description adds value by emphasizing preference hierarchy (file_path > url > data) and noting mimeType required only with base64 data, going beyond 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?

Description clearly states 'Upload an image to img-src.io', specifies supported formats and max size. Differentiates from sibling tools like delete_image and get_image.

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?

Provides clear parameter preferences: prefer file_path over base64 data to avoid context limits, use url for web images, data as last resort. Does not explicitly exclude cases but gives actionable guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.10
    • Changedget_cdn_url1 field changed
      • changedInput schema / properties / format / enum
        Previous value: -[
-  "webp",
-  "avif",
-  "jpeg",
-  "png"
-]New value: +[
+  "webp",
+  "avif",
+  "jpeg",
+  "png",
+  "jxl"
+]
  2. 8 tool updatesv0.2.5
    • First observeddelete_image
    • First observedget_cdn_url
    • First observedget_image
    • First observedget_settings
    • First observedget_usage
    • First observedlist_images
    • First observedsearch_images
    • First observedupload_image
Deploy Server
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

TDQS

A4/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: delete, generate CDN URL, get metadata, get settings, get usage, list, search, and upload. No two tools overlap in functionality, making it easy for an agent to select the correct one.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., delete_image, get_cdn_url). The naming is uniform and predictable across the entire set.

Tool Count5/5

With 8 tools, the server provides a well-scoped set for image management. Each tool serves a necessary function without redundancy or excessive granularity.

Completeness4/5

The tool set covers core image lifecycle operations: upload, read (get, list, search, CDN URL), and delete. A minor gap is the lack of an update tool for modifying image metadata, but the main workflows are supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers