Tripmo

Create a trip

create_trip

Start a new trip with this person as its owner. Dates are optional and can be rough or missing; items can use relative days ("day 3") until the trip has dates. Returns the trip's url (give it to your human), its join_link (for the others coming: they ask to join, the owner lets them in) and what pays for it (coverage: pass, plan, or legacy when nothing needed to pay for it). Look at list_trips' billing first: with no billing, or can_create_trip true, the trip just starts, an unused Trip Pass used by itself (note says so). When can_create_trip is false, a trip needs a Trip Pass or a plan: it answers needs_payment with pay_url, plans_url and message instead: pass the link on calmly, as message says; the trip is created by itself once it's paid, and asking again meanwhile gives the same link. Over a plan's fair use, or with starting trips paused on the account, it's refused, saying why.

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": {
      "title": "<title>"
    },
    "name": "create_trip"
  }
}

Input Schema

Name	Required	Description
`brief`	No	What the trip is for: goals, constraints, preferences (markdown).
`dates`	No
`title`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond annotations by disclosing the multi-outcome behavior: success returns url/join_link/coverage, needs_payment returns links instead, and refusal happens over fair-use limits or when starting trips is paused. It doesn't spell out return shape or permissions requirements in detail, but the payment and refusal paths are a strong addition for a non-idempotent 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.

Conciseness3/5

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

Front-loaded with the core action, but the billing explanation is delivered in long, clause-heavy sentences with parenthetical asides ('coverage: pass, plan, or legacy when nothing needed to pay for it'), making it harder to parse than necessary. The information earns its place, but the structure is dense.

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?

For a write tool with no output schema the description does cover return values (url, join_link, coverage) and the alternate needs_payment response. What's missing is a note on who may call it by role and what the trip starts with by default, but overall an agent has enough to call it 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 only 33% and the complex dates oneOf variants carry no descriptions, so the description's note that dates are optional, can be rough or missing, and that 'day 3'-style relative days are valid adds real meaning the schema can't convey on its own. Title and brief are left to the schema.

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?

Opens with a specific verb and resource plus a scope qualifier ('Start a new trip with this person as its owner'), which immediately distinguishes it from join_trip and list_trips. An agent can tell what it creates and who owns the result without reading the 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 routes the agent: 'Look at list_trips' billing first', then branches by can_create_trip true/false and names the sibling to consult. It also states what to do with the pay_url/plans_url and that retries return the same link, which is genuinely actionable sequencing guidance.

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?