Skip to main content
Glama
Sign In
meta-ads-mcp

meta-ads-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

send_offline_event

Send offline conversion events to a Meta dataset via Conversions API, using action_source=physical_store for store events.

Instructions

Send offline conversion events through the Conversions API to a dataset. Store events must use action_source=physical_store.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "event_set_id": "<event_set_id>",
      "events": "<events>"
    },
    "name": "send_offline_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
eventsYesJSON array of offline events
event_set_idYesDataset ID for offline events (legacy parameter name retained)
test_event_codeNoEvents Manager test code; use to verify delivery as test events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.1
    • changedInput schema / properties / event_set_id / description
      Previous value: -"Offline event set ID"New value: +"Dataset ID for offline events (legacy parameter name retained)"
    • addedInput schema / properties / test_event_code
      Added value: +{
+  "description": "Events Manager test code; use to verify delivery as test events",
+  "type": "string"
+}
  2. First observedv1.2.0

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It adds one real behavioral rule not found in the schema (the action_source=physical_store requirement for store events), but is silent on permissions, batch/size limits, deduplication, and error behavior for what is a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, no filler, with the core action stated first and the constraining rule second. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description covers the essential targeting and one constraint but omits anything about the response, success/failure behavior, or delivery verification beyond the schema's test_event_code. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so event_set_id, events, and test_event_code are already documented. The description adds only a loose reference to 'a dataset' for event_set_id and no detail on the events JSON structure or test_event_code semantics, so it matches the baseline rather than adding value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (send), resource (offline conversion events), and mechanism/destination (Conversions API to a dataset), which separates it from the create/list offline-event-set siblings. It does not explicitly name or contrast the close sibling send_conversion_event, so sibling differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a concrete usage rule for store events (action_source=physical_store), which is a genuine usage constraint. However, it never says when to use this tool versus send_conversion_event, nor does it state prerequisites such as the dataset having to already exist or the required access.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools