# RevCent MCP Operation: `TriggerFunction`

This document explains the `TriggerFunction` operation in depth so MCP/AI clients can correctly and safely trigger RevCent Functions.

This guide focuses especially on:

- Why `function_id` is required.
- Why `item_type` and `item_id` exist.
- How `custom_arguments` work.
- Why MCP/AI must read the source Function’s configured `custom_arguments` before triggering.
- How MCP/AI should infer custom argument values from the custom argument descriptions.
- Why MCP/AI must not trigger Functions unless explicitly told to do so.

Sources:
- RevCent API/MCP schema for `TriggerFunction`
- RevCent API/MCP schema for `GetFunction`
- RevCent API/MCP schema for `EditFunction`
- RevCent Knowledge Base: [AI Custom Arguments](https://kb.revcent.com/en/tools/ai#custom-arguments)
- RevCent Knowledge Base: [Functions](https://kb.revcent.com/en/integrations/functions)

---

## Operation Summary

`TriggerFunction` triggers a specific RevCent Function by Function ID.

Important:

```text
Only Functions configured with event_source = api_direct are triggerable via TriggerFunction.
```

A Function configured for:

```text
account_event
email_template
payment_profile
function_url
schedule
```

should not be triggered through `TriggerFunction` unless it is also configured as `api_direct`.

`TriggerFunction` is mainly used when a user, MCP client, AI Assistant, AI Voice Agent system action, or other API caller needs to run a Function on demand.

---

# Critical Safety Rule: Do Not Trigger Unless Explicitly Told

MCP/AI must not trigger a Function unless the user or client explicitly asks to trigger/run/execute that Function.

Do not trigger a Function merely because it appears relevant.

Correct:

```text
Trigger the function named Customer Summary for this customer.
Run function ID XXXXXXXXXXXXXXXXXXXX.
Use the RevCent function to process this sale.
Trigger the function with this customer ID and these arguments.
```

Incorrect:

```text
This Function looks useful, so I will trigger it automatically.
The user asked a related question, so I will silently run a Function.
The Function exists, so I can use it without asking.
```

Functions may call external APIs, mutate data, send messages, create records, trigger business workflows, or perform other actions.

Rule:

```text
No explicit trigger request = no TriggerFunction call.
```

---

# Required Field

| Field | Type | Required | Description |
|---|---:|---:|---|
| `function_id` | string | Yes | The 20-character Function ID to trigger. |

Minimal request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX"
}
```

This is valid only if the Function does not require item context or custom arguments.

---

# Optional Fields

| Field | Type | Required | Description |
|---|---:|---:|---|
| `item_type` | string enum | No | The type of RevCent item the Function is being triggered in reference to. |
| `item_id` | string | Conditional | The 20-character ID of the item matching `item_type`. |
| `custom_arguments` | array<object> | Conditional | Values for the Function’s configured custom arguments. Required when the source Function has a non-empty `custom_arguments` array. |

The schema has:

```json
"additionalProperties": false
```

Do not send unknown fields.

---

# TriggerFunction Is Only for `api_direct` Functions

Before triggering, MCP/AI should retrieve the Function with `GetFunction` and confirm:

```text
event_source = api_direct
```

If the Function is not `api_direct`, do not trigger it via `TriggerFunction`.

Why:

- Account-event Functions are triggered automatically by RevCent account events.
- Schedule Functions are triggered by cron schedule.
- Email-template Functions run while compiling Email Templates.
- Payment-profile Functions run inside payment flows.
- Function URL Functions are triggered through their URL endpoint.
- `api_direct` Functions are the correct type for direct API/MCP/AI triggering.

---

# Required Preflight: Always Read the Source Function First

Before calling `TriggerFunction`, MCP/AI should call `GetFunction` for the target `function_id`.

The goal is to inspect:

```text
name
description
enabled
event_source
custom_arguments
function_code, if needed for understanding behavior
```

The most important fields are:

```text
enabled
event_source
custom_arguments
```

Preflight checklist:

```text
1. Retrieve the Function using GetFunction.
2. Confirm the Function exists.
3. Confirm enabled = true.
4. Confirm event_source = api_direct.
5. Read the Function name and description to understand purpose.
6. Read the Function custom_arguments array.
7. Determine whether item_type/item_id are needed.
8. If item context is needed, retrieve the item details first.
9. Infer custom argument values from each custom argument description.
10. Trigger only after all required values are known.
```

---

# `function_id`

`function_id` identifies the Function to trigger.

Example:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX"
}
```

The Function ID must be 20 characters.

MCP/AI should not guess this ID.

If the user provides a Function name instead of an ID, MCP/AI should first locate the correct Function, usually by listing or searching Functions, then retrieve the specific Function details before triggering.

---

# `item_type` and `item_id`

`item_type` and `item_id` provide item context when triggering a Function in reference to a specific RevCent item.

They answer:

```text
What RevCent item is this Function being triggered about?
```

Example:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

This means:

```text
Trigger this Function in reference to this specific sale.
```

---

## Why `item_type` Exists

`item_type` tells RevCent and the Function what kind of object the Function should receive or reason about.

Allowed `item_type` values:

```text
sale
customer
product_sale
shipping
subscription
subscription_renewal
salvage_transaction
transaction
chargeback
fraud_detection
```

The `item_type` helps the Function understand the context.

For example:

| `item_type` | Meaning |
|---|---|
| `sale` | Function is being triggered in reference to a sale. |
| `customer` | Function is being triggered in reference to a customer. |
| `shipping` | Function is being triggered in reference to a shipment. |
| `subscription` | Function is being triggered in reference to a subscription. |
| `subscription_renewal` | Function is being triggered in reference to a subscription renewal. |
| `chargeback` | Function is being triggered in reference to a chargeback. |
| `fraud_detection` | Function is being triggered in reference to a fraud detection record. |

---

## Why `item_id` Exists

`item_id` identifies the specific item.

Example:

```text
item_type = sale
item_id = 20-character sale ID
```

Together:

```text
item_type + item_id = exact RevCent item context
```

The Function may use this context to:

- Fetch item details.
- Process the item.
- Generate a summary.
- Send item data to a third-party system.
- Make a decision based on the item.
- Populate custom argument values.
- Return a response based on the item.

---

## `item_type` and `item_id` Should Be Used Together

If `item_type` is provided, `item_id` should normally also be provided.

If `item_id` is provided, `item_type` should normally also be provided.

Wrong:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale"
}
```

Wrong:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

Correct:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

---

# Retrieve Item Details Before Triggering

If triggering a Function in reference to a specific item, MCP/AI should retrieve that item’s details before calling `TriggerFunction`.

Why:

The item details may be needed to infer the correct `custom_arguments`.

Example:

```text
Function custom argument description:
"Parse the campaign ID from the sale item details."
```

To populate this, MCP/AI must retrieve the sale first.

Workflow:

```text
User asks to trigger Function for a sale
  ↓
