Tineo

Share trips with a friend

trip_sharing_set

DestructiveIdempotent

Give one friend view or edit access to the user's own trips, change their level, or remove it (access=none), for specific trips (trip_ids) or every trip the user owns (all_trips=true, 25 per page). Idempotent: it checks each trip first and only changes what differs, so re-running it never sends a duplicate invitation. New access is an invitation emailed to the friend, who gets access once they accept. Without confirmed=true nothing is written or emailed: it returns the plan per trip (would_invite, would_update_access, would_revoke, already_correct, already_invited, needs_attention). Show that plan, and call again with the same arguments plus confirmed=true only once the user has explicitly asked for this change, in this conversation or in the instructions of a scheduled task they set up; after they approve the plan, apply it without previewing or asking again. Results per trip: invited, invitation_updated, access_updated, revoked, already_correct, already_invited, needs_attention (with a reason, e.g. not the owner or access via the traveler list) or failed; report them to the user, describing invited trips as pending invitations rather than access already granted. Friend summaries are separate and never changed here: they follow the user's friend settings and each trip's hide-from-friends switch. Only friends can get access; for someone who is not a friend yet, offer friend_request_send first. If their friend request is still pending, the call changes nothing and returns friendRequest and a note: tell the user they haven't accepted yet, and only if the user still wants it, call again with confirmed=true and pending_friend_confirmed=true. Get friend_user_id from friends_list; never guess it from a name. Never show IDs to the user.

Input Schema

Name	Required	Description
`page`	No	With all_trips, the 1-based page of 25 trips. Default 1.
`access`	Yes	view = can see the trip; edit = can change it; none = remove their per-trip access.
`message`	No	Optional note for new invitation emails (max 280 chars).
`trip_ids`	No	Trip IDs to change. Provide this OR all_trips.
`all_trips`	No	Apply to every trip the user owns, 25 per page. Provide this OR trip_ids.
`confirmed`	No	true applies the change. Omit or false to preview without writing or emailing anything.
`upcoming_only`	No	With all_trips, only trips that have not ended yet. Default false.
`friend_user_id`	Yes	The friend's user_id from friends_list. For access=none, any user_id listed with access in trip_sharing_get.
`pending_friend_confirmed`	No	Only when the friend request is still pending: true once the user, told they haven't accepted yet, still wants to grant this access.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / pending_friend_confirmed

Added value: +{
+  "description": "Only when the friend request is still pending: true once the user, told they haven't accepted yet, still wants to grant this access.",
+  "type": "boolean"
+}

AddedOct 16, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: idempotency is explained by its mechanism (checks each trip, only changes what differs, no duplicate invitations), new access is an emailed invitation effective on acceptance, and every outcome code (invited, needs_attention, failed) plus the undo path (access=none) is spelled out. The destructiveHint is implicit in the revoke flow rather than explicitly framed as irreversible, which is the only gap.

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 confirmation gate, and essentially every clause carries operative information (preview fields, outcome codes, error reasons, ID-hiding rule). It is a dense single block, though, and the outcome-code lists are repeated in both preview and result form, which adds 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?

With no output schema, the description fully compensates by enumerating the preview plan fields and the per-trip result values, including what to tell the user (pending invitations vs. granted access) and what to do on needs_attention. For a 9-parameter destructive, open-world tool, an agent has everything needed 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 100%, so the baseline is 3, but the description adds real workflow meaning the schema cannot: the two-step confirmed gate, the conditional pending_friend_confirmed=true re-call, the source of friend_user_id (never guessed from a name), and access=none accepting IDs from trip_sharing_get. Minor deduction for not elaborating all_trips/upcoming_only/paging beyond 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: grant view/edit access to the user's own trips, change level, or remove with access=none, across trip_ids or all_trips. It is clearly distinguished from siblings by naming the adjacent tools it is not (trip_sharing_get, friends_list, friend_request_send).

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 routing rules: use friends_list for friend_user_id, offer friend_request_send for non-friends, and a precise when-to-confirm protocol (only after explicit user request in this conversation or a scheduled-task instruction; apply after approval without re-previewing). It even covers the pending-friend-request branch and the separate friend-summary path.

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

All Tineo tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?