Skip to main content
Glama
Sign In

checklists

by com.wildernesstimes
OverviewDiscussionsAdmin

Share a checklist link

share_checklist
Read-onlyIdempotent

Turn a checklist — including one the user has tailored — into a link that opens it in the free Wilderness Times checklist builder, where items tick off and it exports to PDF, Excel, Google Sheets or print with the gear links intact. Suited to saving, sharing, printing, downloading or getting a PDF of a customised list. Accepts the same customisation arguments as the checklist builder tool (activity, categories, exclude, add), plus an optional name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "activity": "<activity>"
    },
    "name": "share_checklist"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoOptional. Extra items to include.
nameNoOptional label, e.g. 'Yosemite, October'. Shown when the link is opened.
excludeNoOptional. Item names to leave out.
activityYesBase activity. One of: camping, backpacking, hiking, winter-camping, cabin-camping, couples-camping, kayak-camping, motorcycle-camping, toddler-camping, beach-camping, rv-camping, rv-rental, fishing, snowboarding.
categoriesNoOptional. Keep only these categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / activity / description
      Previous value: -"Base activity. One of: camping, backpacking, hiking, winter-camping, cabin-camping, couples-camping, kayak-camping, motorcycle-camping, toddler-camping, beach-camping, fishing, snowboarding."New value: +"Base activity. One of: camping, backpacking, hiking, winter-camping, cabin-camping, couples-camping, kayak-camping, motorcycle-camping, toddler-camping, beach-camping, rv-camping, rv-rental, fishing, snowboarding."
  2. Changed1 schema field changed
    • changedInput schema / properties / activity / description
      Previous value: -"Base activity. One of: camping, backpacking, hiking, winter-camping, cabin-camping, couples-camping, kayak-camping, motorcycle-camping, toddler-camping, fishing, snowboarding."New value: +"Base activity. One of: camping, backpacking, hiking, winter-camping, cabin-camping, couples-camping, kayak-camping, motorcycle-camping, toddler-camping, beach-camping, fishing, snowboarding."
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), and the description adds genuine context beyond them: the output is a link (not a file or stored checklist), it opens in the free builder, items remain interactive, exports work in four formats, and affiliate gear links are preserved. It does not explain link persistence, expiry, or whether the link appears in list_checklists, which are the remaining behavioral unknowns.

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

Conciseness4/5

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

Front-loaded with the core action, followed by use cases and then parameter notes; roughly three sentences with no filler. Minor waste from repeating the customisation idea ('one the user has tailored' / 'customised list'), and the first sentence is dense enough to require a second read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 correctly explains what comes back (an interactive builder link with export options) and what the optional name does. It leaves open whether links persist server-side, expire, or show up via list_checklists, which matters for a tool whose whole output is a shareable artifact and which is annotated idempotent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaningful framing: the customisation arguments are the same as the checklist builder tool's (activity, categories, exclude, add), which tells an agent it can reuse argument values already established for build_checklist. The 'name' parameter is described as being shown when the link is opened, adding context the schema states only tersely.

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: turning a (possibly customized) checklist into a shareable link that opens in the Wilderness Times builder. It is clearly distinct from build_checklist (construction) and get_checklist (retrieval), but the phrase 'getting a PDF of a customised list' partially overlaps with the get_checklist_pdf sibling, blurring the boundary slightly.

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?

Offers a use-case list ('saving, sharing, printing, downloading or getting a PDF'), which is real when-to-use guidance. However there are no exclusions, and the PDF/download phrasing points at territory owned by get_checklist_pdf, so an agent still has to guess between the two for file-download intent.

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

All checklists toolsInspect
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