Skip to main content
Glama
Sign In

ShipDesk

by dev.shipdesk
OverviewDiscussionsAdmin

Update a listing for sale

update_listing_draft

Change a listing's details. Only the fields you give change; asking_price null makes it open to offers. Once a listing has been sent in, its link and kind stay as they were checked.

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": {
      "id": "<id>"
    },
    "name": "update_listing_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesthe listing id from create_listing_draft or my_listings
urlNothe product's website, or its App Store or Google Play page
kindNosaas, web (a web app), ios, android, mac or other
nameNothe product's name
detailsNowhat it does, users, traffic, the stack, how it gets customers, what a new owner could do next. only facts the founder gave or the project shows
privateNokeep the name, link and logo hidden until the founder accepts a buyer
includesNowhat the buyer gets
one_lineNoone line about what it does
why_sellingNowhy the founder is selling, in a sentence or two, in their own words. ask them; never guess
asking_priceNothe asking price in whole US dollars, from the founder. leave it out (or null) for open to offers
started_yearNothe year it was started

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it discloses patch semantics (only supplied fields change), the special null handling for asking_price, and a genuine immutability rule that url and kind are frozen once a listing is sent in. It leaves open whether edits are permitted at all after submission and what permission or ownership check is required, which is why it is not a 5.

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?

Three short sentences with no filler, and the partial-update rule is front-loaded before the edge cases. The phrasing "sent in" is slightly colloquial and forces the agent to infer that it means submitted or published.

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?

For an 11-parameter mutation tool with no annotations and no output schema, the description covers the essentials of how the write behaves, but it omits whether a listing can still be edited after submission, what permissions or ownership are needed, and what the call returns. Those gaps are reachable only by guessing or calling sibling tools.

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 the baseline is 3, and the description earns above that by explaining that url and kind become read-only after submission, which meaningfully constrains two parameters beyond their schema text. The asking_price null behavior largely restates the schema description rather than adding to it.

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?

"Change a listing's details" states a concrete verb and resource, and the title confirms it targets listings for sale. It does not distinguish itself from create_listing_draft or update_launch_draft, so the agent must infer that this is the edit path for an existing listing rather than a launch.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance and no mention of the sibling tools that could be confused with it (create_listing_draft for new listings, update_launch_draft for launches). The only usage signal is implicit: it modifies an existing listing identified by id.

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

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