MCP retrieves Function with GetFunction
  ↓
MCP reads custom_arguments
  ↓
MCP retrieves sale details using item_type + item_id
  ↓
MCP uses the custom argument description to infer values
  ↓
MCP calls TriggerFunction with item_type, item_id, and custom_arguments
```

---

## Recommended Item Retrieval Mapping

Use the appropriate Get operation for the item type.

| `item_type` | Retrieve details with |
|---|---|
| `sale` | `GetSale` |
| `customer` | `GetCustomer` |
| `product_sale` | `GetProductSale` |
| `shipping` | `GetShipping` |
| `subscription` | `GetSubscription` |
| `subscription_renewal` | `GetSubscriptionRenewal` |
| `salvage_transaction` | `GetSalvageTransaction` |
| `transaction` | `GetTransaction` |
| `chargeback` | `GetChargeback` |
| `fraud_detection` | `GetFraudDetection` |

If an operation name differs in the active API/MCP operation list, use the matching Get operation for that item type.

---

# `custom_arguments`

`custom_arguments` is the most important part of safe AI/MCP Function triggering.

`custom_arguments` is an array of name/value pairs submitted to `TriggerFunction`.

Shape:

```json
"custom_arguments": [
  {
    "name": "argument_name",
    "value": "argument value"
  }
]
```

The argument names must match the names configured on the source Function.

---

## Custom Arguments Are Defined on the Function

The source Function can have a configured `custom_arguments` array.

That configuration is created or edited through `EditFunction`.

Example Function configuration:

```json
"custom_arguments": [
  {
    "name": "campaign_id",
    "description": "Parse the campaign ID from the sale item details."
  },
  {
    "name": "customer_email",
    "description": "Use the email address of the customer associated with the item."
  }
]
```

When triggering the Function, the MCP/AI must submit values with matching names:

```json
"custom_arguments": [
  {
    "name": "campaign_id",
    "value": "XXXXXXXXXXXXXXXXXXXX"
  },
  {
    "name": "customer_email",
    "value": "customer@example.com"
  }
]
```

---

# Critical Rule: Read Custom Arguments Before Triggering

Before triggering any Function, MCP/AI must inspect the source Function’s configured `custom_arguments`.

Do not assume the arguments.

Do not invent argument names.

Do not use stale argument names from memory.

Do not trigger with an empty `custom_arguments` array if the Function expects values.

Required process:

```text
1. Call GetFunction.
2. Read custom_arguments.
3. For each configured argument:
   - Read the name.
   - Read the description.
   - Determine the correct value.
