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.

Wait for extraction using jobs.get or documents.get, then inspect rows.search. Call analysis.crosscheck for consistency findings, or analysis.credit_memo for a commercial loan memo. Memo generation includes a crosscheck internally, so a separate crosscheck call is unnecessary when you only need the memo. Both require mcp:read, return their model-generated analysis in the same call, and leave saved data unchanged.

Pass a table ID or slug from tables.list as table_id. Optional job_id must identify a job for that table in the selected project; it restricts evidence to the job's document file IDs. Filters are combined with AND and further narrow that selection. For example, call analysis.credit_memo with:

{
  "project_slug": "purchase-orders",
  "table_id": "your-table-id",
  "job_id": 17,
  "memo_profile": "commercial-loan-v1",
  "filters": [{ "column": "document_record_id", "op": "in", "value": ["your-file-id"] }]
}

Omit job_id to analyze without a job restriction, and omit filters or pass [] for no additional filtering. commercial-loan-v1 is the only supported memo profile. Use connection.info to select project_slug; omission works only when the account has exactly one visible project.

Analysis sends bounded evidence to an external model: at most 80 rows from the first 200 matches, with long values shortened. Inspect the returned evidence coverage and review citations and assumptions before relying on the result. Use rows.search for paginated access to the raw records.

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