Skip to main content
Glama

Mahonia

by app.mahonia
OverviewDiscussionsAdmin

Server Details

Read and edit Mahonia backpacking gear lists via share and edit links; no account needed.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
ryankiley/mahonia
GitHub Stars
0

TDQS

A4.1/5.0

Scored across 7 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: add_items modifies a list, create_list initializes one, get_list and get_list_markdown retrieve in different formats, and get_catalog_product vs search_catalog handle specific vs fuzzy lookup. No overlaps or ambiguity in tool selection.

Naming Consistency4/5

Most tool names follow a verb_noun pattern (add_items, create_list, get_list, set_trip), but 'search_catalog' uses verb_noun with a domain qualifier, and 'get_list_markdown' includes a format suffix. These are minor deviations that remain predictable and readable.

Tool Count5/5

With 7 tools, the set is well-scoped for a domain focused on managing shared gear lists. Each tool earns its place, covering creation, retrieval, modification, and catalog lookup without redundancy.

Completeness4/5

The surface covers key CRUD operations for lists (create, read, update, add rows) and catalog search. However, there is no explicit delete tool for lists or items, and no update for individual rows or catalog data, which are minor gaps that could require workarounds.

Available Tools

7 tools
add_itemsAdd rows to a listAInspect

Adds rows to an existing list. Takes the list's edit link and the rows; each row may name a folder, and a folder that doesn't exist yet is created.

ParametersJSON Schema
NameRequiredDescriptionDefault
againNoA 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.
itemsYes
folderNoA folder name for every row that doesn't name its own.
edit_linkYesThe list's edit link, whole (mahonia.app/e/CODE#token). The part after # is the write capability.

Output Schema

ParametersJSON Schema
NameRequiredDescription
addedYesRows added.
totalsYesWhole grams, summed over every row of the list.
repeatedYesTrue 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.
share_linkYes
folders_madeYesFolders that didn't exist and were made for these rows.

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world. The description adds one trait beyond them: a folder that doesn't exist yet is created as a side effect. It does not mention the retry/duplicate-suppression behavior ("again") that the schema documents, nor permission/auth requirements.

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?

Two short sentences with no filler; the core action is front-loaded and the folder side effect follows. Every clause carries information, though the second sentence is slightly run-on.

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?

An output schema exists, so return values need not be explained, and the schema itself is highly detailed for the fields. The description covers the key write-side effect (folder creation) but omits any mention of retry semantics or list prerequisites, leaving a minor gap.

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?

Schema description coverage is 75%, so most parameters are already well documented in the schema. The description only restates the edit-link and folder semantics at a high level and adds no syntax or format detail beyond what the schema provides, so a baseline score is appropriate.

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?

States a specific verb and resource ("Adds rows to an existing list") and even summarizes the required inputs (edit link + rows). It is clearly distinct from create_list and get_list, though it doesn't explicitly name those siblings to sharpen the boundary.

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?

The phrase "an existing list" implies a list must already exist, and the description names the edit link and rows as inputs, so usage is implied. But there is no explicit when-to-use, when-not-to-use, or pointer to create_list for lists that don't exist yet.

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

create_listMake a new listAInspect

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. Keep the edit link: it is the only way back into the list.

ParametersJSON Schema
NameRequiredDescriptionDefault
unitNoThe unit the list displays in. Weights are in grams regardless.
itemsNoRows not placed through a folder above; each may name its folder.
titleNo
foldersNoFolders in order, each with its default classification and, optionally, its rows.
end_dateNoYYYY-MM-DD
trail_urlNoAn http(s) link to the route or trail page.
start_dateNoYYYY-MM-DD
trail_labelNoWhat to call the trail, when the link's own name won't do.
trail_distance_kmNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
itemsYesRows made.
titleYesUser text.
totalsYesWhole grams, summed over every row of the list.
foldersYesFolders made.
edit_linkYesThe write capability. Keep it; it is the only way back into the list.
share_codeYes
share_linkYesThe read capability, safe to pass on.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is partly covered. The description earns credit beyond that by warning that the edit link is "the only way back into the list" – a genuine operational consequence that is not encoded in the annotations. It stops short of noting auth needs or whether the share link is public.

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

Conciseness5/5

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

Three sentences, zero waste: the action and its outputs come first, the optional payload second, and the critical edit-link warning last. Every sentence carries distinct information.

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?

An output schema exists, so return values need not be explained, and the annotation set plus the edit-link warning covers the mutation profile. With 9 all-optional parameters and 78% schema coverage, the description is sufficient for correct invocation, though it could say more about what happens when optional fields are omitted.

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?

