Tripmo

Attach a file from the chat

attach_file

Attach the file your human gave you in this chat to an item; with as "photo", a picture they say is of the place, stay or option, shown as its photo (never a ticket, a screenshot or a QR code). Only when they ask. For hosts that pass files to tools (ChatGPT fills in file itself): Tripmo fetches it from the host and keeps it on the record's card (ready on the phone without signal) if it's a PDF or an image up to 20 MB. If the file doesn't come through (ChatGPT's phone apps don't pass files yet), the reply has a link to give your human instead. Without a host that passes files, use upload_link. Never paste a file's contents into a call.

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": {
      "trip": "<trip>",
      "record": "<record>",
      "file": "<file>"
    },
    "name": "attach_file"
  }
}

Input Schema

Name	Required	Description
`as`	No	Leave it out, or "file", for a ticket, a confirmation, a screenshot or a QR code. "photo" only when your human says it's a picture of the place (an image): it then shows as the item's photo.
`file`	Yes	The file your human attached in this chat (ChatGPT passes it).
`trip`	Yes	The trip id, e.g. "trp_8Kd2…", from list_trips.
`record`	Yes	The item (itm_…) the file goes on.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / as / description

Previous value: -"Leave it out, or \"file\", for a ticket, a confirmation, a screenshot or a QR code. \"photo\" only when your human says it's a picture of the place (an image of an item, not a document): it then shows as the item's photo."New value: +"Leave it out, or \"file\", for a ticket, a confirmation, a screenshot or a QR code. \"photo\" only when your human says it's a picture of the place (an image): it then shows as the item's photo."

changedInput schema / properties / record / description

Previous value: -"The item (itm_…) or the person's own travel document (doc_…)."New value: +"The item (itm_…) the file goes on."

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare it is a non-idempotent, non-destructive write; the description adds the traits that actually matter: the file is fetched from the host, persisted onto the record's card and made available offline, restricted to PDF or image up to 20 MB, and a link is returned in the reply when the host can't pass files. Platform-specific failure mode (ChatGPT phone apps) is disclosed.

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 the action and the conditional clause; every sentence carries real constraint information. Minor waste from restating the ChatGPT host limitation twice and from the awkward mid-sentence parentheticals, which make it slower to parse than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the nested file object's provenance, size/type limits, offline caching, and the fallback path when the host cannot deliver the file — enough for an agent to call it correctly with no output schema. It stops short of saying what identifier or handle is returned on success, which would close the loop.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% and the enum semantics for 'as', the file object shape, and the trip/record ids are already documented in the schema in nearly the same words. The description adds no syntax, format, or defaulting detail beyond what the schema provides, so the baseline 3 applies.

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 ('Attach the file ... to an item') and immediately scopes the variant behavior ('as photo'). It also names the sibling it is not — 'Without a host that passes files, use upload_link' — so the agent can distinguish it 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?

Explicit gating ('Only when they ask'), explicit exclusions for the photo mode ('never a ticket, a screenshot or a QR code'), an explicit alternative (upload_link), and an explicit prohibition ('Never paste a file's contents into a call'). This is close to a full when/when-not/alternatives rubric.

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

All Tripmo 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?