Recipes

Three patterns cover most MCP workloads. Each one is a chain of tool calls the assistant runs on your behalf — the prompts below are what you’d actually type, and the steps describe what the assistant does in response.

Import an Airtable Export into Adva

Goal: bring a CSV export of customers from Airtable into Adva and re-sync weekly without duplicates.

Prompt:

“Import customers.csv from my Airtable export into Adva. Tag them with source airtable so I can re-sync next week.”

Flow:

1. get_csv_template → entity_type: "customer" The assistant fetches the current Adva customer template and compares its headers against your CSV.
2. suggest_column_mapping → entity_type: "customer", source_columns: [...], sample_rows: [...] Optional, but useful when your source headers don’t match Adva’s exactly.
3. get_upload_url → entity_type: "customer", source: "airtable", filename: "customers.csv" Returns a pre-signed upload_url and an upload_token.
4. The assistant HTTP-PUTs the CSV file’s bytes directly to upload_url — the file never passes through the model, so no value can be altered or invented.
5. start_csv_import → upload_token: "..." Returns import_job_id. The server validates the uploaded file and rejects the whole import if any row is missing its external_id.
6. get_import_status → job_id: ... Poll every few seconds until status: "completed".

Next week, re-run steps 3-5 with the latest export. Rows with a matching external_id update in place; new rows are created. No duplicates.

Sync from a CRM Using source + external_id for Idempotency

Goal: keep Adva in sync with a separate CRM (Salesforce, HubSpot, a custom tool) on a schedule.

Prompt:

“Here are 1,200 leads from our CRM. Upsert them into Adva customers using crm as the source and each record’s CRM ID as the external_id.”

Flow:

1. get_external_ids → entity_type: "customer", source: "crm" Lists every customer Adva already knows about for this source. The assistant uses this to decide what’s new vs. existing.
2. The assistant prepares a CSV file with one row per CRM lead — each row carrying its CRM ID in the external_id column. external_id is required on every row.
3. get_upload_url → entity_type: "customer", source: "crm", filename: "...", then HTTP-PUT the file’s bytes to the returned upload_url.
4. start_csv_import → upload_token: "..." Returns import_job_id. Every subsequent run with the same (source, external_id) updates rather than duplicates.
5. get_import_status per returned import_job_id.

To run this on a schedule, script it with your preferred orchestrator (cron, Temporal, Trigger.dev) using an API key instead of OAuth.

Catch Bad Data Before It Lands

Goal: make sure broken rows never partially corrupt Adva.

Prompt:

“I have 500 proposals in a file. Import them, and if anything’s broken tell me before it lands.”

Flow:

1. get_import_schema → entity_type: "proposal" The assistant inspects the JSON Schema to know which fields matter and maps your file’s columns.
2. suggest_column_mapping (if source columns don’t match Adva).
3. get_upload_url, HTTP-PUT the file’s bytes, then start_csv_import.
4. get_import_status → job_id: ... The server validated the uploaded file as part of the import. Every row must have a non-blank external_id; if any row is missing it, the whole import is rejected before any record is written and the job ends failed with row-level errors[].
5. Review the errors with the assistant, fix the source file, and re-run the upload. The import is idempotent on (source, external_id), so a corrected re-run is safe.

You never get a half-written import — a file that fails validation writes nothing.