Skip to main content
Glama

Show the shop to my human

show_shop_to_owner

Show your human what AgentMart sells, as cards in plain words with prices, and let them pick. Makes a pick link, your human's own page for it (7 days; your human presses Open my page, ticks items and presses Send to my agent). Send pick_url to your human only, in a private message. It opens in the first browser where they press Open my page, and then only there. Never open pick_url yourself or press Open in your own browser. For another device, reopen it (reopen_shop_window). In chats that show MCP Apps, the cards appear right here and the picks come back as a chat message. Put up to 12 items you recommend first, with a short note (plain words, no links). Picking never buys anything: read the picks with get_owner_picks, and confirm with your human before you buy (on the link, only the first browser that presses Open my page can pick, and that may not be your human if the link was passed on; the in-chat cards pick too). 20 links per day.

Input Schema

NameRequiredDescriptionDefault
noteNoOnly when your passport has an active paying owner: a short note to your human, up to 300 characters of plain words about why you suggest these. No links, codes, contact details, requests for data or payments.
itemsNoUp to 12 slugs you recommend (from search_catalog), shown first.
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.
inbox_instance_idNoOne of your webhook inboxes: every change of the picks also arrives there.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "items": [
      +      "memory-locker",
      +      "webhook-inbox"
      +    ]
      +  }
      +]
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."New value: +"Your amp_ token, only if you have no app sign-in and cannot send a header."
  2. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."New value: +"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."
    • addedInput schema / properties / passport_token / maxLength
      Added value: +200
    • removedInput schema / properties / passport_token / pattern
      Removed value: -"^amp_(?:s_)?[A-Za-z0-9_-]{43}$"
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations to disclose link lifetime (7 days), browser binding ('only the first browser that presses Open my page can pick'), the security risk of a forwarded link, the 20-links-per-day rate limit, and that picking never purchases anything. Annotations only say it is a non-destructive, non-idempotent write; the description supplies the actual operational behavior.

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 purpose is front-loaded in the first clause, and each subsequent sentence carries distinct information (link behavior, safety warning, in-chat variant, next steps, rate limit). It is dense with parentheticals and run-on constructions, which slightly hurts scanability, but there is essentially no filler.

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?

For a tool that generates a human-facing link, it covers the full lifecycle: what the human sees, how the link is scoped, what to do on other devices, how picks return, how to read them (get_owner_picks), and the daily cap. No output schema is needed because the description already states what comes back.

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 coverage is 100%, so the schema already documents all four parameters, and the description mostly restates them ('up to 12 items you recommend first, with a short note (plain words, no links)'). It adds the useful nuance that items are shown first in recommendation order, but says nothing about passport_token or inbox_instance_id beyond what the schema provides.

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 ('Show your human what AgentMart sells'), plus the exact output artifact (cards with prices, a pick link). It is clearly separable from siblings like search_catalog, get_owner_picks, and reopen_shop_window, each of which is named or implied at the right point.

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?

Explicit when-to-use, what to do in MCP Apps chats ('cards appear right here and picks come back as a chat message'), and the named alternative for another device ('reopen_shop_window'). It also gives hard exclusions: never open pick_url yourself, send it only in a private message, and confirm before buying.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.