Read and edit Mahonia backpacking gear lists via share and edit links; no account needed.
Scored across 6 tools
Each tool targets a distinct resource/action pair: create/edit/get list, edit/get My Gear, and search catalog. The detailed descriptions further clarify boundaries, such as edit_list changing existing lists while create_list makes new ones, and get_list's account-list mode is clearly separate from get_my_gear's gear inventory.
All six tools follow a consistent snake_case verb_noun pattern: create_list, edit_list, get_list, edit_my_gear, get_my_gear, search_catalog. The use of 'my_gear' is consistent across the two account-gear tools.
Six tools is well-scoped for this domain, with each tool covering a meaningful operation rather than proliferating narrow endpoints. The broad edit_list and edit_my_gear tools consolidate many row/folder/piece operations appropriately.
Core workflows are covered: list creation, retrieval, editing, row/folder removal, gear add/update/remove/restore, and catalog search. The main gap is the absence of a delete-list operation, so full list lifecycle coverage is missing, though most practical tasks can be accomplished.
Creates a list and returns its edit link and share link. Optionally with a title, unit, trip dates, a trail link and rows, grouped into folders; a row with items nested under it is a group (stakes under a tent, snacks under a day). Keep the edit link: it is the only way to change a list that isn't filed under an account. If this connector carries a read-and-write access token the list is filed under that account too, and saved_to_account says whether it was; otherwise the list belongs to whoever holds the edit link, as every list does.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | The unit the list displays in. Weights are in grams regardless. | |
| items | No | Rows not placed through a folder above; each may name its folder. | |
| title | No | ||
| folders | No | Folders in order, each with its default classification and, optionally, its rows. | |
| end_date | No | YYYY-MM-DD | |
| trail_url | No | An http(s) link to the route or trail page. | |
| start_date | No | YYYY-MM-DD | |
| trail_label | No | What to call the trail, when the link's own name won't do. | |
| trail_distance_km | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | Rows made. |
| title | Yes | User text. |
| totals | Yes | Whole grams, summed over every row of the list. |
| folders | Yes | Folders made. |
| edit_link | Yes | The write capability. Keep it; it is the only way to change a list that isn't filed under an account. |
| share_code | Yes | |
| share_link | Yes | The read capability, safe to pass on. |
| account_note | No | Only when the connector sent an access token and the list still could not be filed under its account: the reason, and what to do instead. |
| saved_to_account | Yes | True when the connector's read-and-write access token filed the list under its account, where the owner sees it on every device they sign in on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-destructive, non-idempotent write; the description adds the important behavioral facts an agent cannot infer: a share link and edit link come back, the edit link is the sole credential for lists not filed under an account, and whether the list is filed under the token's account is reported as saved_to_account. That is genuine disclosure beyond the structured fields, including the account-scoping consequence of the connector's token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and return values are front-loaded, then composition, then the edit-link caution — a sensible order with no filler sentences. The closing clause ("as every list does") is slightly convoluted and the paragraph runs long, but each element carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, all-optional creation tool with an output schema, the description covers ownership semantics, link retention, and structural composition well. Minor gaps remain: no defaults for unit/dates and no statement on whether repeated calls create duplicate lists, which matters given idempotentHint=false.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 78%, so per-field meaning is largely already documented. The description still adds a holistic model of how parameters relate — items vs. folders, and that a row containing nested items becomes a group ("stakes under a tent, snacks under a day") — which the field-by-field schema does not frame. It stops short of covering the undescribed title and trail_distance_km parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Creates a list") and immediately names both artifacts returned (edit link and share link), plus the composition model of folders/rows/groups. The note that the edit link "is the only way to change a list that isn't filed under an account" implicitly routes modification to the edit_list sibling, so an agent can tell create from edit without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use: everything is optional, so the tool can be called bare or with a full folder/row tree, and the edit-link remark signals that subsequent changes go through a different tool. There is no explicit "do not use when…" exclusion or a named alternative beyond that hint, which keeps it at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes a list that already exists, all of it in one call. list sets the list's own title, display unit, trip dates and trail (only the fields given; an empty string clears a date or the trail). folders renames, reorders, reclassifies or removes folders, named by id or current name; removing one removes its rows. add puts new rows on, into a folder by name (made when missing) or under a group by the parent row's id. update changes rows by the ids get_list gives: any field, null clearing one that can be cleared; a new folder, place or group; a catalog_id to link or relink the row where it sits, null to unlink. remove takes rows off by id, a group's nested rows with it. The parts apply in that order as one change, and nothing is applied unless every part is valid: a row or folder named that isn't there fails the whole call. A name or weight changed on a catalog-linked row is kept as the owner's own. Takes the list's edit link, or its share code under a signed-in account that has filed it.
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | New rows. Each may name its folder, or the group to join. | |
| list | No | The list's own fields. Only the fields given change. | |
| again | No | A call with rows to add that is identical to one made in the last ten minutes is taken as a retry and does nothing: the earlier result comes back with repeated set. Pass true to make the same change a second time on purpose. | |
| remove | No | Ids of rows to take off, from get_list. | |
| update | No | Changes to rows that exist, each by id. | |
| folders | No | Changes to folders that exist. | |
| edit_link | No | The list's edit link, whole (mahonia.app/e/CODE#token). The part after # is the write capability. Leave it out to name a list filed under the signed-in account by share_code instead. | |
| share_code | No | Instead of the edit link: the share code or share link of a list filed under the connector's account, as get_list with no share_code gives it. Takes a sign-in with read-and-change access, and reaches only the lists that account has filed. |
| Name | Required | Description |
|---|---|---|
| unit | Yes | The unit the list displays in. Weights are in grams regardless. |
| added | Yes | Rows added, nested ones counted. |
| dates | Yes | |
| title | Yes | User text. |
| trail | Yes | |
| totals | Yes | Whole grams, summed over every row of the list. |
| folders | Yes | Every folder's name, in the list's order, after the change. |
| removed | Yes | Rows taken off: by remove, with a removed group, or with a removed folder. |
| updated | Yes | Rows changed, moved or regrouped. |
| repeated | Yes | True when this call, with rows to add, repeated one made in the last ten minutes: nothing was done again, and the figures are that call's. Pass again: true to do it a second time. |
| share_link | Yes | |
| folders_made | Yes | Folders that didn't exist and were made for rows named into them. |
| folders_changed | Yes | Folders renamed, reordered, reclassified or removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: atomic all-or-nothing validation, the fixed order of list/folders/add/update/remove, cascading folder removal, empty-string clearing, catalog-link ownership rules, and retry deduplication with the 'again' override. These details materially help an agent predict destructive and non-idempotent effects, consistent with destructiveHint=true and idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and densely organized by operation, with no obvious filler. It is long and clause-heavy rather than scannable, but the length is justified by the tool's complexity and the need to explain atomic multi-part edits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 optional parameters, nested objects, full schema coverage, annotations, and an output schema, the description covers the important missing context: access via edit link or share code, ordering, atomicity, retry behavior, and catalog-link side effects. No essential agent-facing behavior appears omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds cross-parameter meaning: the order in which list, folders, add, update, and remove are applied, the all-or-nothing validation rule, and the fact that removing a folder removes its rows. Much individual field semantics are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Changes a list that already exists,' and emphasizes the multi-part scope 'all of it in one call.' It implicitly distinguishes from create_list by requiring an existing list and from get_list by describing mutations rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: existing lists only, edit link or share code for access, and references get_list and search_catalog for ids. However, it does not explicitly say when to use create_list instead, nor does it spell out exclusions beyond the existing-list condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes the connector's account's My Gear, in one call. add puts new pieces in; one the account already holds (same brand, name and variant) comes back as already_have and is left as it was. update changes pieces by the ids get_my_gear gives, only the fields sent, null clearing one. A piece that names a catalog_id, as it is added or later, is linked to that catalog row and takes its brand, name, variant, gear type and weight where none were given; null unlinks it. remove puts pieces away by id: they stop being offered on lists, and the lists that still carry them will not bring them back. restore brings put-away pieces back. Each piece answers for itself, in the order sent. What is added or changed here counts as the owner's own word on the piece, so a list saved later cannot overwrite it. Needs a read-and-change access token.
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | New pieces. | |
| remove | No | Ids of pieces to put away. | |
| update | No | Changes to pieces that exist, each by id. | |
| restore | No | Ids of put-away pieces to bring back. |
| Name | Required | Description |
|---|---|---|
| added | Yes | Pieces that were new to My Gear. |
| removed | Yes | One per id in remove, then one per id in restore, in the order sent. |
| results | Yes | One per piece in add, in the order sent. |
| updated | Yes | One per entry in update, in the order sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds substantial behavior beyond the annotations: duplicate adds return already_have and leave the piece unchanged, update changes only the fields sent with null clearing, catalog_id links and inherits catalog fields, remove hides pieces from lists, and restore reverses that. It also discloses ordering semantics and the access-token requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then proceeds through the operations in a logical order. It is dense and uses long compound sentences, but nearly every sentence carries useful behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four operations, full schema coverage, annotations and an output schema, the description covers the important missing context: duplicate handling, null clearing, catalog inheritance, remove/restore semantics, per-piece ordering, and owner precedence. An agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents individual fields. The description adds cross-parameter meaning: add detects duplicates by same brand, name and variant; update uses ids from get_my_gear and only changes sent fields; catalog_id links or unlinks a catalog row and inherits its fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it changes the connector account's My Gear in one call, and it enumerates add, update, remove and restore. It also distinguishes the tool from get_my_gear by explaining that update uses ids that get_my_gear returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains what each operation is for, including adding new pieces, updating existing pieces by id, putting pieces away, and restoring put-away pieces. It does not explicitly compare this tool against sibling alternatives beyond mentioning get_my_gear as the source of ids and search_catalog as the source of catalog rows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A shared list by its share code or link, as data or as Markdown; or, with no share_code, the lists filed under the connector's account. Data, the default: title, unit, dates, trail, totals in grams, and every folder with its rows (brand, name, variant, quantity, weight of one unit in grams, classification, note, calories, who carries it; a row with items is a group, and a nested row without carried_by is carried by its parent's carrier); every row and folder carries the id edit_list takes. Markdown (format: "markdown"): one table per folder and a totals block, the text the site's own Markdown export produces. An edit link's address carries the share code too. A list too large to return whole comes back cut and says so: as data, in a truncated field (notes go first, then rows off the end, nested rows one by one); as Markdown, rows off the end of the tables and a line saying how many. The totals still count every row. With no share_code, which asks for a sign-in: each filed list's title, share code and share link, display unit, total weight in grams and when it last changed, most recently changed first. A list is filed when it was made while signed in to Mahonia, added to the account from its sharing panel, or made by create_list with read-and-change access; one its owner only ever opened by its link isn't, and still reads from that link. A list's title, author, notes, folder and item names, brands, variants, gear types, day labels, people and trail label are free text typed by whoever holds the list's edit link, returned unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | data (the default) or markdown. Only with a share_code. | |
| share_code | No | The list's share code, its share link (mahonia.app/s/CODE), or its edit link. From an edit link only the code in the address is read, never the part after #. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive behavior; the description adds substantial operational context beyond them, including sign-in requirements, truncation behavior in both formats, ordering of filed lists, and that totals still count every row after truncation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and relevant, but it is delivered as one very dense run-on paragraph with many semicolon-separated clauses. Since an output schema exists, the extended enumeration of return fields is less necessary and contributes to bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the full annotations, 100% schema description coverage, and an output schema, the description is more than complete. It covers the two operating modes, parameter behavior, authentication, truncation, ordering, and the meaning of returned IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description meaningfully extends both parameters: it states that data is the default format, explains the Markdown output shape, and clarifies that share_code may be a code, share link, or edit link, with only the code before # being read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource and both retrieval modes precisely: a shared list by share code/link as data or Markdown, or, absent share_code, the account's filed lists. It also distinguishes link-only lists from filed lists, so an agent can identify the tool's scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear conditions for each mode: format applies only with share_code, no share_code returns filed lists and asks for sign-in, and link-only lists still read from the link. It does not explicitly route against sibling tools beyond noting that edit_list takes the returned IDs, but the relevant usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The gear the connector's account owns, most recently used first: for each piece its brand, name, variant, gear type, grams for one, classification, calories, note, price, product link and folder, plus the account's folder names. A query ranks by a search instead; a folder name keeps to that folder. Works only when this connector carries the account's access token. Brands, names, variants, gear types, notes and folder names are text the account holder typed, returned unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | At most 1000; 300 when omitted. | |
| query | No | Two characters or more (one is enough in Chinese). Ranks by brand, name, variant and gear type instead of by recent use. | |
| folder | No | Keep to one folder, by name. An empty string means the unfiled pieces. | |
| offset | No | How many matches to skip, for the next page. |
| Name | Required | Description |
|---|---|---|
| gear | Yes | This page of the matches. |
| total | Yes | Matches in all, before offset and limit. |
| offset | Yes | |
| folders | Yes | Every folder My Gear has, in the owner's order, empty ones included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower, and the description still adds real context: it discloses the access-token prerequisite ('Works only when this connector carries the account's access token') and warns that brands, names, variants, notes and folder names are raw account-typed text returned unchanged — a useful trust/prompt-injection signal. It also states the default ordering, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and ordering, which is good, but a large share of the text is a field-by-field inventory of the response ('brand, name, variant, gear type, grams..., product link and folder') that duplicates the output schema and does not help an agent decide or invoke. The remainder is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter read with an output schema, the description covers the essential unknown — the auth-token precondition — plus default ordering and text passthrough. Pagination mechanics live in the schema, and return shape is covered by the output schema, so nothing critical is missing; only the sibling routing is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters are already documented, including limits, the Chinese-character query nuance, and the empty-string folder case. The description adds only the default sort order ('most recently used first') and a paraphrase of query ranking, so it neither compensates for nor extends the schema meaningfully — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: reads the gear the connector's account owns, returns it most-recently-used first, and enumerates what each entry contains. It is clear what the tool returns, but it never names or contrasts itself with siblings like search_catalog or get_list, so an agent must infer the boundary on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'A query ranks by a search instead; a folder name keeps to that folder' explains how parameters steer results, which implies when to use them, but there is no explicit when-to-use/when-not guidance and no named alternative for catalog-wide search or for mutating gear (edit_my_gear). Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mahonia's cited gear catalog. With query: a fuzzy search by brand, product or kind of gear ("duplex", "zpacks", "quilt"), best first, each result a catalog row with its id, the cited weight in grams and whether it is verified. With product_id (a row id from a search), or brand and name: every variant of that one product (sizes, lengths, temperature ratings) with the weight and source of each. A row on a list that names a catalog_id takes the catalog's brand, variant, gear type and weight.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | With brand, instead of a query: the product name without brand or variant. | |
| brand | No | With name, instead of a query: the product's maker. | |
| limit | No | Matches to return, up to 25. Default 12. | |
| query | No | What to search for: two characters or more, or a single Chinese character. | |
| product_id | No | Instead of a query: a catalog row id, for that product's variants. |
| Name | Required | Description |
|---|---|---|
| query | No | The query as searched: trimmed, at most 100 characters. On a search. |
| product | No | The product looked up, when one was. |
| results | Yes | A search's matches, best first; or a product's variants, in variant order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description goes beyond them with real behavioral detail: fuzzy matching, best-first ordering, per-row id/weight-in-grams/verified fields, and variant fan-out with per-variant weight and source. The closing sentence about a list row "taking" a catalog_id is cryptic and reads like cross-tool behavior rather than something this call does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The mode list is front-loaded and the query examples are efficiently packed, but the final sentence about list rows and catalog_id is dense and ambiguous enough to cost more attention than it returns. The description also re-explains return fields that an output schema already covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value explanation isn't required, so the description is complete on modes and matching. However, a tool with zero required parameters and a limit default is missing the most important missing case — what an argument-free call does — and the ambiguous trailing sentence leaves an agent unsure whether it describes this tool's output or a downstream behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by showing the mode grouping and giving concrete query examples ("duplex", "zpacks", "quilt") that convey the fuzzy-match domain better than "what to search for" does. It also clarifies that product_id is a row id obtained from a prior search, which the schema only hints at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("Mahonia's cited gear catalog" searched fuzzily) and enumerates three distinct modes: free-text query, product_id, and brand+name. It is clearly a read-only catalog lookup, distinct from the list/gear-mutation siblings, though it never states that distinction explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"With query…" / "With product_id (a row id from a search)…" / "or brand and name…" spells out which mode to pick and even chains one call into the next (search first, then fetch variants by row id). What's missing is the zero-argument case: no required parameters exist, so an agent has no guidance on what a bare call returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_catalog1 field changedInput schema / properties / query / descriptionPrevious value: -"Two characters or more."New value: +"Two characters or more; a single Chinese character is enough."add_items1 field changedInput schema / properties / items / items / properties / needs_cookingAdded value: +{
+ "description": "Food to cook on this trip. Each unit assumes one boil for a rough fuel estimate; no quantity or weight changes.",
+ "type": "boolean"
+}create_list2 fields changedInput schema / properties / folders / items / properties / items / items / properties / needs_cookingAdded value: +{
+ "description": "Food to cook on this trip. Each unit assumes one boil for a rough fuel estimate; no quantity or weight changes.",
+ "type": "boolean"
+}Input schema / properties / items / items / properties / needs_cookingAdded value: +{
+ "description": "Food to cook on this trip. Each unit assumes one boil for a rough fuel estimate; no quantity or weight changes.",
+ "type": "boolean"
+}get_list2 fields changedOutput schema / properties / folders / items / properties / items / items / properties / items / items / properties / needs_cookingAdded value: +{
+ "description": "Food marked for cooking on this trip.",
+ "type": "boolean"
+}Output schema / properties / folders / items / properties / items / items / properties / needs_cookingAdded value: +{
+ "description": "Food marked for cooking on this trip.",
+ "type": "boolean"
+}add_items1 field changedInput schema / properties / items / items / properties / name / minLengthAdded value: +1create_list3 fields changedInput schema / properties / folders / items / properties / items / items / properties / name / minLengthAdded value: +1Input schema / properties / folders / items / properties / name / minLengthAdded value: +1Input schema / properties / items / items / properties / name / minLengthAdded value: +1add_items3 fields changedInput schema / properties / againAdded value: +{
+ "description": "A call identical to one made in the last ten minutes is taken as a retry and adds nothing: the earlier result comes back with repeated set. Pass true to add the same rows a second time on purpose.",
+ "type": "boolean"
+}Output schema / properties / repeatedAdded value: +{
+ "description": "True when this call repeated one made in the last ten minutes: nothing was added again, and the figures are that call's. Pass again: true to add the rows a second time.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "added",
- "folders_made",
- "share_link",
- "totals"
-]New value: +[
+ "added",
+ "folders_made",
+ "share_link",
+ "totals",
+ "repeated"
+]get_list1 field changedOutput schema / properties / truncated / descriptionPrevious value: -"Present only when the list was too large to return whole, naming what was cut: notes (true: every row's note), rows (how many came off the end, nested rows counted), fields (which of description, days, trail and people went, only when the rest alone was too large). The totals still count every row. get_list_markdown returns the same rows in about a third of the space, without notes."New value: +"Present only when the list was too large to return whole, naming what was cut: notes (true: every row's note), rows (how many came off the end, nested rows counted), fields (which of description, days, trail and people went, only when the rest alone was too large). The totals still count every row. get_list_markdown holds about three times as many rows, without notes, and is cut the same way only past that."add_items1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "added": {
+ "description": "Rows added.",
+ "type": "integer"
+ },
+ "folders_made": {
+ "description": "Folders that didn't exist and were made for these rows.",
+ "items": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "share_link": {
+ "type": "string"
+ },
+ "totals": {
+ "description": "Whole grams, summed over every row of the list.",
+ "properties": {
+ "base_g": {
+ "description": "In the pack, consumables aside.",
+ "type": "integer"
+ },
+ "carried_g": {
+ "description": "base_g plus consumable_g: what is on your back.",
+ "type": "integer"
+ },
+ "consumable_g": {
+ "description": "Food, fuel, water.",
+ "type": "integer"
+ },
+ "item_count": {
+ "description": "Rows, nested ones included.",
+ "type": "integer"
+ },
+ "kcal": {
+ "description": "Only when a food row carries calories.",
+ "type": "number"
+ },
+ "total_g": {
+ "description": "carried_g plus worn_g.",
+ "type": "integer"
+ },
+ "worn_g": {
+ "description": "On your body.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "base_g",
+ "worn_g",
+ "consumable_g",
+ "carried_g",
+ "total_g",
+ "item_count"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "added",
+ "folders_made",
+ "share_link",
+ "totals"
+ ],
+ "type": "object"
+}create_list2 fields changedInput schema / properties / unit / descriptionPrevious value: -"The unit the list displays in. Weights are still given in grams."New value: +"The unit the list displays in. Weights are in grams regardless."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "edit_link": {
+ "description": "The write capability. Keep it; it is the only way back into the list.",
+ "type": "string"
+ },
+ "folders": {
+ "description": "Folders made.",
+ "type": "integer"
+ },
+ "items": {
+ "description": "Rows made.",
+ "type": "integer"
+ },
+ "share_code": {
+ "type": "string"
+ },
+ "share_link": {
+ "description": "The read capability, safe to pass on.",
+ "type": "string"
+ },
+ "title": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "totals": {
+ "description": "Whole grams, summed over every row of the list.",
+ "properties": {
+ "base_g": {
+ "description": "In the pack, consumables aside.",
+ "type": "integer"
+ },
+ "carried_g": {
+ "description": "base_g plus consumable_g: what is on your back.",
+ "type": "integer"
+ },
+ "consumable_g": {
+ "description": "Food, fuel, water.",
+ "type": "integer"
+ },
+ "item_count": {
+ "description": "Rows, nested ones included.",
+ "type": "integer"
+ },
+ "kcal": {
+ "description": "Only when a food row carries calories.",
+ "type": "number"
+ },
+ "total_g": {
+ "description": "carried_g plus worn_g.",
+ "type": "integer"
+ },
+ "worn_g": {
+ "description": "On your body.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "base_g",
+ "worn_g",
+ "consumable_g",
+ "carried_g",
+ "total_g",
+ "item_count"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "title",
+ "edit_link",
+ "share_link",
+ "share_code",
+ "folders",
+ "items",
+ "totals"
+ ],
+ "type": "object"
+}get_catalog_product1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "brand": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "gear_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "The product name, without brand or variant.",
+ "type": "string"
+ },
+ "variants": {
+ "description": "Every active variant, in variant order.",
+ "items": {
+ "properties": {
+ "id": {
+ "description": "The catalog row id, the one add_items and create_list take as catalog_id.",
+ "type": "integer"
+ },
+ "kcal": {
+ "description": "Calories per unit, on food.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "source_url": {
+ "description": "The page the weight was read from.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "variant": {
+ "description": "Size, length or rating; null on a product sold one way.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verified": {
+ "description": "Whether the cited weight has been verified.",
+ "type": "boolean"
+ },
+ "weight_g": {
+ "description": "The cited weight in grams, to a tenth.",
+ "type": "number"
+ },
+ "weight_source": {
+ "description": "Where the weight comes from.",
+ "enum": [
+ "manufacturer",
+ "measured",
+ "community",
+ "imported"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "variant",
+ "weight_g",
+ "verified",
+ "weight_source",
+ "kcal",
+ "source_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "brand",
+ "name",
+ "gear_type",
+ "category",
+ "variants"
+ ],
+ "type": "object"
+}get_list1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "author": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "dates": {
+ "properties": {
+ "end": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "start": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "start",
+ "end"
+ ],
+ "type": "object"
+ },
+ "days": {
+ "description": "The trip's days in order, when the owner has planned them.",
+ "items": {
+ "properties": {
+ "ascent_m": {
+ "description": "Typed by the owner, or read off the route's profile.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "day": {
+ "description": "Day 1; with trip dates, the weekday too: Saturday, Day 1.",
+ "type": "string"
+ },
+ "distance_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "label": {
+ "description": "The owner's name for the day. User text.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "day",
+ "distance_m",
+ "ascent_m"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "description": {
+ "description": "The list's own notes. User text.",
+ "type": "string"
+ },
+ "folders": {
+ "description": "In the list's order, each with its rows in order. A folder with no rows is left out; rows in no folder come last, under Unfiled.",
+ "items": {
+ "properties": {
+ "items": {
+ "items": {
+ "properties": {
+ "brand": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "carried_by": {
+ "description": "Who carries it. A nested row without one is carried by its parent's carrier. User text.",
+ "type": "string"
+ },
+ "catalog_id": {
+ "description": "The catalog row the item was picked from.",
+ "type": "number"
+ },
+ "classification": {
+ "description": "The row's own, or its folder's when it has none.",
+ "enum": [
+ "base",
+ "worn",
+ "consumable"
+ ],
+ "type": "string"
+ },
+ "display_name": {
+ "description": "Brand, name and variant joined, the way the list shows the row.",
+ "type": "string"
+ },
+ "gear_type": {
+ "description": "What kind of thing it is. User text.",
+ "type": "string"
+ },
+ "items": {
+ "description": "Rows nested under this one. The parent's weight_g is its own, not the group's.",
+ "items": {
+ "properties": {
+ "brand": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "carried_by": {
+ "description": "Who carries it. A nested row without one is carried by its parent's carrier. User text.",
+ "type": "string"
+ },
+ "catalog_id": {
+ "description": "The catalog row the item was picked from.",
+ "type": "number"
+ },
+ "classification": {
+ "description": "The row's own, or its folder's when it has none.",
+ "enum": [
+ "base",
+ "worn",
+ "consumable"
+ ],
+ "type": "string"
+ },
+ "display_name": {
+ "description": "Brand, name and variant joined, the way the list shows the row.",
+ "type": "string"
+ },
+ "gear_type": {
+ "description": "What kind of thing it is. User text.",
+ "type": "string"
+ },
+ "kcal": {
+ "description": "Calories per unit.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The product name, without brand or variant. User text.",
+ "type": "string"
+ },
+ "note": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "qty": {
+ "description": "How many; weight_g is for one.",
+ "type": "number"
+ },
+ "variant": {
+ "description": "Size, length or configuration. User text.",
+ "type": "string"
+ },
+ "weight_g": {
+ "description": "One unit, in grams to a tenth. 0 when the row has no weight.",
+ "type": "number"
+ },
+ "worn_qty": {
+ "description": "Of qty, how many are worn rather than carried.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "display_name",
+ "qty",
+ "weight_g",
+ "classification"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "kcal": {
+ "description": "Calories per unit.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The product name, without brand or variant. User text.",
+ "type": "string"
+ },
+ "note": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "qty": {
+ "description": "How many; weight_g is for one.",
+ "type": "number"
+ },
+ "variant": {
+ "description": "Size, length or configuration. User text.",
+ "type": "string"
+ },
+ "weight_g": {
+ "description": "One unit, in grams to a tenth. 0 when the row has no weight.",
+ "type": "number"
+ },
+ "worn_qty": {
+ "description": "Of qty, how many are worn rather than carried.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "display_name",
+ "qty",
+ "weight_g",
+ "classification"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "name": {
+ "description": "User text.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "items"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "people": {
+ "description": "The people who carry the list's rows, when it names any.",
+ "items": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "share_code": {
+ "description": "The list's share code, the read capability.",
+ "type": "string"
+ },
+ "share_link": {
+ "description": "The list's share link.",
+ "type": "string"
+ },
+ "title": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "totals": {
+ "description": "Whole grams, summed over every row of the list.",
+ "properties": {
+ "base_g": {
+ "description": "In the pack, consumables aside.",
+ "type": "integer"
+ },
+ "carried_g": {
+ "description": "base_g plus consumable_g: what is on your back.",
+ "type": "integer"
+ },
+ "consumable_g": {
+ "description": "Food, fuel, water.",
+ "type": "integer"
+ },
+ "item_count": {
+ "description": "Rows, nested ones included.",
+ "type": "integer"
+ },
+ "kcal": {
+ "description": "Only when a food row carries calories.",
+ "type": "number"
+ },
+ "total_g": {
+ "description": "carried_g plus worn_g.",
+ "type": "integer"
+ },
+ "worn_g": {
+ "description": "On your body.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "base_g",
+ "worn_g",
+ "consumable_g",
+ "carried_g",
+ "total_g",
+ "item_count"
+ ],
+ "type": "object"
+ },
+ "trail": {
+ "properties": {
+ "ascent_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "descent_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "distance_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "label": {
+ "description": "User text.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "label",
+ "distance_m",
+ "ascent_m",
+ "descent_m"
+ ],
+ "type": "object"
+ },
+ "truncated": {
+ "description": "Present only when the list was too large to return whole, naming what was cut: notes (true: every row's note), rows (how many came off the end, nested rows counted), fields (which of description, days, trail and people went, only when the rest alone was too large). The totals still count every row. get_list_markdown returns the same rows in about a third of the space, without notes.",
+ "properties": {
+ "fields": {
+ "items": {
+ "enum": [
+ "description",
+ "days",
+ "trail",
+ "people"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "notes": {
+ "type": "boolean"
+ },
+ "rows": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "unit": {
+ "description": "The unit the list displays in. Weights are in grams regardless.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "share_code",
+ "share_link",
+ "unit",
+ "totals",
+ "folders"
+ ],
+ "type": "object"
+}search_catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "query": {
+ "description": "The query as searched: trimmed, at most 100 characters.",
+ "type": "string"
+ },
+ "results": {
+ "description": "Best first.",
+ "items": {
+ "properties": {
+ "brand": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "description": "The catalog's category: shelter, sleep, pack, and so on.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "display_name": {
+ "description": "Brand, name and variant joined.",
+ "type": "string"
+ },
+ "gear_type": {
+ "description": "What kind of thing it is: Tent, Quilt, Trail runners.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "The catalog row id, the one add_items and create_list take as catalog_id.",
+ "type": "integer"
+ },
+ "kcal": {
+ "description": "Calories per unit, on food.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "The product name, without brand or variant.",
+ "type": "string"
+ },
+ "variant": {
+ "description": "Size, length or rating; null on a product sold one way.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verified": {
+ "description": "Whether the cited weight has been verified.",
+ "type": "boolean"
+ },
+ "weight_g": {
+ "description": "The cited weight in grams, to a tenth.",
+ "type": "number"
+ },
+ "weight_source": {
+ "description": "Where the weight comes from.",
+ "enum": [
+ "manufacturer",
+ "measured",
+ "community",
+ "imported"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "variant",
+ "weight_g",
+ "verified",
+ "weight_source",
+ "kcal",
+ "brand",
+ "name",
+ "display_name",
+ "gear_type",
+ "category"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "results"
+ ],
+ "type": "object"
+}set_trip2 fields changedInput schema / properties / unit / descriptionAdded value: +"The unit the list displays in. Weights are in grams regardless."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dates": {
+ "properties": {
+ "end": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "start": {
+ "description": "YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "start",
+ "end"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "share_link": {
+ "type": "string"
+ },
+ "title": {
+ "description": "User text.",
+ "type": "string"
+ },
+ "trail": {
+ "properties": {
+ "ascent_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "descent_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "distance_m": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "label": {
+ "description": "User text.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "label",
+ "distance_m",
+ "ascent_m",
+ "descent_m"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "unit": {
+ "description": "The unit the list displays in. Weights are in grams regardless.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "unit",
+ "dates",
+ "trail",
+ "share_link"
+ ],
+ "type": "object"
+}add_itemscreate_listget_catalog_productget_listget_list_markdownsearch_catalogset_tripUS backcountry permit and campground rules, dates and recorded openings. Read-only, no sign-in.
Shared lists with no sign-up: ready-made lists and recipes, and pre-filled links to share.
Campground search, live availability, weather, safety, and gear for 10,000+ US campgrounds.
US outdoor recreation: 37k+ trails, 30k+ campgrounds, parks, weather + wildfire safety. Read-only.
Add one secure layer between your agents and this server.
