Skip to main content
These examples combine natural language prompts with the tool sequence needed to answer accurately. Replace example IDs with values returned by your workspace. The prompts are starting points; the assistant still needs to interpret dates and inspect the actual results.

​
Find newly added buyers

Use search_buyers with created_at boundaries. Read total for the number of matching buyer records. To limit the query to buyers that currently have website signals, add website_signal_count > 0; to establish their initial source, inspect first_signal_type in the returned buyer records. A buyer created this week may have an initial signal from an earlier date. If the question is about visits during the week, use the next workflow.

​
Find buyers with website activity

  1. Call get_workspace to establish the workspace time zone.
  2. Call search_signals with signal_type = website and signal_at date boundaries.
  3. Continue through the required signal pages with the same filter.
  4. Group signals by buyer_id and count the matching activity for each buyer.
  5. Call get_buyer for each relevant buyer and inspect created_at to identify new records.
If the question is specifically about page visits, also add trigger = visited_page. Website signals can otherwise include form submissions and abandoned forms.

​
Investigate visits from ads

Search website signals for the period, then inspect: A source platform alone does not establish paid traffic: Google can be organic, and LinkedIn can be social. Report the attribution and evidence the signal actually contains. A click identifier is evidence to investigate, not a blanket guarantee of paid attribution for every platform. Signal search has filters for UTM and click-ID values, but it does not expose a general “has click ID” or visit-attribution-type filter. Do not simulate an existence filter with an empty text value. For a complete platform breakdown, inspect the full matching set within a practical date range. These results describe the website signals recorded by 1eye. Missing tags, unavailable identifiers, or direct attribution limit what can be concluded about the original acquisition source.

​
Review a target list

Call list_target_lists, then get_target_list for the chosen ID. To read its buyers, use:
The current MCP tools read target lists and their buyers. Create lists or change list membership through the supported 1eye app workflow.

​
Diagnose a destination

Use list_destinations, get_destination, then get_destination_console:
The console returns one row per buyer’s latest delivery status. Its total, pushed, pending, failed, and removed counts cover all buyers, regardless of the status filter or page. Read those counters for the summary and the returned rows for examples.

​
Review credit use

Call get_usage with {"month":"2026-10"} and get_billing with {}. Usage months are calendar months in UTC. Keep that boundary explicit when comparing usage with a report in another time zone. Billing tools retrieve information. Purchasing credits and changing the plan are actions in the 1eye app.

​
Prepare a configuration change

First call get_signal_settings. After reviewing the current settings and obtaining confirmation, the change arguments are:
Call update_signal_settings only after approval, then inspect its returned settings. Only supplied fields change. This cap concerns new buyers per day, not a maximum number of website visits.