Skip to main content
Glama

Upload an image

request_image_upload

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Adds an image to one of your own drafts without the browser editor: returns a one-time upload URL and its Authorization header (15 minutes, one PNG, JPEG, WebP or GIF file of the type given, up to 10 MB), and the curl command that PUTs the file from the engineer's machine. Run that curl as given: the token goes only in the header, never in the URL. Location and camera metadata are removed. Then place_image gives the snippet to put in the post. Pass alt only as the engineer's own words.

Input Schema

NameRequiredDescriptionDefault
idYesThe draft's 8-character id (list_drafts lists yours)
altNoThe engineer's own description of the image, for readers who can't see it (5 to 250 characters; not the file name, "screenshot" or the caption). Never write one yourself: leave it out and ask them
filenameYesThe image's file name on the engineer's machine (diagram.png): its served name comes from it
content_typeYesThe image's type; the file's own bytes must say the same

Output Schema

NameRequiredDescriptionDefault
idYes
altNo
curlYesThe command to run where the file is
nameYesThe name the image will be served under (a number is added if the draft already has one)
nextYes
methodYes
max_bytesYes
expires_atYes
upload_urlYesPUT the file here, once, within 15 minutes. It carries no secret
alt_problemNoWhy the alt given wasn't used, and the question to ask the engineer
content_typeYes
allowed_typesYes
authorizationYesThe Authorization header to send with the PUT (Bearer <token>): the one-time token, never put in the URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the auth scope required, the 15-minute single-use nature of the URL, size/format/count limits, metadata stripping, and a security constraint on token placement. The 'token only in the header, never in the URL' instruction is exactly the behavioral context an agent needs before calling.

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?

Front-loads the auth prerequisite and the core action, then the returns, then the next step. Sentences are long and heavily parenthesized, which costs some readability, but nearly every clause carries operational 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?

An output schema exists, yet the description still summarizes the return (upload URL, Authorization header, curl command), which is more than required. Combined with auth, limits, metadata handling, and the place_image handoff, 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds real meaning: alt must be the engineer's own words and must never be generated by the agent, and only one file type matching the declared content_type is accepted. The 'file of the type given' constraint reinforces the enum relationship between filename and content_type.

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 ('adds an image to one of your own drafts') and scopes it away from the browser editor, which is the natural sibling/alternative. The link to place_image makes the workflow position unambiguous.

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?

Clearly sets the precondition (TechFabric engineer sign-in, blog.write scope, own drafts only) and names the follow-up tool, place_image. It does not explicitly name open_editor as the alternative for browser-based uploads, so the exclusion is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.