> ## Documentation Index
> Fetch the complete documentation index at: https://developers.everflow.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Agentic Examples

> End-to-end multi-step workflows using the Everflow MCP Server.

These examples show how an AI agent orchestrates multiple tools in sequence to answer questions that would otherwise require several API calls and manual correlation. Each example includes the prompt you'd send and what the agent does behind the scenes.

***

## Diagnose a traffic drop

A partner reports that their click volume dropped sharply yesterday. You want to know whether it's a tracking issue, a cap being hit, or a real traffic problem.

**Prompt:**

> "Affiliate 142 had significantly fewer clicks yesterday compared to the day before. Can you figure out what happened?"

**What the agent does:**

1. Calls `run_performance_report` with `dimensions=date,affiliate`, filtered to affiliate 142, comparing yesterday vs. the prior day
2. Calls `get_affiliate` with `include=activity` to check portal login recency and API usage
3. Calls `get_offer` with `include=caps` for the affiliate's top offer to check whether a daily click cap was hit
4. Summarizes the findings: volume drop confirmed, cap exhausted at 14:32 UTC, suggests raising the cap or splitting traffic across offers

***

## Partner health check

You want a quick health summary for your top 5 affiliates before a weekly review call.

**Prompt:**

> "Give me a health summary for my top 5 affiliates by revenue this month. Flag anyone with declining performance or low portal activity."

**What the agent does:**

1. Calls `run_performance_report` with `dimensions=affiliate`, date range = current month, sorted by `revenue` descending, `page_size=5`
2. For each affiliate, calls `get_affiliate` with `include=activity` to fetch last login date, login frequency, and API call volume
3. Calls `run_performance_report` again with the prior month for comparison
4. Returns a table: affiliate name, this month's revenue vs. last month, % change, last login date — flagging any with >20% revenue decline or no login in 14+ days

***

## Compare a specific set of offers

You want a side-by-side performance comparison of a handful of specific offers — not your whole account.

**Prompt:**

> "Compare clicks, conversions, and revenue for offers 12, 45, and 78 this month."

**What the agent does:**

1. Calls `run_performance_report` once with `dimensions=offer` and `filters=offer:12|45|78` — the pipe-separated values match all three offers in a single query
2. Returns a per-offer table of clicks, conversions, and revenue

Using one multi-value filter (`offer:12|45|78`) keeps this to a single call. Without it, the agent would run a separate report per offer and stitch the results together. The same works for any ID filter — e.g. `affiliate:7|14` or `advertiser:13|26`.

***

## Investigate a disputed conversion

An advertiser disputes a conversion and claims the order was never placed. You need to trace the full event chain.

**Prompt:**

> "Advertiser says conversion conv\_a1b2c3d4 is fraudulent. Can you pull the full picture?"

**What the agent does:**

1. Calls `get_entity` with `type="conversion"`, `id=conv_a1b2c3d4` — retrieves payout, affiliate, sub parameters, adv parameters, geo, device, order ID, and the originating transaction ID
2. Calls `get_entity` with `type="transaction"` and the transaction ID from step 1 — pulls the whole chain in one call: the originating click (IP, device, referrer, timestamp, unique flag), sibling conversions with their `attribution_method`, pixel-fire logs, and any on-hold conversions
3. Calls `search_activity` with `type="conversion"` filtered to the same affiliate and order ID to check for duplicate conversions on the same order
4. Returns a consolidated timeline: click at 09:14 UTC from IP 203.x.x.x (US, Chrome/iOS), conversion fired 4 minutes later, no duplicate order IDs found, `is_scrub` is false — suggests legitimate attribution

***

## Payout audit for a period

Finance needs to reconcile affiliate payouts for last month before processing invoices.

**Prompt:**

> "Summarize total payouts by affiliate for March 2026, and flag anyone whose payout exceeded \$10,000."

**What the agent does:**

1. Calls `run_performance_report` with `dimensions=affiliate`, date range = March 2026, sorted by `payout` descending
2. Filters the results client-side to flag affiliates where `payout > 10000`
3. For each flagged affiliate, calls `get_affiliate` to retrieve their name, tier, and account manager
4. Returns a ranked table with affiliate name, total payout, account manager, and a flag indicator — ready to paste into a finance report

***

## Offer readiness check

You're about to launch a new offer and want to verify that caps, targeting, and at least one affiliate are properly configured before going live.

**Prompt:**

> "Is offer 88 ready to launch? Check caps, targeting, and whether any affiliates are set up to run it."

**What the agent does:**

1. Calls `get_offer` with `include=caps,targeting,affiliates` for offer 88
2. Checks: at least one payout event exists, global click cap is set, at least one country is targeted, at least one affiliate has visibility
3. Calls `get_affiliate` on the first visible affiliate with `include=activity` to confirm they're an active partner
4. Returns a readiness checklist: payout configured ✓, targeting set to US/CA ✓, 3 affiliates visible ✓, primary affiliate last active 2 days ago ✓ — offer is ready to activate

***

## Full trace: diagnose a blocked click

The examples above describe agent behavior in prose. This example shows the **actual tool calls and abbreviated responses** at each step, so you can see exactly what parameters are passed and what the agent works with.

**Prompt:**

> "Transaction abc123def456abc123def456abc123de is showing error code 6 for affiliate 142. What happened?"

<Steps>
  <Step title="Look up the click">
    Tool: `get_entity` (`type="click"`)

    ```json theme={null}
    {
      "type": "click",
      "id": "abc123def456abc123def456abc123de"
    }
    ```

    Key fields from the response:

    ```json theme={null}
    {
      "transaction_id": "abc123def456abc123def456abc123de",
      "timestamp": "2026-05-20 14:23:11",
      "offer_id": 88,
      "offer_name": "Spring Sale — US",
      "affiliate_id": 142,
      "affiliate_name": "MediaPartner Inc.",
      "error_code": 6,
      "error_message": "Affiliate not approved for offer",
      "is_unique": false,
      "country": "US"
    }
    ```
  </Step>

  <Step title="Resolve the error code">
    Tool: `get_entity`

    ```json theme={null}
    {
      "type": "click_error_code",
      "id": "6"
    }
    ```

    Response confirms: the click was blocked because the affiliate has not been approved to run this offer.
  </Step>

  <Step title="Check the affiliate's approval status on the offer">
    Tool: `get_offer`

    ```json theme={null}
    {
      "offer_id": 88,
      "affiliate_id": 142,
      "include": "affiliate,targeting"
    }
    ```

    Key fields from the response:

    ```json theme={null}
    {
      "offer_id": 88,
      "name": "Spring Sale — US",
      "status": "active",
      "affiliate": {
        "status": "pending",
        "visibility": "require_approval"
      },
      "targeting": {
        "countries": ["US", "CA"]
      }
    }
    ```
  </Step>
</Steps>

**Agent summary:** Affiliate 142 (MediaPartner Inc.) sent traffic to offer 88 while their approval was still `pending`. Offer 88 uses `require_approval` visibility — all affiliates need explicit approval before traffic is accepted. To resolve: approve affiliate 142 for offer 88 in **Control Center → Offers → \[Offer 88] → Affiliates**.
