Skip to main content
Glama
Sign In

ThreadPage

by page.thread
OverviewDiscussionsAdmin

Upload an image

upload_note_image
Idempotent

Upload an image to use in a Note (Add only and up): PNG, JPEG or WebP up to 5 MB and 20 megapixels, as base64 (it passes through your own output, so keep it small or ask the person to add a large one). ThreadPage never fetches a URL. For a Note that already exists, pass its note_id; for a new Note, omit it and create the Note in the same Thread. Answers its attachment_id; the same operation_id answers it again. Uploading does not add it to the Note: then put it on its own line in the Note's Markdown: What the image shows, or a document block {"type": "image", "attrs": {"attachmentId": "<attachment_id>", "alt": "…", "width": null}}. For other files, use upload_note_file.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation_id": "<operation_id>",
      "thread_id": "<thread_id>",
      "mime_type": "<mime_type>",
      "checksum": "<checksum>",
      "data": "<data>"
    },
    "name": "upload_note_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYesThe image file as base64: PNG, JPEG or WebP, up to 5 MB.
note_idNoWhen the image goes in an existing Note: its id (required then).
checksumYesThe lowercase hex SHA-256 of the image bytes (not of the base64).
mime_typeYes"image/png", "image/jpeg" or "image/webp".
thread_idYesThe Thread of the Note the image goes in.
operation_idYesA new UUID for each write. After a lost answer, send the identical call with the same one, or check get_operation before writing again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly=false, idempotent=true, destructive=false; the description adds substantially more: size/type limits, base64 pass-through cost, that ThreadPage never fetches URLs, that uploading does not attach the image, and that the same operation_id returns the same attachment_id. These are exactly the operational facts an agent needs before calling a write tool.

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?

Information is front-loaded (what it accepts, then limits, then the note_id branch, then the return value, then the embedding step). It is dense but nearly every sentence carries decision-relevant content, though the embedded Markdown and JSON document-block examples are lengthy for a description.

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?

With no output schema, the description still states the return value (attachment_id) and its idempotent replay behavior, plus the mandatory post-upload embedding step. For a six-parameter write tool in a rich sibling namespace, nothing an agent needs to call it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: the conditional requiredness of note_id is framed as a workflow decision (existing vs new Note), and thread_id's role in creating a new Note is clarified. It stops short of restating checksum/mime_type details, which the schema already handles.

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 opens with a specific verb and resource ("Upload an image to use in a Note") and immediately distinguishes itself from the sibling upload_note_file ("For other files, use upload_note_file"). An agent can tell this apart from other upload/create tools without opening a 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?

It gives explicit branching guidance: pass note_id for an existing Note, omit it for a new Note created in the same Thread, and route other file types to upload_note_file. It also explains the required follow-up step (embedding the attachment in Markdown), so the agent knows this call alone does not finish the job.

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

All ThreadPage 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