Schema description coverage is 78%, close to the high-coverage baseline, and nested item fields are individually documented in the schema. The description names the major parameter groups (title, unit, trip dates, trail link, rows, folders) but adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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?

States a specific verb and resource ("Creates a list") and adds what the tool yields ("returns its edit link and share link") plus the optional payload shape (title, unit, dates, trail, rows, folders). It does not, however, contrast itself with add_items or set_trip, so sibling differentiation is left to the agent.

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 is implied rather than stated: a new list is created here while add_items and set_trip operate on an existing list. There is no explicit when-to-use, when-not, or named alternative, so the agent must infer the boundary from the sibling names.

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

get_catalog_productOne catalog product, every variantA
Read-onlyIdempotent
Inspect

One product's variants (sizes, lengths, temperature ratings) with the cited weight and source of each. Give a catalog id from search_catalog, or the brand and product name.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoA catalog row id; its siblings are the other variants.
nameNoThe product name without brand or variant.
brandNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameYesThe product name, without brand or variant.
brandYes
categoryYes
variantsYesEvery active variant, in variant order.
gear_typeYes

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that results carry weights and their sources, which is useful framing but largely a summary of what the output schema already encodes. It says nothing about behavior on unknown ids, multiple brand/name matches, or result limits.

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

Conciseness5/5

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

Two compact sentences with zero filler, and the core payload (variants plus cited weight and source) is front-loaded before the invocation guidance.

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 an output schema present, the description need not enumerate return fields, and it adequately covers both input modes and the shape of the payload. A brief note on id-vs-name precedence would close the remaining gap.

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% and one parameter (brand) is undocumented in the schema; the description compensates by explaining that id and the brand+name pair are alternative lookup modes and that the id comes from search_catalog. It does not, however, state precedence when both are supplied or how name matching works.

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?

Specific verb and resource: retrieves one product's variants (sizes, lengths, temperature ratings) along with each variant's cited weight and source. It also distinguishes itself from the sibling search_catalog by naming it as the origin of the id, so an agent can tell the lookup tool from the discovery tool.

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

Usage Guidelines4/5

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

The description states the two ways to invoke it: 'Give a catalog id from search_catalog, or the brand and product name.' That routes the agent through search_catalog first when it lacks an id. It stops short of explicit when-not-to-use guidance or failure behavior for ambiguous names.

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

get_listRead a shared listA
Read-onlyIdempotent
Inspect

A shared list as data: 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 nested row without carried_by is carried by its parent's carrier). Takes a share code or share link. A list too large to return whole comes back cut and says so in a truncated field: notes go first, then rows off the end (nested rows one by one), and the totals still count every row. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
share_codeYesThe list's share code, or its share link (mahonia.app/s/CODE). Not an edit link.

Output Schema

ParametersJSON Schema
NameRequiredDescription
daysNoThe trip's days in order, when the owner has planned them.
unitYesThe unit the list displays in. Weights are in grams regardless.
datesNo
titleYesUser text.
trailNo
authorNoUser text.
peopleNoThe people who carry the list's rows, when it names any.
totalsYesWhole grams, summed over every row of the list.
foldersYesIn 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.
truncatedNoPresent 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.
share_codeYesThe list's share code, the read capability.
share_linkYesThe list's share link.
descriptionNoThe list's own notes. User text.

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and open-world=false behavior. The description adds substantial context beyond that: truncation rules, the fact that totals count every row even when truncated, nested row carrier inheritance, and that free-text fields are returned unchanged.

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?

The description is dense and front-loads the core payload fields before moving to truncation and free-text behavior. The initial enumeration is long, but every sentence carries relevant information for correct invocation.

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?

Although an output schema exists, the description adds important behavioral completeness by explaining truncation, totals semantics, nested-row inheritance, and free-text preservation. Nothing material for calling or interpreting this read tool appears missing.

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?

Schema description coverage is 100%, so the single share_code parameter is already well documented in the schema. The description restates that it accepts a share code or share link and is not an edit link, adding little syntax or format detail beyond the schema.

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 title and description make clear this retrieves a shared list as structured data, naming specific fields returned. It does not, however, explicitly distinguish itself from the sibling get_list_markdown, which likely returns a similar list in a different format.

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?

The description tells the agent the tool takes a share code or share link and warns it is not an edit link, which is useful input guidance. It does not say when to use this tool versus get_list_markdown or other siblings, leaving the primary selection context implied.

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

