Skip to main content
Glama

Import CRM exports

migrate_crm

Import CSV exports from Salesforce, HubSpot, Attio, or another system as a workspace administrator. describe, preview, status and list use read authority; stage, start and run require write authority; explicit tool policies still apply. Start with describe for enabled destinations/fields; preview requires source, a stable sourceInstance, a batch name, files with sourceObject and source ID column, and explicit mappings/exclusions — it writes no CRM records. After the user reviews exact values and exclusions, stage the same preparation, then start the returned jobId for durable background execution. status or list inspect saved progress and every outcome (rows page with rowOffset/rowLimit, max 200). An identical source identity/payload is skipped; changed identities and email/domain collisions need manual resolution — never merge by name. Preserve relationships through referenceObject source IDs and explicitly map owners, stages, currencies, and amount units (money defaults to integer minor units; multiselect to JSON-array strings). Limits: 5000 rows, 2000000 CSV bytes, 3900000 request bytes, 5242880 normalized bytes; reuse the SAME sourceInstance later. run (legacy) advances at most 25 rows synchronously; start retries unsuccessful rows after an execution finishes; replay never duplicates an imported source identity. Per-record approval requirements block this importer, so resolve them first. Historical imports emit no automation events and start no enrichment; custom objects, workflows, attachments and unavailable source history need separate scoping. camelCase keys also accept snake_case aliases (source_instance, job_id, row_offset, row_limit; source_object, id_column on files; object_type, ignored_columns, reference_object, value_map, amount_unit in mappings); outputs are unchanged.

When to use: An administrator imports a Salesforce, HubSpot, Attio or CSV export with explicit mappings and resumable progress.

Example: Help me move our CRM data to Capable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA human-readable name for this import batch (1–120 characters), shown on the staged job and in list/status.
filesNoUp to 20 exports as {name, sourceObject, csv, idColumn?}: csv is the raw CSV text with a header row; idColumn names the stable source-id column (auto-detected when omitted).
jobIdNoThe job id (uuid) returned by stage, list or status; required for start, run and status.
actionYesdescribe (destinations/fields), preview (validate, no writes), stage (save a batch), start (background execution), run (≤25 rows now), status (one job, paged), list (all jobs).
job_idNoAlias of jobId.
sourceNoThe exporting system — salesforce, hubspot, attio or csv; it selects the id-column and column-name conventions used to read the files.
mappingsNoOne per sourceObject: {sourceObject, objectType, fields: {column: {field, referenceObject?, valueMap?, amountUnit?}}, ignoredColumns, defaults?}; every column is mapped or ignored.
rowLimitNoFor status: job rows per page (1–200, default 100).
rowOffsetNoFor status: job rows to skip (0–5000, default 0); advance by the returned rows.length while hasMoreRows is true.
row_limitNoAlias of rowLimit.
row_offsetNoAlias of rowOffset.
sourceInstanceNoA stable label for the customer's source CRM instance (1–200 chars); reuse the same value for every later export so source ids resolve to the same records.
source_instanceNoAlias of sourceInstance.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobNo
jobsNo
noteNo
errorNo
appliedNo
previewNo
destinationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly/destructive/idempotent/openWorld hints; the description adds far more: read-vs-write authority per action, hard limits (5000 rows, byte caps), skip-on-identical-identity and no-duplicate replay semantics, manual collision resolution, and that historical imports emit no automation events or enrichment. This is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the workflow, but the body is a dense semicolon-heavy block that restates some schema-level alias and enum detail. Given 7 actions and 13 parameters the length is partly justified, yet structure and readability suffer.

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 an output schema present, return values need no explanation; the description still covers auth, limits, idempotency, ordering, caveats and alias handling. Nothing an agent needs to invoke it correctly appears missing.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: snake_case aliases for camelCase keys, money defaulting to integer minor units, multiselect serialized as JSON-array strings, and page-size behavior. These go beyond what the field descriptions state.

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 (import) and resource (CRM CSV exports) with named sources (Salesforce, HubSpot, Attio, csv) and the administrator persona. No sibling tool does bulk import, so it is easily distinguished from create_record, commit_reviewed_updates, etc.

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 an explicit 'When to use' line plus the full ordered workflow (describe → preview → stage → start, with status/list for inspection and run as legacy). It also names the conditions that block use (per-record approvals, custom objects, workflows, attachments) so the agent knows when NOT to reach for it.

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