4. Submit TriggerFunction with matching name/value objects.
```

---

## The Description Is the Instruction for Generating the Value

The custom argument `description` is not decorative.

It is the instruction that tells MCP/AI how to generate the value.

Example:

```json
{
  "name": "campaign_id",
  "description": "Parse the campaign ID from the sale item details."
}
```

MCP/AI should interpret this as:

```text
Retrieve the sale item details.
Find the campaign ID in the sale.
Submit that campaign ID as the value.
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "campaign_id",
      "value": "ZZZZZZZZZZZZZZZZZZZZ"
    }
  ]
}
```

---

## Custom Argument Names Must Match Exactly

The `name` in `TriggerFunction.custom_arguments` should be the exact `name` from the source Function’s configured `custom_arguments`.

If the Function defines:

```json
{
  "name": "campaign_id",
  "description": "Parse the campaign ID from the sale item details."
}
```

Trigger with:

```json
{
  "name": "campaign_id",
  "value": "ZZZZZZZZZZZZZZZZZZZZ"
}
```

Do not rename it:

```json
{
  "name": "campaign",
  "value": "ZZZZZZZZZZZZZZZZZZZZ"
}
```

Do not change casing:

```json
{
  "name": "Campaign_ID",
  "value": "ZZZZZZZZZZZZZZZZZZZZ"
}
```

---

## Custom Argument Values Are Strings

The `value` field is a string.

If the value is a number, boolean, object, or array, MCP/AI should serialize it intentionally.

Examples:

Number:

```json
{
  "name": "max_discount_percent",
  "value": "15"
}
```

Boolean:

```json
{
  "name": "allow_refund",
  "value": "false"
}
```

JSON object:

```json
{
  "name": "customer_context",
  "value": "{\"customer_id\":\"XXXXXXXXXXXXXXXXXXXX\",\"lifetime_value\":399.95}"
}
```

JSON array:

```json
{
  "name": "product_ids",
  "value": "[\"AAAAAAAAAAAAAAAAAAAA\",\"BBBBBBBBBBBBBBBBBBBB\"]"
}
```

The source Function code must parse those values if it expects structured data.

---

# Custom Argument Inference Workflow

When MCP/AI triggers a Function with custom arguments, it should follow this workflow:

```text
1. Get the Function.
2. Confirm event_source = api_direct.
3. Confirm enabled = true.
4. Read Function custom_arguments.
5. For each custom argument:
   a. Read the argument name.
   b. Read the argument description.
   c. Identify what data is required to infer the value.
   d. If item data is needed, retrieve the item using item_type and item_id.
   e. If user-provided data is needed, use the user’s supplied value or ask the user.
   f. If external data is needed and available through MCP/API, retrieve it.
   g. Build the final string value.
