Skip to main content
Glama

Create a listing

create_listing

Creates a draft listing of one of the user's codebases. Only they can see it until they publish it on the website, at its manage_url.

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": {
      "input": "<input>",
      "context": "<context>"
    },
    "name": "create_listing"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as "the user" or "a buyer".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. Never include personal data, such as names, email addresses or message text; refer to people by role, such as \"the user\" or \"a buyer\".",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "input"
      -]New value: +[
      +  "input",
      +  "context"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / properties / input / properties / include_release_assets / description
      Previous value: -"Whether buyers also get the files attached to the seller's GitHub release for each release,\nsuch as compiled binaries, to download for any release they're entitled to. Only for\nlistings built from a connected GitHub repository, with `release_assets_description`.\n"New value: +"Whether buyers also get files that come with each release, such as compiled binaries, to\ndownload for any release they're entitled to, with `release_assets_description` saying what\nthey are. For a listing built from a connected GitHub repository, they're the files attached\nto its GitHub release for each release's tag; for others, the seller uploads them\n(`release_asset_upload_url`).\n"
    • changedInput schema / properties / input / properties / npm_packages_enabled / description
      Previous value: -"Whether buyers can install its npm packages from Moatless's npm registry: the tarballs\n`npm pack` makes, attached to each release as release assets, from its GitHub release or\nuploaded (`Moatless.Distribution.NpmPackage`). Their names need a scope (`@scope/name`).\n"New value: +"Whether buyers can install its npm packages from Moatless's npm registry: the tarballs\n`npm pack` makes, attached to each release as release assets, from its GitHub release or\nuploaded (`Moatless.Distribution.NpmPackage`), each its own package. Their names need a\nscope (`@scope/name`) with no public packages on npmjs; a scope is the first seller's to\nsell in it, and a name the first listing's, for good. Each release needs a new version,\nsince a version can't be sold again with other contents.\n"
  3. Changed1 schema field changed
    • addedInput schema / properties / input / properties / npm_packages_enabled
      Added value: +{
      +  "description": "Whether buyers can install its npm packages from Moatless's npm registry: the tarballs\n`npm pack` makes, attached to each release as release assets, from its GitHub release or\nuploaded (`Moatless.Distribution.NpmPackage`). Their names need a scope (`@scope/name`).\n",
      +  "type": "boolean"
      +}
  4. Changed8 schema fields changed
    • addedInput schema / properties / input / properties / demo_url / maxLength
      Added value: +500
    • addedInput schema / properties / input / properties / name / maxLength
      Added value: +100
    • addedInput schema / properties / input / properties / release_assets_description / maxLength
      Added value: +500
    • addedInput schema / properties / input / properties / services / items / properties / name / maxLength
      Added value: +60
    • changedInput schema / properties / input / properties / services / items / properties / purpose / anyOf
      Previous value: -[
      -  {
      -    "description": "What the codebase uses it for, such as payments, sending email, or file storage.",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "description": "What the codebase uses it for, such as payments, sending email, or file storage.",
      +    "maxLength": 200,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / input / properties / services / items / properties / url / anyOf
      Previous value: -[
      -  {
      -    "description": "The service's website, such as https://stripe.com.",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "description": "The service's website, such as https://stripe.com.",
      +    "maxLength": 300,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / input / properties / stack / items / maxLength
      Added value: +40
    • addedInput schema / properties / input / properties / tagline / maxLength
      Added value: +120
  5. Changed2 schema fields changed
    • changedInput schema / properties / input / properties / stack / description
      Previous value: -"Tags for what it's built with, such as Elixir, Phoenix, PostgreSQL."New value: +"Tags for what it's built with and what it works with, such as Elixir, Phoenix, PostgreSQL, Stripe."
    • changedInput schema / properties / input / properties / stack / items / description
      Previous value: -"Tags for what it's built with, such as Elixir, Phoenix, PostgreSQL."New value: +"Tags for what it's built with and what it works with, such as Elixir, Phoenix, PostgreSQL, Stripe."
  6. Changed2 schema fields changed
    • addedInput schema / properties / input / properties / hex_package_enabled
      Added value: +{
      +  "description": "Whether buyers can add it to their Elixir projects as a dependency from Moatless's Hex\nrepository. Its mix.exs needs `package` config and a version, raised for each release; a\nrelease that isn't a package Moatless can read isn't published, and the seller is told why\n(`Moatless.Distribution.HexPackage`).\n",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / input / properties / shadcn_registry_enabled
      Added value: +{
      +  "description": "Whether buyers can install its components into their own projects with the shadcn CLI,\nfrom its registry on Moatless. Its code needs a registry.json at the root, as `shadcn build`\nreads it; a release without one that can be read isn't published, and the seller is told\nwhy (`Moatless.Distribution.Registry`).\n",
      +  "type": "boolean"
      +}
  7. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare openWorldHint=false and destructiveHint=false; the description adds genuinely new behavior — the listing starts privately visible to the seller only, and publishing happens separately on the website via manage_url. That lifecycle context is exactly what an agent needs and is not in the annotations or schema.

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?

Two sentences, zero filler, with the draft-visibility constraint front-loaded before the publishing note.

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 a complex nested creation tool with no output schema, the description covers the key state semantics (draft, private, manage_url, separate publish step). It is light on required-field expectations and on what the call returns beyond manage_url, but the schema carries the field-level detail.

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?

The description names no parameters at all, but the nested schema documents most fields (slug uniqueness, pricing minimums, release asset behavior) in detail. At roughly 50% coverage the schema does most of the work, though the required 'context' explanation parameter and the name/slug requirement go unmentioned in the prose.

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+resource ('Creates a draft listing of one of the user's codebases') and adds the distinguishing qualifier that it is a draft, not a published listing. It does not explicitly contrast with the sibling update_listing, but the create-vs-update split is inferable from the verb.

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?

Usage is implied rather than stated: it is the tool for producing a not-yet-public listing. There is no explicit 'use this when you have no listing yet, use update_listing to change one' guidance, and no mention of prerequisites such as a connected repository or git credential.

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.

Resources