MCP usage examples

Use these prompts in your connected assistant. The JSON samples are tool arguments, not REST requests. Replace example slugs and IDs with values returned by your own account.

Discover and create a project

Show my projects. Create a project called Purchasing if I do not already have one.

1. Call connection.info with {}.
2. If requested, call projects.create with {"name":"Purchasing"}.
3. Use the returned project.slug in later actions.

Create a table and extract a PDF

Create a Purchase orders table in Purchasing. Extract the purchase order number, supplier, and total from this PDF, then show the saved rows.

Call tables.create:

{
  "project_slug": "purchasing",
  "name": "Purchase orders",
  "columns": [
    { "name": "po_number", "type": "text", "prompt": "The purchase order number printed on the document." },
    { "name": "supplier", "type": "text", "prompt": "The supplier company name." },
    { "name": "total", "type": "number", "prompt": "The final purchase order total, as a number." }
  ]
}

Inspect the result or call tables.list to get the table's actual ID and slug. Then call documents.upload with the actual PDF bytes:

{
  "project_slug": "purchasing",
  "filename": "purchase-order.pdf",
  "data_base64": "<base64-encoded PDF bytes>",
  "tableSlug": "<returned table slug>"
}

The base64 placeholder must be replaced before calling the action. A local filename alone does not upload anything. Supplying tableSlug selects the extraction destination; omitting it uses the project's routing path.

If you already have stored document keys for that table, jobs.create starts extraction:

{
  "project_slug": "purchasing",
  "tableSlug": "<returned table slug>",
  "documentKeys": ["<existing stored document key>"]
}

Use jobs.get with project_slug and the returned numeric job_id to inspect progress. Avoid creating another extraction job for an upload that already started processing. Verify the results with rows.search:

{
  "project_slug": "purchasing",
  "table_id": "<returned table ID>",
  "page": 1,
  "pageSize": 50
}

Preview an email workflow

In my Purchasing project, prepare an inbox that classifies supplier purchase orders and extracts their order number and total. Only accept mail from my supplier domain. Show me the configuration before applying it.

The assistant calls workflow.setup with a structured intent:

{
  "dry_run": true,
  "goal": "Organize supplier purchase orders received by email.",
  "project": { "existing_slug": "purchasing" },
  "table": {
    "name": "Emailed purchase orders",
    "columns": [
      { "name": "po_number", "type": "text", "prompt": "The purchase order number." },
      { "name": "total", "type": "number", "prompt": "The final purchase order total." }
    ]
  },
  "routing_rule": {
    "name": "Purchase orders",
    "prompt": "A purchase order issued to a supplier, containing an order number and ordered goods.",
    "confidenceThreshold": 85,
    "enabled": true
  },
  "inbox": {
    "name": "Supplier purchase orders",
    "routing": "classify",
    "sender_allowlist": [{ "type": "domain", "value": "supplier.example" }]
  }
}

Replace the supplier domain, review the preview, then send the same configuration with dry_run: false. Inspect the returned resources and use inboxes.list to confirm the inbox address. A preview describes planned steps; it does not create resources or prove an email has been processed.

Route into multiple tables

Use separate tables for purchase orders and invoices, and route incoming PDFs to the matching table.

1. Call tables.create once for each table.
2. Call routing_rules.create for each document type using the corresponding returned tableId.
3. Inspect routing_rules.list and upload a representative document through the routing path.
4. Check saved rows and review uncertain classifications before treating the workflow as verified.

Example routing rule:

{
  "project_slug": "purchasing",
  "name": "Supplier invoices",
  "prompt": "An invoice requesting payment for goods or services, with an invoice number and amount due.",
  "tableId": "<invoice table ID>",
  "confidenceThreshold": 85,
  "enabled": true
}

workflow.setup currently creates one table per intent. Its input does not accept a tables array.

Split a mixed document

Prepare a logical splitter that separates purchase orders from invoices in mixed PDF attachments, using my project's routing rules. Let me review it before publishing.

Call splitters.create_logical:

{
  "project_slug": "purchasing",
  "name": "Purchasing packet",
  "config": {
    "mode": "logical",
    "sourceInboxId": null,
    "instructions": "Separate each purchase order and invoice into its own document section.",
    "sectionTypes": [
      { "key": "purchase_order", "name": "Purchase order" },
      { "key": "invoice", "name": "Invoice" }
    ],
    "routingMode": "project_rules",
    "reviewUncertainBoundaries": true,
    "reviewUncertainDestinations": true
  }
}

sourceInboxId: null targets project uploads. Use an inbox ID from inboxes.list to bind the splitter to that inbox instead. Creating a draft does not activate it. Inspect it with splitters.get, then call splitters.publish with its splitter_id and current expected_draft_revision after reviewing the configuration.

For known page layouts, use splitters.create_page_range, then splitters.test_page_range to preview assignments. Publish the draft before splitters.run_page_range processes an existing document. There is no separate logical-splitter test action in the current MCP catalog.

Analyze saved data

Crosscheck the extracted rows for inconsistencies and show the source references for each finding.

Call analysis.crosscheck with the selected project_slug and table_id, optionally narrowing by job_id or filters. For a commercial loan memo, use analysis.credit_memo with the same data selection and memo_profile: "commercial-loan-v1". Review the findings and citations before relying on the analysis.

See the complete action reference for all input constraints and output schemas.