Skip to main content
Glama
Sign In

LastList

by com.lastlistapp
OverviewDiscussionsAdmin

Share a list

share_list

Share one of the user's lists with someone they're already connected to. The recipient gets it in their own LastList app and is sent a notification, and (at full access) their edits sync back.

This sends something to another person, so ALWAYS confirm with the user which list and which person before calling it, even if they seem to have already said so. Call list_connections first to get a connectionId. Use accessTier 'view' for a list they should only read, 'full' when they should be able to check things off and add items.

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": {
      "connectionId": "<connectionId>"
    },
    "name": "share_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
listIdNoList to share. Defaults to the user's active shopping list.
accessTierNo'full' (can edit, default) or 'view' (read-only).
connectionIdYesThe connectionId from list_connections — who to share with.
giftVisibilityNoWishlists/registries only. 'surprise' (default) hides who claimed which gift from the list owner; 'open' lets everyone see. Only pass this if the user says which they want.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only readOnly=false/destructive=false; the description goes well beyond by disclosing the real side effect (the recipient gets the list in their own app and is sent a notification), downstream behavior ('at full access, their edits sync back'), and a mandatory pre-call confirmation step. Those are exactly the behavioral traits an agent needs before performing an outward-facing action.

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?

Front-loads the one-line purpose, then the safety gate, then the prerequisite, then parameter selection guidance — a sensible priority order for a consequential tool. No filler; even the emphatic confirmation sentence carries actionable 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?

No output schema exists, and the description still tells the agent what happens as a result (list appears in recipient's app, notification sent, edits sync at full tier), which is more than required. The only shortfall is that giftVisibility's surprise-mode semantics are left entirely to the schema, so the description isn't fully self-contained for that parameter.

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 schema already defines all four parameters including the accessTier and giftVisibility enums. The description's accessTier guidance ('view' for read-only, 'full' to check off and add items) adds a usage-flavored restatement but no new syntax, defaults, or format details, and it never mentions listId's active-list default or giftVisibility. Baseline 3 is appropriate.

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 (Share), a specific resource (one of the user's lists), and a recipient constraint (someone they're already connected to). An agent can distinguish this from create_list or search_lists without opening any schema, and the description also names the follow-on app/notification behavior.

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

Usage Guidelines5/5

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

Gives explicit when-to-act guidance ('ALWAYS confirm with the user which list and which person before calling it, even if they seem to have already said so') and a hard prerequisite ('Call list_connections first to get a connectionId'). It also explains which accessTier value to choose for which user intent, so nothing about invocation choice is left to inference.

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

All LastList 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