Mahonia

Make a new list

create_list

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

Output Schema

TableJSON Schema

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 back into the list.
`share_code`	Yes
`share_link`	Yes	The read capability, safe to pass on.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 13, 2026

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"
+}

Changed3 schema fields changedSep 13, 2026
- 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
```

Changed2 schema fields changedSep 12, 2026

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"
+}

First observedSep 12, 2026

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.

All Mahonia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.