Editmamei Connect

request_upload

Get a one-time way to send photos from the user's device to this server. Photos the user already sent are listed by inspect (what='uploads'), so a photo already there needs no new link. The result leads with page_url, a web page the user opens, from a phone camera roll or a browser; it works in every client. It also carries a curl command that uploads a file from a shell that can reach this host. On claude.ai with code execution on, a photo attached in chat is usually also a file under /mnt/user-data/uploads. A sandbox that blocks this host answers with a 403 or "host not allowed" every time, and the result's if_curl_blocked says how the user can allow it. Nothing announces a page upload: once the user has sent it, it shows up in inspect (what='uploads') as upload:<id>. A curl upload's JSON reply carries upload_id (or an uploads list). open_photo opens either with source "upload:". One link takes several photos: up to 10, and it closes 5 minutes after its last photo arrives and expires in 15 minutes; nothing else limits links (asking for another cancels none). The curl takes one file per command. An upload it produces can be opened from any of your signed-in connections, not only this one. Limits per photo: 40 MB and a pixel limit that depends on the workspace size (overview lists it). RAW camera files up to 100 MB are accepted too; they open on the larger workspace. For an image already online, pass its https:// URL to open_photo instead. Uploads and open photos belong to this server; a photo opened through another Editmamei connector stays with that connector.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`curl`	No
`token`	No
`page_url`	No
`expires_at`	No
`upload_url`	No
`if_curl_blocked`	No
`cancelled_link_minted_at`	No
`cancelled_link_token_prefix`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only set readOnlyHint=false and idempotentHint=false; the description goes far beyond them, disclosing one-time link semantics, the 10-photo cap, the 5-minute idle close / 15-minute expiry, 40 MB and RAW 100 MB limits, the curl 403/'host not allowed' path with `if_curl_blocked`, and cross-connection visibility. This is unusually rich behavioral disclosure.

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?

It is front-loaded with the core purpose, and almost every sentence carries actionable detail (limits, curl fallback, inspect cross-reference). However, it is dense and long for a zero-parameter tool, and the `inspect`(what='uploads') reference is repeated, which slightly dilutes conciseness.

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 an output schema exists, the description needn't explain returns, yet it still clarifies the key result fields (page_url, curl, if_curl_blocked, upload_id). Combined with the limits and expiry rules, nothing an agent needs to call this correctly is missing.

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?

There are zero input parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate in the schema. The description's detail about output fields is not input-parameter semantics.

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: 'Get a one-time way to send photos from the user's device to this server.' It then distinguishes itself from siblings by naming `inspect` (what='uploads') for already-sent photos and `open_photo` for online images, so an agent can route correctly without opening schemas.

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 tells when NOT to call it: 'a photo already there needs no new link' (use `inspect`) and 'For an image already online, pass its https:// URL to `open_photo` instead.' It also covers the sandbox-blocked case and cross-connection opening, leaving little to inference.

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

All Editmamei Connect tools Inspect

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

Need Help?