Skip to main content
Glama
qiniu

Qiniu MCP Server

Official
by qiniu

image_round_corner

Add rounded corners to images stored in Qiniu Cloud by specifying horizontal and vertical radius values in pixels or percentages, then retrieve the processed image via URL.

Instructions

Image rounded corner tool that processes images based on width, height, and corner radius, returning information about the processed image. If only radius_x or radius_y is set, the other parameter will be assigned the same value, meaning horizontal and vertical parameters will be identical. The information includes the object_url of the processed image, which users can directly use for HTTP GET requests to retrieve the image content or open in a browser to view the file. The image must be stored in a Qiniu Cloud Bucket. Supported original image formats: psd, jpeg, png, gif, webp, tiff, bmp, avif, heic. Image width and height cannot exceed 30,000 pixels, and total pixels cannot exceed 150 million. Corner radius supports pixels and percentages, but cannot be negative. Pixels are represented by numbers, e.g., 200 means 200px; percentages use !xp, e.g., !25p means 25%.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
object_urlYesThe URL of the image. This can be a URL obtained via the GetObjectURL tool or a URL generated by other Fop tools. Length Constraints: Minimum length of 1.
radius_xNoParameter for horizontal corner size. Can use: pixel values (e.g., 200 for 200px) or percentages (e.g., !25p for 25%), all non-negative values.
radius_yNoParameter for vertical corner size. Can use: pixel values (e.g., 200 for 200px) or percentages (e.g., !25p for 25%), all non-negative values.

Implementation Reference

  • The handler function for the image_round_corner tool that applies rounded corners to the image using Qiniu FOP by constructing the func string and adding it to the object URL.
    def image_round_corner(self, **kwargs) -> list[types.TextContent]:
        object_url = kwargs.get("object_url", "")
        radius_x = kwargs.get("radius_x", "")
        radius_y = kwargs.get("radius_y", "")
        if object_url is None or len(object_url) == 0:
            return [
                types.TextContent(
                    type="text",
                    text="object_url is required"
                )
            ]
    
        if (radius_x is None or len(radius_x) == 0) and (radius_y is None or len(radius_y) == 0) is None:
            return [
                types.TextContent(
                    type="text",
                    text="At least one of radius_x or radius_y must be set"
                )
            ]
    
        if radius_x is None or len(radius_x) == 0:
            radius_x = radius_y
        elif radius_y is None or len(radius_y) == 0:
            radius_y = radius_x
    
        func = f"roundPic/radiusx/{radius_x}/radiusy/{radius_y}"
        object_url = utils.url_add_processing_func(auth=self.auth, url=object_url, func=func)
        return [
            types.TextContent(
                type="text",
                text=str({
                    "object_url": object_url,
                })
            )
        ]
  • Tool metadata including name, description, and input schema definition for image_round_corner using @tools.tool_meta decorator.
        types.Tool(
            name="image_round_corner",
            description="""Image rounded corner tool that processes images based on width, height, and corner radius, returning information about the processed image.
            If only radius_x or radius_y is set, the other parameter will be assigned the same value, meaning horizontal and vertical parameters will be identical.
            The information includes the object_url of the processed image, which users can directly use for HTTP GET requests to retrieve the image content or open in a browser to view the file.
            The image must be stored in a Qiniu Cloud Bucket.
            Supported original image formats: psd, jpeg, png, gif, webp, tiff, bmp, avif, heic. Image width and height cannot exceed 30,000 pixels, and total pixels cannot exceed 150 million.
            Corner radius supports pixels and percentages, but cannot be negative. Pixels are represented by numbers, e.g., 200 means 200px; percentages use !xp, e.g., !25p means 25%.""",
            inputSchema={
                "type": "object",
                "properties": {
                    "object_url": {
                        "type": "string",
                        "description": _OBJECT_URL_DESC
                    },
                    "radius_x": {
                        "type": "string",
                        "description": "Parameter for horizontal corner size. Can use: pixel values (e.g., 200 for 200px) or percentages (e.g., !25p for 25%), all non-negative values."
                    },
                    "radius_y": {
                        "type": "string",
                        "description": "Parameter for vertical corner size. Can use: pixel values (e.g., 200 for 200px) or percentages (e.g., !25p for 25%), all non-negative values."
                    },
                },
                "required": ["object_url"],
            }
        )
    )
  • Registration of the image_round_corner tool handler by passing tool_impl.image_round_corner to tools.auto_register_tools in the register_tools function.
    tools.auto_register_tools(
        [
            tool_impl.image_scale_by_percent,
            tool_impl.image_scale_by_size,
            tool_impl.image_round_corner,
            tool_impl.image_info,
        ]
    )
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies that the tool returns an 'object_url' for HTTP GET requests, details supported image formats, size constraints (width/height ≤ 30,000 pixels, total ≤ 150 million pixels), and rules for radius values (non-negative, pixels or percentages). It also explains the default behavior when only one radius is set. This covers many operational aspects, though it could mention error handling or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is front-loaded with the core purpose but becomes verbose with detailed specifications (e.g., supported formats, size limits, radius rules). While informative, some sentences could be more streamlined, and the structure mixes operational details with prerequisites, reducing overall conciseness. It's adequately sized but not optimally efficient.

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 tool's complexity (image processing with constraints) and no annotations or output schema, the description compensates well by covering prerequisites (Qiniu Cloud Bucket), input constraints (formats, sizes), parameter behavior, and output details (object_url usage). It provides a solid foundation for an agent to use the tool correctly, though it could benefit from mentioning error cases or linking to sibling tools for context.

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, providing clear details for 'object_url,' 'radius_x,' and 'radius_y.' The description adds some value by explaining the relationship between radius parameters (if only one is set, the other gets the same value) and elaborating on radius formats (pixels vs. percentages with examples). However, it doesn't introduce new parameter meanings beyond what the schema already covers, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'processes images based on width, height, and corner radius, returning information about the processed image,' which specifies the verb (processes), resource (images), and operation (rounding corners). However, it doesn't explicitly differentiate from sibling tools like 'image_scale_by_percent' or 'image_scale_by_size,' which also process images but for different transformations.

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 by stating prerequisites such as 'The image must be stored in a Qiniu Cloud Bucket' and listing supported formats and size limits. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other image processing siblings) or any exclusions, leaving the context somewhat inferred rather than clearly defined.

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

Install Server

Other Tools

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/qiniu/qiniu-mcp-server'

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