get_list_markdownRead a shared list as MarkdownA
Read-onlyIdempotent
Inspect

The same list as Markdown: one table per folder and a totals block, the text the site's own Markdown export produces. Takes a share code or share link. A list too large to return whole loses rows off the end of the tables, a line under them says how many, and the totals still count every row. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
share_codeYesThe list's share code, or its share link (mahonia.app/s/CODE). Not an edit link.

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare the read-only/idempotent/non-destructive safety profile, and the description goes well beyond them: it discloses truncation behavior for oversized lists (rows dropped off table ends, a line reporting how many, totals still counting every row) and warns that title, author, notes, names, brands and labels are untrusted free text returned unchanged — a genuinely valuable injection-surface signal for an agent.

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 what is returned, then input form, then the truncation caveat, then the untrusted-text note. Every sentence carries information, though the long final sentence mixing several field categories is denser than it needs to be.

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 carries the return-value burden itself and does so: it describes the table-per-folder and totals structure, the exact behavior when output is truncated, and the trust level of returned text. Nothing an agent needs to call or interpret this tool is missing.

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?

Schema description coverage is 100% for the single parameter, so the schema already documents the share code / share link / not-an-edit-link semantics. The description's 'Takes a share code or share link' adds no format or syntax detail beyond that, so the baseline 3 applies.

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 ('read a list as Markdown') and immediately scopes it against the sibling get_list via 'The same list as Markdown' plus the concrete shape it returns (one table per folder, totals block). An agent can distinguish it from get_list and the catalog/trip siblings without opening any schema.

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 implied rather than stated: 'the same list as Markdown' and 'the text the site's own Markdown export produces' tells the agent this is the export-format variant of get_list, but it never says explicitly when to prefer Markdown over the structured sibling or when not to use it. The input guidance ('share code or share link, not an edit link') is about the parameter, not tool selection.

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

search_catalogSearch the gear catalogA
Read-onlyIdempotent
Inspect

Fuzzy search of Mahonia's cited gear catalog by brand, product or kind of gear ("duplex", "zpacks", "quilt"). Each result carries a catalog id, the cited weight in grams and whether it is verified. Use get_catalog_product for every variant of one product.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoUp to 25. Default 12.
queryYesTwo characters or more.

Output Schema

ParametersJSON Schema
NameRequiredDescription
queryYesThe query as searched: trimmed, at most 100 characters.
resultsYesBest first.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and an output schema exists, so the description does not need to explain safety or return shape. It still adds real behavioral context: matching is fuzzy rather than exact, and results carry a catalog id plus grams/verified flags. This is useful disclosure 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.

Conciseness5/5

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

