Skip to main content
Glama

Find records in a trip

query
Read-only

Find records in a trip; on a trip shared with your human to view (its view link or code in trip), the same filters over only what it shares, with viewing true (no pads, friends' tips, questions or reminders). Find items (or, with record "interest", people's interest; with record "link", saved links: item filters them by what they're about, item "none" is the inbox; with record "pad", the trip's pads and their links; with record "pad_entry", what friends wrote: pad and taken filter them; with record "note", people's notes: on (an item, a finding, the trip or a member) and person (the author) filter them; with record "ask", questions with their answers and who they still wait on: open_for "me", item (what it's about), person (who asked), status; with record "reminder", reminders: person (who they reach; "me"), item, sent (a reminder with missed_at fell due while the trip was deleted and wasn't sent); with record "research", what AIs found out: item (what it's about; "none" for the trip in general), text). For tasks, owner ("me", a person or a member) finds whose they are. For items, origin filters where they came from (friend, ai, none). Filters combine: ids, item_type, status, category, text (searches titles and all fields), parent, near (a point or an item, within radius_m; nearest first), during (days, as dates or "day N": everything on day 6), when_precision ("none" for what has no time yet), unrated_by "me" (what waits on my rating, as get_trip's unrated_by_you), person (whose interest; "me" or a person id), tier (one or several of "no" (not interested), "maybe" and "yes" (really want it): what someone, or person when given, said that to; with record "interest", the ratings), going ("yes", "no", "maybe", likewise), changed_since. include ["interest"] adds everyone's interest to each item, ["children"] a goal's candidates or a choice's options (each with the rest of include), ["links"] the links saved about it (as links_found), ["notes"] people's notes on it (as notes_left), ["files"] the files attached to it (name, type, size, and as: "photo" for its own photos), ["weather"] each day's weather beside the items (as weather; for the days during covers, else every day with a place: see guide "days"); fields limits what comes back. Items with a price or payments come with your_currency, as get_trip's. Results are paged: pass next_cursor as cursor.

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": "query"
  }
}

Input Schema

NameRequiredDescriptionDefault
onNoWith record note: notes on this item, a finding (rsr_…), the trip's id, or a member id (mem_…).
idsNo
padNoWith record pad_entry: one pad's entries.
itemNo
nearNo
sentNoWith record reminder: false for those still to go (not sent, nor missed), true for those sent.
textNo
tierNoA tier, or several: "no" (not interested), "maybe" or "yes" (really want it). Items someone gave it (person, when given), or with record interest the ratings.
tripYesThe trip id, e.g. "trp_8Kd2…", from list_trips; or a trip shared with your human to view: its view link ("https://…/v/Zq3…") or just its code.
goingNo"yes", "no" or "maybe", or several: items someone (person, when given) said it of, or with record interest the ratings.
limitNo
ownerNoTasks owned by "me", a person or a member (mem_…).
takenNoWith record pad_entry: false for what's not in the plan yet.
cursorNo
duringNoItems whose time touches these days, inclusive: dates, or "day N".
fieldsNo
originNoWhere items came from: "friend" (a friend recommends it), "ai" (an AI's suggestion), or "none" (a person's own).
parentNo
personNo
recordNoitem
statusNo
includeNo
categoryNo
open_forNoWith record ask: the open asks waiting on me (asked of me, not answered yet).
item_typeNo
not_on_mapNoItems whose location (or a move's from or to) has a precision but no coordinates yet.
unrated_byNo
changed_sinceNo
recommended_byNoItems a friend recommends, by the friend's name.
when_precisionNoHow precise the time is; "none" finds what has no time yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / record / enum
      Previous value: -[
      -  "item",
      -  "interest",
      -  "link",
      -  "pad",
      -  "pad_entry",
      -  "note",
      -  "ask",
      -  "reminder",
      -  "document",
      -  "research"
      -]New value: +[
      +  "item",
      +  "interest",
      +  "link",
      +  "pad",
      +  "pad_entry",
      +  "note",
      +  "ask",
      +  "reminder",
      +  "research"
      +]
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: paging via next_cursor, shared-trip scoping that hides pads/friends' tips/questions/reminders, include-array expansion semantics, and your_currency on priced items. It never contradicts the read-only annotation.

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 first clause is front-loaded and content is information-dense with little true waste, which is defensible for a 30-parameter tool. But it is delivered as one enormous semicolon-chained paragraph with no grouping, making it hard to scan and forcing the agent to parse a wall of text to locate the record-mode and include rules.

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 parameter-heavy query tool with no output schema, the description covers the record modes, combinable filters, include expansions, currency fields, and pagination, which is close to what an agent needs. Remaining gaps are the default item shape and the exact mechanics of obtaining a next_cursor, but these are minor relative to total complexity.

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?

With 30 parameters at only 47% schema description coverage, the description must carry most of the semantic load, and it does explain several filters well (near, during, include, tier/going, open_for, sent, taken). But core filters such as ids, item_type, status, category, parent, and fields are only listed in a comma run with no semantics, leaving a substantial share of parameters under-documented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause 'Find records in a trip' gives a specific verb and resource, and the record enumeration (item, interest, link, pad, note, ask, reminder, research) makes clear this is the general filtered-search tool rather than a single-trip fetch. It does not explicitly name get_trip or list_trips as the non-search alternatives, so sibling differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is embedded in the record-type taxonomy ('with record "ask", questions with their answers...'), which implies when each mode applies, and the shared-view sentence explains behavior on view-only trips. However, there is no explicit 'use this when / use get_trip instead when' guidance, so the agent must infer the routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources