Cloudlabels

Enable catalog sheet

enable_catalog_sheet

Destructive

Turn Catalog on for a manual sheet (1-10). An empty sheet with generic headers gets the catalog preset: Photo, Name, SKU, Barcode, prices, Type, Brand, Description, Notes, and two group options. Colour and Size are group options 1 and 2. Category is Type. Roles: photo, name, sku, barcode, unitCost, sellingPrice, type, brand, totalQty, defaultLocation, variantOption1, variantOption2, description, notes. A sheet that already has a stored catalog map can be turned on without rewriting columns. preset_applied is true only when the preset was actually applied. The response includes a catalog block. If the stored map is not catalog-ready after a flag-only enable, the response says so. Sheets with items or custom headers and no stored map are refused with a message that points to adopt_catalog_sheet. Ask the user if the preset fits before applying it on an empty sheet. barcode_standard is optional. If it is omitted, the sheet standard is left unchanged. If it is sent on an empty sheet, that standard is stored. Does not rewrite barcode values.

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": {
      "sheet_number": "<sheet_number>"
    },
    "name": "enable_catalog_sheet"
  }
}

Input Schema

Name	Required	Description	Default
`sheet_number`	Yes
`barcode_standard`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag destructiveHint=true, and the description backs that up by spelling out exactly what gets written (headers/roles on an empty sheet), what is not touched (columns when a stored map exists, barcode values), and what preset_applied and the response catalog block mean. It adds material context beyond the annotations rather than restating them.

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?

The action and scope lead, followed by preset contents, refusals, and parameter behavior in a logical order, and the long role list does earn its place for understanding the preset. It is somewhat dense and run-on (the response-shape sentences and the barcode paragraph could be tightened), but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing the returned catalog block, the preset_applied flag, and the not-catalog-ready warning after a flag-only enable. Combined with the refusal semantics, an agent has enough to call it correctly and interpret the result.

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 0%, so the description must carry the load and largely does: sheet_number's 1-10 bound is restated, and barcode_standard's optionality plus the three distinct behaviors (omitted = unchanged, sent on empty sheet = stored, never rewrites existing values) are explained. The enum members themselves are left to the schema, which is acceptable.

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 specific verb and resource (turn Catalog on for a manual sheet 1-10) and immediately defines what that means: a preset of generic headers and roles. It is clearly distinct from the sibling adopt_catalog_sheet, which is named only in the refusal case.

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

Usage Guidelines5/5

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

Gives explicit preconditions per sheet state: empty sheet gets the preset, a sheet with a stored catalog map can be flag-enabled without rewriting columns, and sheets with items or custom headers and no map are refused with a pointer to adopt_catalog_sheet. It also instructs the agent to confirm the preset with the user before applying it, which is unusual and valuable routing guidance.

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

All Cloudlabels tools Inspect

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

Need Help?