Jornalo — futures trading journal

Attach chart screenshots to a trade

request_image_upload

Get single-use upload URLs to attach chart screenshots to one trade. The image bytes are NOT sent through this tool — tool arguments cannot carry megabytes of base64 — so call it, then have your runtime HTTP PUT the raw file body to each uploadUrl within 15 minutes (e.g. curl --data-binary @file) with Content-Type image/png, image/jpeg or image/webp; max 4 MB per image, 6 images per trade. One ticket = one image: pass one label per file (e.g. ['Ejecución','Análisis']). By default the screenshot is also attached to the same trade mirrored in the user's other copier accounts (mirror=false to skip). Before calling: ask the user where the files are and which account they belong to, match each file to a trade with find_trades, check the trade's existing images so re-runs do not create duplicates, and confirm the mapping with the user. Requires a client that can read local files and make HTTP requests.

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": {
      "tradeId": "<tradeId>"
    },
    "name": "request_image_upload"
  }
}

Input Schema

Name	Required	Description
`labels`	No	One upload ticket per entry; the label is shown under the screenshot (e.g. ["Ejecución","Análisis"]). Omit for a single unlabeled ticket.
`mirror`	No	Also attach each image to the same trade mirrored in the user's other accounts. Default true.
`tradeId`	Yes	Trade id from find_trades, list_trades or list_recent_trades_for_tagging.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the generic safety profile (not read-only, not idempotent, not destructive, closed-world). The description adds context annotations cannot carry: bytes are not sent through the tool, the runtime must HTTP PUT to each uploadUrl within 15 minutes, accepted content types, the 4 MB / 6 images limits, mirror defaults, and the requirement for a client that can read local files and make HTTP requests.

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?

Purpose, transport mechanics and pre-call workflow are front-loaded in a logical order, and virtually every clause carries operational information. It is dense with parentheticals and limits, but trimming any of it would lose real constraint detail, so only a small deduction for bulk.

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?

There is no output schema, so the description carries the return-value burden itself: it explains that the result is upload URLs that must be PUT to, and ties that to the ticket/label mapping. Combined with the pre-call workflow, an agent has everything needed to execute the two-phase upload correctly.

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, and the schema already documents labels, mirror and tradeId. The description still adds the operational coupling the schema only hints at: 'One ticket = one image', one label per file, and 'mirror=false to skip' as the opt-out for the default-on mirroring behaviour.

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: 'Get single-use upload URLs to attach chart screenshots to one trade.' It also clarifies the scope ('one trade') and the indirect nature of the operation, so an agent can immediately distinguish this from siblings like annotate_trade or tag_trade.

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 an explicit pre-call checklist (ask where the files are, match files to trades with find_trades, check the trade's existing `images` to avoid duplicates, confirm mapping with the user) and names the sibling tool find_trades. This is when-to-use and prerequisite guidance at a level rarely seen.

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

All Jornalo — futures trading journal 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?