Three short sentences, front-loaded with what the tool does, then result contents, then the routing hint. Every sentence carries distinct information and there is no padding or repetition.

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 annotations covering the safety profile, a full input schema and an output schema, the description only needs to add purpose, matching semantics and sibling routing - all present. Nothing an agent needs to select or invoke this tool correctly is missing.

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 description coverage is 100%, so the baseline is 3 and the schema already documents the two-character minimum and the default/max for limit. The description earns above baseline by giving concrete query examples ('duplex', 'zpacks', 'quilt') that illustrate the expected value space, which the schema does not.

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 matching behavior ('Fuzzy search'), names the exact resource ('Mahonia's cited gear catalog'), and enumerates the searchable dimensions (brand, product, kind of gear) with concrete example queries. It also names the sibling get_catalog_product and how it differs, so an agent can separate the two without opening either schema.

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

Usage Guidelines4/5

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

Explicitly routes multi-variant lookups to get_catalog_product, giving a clear condition that selects the alternative. It stops short of a full when/when-not statement (e.g. what to do when the fuzzy search returns nothing, or how it relates to add_items/create_list workflows), so it is clear context rather than exhaustive guidance.

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

set_tripSet a list's title, dates, unit and trailA
DestructiveIdempotent
Inspect

Sets any of a list's title, display unit, trip dates and trail on an existing list. Only the fields given change; an empty string clears a date or the trail. Takes the list's edit link.

ParametersJSON Schema
NameRequiredDescriptionDefault
unitNoThe unit the list displays in. Weights are in grams regardless.
titleNo
end_dateNoYYYY-MM-DD, or an empty string to clear.
edit_linkYesThe list's edit link, whole (mahonia.app/e/CODE#token). The part after # is the write capability.
trail_urlNoAn http(s) link, or an empty string to clear the trail and everything that came with it (label, distance, climb, route).
start_dateNoYYYY-MM-DD, or an empty string to clear.
trail_labelNo
trail_distance_kmNoStored in metres and shown in the list's own distance unit.

Output Schema

ParametersJSON Schema
NameRequiredDescription
unitYesThe unit the list displays in. Weights are in grams regardless.
datesYes
titleYesUser text.
trailYes
share_linkYes

TDQS

A4.2/5.0
Behavior4/5

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

With annotations already declaring destructiveHint=true and idempotentHint=true, the description adds real context beyond them: it explains that unspecified fields are left untouched and that an empty string clears a date or the trail. This directly discloses the destructive semantics of clearing rather than merely repeating the annotation.

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

Conciseness5/5

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

Three sentences, no filler, front-loaded with the set of mutable fields before the partial-update and clearing rules. Every sentence contributes an operative fact an agent needs.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile for this mutation. The description covers partial-update semantics and clearing, leaving only edge cases like invalid or expired edit links unaddressed.

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?

Schema description coverage is 75% and the schema already documents edit_link (with the # write capability), the empty-string clearing convention, and unit storage behavior. The description's 'Takes the list's edit link' and clearing rules largely restate what the schema provides, adding little syntax or format detail beyond it.

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?

The description states a specific verb (sets) plus resource (a list's fields) and enumerates exactly which fields are mutable: title, display unit, trip dates, and trail. The phrase 'on an existing list' implicitly separates it from create_list, so the agent can route between siblings without opening a schema.

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

Usage Guidelines4/5

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

It gives clear operative context: 'Only the fields given change' defines the partial-update contract, and 'Takes the list's edit link' signals the prerequisite input. However, it never names an alternative tool or states when not to use this (e.g. versus create_list for a new list), so it stops short of explicit exclusion guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedadd_items1 field changed
      • addedInput schema / properties / items / items / properties / needs_cooking
        Added 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"
+}
    • Changedcreate_list2 fields changed
      • addedInput schema / properties / folders / items / properties / items / items / properties / needs_cooking
        Added 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"
+}
      • addedInput schema / properties / items / items / properties / needs_cooking
        Added 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"
+}
    • Changedget_list2 fields changed
      • addedOutput schema / properties / folders / items / properties / items / items / properties / items / items / properties / needs_cooking
        Added value: +{
+  "description": "Food marked for cooking on this trip.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / folders / items / properties / items / items / properties / needs_cooking
        Added value: +{
+  "description": "Food marked for cooking on this trip.",
+  "type": "boolean"
+}
  2. 2 tool updates
    • Changedadd_items1 field changed
      • addedInput schema / properties / items / items / properties / name / minLength
        Added value: +1
    • Changedcreate_list3 fields changed
      • addedInput schema / properties / folders / items / properties / items / items / properties / name / minLength
        Added value: +1
      • addedInput schema / properties / folders / items / properties / name / minLength
        Added value: +1
      • addedInput schema / properties / items / items / properties / name / minLength
        Added value: +1
  3. 2 tool updates
    • Changedadd_items3 fields changed
      • addedInput schema / properties / again
        Added 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"
+}
      • addedOutput schema / properties / repeated
        Added 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"
+}
      • changedOutput schema / required
        Previous value: -[
-  "added",
-  "folders_made",
-  "share_link",
-  "totals"
-]New value: +[
+  "added",
+  "folders_made",
+  "share_link",
+  "totals",
+  "repeated"
+]
    • Changedget_list1 field changed
      • changedOutput schema / properties / truncated / description
        Previous 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."
  4. 6 tool updates
    • Changedadd_items1 field changed
      • 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"
+}
    • Changedcreate_list2 fields changed
      • changedInput schema / properties / unit / description
        Previous 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."
      • changedOutput 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"
+}
    • Changedget_catalog_product1 field changed
      • 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"
+}
    • Changedget_list1 field changed
      • 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"
+}
    • Changedsearch_catalog1 field changed
      • 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"
+}
    • Changedset_trip2 fields changed
      • addedInput schema / properties / unit / description
        Added value: +"The unit the list displays in. Weights are in grams regardless."
      • changedOutput 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"
+}
  5. 7 tool updates
    • First observedadd_items
    • First observedcreate_list
    • First observedget_catalog_product
    • First observedget_list
    • First observedget_list_markdown
    • First observedsearch_catalog
    • First observedset_trip

Related MCP Connectors

Related MCP Servers

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