Skip to main content
Glama

Pixeloa

addCatalogItem

Add an item to a catalog (appends unless position is given). Both the catalog and the item must belong to the key's account (404 otherwise). 409 conflict when the item is not ready (details.status says where it is), is not eligible for catalogs, is unlisted (link only), or is already in the catalog. Requires scope: write_catalog.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUUID
item_idYes
positionNo
idempotency_keyNoOptional Idempotency-Key: repeat-safe retries return the original result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing append-vs-position ordering behavior, the 404 cross-account condition, the specific 409 conflict causes (item not ready with details.status, not catalog-eligible, unlisted, already present), and the required write_catalog scope. With readOnlyHint=false and destructiveHint=false already given, this adds substantial operational context.

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?

Three tight sentences with the core action and append behavior front-loaded, followed by failure modes and the auth requirement. No filler and every clause carries information.

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?

Covers preconditions, error taxonomy, scope requirement, and ordering behavior for a mutation tool with no output schema. Only the return/shape of the added item is unaddressed, which is minor given no output schema is defined.

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 coverage is 50% and the description's 'appends unless position is given' is the only real explanation of the position parameter's semantics. The id and item_id parameters remain undocumented outside their types, so the description adds value but does not fully compensate for the coverage gap.

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 ('Add an item to a catalog') and immediately clarifies scope and ordering semantics ('appends unless position is given'). It is unambiguous and clearly separates the tool from siblings like removeCatalogItem and createItem.

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?

Gives concrete preconditions (both catalog and item must belong to the key's account) and the required scope, which tells the agent when the call will succeed. It does not explicitly name an alternative tool or state when not to use this one, but the eligibility and conflict rules make the usage boundary clear.

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