Skip to main content
Glama
Sign In
cws-mcp

cws-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update-metadata

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
    • addedInput schema / properties / accountIndex
      Added value: +{
+  "description": "Google account index",
+  "maximum": 9,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / category / description
      Previous value: -"Category (e.g. 'productivity', 'developer_tools')"New value: +"Exact category label displayed by the dashboard"
    • changedInput schema / properties / defaultLocale / description
      Previous value: -"Default locale (e.g. 'ko', 'en')"New value: +"Unsupported: change manifest default_locale and upload a new ZIP"
    • changedInput schema / properties / description / description
      Previous value: -"Store listing description"New value: +"Detailed store listing description"
    • addedInput schema / properties / headless
      Added value: +{
+  "description": "Run browser headless; use false for the first sign-in",
+  "type": "boolean"
+}
    • 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"
    • changedInput schema / properties / metadata / description
      Previous value: -"Raw metadata object forwarded as-is to the v1 API. Useful for fields not exposed as first-class params."New value: +"Unsupported: use the explicit dashboard fields"
    • addedInput schema / properties / storeIconPath
      Added value: +{
+  "description": "Unsupported: upload the store icon directly in the dashboard",
+  "type": "string"
+}
    • 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/5.0
Behavior4/5

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

No annotations, so the description carries the full burden and does well: it discloses that changes are saved as a draft (non-destructive, reversible, no review trigger), that a signed-in session is required, and that a reload is needed to confirm. It omits failure semantics and, critically, what happens when called with zero arguments given all 12 parameters are optional — whether it is a partial merge or a full overwrite.

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, both front-loaded: the first gives the supported scope and the verification step, the second gives the exclusions. No redundant restatement of the name or filler.

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, no-annotation, no-output-schema tool, the description covers mutability, auth channel, verification, and exclusions. Remaining gaps are the return/response shape (no output schema exists, so a sentence on what is echoed back would help) and the semantics of the optional-only parameter set.

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 baseline is 3; the schema already marks unsupported fields and documents 'empty string clears it'. The description consolidates the supported/unsupported split, which helps, but adds no syntax, format, or interaction detail (e.g. category label matching, accountIndex choice) beyond what the schema states.

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 (save draft) plus the exact resource fields (listing description, category, homepage/support URL) and the channel (Developer Dashboard), which is far more precise than the name alone. It distinguishes itself from publish by stating 'Does not submit for review', but never names the closely-named sibling update-metadata-ui, so an agent has to infer the browser-driven vs. UI difference.

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?

'Does not submit for review' plus the explicit unsupported list (title/summary, raw payloads, icon uploads) gives clear when-not guidance with the redirect (change manifest and upload a new ZIP). It lacks an explicit 'use publish for X / use update-metadata-ui for Y' routing statement, but the boundaries are implied clearly enough to act on.

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