Skip to main content
Glama
jbergant

Image Processor MCP Server

by jbergant
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Image Processor MCP Server

This MCP server provides tools for image processing and uploading to Vercel Blob storage. It allows you to:

  1. Optimize and resize images (from local files or URLs)

  2. Convert images to WebP format

  3. Upload both versions to Vercel Blob storage

Features

  • Image Optimization: Resize and optimize images for better performance

  • WebP Conversion: Convert images to the WebP format for smaller file sizes

  • Vercel Blob Integration: Automatically upload processed images to Vercel Blob storage

  • Customizable Dimensions: Specify custom dimensions for image resizing

  • URL Support: Process images from external URLs

Related MCP server: image_mcp

Installation

The server is already installed and configured in the MCP settings file. It uses the Vercel Blob token from your environment variables.

Usage

You can use the MCP server in Claude by using the use_mcp_tool function:

For Local Images

<use_mcp_tool>
<server_name>image-processor</server_name>
<tool_name>process_and_upload_image</tool_name>
<arguments>
{
  "imagePath": "/path/to/image.png",
  "newName": "new-image-name",
  "width": 550,
  "height": 300
}
</arguments>
</use_mcp_tool>

For Images from URLs

<use_mcp_tool>
<server_name>image-processor</server_name>
<tool_name>process_and_upload_image_from_url</tool_name>
<arguments>
{
  "imageUrl": "https://example.com/image.jpg",
  "newName": "new-image-name",
  "width": 550,
  "height": 300
}
</arguments>
</use_mcp_tool>

Parameters for Local Images

  • imagePath (required): Path to the image file to process

  • newName (required): New name for the processed image (without extension)

  • width (optional): Width to resize the image to (default: 550)

  • height (optional): Height to resize the image to (default: 300)

Parameters for URL Images

  • imageUrl (required): URL of the image to process

  • newName (required): New name for the processed image (without extension)

  • width (optional): Width to resize the image to (default: 550)

  • height (optional): Height to resize the image to (default: 300)

Response

The server will return a JSON response with the following structure:

{
  "success": true,
  "message": "Successfully processed and uploaded image: new-image-name",
  "results": {
    "png": {
      "fileName": "new-image-name_small.png",
      "localPath": "/path/to/temp/new-image-name_small.png",
      "blobUrl": "https://vercel-blob-url/new-image-name_small.png"
    },
    "webp": {
      "fileName": "new-image-name.webp",
      "localPath": "/path/to/temp/new-image-name.webp",
      "blobUrl": "https://vercel-blob-url/new-image-name.webp"
    }
  }
}

Implementation Details

The server uses:

  • Sharp: For image processing and optimization

  • @vercel/blob: For uploading to Vercel Blob storage

  • fs-extra: For file system operations

Examples

Example 1: Processing a Local Image

<use_mcp_tool>
<server_name>image-processor</server_name>
<tool_name>process_and_upload_image</tool_name>
<arguments>
{
  "imagePath": "/pathto_file/image_name.png",
  "newName": "test-processed-image",
  "width": 550,
  "height": 300
}
</arguments>
</use_mcp_tool>

Example 2: Processing an Image from URL

<use_mcp_tool>
<server_name>image-processor</server_name>
<tool_name>process_and_upload_image_from_url</tool_name>
<arguments>
{
  "imageUrl": "https://pplx-res.cloudinary.com/image/upload/v1749567759/pplx_project_search_images/6dff647e4fb1083aecf9ea6b1d49ea19386be588.jpg",
  "newName": "cloud-image",
  "width": 550,
  "height": 300
}
</arguments>
</use_mcp_tool>

Both examples will:

  1. Take the image (from local path or URL)

  2. Optimize and resize it to 550x300 pixels

  3. Create a PNG version with "_small" suffix

  4. Create a WebP version

  5. Upload both to Vercel Blob

  6. Return the URLs of the uploaded images

Available Tools

2 tools
process_and_upload_imageA

Process a local image file (optimize, resize, convert to WebP) and upload to Vercel Blob

