Skip to main content
Glama

list_imports

Read-only

The import batches of the project, most recent first: source, date, report (created / updated / skipped / conflicts / errors), rolled back or not, and the number of tasks STILL present. With importId: the PER-TASK REPORT of that batch (created, updated with which fields, skipped, in conflict, in error — identifiers, outcome, reason and field NAMES, without the content of a task), paginated by page; it exists only if the server keeps it, otherwise the response says so. Read-only.

Input Schema

NameRequiredDescriptionDefault
pageNoWith `importId`: the slice of the report (default 1); `report.pages` says how many there are, `report.nextPage` the next one.
limitNoDefault: 20 batches, most recent first.
importIdNoThe batch whose PER-TASK REPORT you want (created, updated with which fields, skipped, in conflict, in error) — without it, the list of batches as numbers. `limit` does not apply to it.
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / importId / description
      Previous value: -"Le lot dont tu veux le RAPPORT PAR TÂCHE (créée, mise à jour avec quels champs, ignorée, en conflit, en erreur) — sans lui, la liste des lots en nombres. `limit` n’y sert pas."New value: +"The batch whose PER-TASK REPORT you want (created, updated with which fields, skipped, in conflict, in error) — without it, the list of batches as numbers. `limit` does not apply to it."
    • changedInput schema / properties / limit / description
      Previous value: -"Défaut : 20 lots, du plus récent au plus ancien."New value: +"Default: 20 batches, most recent first."
    • changedInput schema / properties / page / description
      Previous value: -"Avec `importId` : la tranche du rapport (défaut 1) ; `report.pages` dit combien il y en a, `report.nextPage` la suivante."New value: +"With `importId`: the slice of the report (default 1); `report.pages` says how many there are, `report.nextPage` the next one."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so 'Read-only' adds nothing. However, the description adds genuine behavioral context beyond annotations: the report 'exists only if the server keeps it, otherwise the response says so,' plus the pagination model and the fact that `limit` does not apply in report mode.

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?

Front-loads the default list behavior and its returned fields, then the importId variant. Dense with parenthetical detail but every clause conveys distinct return-shape information; only the trailing 'Read-only' is redundant given annotations.

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 carries the full burden of describing return values, and it does so thoroughly for both modes (batch fields and per-task report fields including which fields changed and reasons). Nothing essential for correct invocation is missing.

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 schema already documents all four parameters thoroughly. The description reinforces the mode-switching meaning of `importId` (list vs per-task report) but adds little syntax or format detail beyond what the schema provides. Baseline 3 applies.

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 (list) and resource (import batches of the project) and distinguishes two distinct modes: the batch list by default, and the per-task report when `importId` is supplied. It is clearly separable from siblings like rollback_import and import_tasks.

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?

Clearly explains the condition that selects each mode (with/without `importId`) and what each returns, which is effective usage guidance. It does not, however, name or route to any sibling tool (e.g., rollback_import for undoing a batch), so the 'vs alternatives' aspect is absent.

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.