Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

meta_ads_pixels_create

Create a Meta Pixel on your ad account to track website conversions and receive the new pixel ID for installing the tracking code.

Instructions

Creates a new Meta Pixel on the ad account. Returns the new pixel id. Mutating — not automatically reversible; pixels cannot be deleted via the Graph API once created, so record before-state with mureo_state_action_log_append if you may need to audit the change. Call meta_ads_pixels_list first to check for an existing pixel — ad accounts have a pixel limit, and reusing an existing pixel is almost always preferable to creating a duplicate. After creation, install the pixel's code on the site and use meta_ads_pixels_stats / events to confirm it is firing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPixel name shown in Events Manager. Pick something descriptive (e.g. the site or brand) so it is easy to identify later.
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.
account_idNoMeta Ads account ID in the format 'act_XXXXXXXXXX' (e.g. 'act_1234567890'). Optional — falls back to META_ADS_ACCOUNT_ID from the configured credentials. The leading 'act_' prefix is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
+  "maxLength": 500,
+  "type": "string"
+}
  2. Addedv0.10.37

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description fully carries the behavioral burden. It explicitly discloses that the call is mutating, not automatically reversible, and that pixels cannot be deleted via the Graph API once created. It also flags the pixel-limit constraint and the need to record before-state for auditability, which are exactly the kind of consequences an agent needs to know before invoking a mutating tool.

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?

The description is compact and front-loaded: purpose and return value first, then irreversibility, then pre-flight check, then post-creation verification. Every sentence carries operationally important information with no fluff or repetition, earning its place despite the length.

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

Completeness5/5

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

The description covers what the tool returns, its mutating and irreversible nature, an important account-level constraint (pixel limit), the recommended pre-check, a possible audit step, and post-creation verification. There is no output schema, but the return value is explicitly stated, so an agent has everything necessary to decide, invoke, and validate this tool correctly.

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?

The input schema already covers all three parameters with 100% description coverage, including the act_ prefix requirement for account_id and the fallback behavior. The description adds general context about the pixel lifecycle but does not add parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Creates a new Meta Pixel on the ad account,' and immediately states the return value ('Returns the new pixel id'). It also distinguishes this creation tool from related pixel tools by naming meta_ads_pixels_list, meta_ads_pixels_stats, and meta_ads_pixels_events, so an agent can tell creation, listing, and verification apart.

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

Usage Guidelines5/5

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

Gives explicit workflow guidance: call meta_ads_pixels_list first to check for an existing pixel, note that reusing an existing pixel is almost always preferable, and afterwards install the code and use meta_ads_pixels_stats/events to confirm firing. It also recommends an audit side-action (mureo_state_action_log_append) if the change may need to be traced, making when and how to use the tool very clear.

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