ParametersJSON Schema
NameRequiredDescriptionDefault
heightNoHeight to resize the image to (default: 300)
imagePathYesPath to the image file to process
newNameYesNew name for the processed image (without extension)
widthNoWidth to resize the image to (default: 550)

TDQS

A3.7/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 mentions processing (optimize, resize, convert) and uploading, but lacks details on behavioral traits like required permissions, rate limits, error handling, or what happens if processing fails. For a tool that modifies and uploads files with no annotation coverage, this is a significant gap.

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 a single, efficient sentence that front-loads key information (process local image, upload to Vercel Blob) and includes essential details (optimize, resize, convert to WebP). Every part earns its place with no wasted words.

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

Completeness3/5

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

Given the tool's complexity (processing and uploading images) and lack of annotations and output schema, the description is moderately complete. It covers the core purpose and distinguishes from siblings, but lacks details on behavioral aspects and output, which are important for a tool with mutation and external integration.

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 all parameters. The description adds no specific parameter semantics beyond what the schema provides, such as explaining interactions between parameters (e.g., how width/height affect resizing). Baseline 3 is appropriate when the schema handles parameter documentation.

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 specific verb ('process and upload') and resource ('local image file'), and distinguishes from the sibling tool 'process_and_upload_image_from_url' by specifying the source as local rather than URL-based. It explicitly lists the processing operations: optimize, resize, convert to WebP, and the destination: Vercel Blob.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (for local image files) and implies an alternative (the sibling tool for URL-based images). However, it does not explicitly state when NOT to use this tool or mention other potential alternatives beyond the sibling, such as direct upload without processing.

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

process_and_upload_image_from_urlA

Process an image from a URL (optimize, resize, convert to WebP) and upload to Vercel Blob

ParametersJSON Schema
NameRequiredDescriptionDefault
heightNoHeight to resize the image to (default: 300)
imageUrlYesURL of the image to process
newNameYesNew name for the processed image (without extension)
widthNoWidth to resize the image to (default: 550)

TDQS

A3.9/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 the full burden. It discloses key behavioral traits: the tool processes (optimizes, resizes, converts to WebP) and uploads to Vercel Blob. However, it lacks details on permissions, rate limits, error handling, or what happens if upload fails, which are important 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place by specifying the action, source, processing steps, and destination without any redundancy or fluff.

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

Completeness3/5

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

Given the tool's complexity (image processing and upload), lack of annotations, and no output schema, the description is minimally adequate. It covers the what and where but misses details on behavioral aspects like success/failure outcomes, which would enhance completeness for a mutation tool.

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 schema description coverage is 100%, so the schema already documents all parameters. The description does not add any additional meaning or context beyond what the schema provides, such as explaining the optimization process or WebP conversion specifics. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action: 'Process an image from a URL (optimize, resize, convert to WebP) and upload to Vercel Blob'. It uses precise verbs ('process', 'upload'), specifies the resource ('image'), and distinguishes from its sibling 'process_and_upload_image' by explicitly mentioning 'from a URL'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying 'from a URL', which suggests this tool is for remote images rather than local files. However, it does not explicitly state when to use this versus the sibling tool 'process_and_upload_image' or provide any exclusion criteria, leaving some ambiguity.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation3/5

The two tools have overlapping purposes—both process images and upload to Vercel Blob—but the descriptions clearly differentiate them by input source (local file vs. URL). This overlap could cause minor confusion, but the distinctions are explicit enough to guide selection.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern with 'process_and_upload_image' as the base, extended with 'from_url' for the second tool. This predictable naming makes it easy to understand the tool set's structure and relationships.

Tool Count2/5

With only 2 tools, the server feels under-scoped for an 'Image Processor' domain. This minimal set lacks operations like basic processing without upload, downloading images, or managing uploaded files, limiting agent workflows.

Completeness2/5

The tool set is severely incomplete for image processing. It covers only upload-oriented workflows, missing essential operations such as standalone processing, format conversion, resizing, or retrieval of images, leaving obvious gaps in the domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbergant/mcp_image_processor_to_vercel_blob'

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