Skip to main content
Glama
Sign In

Pageree

by com.pageree
OverviewDiscussionsAdmin

Upload image

upload_asset

Host an image the user already has — a logo, product shot, screenshot or team photo — and get back a URL to use in the page. Real imagery of the user's own business converts better than anything generated, so prefer this whenever they can supply a file. Choose ONE transport: sourceUrl if the image is already on a public https URL (we fetch it); no argument at all to get a one-time upload URL to PUT the file to with curl (best when you have a shell and a file on disk); or base64 for a small file you can inline. Whatever arrives is resized to fit, converted to WebP and stored — including SVG, which is rasterised. The asset is attached to a page automatically when you publish a page that uses its URL.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "upload_asset"
  }
}

Input Schema

NameRequiredDescriptionDefault
base64NoImage bytes, base64-encoded, for a small file only (max 2 MB decoded). Costs context — prefer sourceUrl, or the upload URL when you have a shell.
filenameNoOriginal file name, kept for the user's reference. Optional.
sourceUrlNoPublic https URL of an image to fetch and host. Use when the user gives you a link to their logo or photo.
descriptionNoWhat the image shows, e.g. "Acme wordmark, dark on transparent". Stored filenames are short ids, so this is how you and the user tell assets apart later. Always worth setting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already disclose mutation, open-world and non-idempotent behaviour, and the description adds substantial context beyond them: incoming bytes are resized, converted to WebP, SVG is rasterised, and the asset auto-attaches to a page when that URL is published. It does not mention auth/token requirements or what happens to duplicate uploads (relevant given idempotentHint=false), so it falls short of a 5.

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-loaded with purpose, then transport choice, then processing behaviour, then attachment — each sentence carries new information and nothing is repeated from the schema. It is a single dense block rather than scannable structure, and the 'no argument at all' phrasing is slightly awkward, which keeps it from a 5.

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 four-parameter, optional-only tool with no output schema, the description still covers the return value (a URL), the three invocation modes, the transformation pipeline, and the side effect on publish. An agent has everything needed to call this correctly on the first attempt.

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 100%, so a baseline of 3 is already earned, but the description adds real decision semantics the schema does not: base64 'costs context', the upload-URL path suits a shell with a file on disk, and the description param is how assets are told apart later. That elevates it above the baseline.

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 ('Host an image the user already has') plus the return value ('get back a URL to use in the page'), and gives concrete examples (logo, product shot, screenshot, team photo). The clause about preferring real imagery over generated implicitly separates it from the generate_image sibling, so an agent can route without opening either schema.

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 says when to reach for this tool ('prefer this whenever they can supply a file') and then gives when-to-use guidance for each of three mutually exclusive transports, with the deciding conditions spelled out: public https link, shell with a file on disk, or small inline file. The agent is never left to guess which path to take.

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

All Pageree toolsInspect
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