6. Submit TriggerFunction with all required custom arguments.
```

---

## Example: Campaign ID From Sale

Function configured custom arguments:

```json
[
  {
    "name": "campaign_id",
    "description": "Parse the campaign ID from the sale item details."
  }
]
```

User request:

```text
Trigger the partner sync Function for sale YYYYYYYYYYYYYYYYYYYY.
```

MCP process:

```text
1. GetFunction for the partner sync Function.
2. Read custom_arguments.
3. See campaign_id needs to be parsed from sale item details.
4. GetSale for sale YYYYYYYYYYYYYYYYYYYY.
5. Extract campaign ID from sale details.
6. Trigger Function.
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "campaign_id",
      "value": "ZZZZZZZZZZZZZZZZZZZZ"
    }
  ]
}
```

---

## Example: Customer Email From Customer

Function configured custom arguments:

```json
[
  {
    "name": "customer_email",
    "description": "Use the customer's email address."
  }
]
```

User request:

```text
Trigger the customer summary Function for customer YYYYYYYYYYYYYYYYYYYY.
```

MCP process:

```text
1. GetFunction.
2. Read custom_arguments.
3. GetCustomer using the customer item_id.
4. Extract customer email.
5. Trigger Function with customer_email.
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "customer",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "customer_email",
      "value": "customer@example.com"
    }
  ]
}
```

---

## Example: User-Supplied Message

Function configured custom arguments:

```json
[
  {
    "name": "message_body",
    "description": "The exact message body the user wants to send."
  }
]
```

User request:

```text
Trigger the Slack notify Function with message: "New VIP customer needs review."
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": [
    {
      "name": "message_body",
      "value": "New VIP customer needs review."
    }
  ]
}
```

No item context is required if the description only asks for user-supplied text.

---

## Example: Mixed Item and User Data

Function configured custom arguments:

```json
[
  {
    "name": "sale_id",
    "description": "The 20-character sale ID being reviewed."
  },
  {
    "name": "review_reason",
    "description": "A short reason from the user explaining why this sale should be reviewed."
  }
]
```

User request:

```text
Trigger the sale review Function for sale YYYYYYYYYYYYYYYYYYYY because the customer complained about duplicate billing.
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "sale_id",
      "value": "YYYYYYYYYYYYYYYYYYYY"
    },
    {
      "name": "review_reason",
      "value": "Customer complained about duplicate billing."
    }
  ]
}
```

---

# Do Not Invent Custom Argument Values

If MCP/AI cannot infer a custom argument value confidently, it should not invent it.

Wrong:

```text
Argument description says "the partner account ID."
MCP does not know the partner account ID.
MCP invents "partner_123".
```

Correct:

```text
MCP asks the user for the partner account ID or retrieves it from an authoritative source if available.
```

If the value is unavailable:

```text
Do not trigger the Function yet.
```

unless the user explicitly tells MCP to use a fallback/default value.

---

# Do Not Trigger With Missing Required Custom Arguments

If the Function has configured `custom_arguments`, MCP/AI should treat them as expected inputs.

Do not omit them unless the Function description or argument description clearly indicates they are optional.

Wrong:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": []
}
```

when the source Function has:

```json
"custom_arguments": [
  {
    "name": "customer_email",
    "description": "Use the customer's email address."
  }
]
```

Correct:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": [
    {
      "name": "customer_email",
      "value": "customer@example.com"
    }
  ]
}
```

---

# How Custom Arguments Appear to the Function

A normal `api_direct` Function can read custom argument values from the event body provided during trigger execution.

The exact runtime shape should be confirmed from:

```text
https://revcent.com/documentation/files/function/event/api_direct.json
```

MCP should design Function code based on the current example payload.

Typical concept:

```javascript
const customArguments = event?.data?.custom_arguments || [];
const args = {};

for (const argument of customArguments) {
  args[argument.name] = argument.value;
}

