Skip to main content
Glama
Sign In
cws-mcp

cws-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update-metadata-ui

Save draft listing description, category, homepage or support URL via the signed-in Developer Dashboard, then reload to verify. Does not submit for review. Package title/summary, raw payloads, and icon uploads are unsupported.

Instructions

Save draft listing description, category, homepage or support URL via the signed-in Developer Dashboard, then reload to verify. Does not submit for review. Package title/summary, raw payloads, and icon uploads are unsupported.

Input Schema

NameRequiredDescriptionDefault
titleNoUnsupported: change manifest name and upload a new ZIP
itemIdNoExtension item ID
summaryNoUnsupported: change manifest description and upload a new ZIP
categoryNoExact category label displayed by the dashboard
headlessNoRun browser headless; use false for the first sign-in
metadataNoUnsupported: use the explicit dashboard fields
supportUrlNoSupport URL; empty string clears it
descriptionNoDetailed store listing description
homepageUrlNoHomepage URL; empty string clears it
accountIndexNoGoogle account index
defaultLocaleNoUnsupported: change manifest default_locale and upload a new ZIP
storeIconPathNoUnsupported: upload the store icon directly in the dashboard

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv2.0.2
    • changedInput schema / properties / accountIndex / description
      Previous value: -"Google account index in dashboard URL (default: 0)"New value: +"Google account index"
    • changedInput schema / properties / category / description
      Previous value: -"Category label as shown in dashboard UI"New value: +"Exact category label displayed by the dashboard"
    • addedInput schema / properties / defaultLocale
      Added value: +{
+  "description": "Unsupported: change manifest default_locale and upload a new ZIP",
+  "type": "string"
+}
    • changedInput schema / properties / description / description
      Previous value: -"Store listing long description"New value: +"Detailed store listing description"
    • changedInput schema / properties / headless / description
      Previous value: -"Run browser headless (default: false)"New value: +"Run browser headless; use false for the first sign-in"
    • changedInput schema / properties / homepageUrl / description
      Previous value: -"Homepage URL"New value: +"Homepage URL; empty string clears it"
    • changedInput schema / properties / itemId / description
      Previous value: -"Extension item ID (defaults to CWS_ITEM_ID env var)"New value: +"Extension item ID"
    • addedInput schema / properties / metadata
      Added value: +{
+  "additionalProperties": {},
+  "description": "Unsupported: use the explicit dashboard fields",
+  "type": "object"
+}
    • changedInput schema / properties / storeIconPath / description
      Previous value: -"Absolute path to 128x128 store icon image"New value: +"Unsupported: upload the store icon directly in the dashboard"
    • changedInput schema / properties / summary / description
      Previous value: -"Store listing short summary"New value: +"Unsupported: change manifest description and upload a new ZIP"
    • changedInput schema / properties / supportUrl / description
      Previous value: -"Support URL"New value: +"Support URL; empty string clears it"
    • changedInput schema / properties / title / description
      Previous value: -"Store listing title"New value: +"Unsupported: change manifest name and upload a new ZIP"
  2. First observedv1.4.1

TDQS

A4.2/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 load and does well: it discloses that the write happens through a browser session against the live dashboard, that a reload is used to verify, and that review submission is out of scope. It does not mention auth prerequisites (beyond 'signed-in'), duration, or whether the update is partial vs. overwriting.

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 padding: supported fields first, verification behavior second, exclusions last. Nothing repeats the name or title.

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 12-parameter, nested-object mutation tool with no annotations and no output schema, the description covers scope, mechanism, and unsupported inputs adequately. It leaves unstated what a successful call returns and whether omitted fields are preserved or cleared, which matters for a save operation.

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 description coverage is 100%, so the schema already explains every field including the 'Unsupported:' notes. The description's list of unsupported inputs (title/summary, raw payloads, icon uploads) largely duplicates that, adding only the framing that they require a new ZIP or direct dashboard action.

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 concrete verb and resource set ('Save draft listing description, category, homepage or support URL') plus the mechanism (signed-in Developer Dashboard), and immediately separates itself from `publish` by saying it does not submit for review.

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

Usage Guidelines4/5

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

The 'Does not submit for review' clause gives an explicit exclusion and implicitly routes the agent to `publish` for submission, but it never tells the agent when to prefer this UI-driven tool over the sibling `update-metadata`.

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

Deploy Server

Other Tools