Skip to main content
Glama
Sign In

Aalto

by app.aalto
OverviewDiscussionsAdmin

Preview a spreadsheet import

aalto_import_preview
Idempotent

Reads the CSV staged by aalto_import_start and shows what an import would do: column mapping, new rows, duplicates of existing products, rows with errors, and whether it fits the plan. Imports nothing. Returns status needs_input (fix the mapping with mapping_overrides and call again) or ready with a confirm_token for aalto_import_commit. Once ready the plan is frozen: calling again returns the same preview; to change it, start a new import.

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": {
      "job_id": "<job_id>"
    },
    "name": "aalto_import_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes
on_duplicateNoWhat to do with rows matching a product already in the workspace (by source_url, sku, or name + brand).skip
mapping_overridesNoColumn name → target: a product field (name, brand, price, sku, source_url, image_url, …), tags, section, status, "custom:<field name>", "notes_append" (adds "Column: value" to the notes; several columns may use it) or "ignore".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=false and idempotentHint=true, and the description corroborates this by adding genuinely useful context: 'Imports nothing', the frozen-plan behaviour on repeat calls, and the two possible status outcomes with their follow-up actions. However, readOnlyHint=false is not addressed at all, and the description does not explain what state the preview call itself writes or what happens to preview state if the caller abandons without committing or restarting. That leaves a real behavioural gap for a tool whose write semantics are non-obvious.

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?

Four tight sentences, front-loaded with what the tool does before the status/retry mechanics. No filler, no restatement of the title, and every clause (mapping, duplicates, errors, plan fit, no import, statuses, frozen plan) carries distinct 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?

There is no output schema, so the description correctly takes on the burden of explaining return values via the needs_input/ready statuses and confirm_token. Combined with the enumerated preview contents, an agent has what it needs to call and interpret the tool, with only the preview-state lifecycle left unstated.

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 67% and both optional parameters already have rich inline descriptions (the on_duplicate enum semantics and the mapping_overrides target vocabulary). The description adds workflow meaning beyond the schema by tying mapping_overrides to the needs_input retry loop, which the schema alone does not convey. The required job_id is undocumented in both places, though its name and uuid format make it mostly self-evident.

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 ('Reads the CSV staged by aalto_import_start and shows what an import would do') and enumerates exactly what is previewed: column mapping, new rows, duplicates, error rows, plan fit. It explicitly contrasts itself with aalto_import_commit by declaring 'Imports nothing', so an agent can separate it from its siblings without opening either schema.

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?

The description gives the full decision tree: call after aalto_import_start, fix mapping with mapping_overrides and re-call on status needs_input, hand the confirm_token to aalto_import_commit on ready, and start a new import if the frozen plan must change. Both the alternatives and the conditions that select them are named explicitly.

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

All Aalto toolsInspect
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