Skip to main content
Glama

Save a product from a web page

aalto_save_product_from_url
Idempotent

Saves a supplier product page into Aalto and fills name, brand, price, images and specs automatically. Waits up to 30 seconds and reports whether the details were filled in (extraction_status complete, partial or failed); pending means it is still running, so check with aalto_get_product. Each new product saved this way uses one of the workspace's AI product imports (Free 5, Pro 150 a month), given back if nothing could be filled in; reusing a URL already saved uses none. Ad-tracking parameters (utm_*, gclid and similar) are removed from the link. Defaults to the Library collection. Pass section with collection_id to place it in a section; a product already in that collection keeps its section.

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": {
      "url": "<url>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "aalto_save_product_from_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
kindNoproduct
sectionNoSection name in collection_id; created if missing (≤100 chars). Needs collection_id, and not the Library.
collection_idNo
idempotency_keyYesRequired. A new unique string per intended change (8–128 chars). Retrying with the same key and same arguments replays the first result instead of writing twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), the description discloses the 30-second wait window, the three extraction_status outcomes plus the pending state, the monthly quota cost (Free 5 / Pro 150) with refund-on-failure semantics, and URL normalization of utm_*/gclid. These are non-obvious operational traits an agent could not derive from structured fields.

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?

Purpose is front-loaded and each sentence carries distinct, non-redundant information (status handling, quota, URL cleanup, placement). It is dense and runs as one unbroken block, which makes the quota and section details harder to scan, but nothing is wasted.

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 5-parameter mutation with no output schema, the description covers the critical unknowns: what statuses come back, how to poll, what the call costs, and how placement works. It does not say whether the response includes the new product's id (needed to call aalto_get_product) nor explain the `kind` parameter, which are the remaining gaps.

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?

With only 40% schema description coverage, the description compensates well for url (ad-tracking parameters stripped), collection_id and section (default Library, section requires collection_id and a non-Library collection, existing products keep their section). The one gap is `kind`: the product vs. inspiration enum is never explained in the description or schema, leaving that choice ambiguous.

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 ("Saves a supplier product page into Aalto") plus the automatic enrichment it performs (name, brand, price, images, specs). This clearly distinguishes it from siblings like aalto_create_products (manual creation) and aalto_import_start (bulk import), which an agent can tell apart without opening any schema.

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 clear routing conditions: "pending means it is still running, so check with aalto_get_product" and the note that reusing an already-saved URL consumes no import quota. It does not explicitly contrast with aalto_create_products or the import_* family, so the agent must infer when a URL-based save beats a manual or bulk path.

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