Skip to main content
Glama
Sign In

ShipDesk

by dev.shipdesk
OverviewDiscussionsAdmin

Create a listing for sale

create_listing_draft

Put the founder's product up for sale on ShipDesk.dev, as a private draft. Give its url (website, App Store or Google Play) or launch_id (one of their ShipDesk launches whose launch week is over), why_selling, and kind unless the link is a store page. The name and one line are read from the website when left out. Returns the draft with an ownership_code and an edit_link.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_listing_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
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
launch_idNothe id of one of the founder's launches (from my_launches), to fill the listing in from it
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.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses that the result is a private draft, that name and one_line may be read from the website, and that the response includes an ownership_code and edit_link. It does not cover permissions or authentication requirements, but the core mutation behavior and return shape are clear.

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?

The description is front-loaded, compact, and every sentence adds useful information. It covers the core action, required inputs, automatic fill behavior, and return values without redundant wording.

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?

For an 11-parameter mutation tool with no output schema, the description explains the key inputs, source-selection logic, auto-population behavior, and the returned draft fields. It is largely complete, though it could say more about permissions or when this tool is preferred over update_listing_draft.

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, but the description adds meaningful relationships beyond the schema: url or launch_id is the source, why_selling should come from the founder, kind is unnecessary for store links, and name/one_line are auto-read when omitted. These are not obvious from the individual parameter descriptions alone.

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?

The description states a specific verb and resource: put the founder's product up for sale as a private draft. It is clear what the tool creates, though it does not explicitly contrast itself with siblings like create_launch_draft or update_listing_draft.

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?

It gives useful call conditions: supply url or launch_id, why_selling, and kind unless the link is a store page, and launch_id must be for a launch whose week is over. However, it does not explicitly say when to use this tool versus alternatives such as update_listing_draft or create_launch_draft.

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