Moatless

Update a listing

update_listing

Idempotent

Changes a listing's details or prices, or where it's built from. Setting a repository_id or a source_url switches its source: releases already published don't change, new ones are built from the new source, and credentials saved for a git URL are removed.

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>",
      "id": "<id>",
      "context": "<context>"
    },
    "name": "update_listing"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`input`	Yes
`context`	Yes	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".

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

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",
-  "id"
-]New value: +[
+  "input",
+  "id",
+  "context"
+]

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / input / properties / plan_name

Added value: +{
+  "description": "What its base plan is called, shown once it's sold in more than one\n(`Moatless.Distribution.Plan`). It's named with its first plan.\n",
+  "maxLength": 40,
+  "type": "string"
+}

Changed2 schema fields changedNov 4, 2026

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"

Changed1 schema field changedNov 4, 2026

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"
+}

Changed8 schema fields changedNov 2, 2026

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
```

changedInput schema / properties / input / properties / services / items / properties / name / anyOf

Previous value: -[
-  {
-    "description": "The service, such as Stripe, OpenAI, PostgreSQL, or Amazon S3.",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "The service, such as Stripe, OpenAI, PostgreSQL, or Amazon S3.",
+    "maxLength": 60,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

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
```

Changed2 schema fields changedNov 1, 2026

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."

Changed2 schema fields changedOct 31, 2026

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"
+}

First observedOct 29, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare idempotent and non-destructive, and the description adds genuinely new behavioral context: that setting `repository_id` or `source_url` switches the build source, that already-published releases are untouched, and that stored git credentials are removed. That side-effect disclosure is exactly the kind of thing annotations cannot express. It stops short of covering other mutation risks such as name uniqueness, price-change effects on existing buyers, or what happens to in-flight releases.

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?

Two sentences, front-loaded with the general purpose followed by the conditional source-switch caveat. No filler, though the second sentence packs several distinct consequences together and would read better as separate clauses.

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 a wide, deeply nested update tool with no output schema, the description covers only the source-switch path and leaves the majority of updatable fields (pricing, hex/npm/shadcn publishing flags, categories) to the schema. Given the schema's own rich field descriptions, that is defensible but incomplete on return/error behavior.

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?

Top-level schema coverage is 33% (only `context` is documented), so the description must compensate — and it does for the two source-related fields (`repository_id`, `source_url`), explaining the switch semantics. However it says nothing about `id`, which fields are optional, or which combinations are valid, so the large nested `input` object is left to the schema's own inline docs.

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 and resource — "Changes a listing's details or prices, or where it's built from" — which tells an agent this is a partial-update operation on listings. It is clearly distinct from create_listing or publish_release by name, but it does not explicitly name which sibling to use instead for adjacent tasks.

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 only implied: the phrasing "details or prices, or where it's built from" suggests a patch-style update, but there is no explicit when-to-use versus create_listing/update_plan guidance and no statement of prerequisites (e.g. seller ownership of the listing).

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

All Moatless tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?