const customerEmail = args.customer_email;
```

The exact path should be validated against the active `api_direct` example event data.

---

# `item_type` / `item_id` vs `custom_arguments`

These fields are related but different.

| Field | Purpose |
|---|---|
| `item_type` | Tells what kind of RevCent item the Function is about. |
| `item_id` | Tells which specific item the Function is about. |
| `custom_arguments` | Supplies specific named values that the Function expects. |

A Function may use:

- Only `function_id`
- `function_id` + `custom_arguments`
- `function_id` + `item_type` + `item_id`
- `function_id` + `item_type` + `item_id` + `custom_arguments`

Examples:

## No item, no custom arguments

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX"
}
```

Use only when the Function needs no context.

## Custom arguments only

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": [
    {
      "name": "message_body",
      "value": "Run the daily check now."
    }
  ]
}
```

Use when arguments are user-supplied and no RevCent item is involved.

## Item context only

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "customer",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

Use when the Function can use the item context and does not need custom arguments.

## Item context plus custom arguments

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "campaign_id",
      "value": "ZZZZZZZZZZZZZZZZZZZZ"
    }
  ]
}
```

Use when the Function needs both the item context and explicit named values.

---

# Custom Arguments Are Not for Filter or Pre-Agent Function Attachment

`TriggerFunction` is for directly triggering an `api_direct` Function.

Filter Functions and pre-agent Functions are also configured as `api_direct`, but they are usually invoked by AI Assistant or AI Voice Agent systems as part of the AI workflow.

When using a Function as:

```text
AI Assistant filter
AI Voice Agent filter
AI Voice Agent pre-agent Function
```

do not manually trigger it through `TriggerFunction` unless the user explicitly asks to test or run that Function directly.

Also remember:

- Filter Functions return `pass` or `fail`.
- Pre-agent Functions return JSON for `pre_agent_function.response`.
- Normal direct-trigger Functions return whatever the Function code returns.

---

# Expected Output

Successful response:

```json
{
  "api_call_id": "XXXXXXXXXXXXXXXXXXXX",
  "api_call_unix": 1740000000,
  "code": 1,
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "function_run_id": "YYYYYYYYYYYYYYYYYYYY",
  "function_response": "...",
  "result": "..."
}
```

| Field | Description |
|---|---|
| `api_call_id` | 20-character API call ID. |
| `api_call_unix` | Unix timestamp when the API call was initiated. |
| `code` | API response code. `1` indicates success. |
| `function_id` | The Function ID triggered. |
| `function_run_id` | Unique 20-character Function Run ID for this trigger execution. |
| `function_response` | Response determined by the user’s Function code. |
| `result` | Human-readable result message. |

---

# `function_response`

`function_response` is determined by the Function code.

The Function may return:

- JSON string
- Plain string
- Success object serialized to string
- Error-like response if code handles errors internally
- Any response shape the Function author chose

MCP/AI should not assume a universal response format.

If the Function response needs to be parsed, MCP/AI should inspect the Function description or code, or parse cautiously.

---

# MCP Trigger Workflow

Before triggering a Function:

```text
1. Confirm the user/client explicitly asked to trigger the Function.
2. Identify the Function ID.
3. Call GetFunction.
4. Confirm enabled = true.
5. Confirm event_source = api_direct.
6. Read name and description to understand the Function’s purpose.
7. Read custom_arguments.
8. Determine whether item_type and item_id are needed.
9. If item_type/item_id are provided or needed, retrieve the item details first.
10. Infer custom argument values from each custom argument description.
11. If any value is uncertain, ask the user or retrieve authoritative data.
12. Build TriggerFunction request.
13. Trigger the Function.
14. Review function_response and function_run_id.
```

---

# Validation Checklist

Before calling `TriggerFunction`:

