Skip to main content
Glama
Sign In

Tripmo

by me.tripmo
OverviewDiscussionsAdmin

Add spots to a trip

add_seats
Idempotent

Get a pay link for more people on a trip you own: 5 more spots per block, $5 a block in US dollars with tax included (Checkout shows it in your human's own currency; owner included in the count). Give the link to your human; once paid, the spots are added and anyone in let_in who is still asking is let in. Use it when a let-in is refused because the trip is full, or when your human asks for more room. Not on a read-only trip (get_trip's locked): refused as its writes are (payment_required), its message saying why and, when its owner can buy the trip a new Trip Pass, the link.

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>"
    },
    "name": "add_seats"
  }
}

Input Schema

NameRequiredDescriptionDefault
tripYesThe trip id, e.g. "trp_8Kd2…", from list_trips.
blocksNo
let_inNomem_… ids of people asking to join, to let in once it's paid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false and idempotentHint=true, but the description adds substantial value: the write only takes effect after payment, spots are added in 5-spot blocks, pending let_in requesters are admitted on payment, and read-only trips return a payment_required refusal plus a Trip Pass purchase link. That is real behavioral context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The pricing and usage information is front-loaded, but the final sentence is a run-on tangle ('refused as its writes are (payment_required), its message saying why and, when its owner can buy the trip a new Trip Pass, the link') that is hard to parse. Information density is high but readability suffers.

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?

With no output schema, the description correctly explains what the agent gets back (a pay link to hand to the human) and what changes after payment. It is nearly complete for a 3-parameter mutation tool; only the link's format/expiry is left unstated, which is minor.

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 67% — 'trip' and 'let_in' are documented in-schema, while 'blocks' is not. The description compensates by defining a block as 5 spots at $5 with tax included and noting the owner counts toward the total, which is meaning the schema does not carry.

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 — 'Get a pay link for more people on a trip you own' — and immediately quantifies the unit (5 spots per block, $5/block, owner included in the count). It is clearly distinguishable from siblings like create_trip and join_trip.

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 names the triggering conditions: 'Use it when a let-in is refused because the trip is full, or when your human asks for more room.' It also gives an exclusion: not on a read-only trip, where it is refused as payment_required. Both when and when-not are covered.

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

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