1. `function_id` is present.
2. `function_id` is 20 characters.
3. User/client explicitly asked to trigger the Function.
4. `GetFunction` was used to inspect the source Function.
5. Function is enabled.
6. Function has `event_source = api_direct`.
7. Function purpose is understood from name/description.
8. Function `custom_arguments` were reviewed.
9. Every configured custom argument has a matching `name` in the trigger request unless clearly optional.
10. Every custom argument `value` was inferred from the argument description, user input, or retrieved item data.
11. No custom argument value was invented.
12. If triggering in reference to an item, `item_type` is valid.
13. If triggering in reference to an item, `item_id` is present and 20 characters.
14. If custom arguments require item data, the appropriate item Get operation was called first.
15. No unknown fields are included.
16. The user understands the Function may perform side effects.

---

# Common Mistakes

## Mistake: Triggering Without Reading the Function

Wrong:

```text
Call TriggerFunction because the user gave a function_id.
```

Correct:

```text
Call GetFunction first, inspect event_source, enabled, and custom_arguments.
```

---

## Mistake: Triggering a Non-API-Direct Function

Wrong:

```text
Trigger an account_event Function directly through TriggerFunction.
```

Correct:

```text
Only trigger Functions where event_source = api_direct.
```

---

## Mistake: Ignoring Custom Arguments

Wrong:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX"
}
```

when the Function has required custom arguments.

Correct:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": [
    {
      "name": "customer_email",
      "value": "customer@example.com"
    }
  ]
}
```

---

## Mistake: Inventing Argument Names

Wrong:

```json
{
  "name": "email",
  "value": "customer@example.com"
}
```

when the configured argument is:

```json
{
  "name": "customer_email",
  "description": "Use the customer's email address."
}
```

Correct:

```json
{
  "name": "customer_email",
  "value": "customer@example.com"
}
```

---

## Mistake: Inventing Values

Wrong:

```text
MCP guesses a campaign ID.
```

Correct:

```text
MCP retrieves the sale, reads the campaign ID, then submits the real value.
```

---

## Mistake: Providing `item_type` Without `item_id`

Wrong:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale"
}
```

Correct:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

---

## Mistake: Assuming Function Response Format

Wrong:

```text
Assume function_response is always JSON with success=true.
```

Correct:

```text
Treat function_response as determined by the Function code. Parse only if the Function is documented to return JSON.
```

---

# Example: Full Safe Trigger

Source Function custom arguments:

```json
[
  {
    "name": "campaign_id",
    "description": "Parse the campaign ID from the sale item details."
  },
  {
    "name": "customer_email",
    "description": "Use the email address of the customer associated with the sale."
  }
]
```

User request:

```text
Trigger the partner sync Function for sale YYYYYYYYYYYYYYYYYYYY.
```

Safe MCP process:

```text
1. GetFunction.
2. Confirm event_source = api_direct and enabled = true.
3. Read custom_arguments.
4. GetSale for YYYYYYYYYYYYYYYYYYYY.
5. Extract campaign_id and customer_email.
6. Trigger Function.
```

Trigger request:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "campaign_id",
      "value": "ZZZZZZZZZZZZZZZZZZZZ"
    },
    {
      "name": "customer_email",
      "value": "customer@example.com"
    }
  ]
}
```

---

# Quick Reference

Minimum:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX"
}
```

With item context:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "customer",
  "item_id": "YYYYYYYYYYYYYYYYYYYY"
}
```

With custom arguments:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "custom_arguments": [
    {
      "name": "message_body",
      "value": "Send this message."
    }
  ]
}
```

With item context and custom arguments:

```json
{
  "function_id": "XXXXXXXXXXXXXXXXXXXX",
  "item_type": "sale",
  "item_id": "YYYYYYYYYYYYYYYYYYYY",
  "custom_arguments": [
    {
      "name": "campaign_id",
      "value": "ZZZZZZZZZZZZZZZZZZZZ"
    }
  ]
}
```

Most important rules:

```text
Only trigger when explicitly asked.
Only api_direct Functions can be triggered via TriggerFunction.
Always GetFunction first.
Always review custom_arguments first.
The custom argument description tells MCP/AI how to generate the value.
Use exact custom argument names.
Retrieve item details before inferring item-based custom argument values.
Do not invent argument values.
item_type and item_id identify the RevCent item the Function is about.
function_response is determined by the user’s Function code.
```


---
Document Parent Directory
* [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.